Comment accorder des autorisations différentes pour chaque utilisateur?

Donc, j'utilise Linux depuis quelques années maintenant, et je devrais vraiment connaître cette réponse, mais j'ai du mal à la trouver. Plus précisément, j'utilise des distributions basées sur Debian .... principalement Ubuntu.

Si j'ai un serveur qui compte plus de trois utilisateurs, comment puis-je définir un ensemble différent d'autorisations sur un fichier pour chaque utilisateur.

Par exemple:

Si j'ai un fichier avec ces autorisations et cette propriété:

rwx rw_ r__ user1:group1 file1.txt

et j'ai 3 utilisateurs avec ces autorisations souhaitées ....

• user1 rwx
• user2 rw_
• user3 r__

Tout ce que je dois faire est d' avoir user1 propriétaire du fichier, user2 dans groupe1 , et user3 peut être ni - correct?

Mais que se passe-t-il si j'ai un utilisateur4 et un utilisateur5 .

• user4 _wx
• user5 __x

Comment pourrais-je configurer cela?

Je n'ai pas eu à le faire auparavant, mais un administrateur Windows m'a posé cette question et je n'ai honnêtement pas pu répondre.

Les autorisations Unix traditionnelles n'autorisent que les autorisations d'utilisateur, de groupe et d'autres que vous avez trouvées. Il peut en résulter une combinaison maladroite de groupes à créer ...

Une nouvelle forme d'ACL (Access Control Lists) a donc été ajoutée. Cela vous permet de spécifier plusieurs utilisateurs et plusieurs groupes avec des autorisations différentes. Ceux-ci sont définis avec la setfaclcommande et lus avecgetfacl

$ setfacl -m u:root:r-- file.txt
$ setfacl -m u:bin:-wx file.txt 
$ setfacl -m u:lp:--x file.txt 
$ getfacl file.txt
# file: file.txt
# owner: sweh
# group: sweh
user::rw-
user:root:r--
user:bin:-wx
user:lp:--x
group::r--
mask::rwx
other::r--

Vous pouvez facilement savoir si un fichier a une ACL en regardant la lssortie:

$ ls -l file.txt
-rw-rwxr--+ 1 sweh sweh 0 Jul 26 10:33 file.txt

Le +à la fin des autorisations indique une ACL.

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é maskdans getfacl), mais setfacldoivent 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 -wxet user5 with --xn'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 xbit, 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é.