Le truc, c'est que j'ai toujours pensé que ces autorisations s'effondraient les unes sur les autres, à commencer par la plus générale (autre -> groupe -> utilisateur).
Si c'était le cas, les «autres» autorisations s'appliqueraient à tout le monde.
En d'autres termes, si o = rwx, peu importe quelles sont les persmissions pour le groupe et l'utilisateur?
C'est différent de votre phrase précédente. Ici, vous sous-entendez que les autorisations sont combinées, par exemple, que userX a la permission de lecture si userX possède le fichier et que le fichier est lisible par l'utilisateur, ou si un groupe auquel appartient userX possède le fichier et le fichier est groupe -readable, ou si le fichier est lisible par un autre. Mais ce n'est pas comme ça que ça fonctionne. En fait, cela o=rwxsignifie que les rwxautorisations s'appliquent aux autres, mais cela ne dit rien sur les entités qui ne sont pas des autres.
Tout d'abord, peu importe à quels groupes un utilisateur appartient. Le noyau n'a pas la notion d'utilisateurs appartenant à des groupes. Ce que le noyau maintient est, pour chaque processus, un ID utilisateur (l' UID effectif ) et une liste d' ID de groupe (le GID effectif et les GID supplémentaires). Les groupes sont déterminés au moment de la connexion, par le processus de connexion - c'est le processus de connexion qui lit la base de données du groupe (par exemple /etc/group). Les ID utilisateur et groupe sont hérités par les processus enfants¹.
Lorsqu'un processus tente d'ouvrir un fichier, avec les autorisations Unix traditionnelles:
- Si l'utilisateur propriétaire du fichier est l'UID effectif du processus, les bits d'autorisation utilisateur sont utilisés.
- Sinon, si le groupe propriétaire du fichier est le GID effectif du processus ou l'un des ID de groupe supplémentaire du processus, les bits d'autorisation de groupe sont utilisés.
- Sinon, les autres bits d'autorisation sont utilisés.
Un seul ensemble de bits rwx est jamais utilisé. L'utilisateur a priorité sur le groupe qui a priorité sur les autres. Lorsqu'il existe des listes de contrôle d'accès , l'algorithme décrit ci-dessus est généralisé:
- S'il y a une ACL dans le fichier pour l'UID effectif du processus, elle est utilisée pour déterminer si l'accès est accordé.
- Sinon, s'il y a une ACL dans le fichier pour le GID effectif du processus ou l'un des ID de groupe supplémentaires du processus, alors les bits d'autorisation de groupe sont utilisés.
- Sinon, les autres bits d'autorisation sont utilisés.
Voir aussi Priorité d'ACLS lorsqu'un utilisateur appartient à plusieurs groupes pour plus de détails sur la façon dont les entrées ACL sont utilisées, y compris l'effet du masque.
-rw----r-- alice internsIndique ainsi un fichier qui peut être lu et écrit par Alice, et qui peut être lu par tous les autres utilisateurs à l'exception des stagiaires. Un fichier avec des autorisations et la propriété ----rwx--- alice internsest accessible uniquement aux stagiaires, sauf Alice (qu'elle soit stagiaire ou non). Étant donné qu'Alice peut appeler chmodpour modifier les autorisations, cela ne fournit aucune sécurité; c'est un cas de bord. Sur les systèmes avec ACL, le mécanisme généralisé permet de supprimer des autorisations d'utilisateurs ou de groupes spécifiques, ce qui est parfois utile.
L'utilisation d'un seul ensemble de bits, plutôt que de gérer tous les bits pour chaque action (lecture, écriture, exécution), présente plusieurs avantages:
- Il a pour effet utile de permettre la suppression des autorisations d'un ensemble d'utilisateurs ou de groupes, sur les systèmes avec ACL. Sur les systèmes sans ACL, les autorisations peuvent être supprimées d'un groupe.
- Il est plus simple à mettre en œuvre: vérifiez un ensemble de bits, plutôt que de combiner plusieurs ensembles de bits ensemble.
- Il est plus simple d'analyser les autorisations d'un fichier, car moins d'opérations sont impliquées.
¹ Ils peuvent changer lorsqu'un processus setuid ou setgid est exécuté. Ce n'est pas lié au problème en question.