Pourquoi chmod (1) sur le groupe affecte-t-il le masque ACL?

J'essaie de comprendre ce comportement Unix (que je teste sur Ubuntu 11.10):

$ touch foo
$ setfacl -m u:nobody:rwx foo
$ getfacl foo
# file: foo
# owner: michael
# group: michael
user::rw-
user:nobody:rwx
group::rw-
mask::rwx
other::r--

$ chmod g-rw foo
$ getfacl foo
# file: foo
# owner: michael
# group: michael
user::rw-
user:nobody:rwx         #effective:--x
group::rw-          #effective:---
mask::--x
other::r--

Notez que la commande chmod (1) a mis à jour le masque ACL. Pourquoi cela arrive-t-il?

La page de manuel SunOS contient les informations suivantes:

Si vous utilisez la commande chmod (1) pour modifier les autorisations de propriétaire de groupe de fichiers sur un fichier avec des entrées ACL, les autorisations de propriétaire de groupe de fichiers et le masque ACL sont modifiés pour les nouvelles autorisations. N'oubliez pas que les nouvelles autorisations de masque ACL peuvent modifier les autorisations effectives pour les utilisateurs et groupes supplémentaires qui ont des entrées ACL dans le fichier.

Je demande parce que ce serait pratique pour moi si chmod (1) n'avait pas ce comportement. J'espère qu'en comprenant pourquoi il fait ce qu'il fait, je peux mieux concevoir la façon dont je configure les autorisations du système de fichiers.

Ce ne serait pas pratique pour vous si vous chmod()n'aviez pas ce comportement.

Ce serait très gênant, car les choses que les gens s'attendent traditionnellement à travailler sur Unix se briseraient. Ce comportement vous sert bien, ne le saviez-vous pas?

Il est dommage que IEEE 1003.1e ne soit jamais devenu une norme et ait été retiré en 1998. En pratique, quatorze ans plus tard, c'est une norme qu'une large gamme de systèmes d'exploitation - de Linux à FreeBSD en passant par Solaris - implémentent réellement.

Le projet de travail n ° 17 de l'IEEE 1003.1e rend la lecture intéressante, et je le recommande. Dans l'annexe B § 23.3, le groupe de travail fournit une justification détaillée de huit pages pour la manière quelque peu complexe que les ACL POSIX fonctionnent en ce qui concerne les anciens S_IRWXGdrapeaux d'autorisation de groupe. (Il convient de noter que les personnes TRUSIX ont fourni à peu près la même analyse dix ans plus tôt.) Je ne vais pas tout copier ici. Lisez la justification dans le projet de norme pour plus de détails. Voici un très bref précis :

• Le manuel SunOS est incorrect. Il faut lire

  Si vous utilisez la chmod(1)commande pour modifier les permissions du propriétaire du groupe de fichiers sur un fichier avec les entrées ACL, soit les permissions du propriétaire du groupe de fichiers ou le masque ACL sont modifiés pour les nouvelles autorisations.

  C'est le comportement que vous pouvez voir se produire , malgré ce que dit la page de manuel actuelle, dans votre question. C'est également le comportement spécifié par le projet de norme POSIX. Si une entrée de contrôle d'accès CLASS_OBJ(terminologie de Sun et TRUSIX pour ACL_MASK) existe, les bits de groupe d'un la chmod()définissent, sinon ils définissent l' GROUP_OBJentrée de contrôle d'accès.

• Si ce n'était pas le cas, les applications qui ont fait diverses choses standard avec `chmod ()`, s'attendant à ce qu'il fonctionne comme `chmod ()` a traditionnellement travaillé sur les anciens Unix non-ACL, laisseraient des trous de sécurité béants ou verraient ce que ils pensent être des trous de sécurité béants:

  • Les applications Unix traditionnelles s'attendent à pouvoir refuser tout accès à un fichier, un canal nommé, un périphérique ou un répertoire avec chmod(…,000). En présence d'ACL, cela désactive uniquement toutes les autorisations des utilisateurs et des groupes si l'ancien S_IRWXGcorrespond à CLASS_OBJ. Sans cela, la définition des anciennes autorisations de fichier 000n'affecterait aucune entrée USERou GROUPet les autres utilisateurs auraient, de manière surprenante, toujours accès à l'objet.

    Changer temporairement les bits d'autorisation d'un fichier pour ne plus y avoir accès chmod 000, puis les modifier à nouveau était un ancien mécanisme de verrouillage de fichier, utilisé avant qu'Unixes n'ait acquis des mécanismes de verrouillage consultatifs, que - comme vous pouvez le voir - les gens utilisent encore aujourd'hui .

  • Les scripts Unix traditionnels s'attendent à pouvoir s'exécuter chmod go-rwxet se retrouver avec uniquement le propriétaire de l'objet en mesure d'accéder à l'objet. Encore une fois - comme vous pouvez le voir - c'est toujours la sagesse reçue douze ans plus tard. Et encore une fois, cela ne fonctionne pas à moins que les anciennes S_IRWXGcartes de CLASS_OBJsi elle existe, car sinon que la chmodcommande ne serait pas désactiver les USERou les GROUPentrées de contrôle d'accès, ce qui conduit à des utilisateurs autres que le propriétaire et les groupes non propriétaires en conservant un accès à quelque chose qui est devrait être accessible uniquement au propriétaire.

  • Un système dans lequel les bits d'autorisation étaient par ailleurs séparés des andlistes de contrôle d'accès et édités avec eux nécessiterait que les drapeaux d'autorisation de fichier soient rwxrwxrwxdans la plupart des cas, ce qui confondrait les nombreuses applications Unix qui se plaignent quand elles voient ce qu'elles pensent être accessible en écriture dans le monde entier. des trucs.

    Un système dans lequel les bits d'autorisation seraient autrement séparés et orédités avec les ACL aurait le chmod(…,000)problème mentionné précédemment.

Lectures complémentaires

• Winfried Trümper (1999-02-28). Résumé sur Posix.1e
• Comité des normes des applications portables de l'IEEE Computer Society (octobre 1997). Projet de norme pour les technologies de l'information - Interface du système d'exploitation portable (POSIX) - Partie 1: Interface du programme d'application du système (API) - Amendement n °: Interfaces de protection, d'audit et de contrôle [langage C] IEEE 1003.1e. Projet 17.
• Craig Rubin (1989-08-18). Justification de la sélection des fonctionnalités de la liste de contrôle d'accès pour le système Unix . NCSC-TG-020-A. Éditions DIANE. ISBN 9780788105548.

Ce comportement s'applique uniquement aux entrées POSIX ACL. La raison pour laquelle ceci est ici est que si vous avez un dossier et à l'intérieur de ce dossier existe un fichier, vous pouvez acl comme rwx (par exemple) le dossier et le fichier. Si les autorisations de groupe du fichier sont rw- (ce qui pourrait être un scénario typique), le masque donne donc à acl les autorisations effectives de rw- même si l'ACL désigne explicitement rwx.

D'un autre côté, le répertoire qui est presque toujours + x possède des autorisations de masque ACL efficaces permettant également + x.

En résumé, ce masque est essentiellement utilisé pour différencier les autorisations entre les fichiers et les dossiers pour l'ensemble ACL POSIX afin qu'un fichier ne devienne pas exécutable alors qu'il ne devrait normalement pas l'être.