Je viens de rencontrer quelque chose d'inattendu (pour moi) concernant les autorisations de fichiers sur Linux (Arch Linux). En gros j'ai :
userXdansgroupXfileX userX:groupX ---rwx----
Ce qui me laisse perplexe :je ne peux effectuer aucune action (rwx ) sur fileX . Est-ce correct? Quelqu'un peut-il confirmer qu'il s'agit bien du comportement attendu ?
Les seules actions que je peux effectuer sont mv et rm car j'ai des droits d'écriture sur le répertoire parent.
Le fait est que j'ai toujours pensé que ces autorisations s'effondraient les unes sur les autres, en commençant par la plus générale (autre -> groupe -> utilisateur). Autrement dit, si o=rwx qui se soucie des autorisations pour le groupe et l'utilisateur ?
Apparemment, ce n'est pas le cas, mais cela n'a pas beaucoup de sens pour moi ; cela semble contre-intuitif. La seule chose pour laquelle cette approche semble être utile, c'est d'exclure facilement une personne / un groupe très spécifique, ce qui ne semble pas être une façon intelligente de s'y prendre (à mon humble avis). De plus, le propriétaire (et le groupe ?) devrait pouvoir chmod quand même non ? Avez-vous des idées à ce sujet ?
Réponse acceptée :
Le fait est que j'ai toujours pensé que ces autorisations s'effondraient les unes sur les autres, en commençant par la plus générale (autre -> groupe -> utilisateur).
Si tel était le cas, les "autres" autorisations s'appliqueraient à tout le monde.
En d'autres termes, si o=rwx, qui se soucie des autorisations pour le groupe et l'utilisateur ?
C'est différent de votre phrase précédente. Ici, vous sous-entendez que les autorisations sont ou sont associées, par exemple. cet utilisateurX a l'autorisation de lecture si l'utilisateurX possède le fichier et que le fichier est lisible par l'utilisateur, ou si un groupe auquel appartient l'utilisateurX possède le fichier et que le fichier est lisible par le groupe, ou si le fichier est lisible par d'autres. Mais ce n'est pas comme ça que ça marche. En fait, o=rwx signifie que le rwx les autorisations s'appliquent aux autres, mais cela ne dit rien sur les entités qui ne sont pas les autres.
Tout d'abord, le groupe auquel appartient un utilisateur n'a pas d'importance directe. Le noyau n'a pas de notion d'utilisateurs appartenant à des groupes. Ce que le noyau maintient, 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 d'utilisateur et de groupe sont hérités par les processus enfants¹.
Lorsqu'un processus essaie d'ouvrir un fichier, avec les permissions Unix traditionnelles :
- Si l'utilisateur propriétaire du fichier est l'UID effectif du processus, les bits d'autorisation de l'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émentaires du processus, les bits d'autorisation de groupe sont utilisés.
- Sinon, les autres bits d'autorisation sont utilisés.
Un seul jeu de bits rwx est 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 existe une ACL sur le fichier pour l'UID effectif du processus, elle est utilisée pour déterminer si l'accès est accordé.
- Sinon, s'il existe une ACL dans le fichier pour le GID effectif du processus ou l'un des ID de groupe supplémentaires du processus, les bits d'autorisation de groupe sont utilisés.
- Sinon, les autres bits d'autorisation sont utilisés.
Ainsi -rw----r-- alice interns indique un fichier qui peut être lu et écrit par Alice, et qui peut être lu par tous les autres utilisateurs sauf les stagiaires. Un fichier avec les autorisations et la propriété ----rwx--- alice interns est accessible uniquement aux stagiaires sauf Alice (qu'elle soit stagiaire ou non). Puisque Alice peut appeler chmod modifier les autorisations, cela ne fournit aucune sécurité ; c'est un cas limite. Sur les systèmes dotés d'ACL, le mécanisme généralisé permet de supprimer les autorisations d'utilisateurs spécifiques ou de groupes spécifiques, ce qui est parfois utile.
L'utilisation d'un seul ensemble de bits, plutôt que d'utiliser 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 dotés d'ACL. Sur les systèmes sans ACL, les autorisations peuvent être supprimées d'un groupe.
- C'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.