Oui, les ACL: permettent de définir librement différents droits pour différents utilisateurs ou groupes. IIRC, les autorisations de groupe habituelles limitent l'ensemble des autorisations que les groupes et les utilisateurs peuvent avoir via ACL: s (comme indiqué mask
dans getfacl
), mais setfacl
doivent y faire face si vous ajoutez des autorisations.
Mais dans certains cas, vous devez vous demander si l'ensemble des autorisations est logique.
J'ai 3 utilisateurs avec les autorisations souhaitées ....
- user1 rwx
- user2 rw_
- user3 r__
Vous pouvez l'implémenter avec ACL: s, ou (approximativement) avec les autorisations Unix habituelles en faisant de l'utilisateur1 le propriétaire du fichier, de l'utilisateur2 un membre du groupe et de laisser les autres, y compris l'utilisateur3, avoir un accès en lecture. Cependant, tout le monde (avec accès au répertoire) aurait également un accès en lecture.
Examinons la signification de ces autorisations. Vous avez un utilisateur qui peut lire et un autre qui peut lire et écrire. C'est tout à fait habituel. Aucun d'eux n'a accès pour exécuter le fichier, mais un troisième utilisateur est également censé pouvoir le faire également.
Cela n'a pas beaucoup de sens dans mon esprit. Tout utilisateur qui peut lire le fichier, peut faire une copie (*), le marquer comme exécutable et l'exécuter, sans accès pour exécuter le fichier d'origine. La seule situation dans laquelle il est logique d'avoir un accès d'exécution pour certains utilisateurs mais pas pour d'autres, est lorsque l'exécutable a des privilèges élevés via suid. Mais si c'était le cas, vous ne devriez pas non plus avoir d'autres utilisateurs avec un accès en écriture au fichier.
Dans le même sens, user4 with -wx
et user5 with --x
n'ont pas de sens pour moi. L'accès en écriture seule pourrait avoir du sens s'il était possible de n'autoriser que les ajouts , mais le système d'autorisation n'est pas aussi fin.
(* sauf s'ils ne peuvent écrire nulle part)
Cependant, si nous supprimons l'exigence étrange pour le x
bit, nous nous retrouvons avec un fichier où l'utilisateur1 et l'utilisateur2 devraient avoir un accès en écriture et l'utilisateur3 devrait avoir un accès en lecture. Un écrivain et plusieurs lecteurs seraient faciles avec le modèle traditionnel, mais ce cas aurait besoin d'astuces pour combiner les autorisations de fichier avec les autorisations du répertoire contenant. Heureusement, dans de nombreux cas, un utilisateur avec plus d'autorisations est suffisant.
Sans l'exigence sur le bit d'exécution, cela ressemble à un cas pour utiliser ACL: s. Mais avec lui, cet exemple particulier me semble plutôt alambiqué.