Utilisation de setfacl pour permettre aux membres du groupe d'écrire dans n'importe quel fichier d'un répertoire

J'aimerais utiliser setfacl pour que n'importe qui dans le groupe «app» puisse éditer n'importe quel fichier contenu dans / usr / local / users / app indépendamment de ce que disent les permissions UNIX traditionnelles. J'ai deux utilisateurs John et Ben. J'ai essayé de suivre les instructions d'une autre question , mais John n'est pas en mesure d'écrire dans certains fichiers. Il semble que ce soit à cause du masque acl. Cependant, j'ai défini le masque par défaut sur le répertoire de rwx, donc les fichiers qu'il contient ne devraient-ils pas en hériter lorsqu'ils sont créés?

Par exemple, john ne peut pas écrire dans le fichier ci-dessous, mais il est membre du groupe 'app' qui a écrit des acls sur le fichier, donc je suis surpris qu'il ne puisse pas modifier le fichier.

ben@app1:/usr/local/users$ ls -la app/app-1.0-SNAPSHOT/lib/play.templates_2.10-2.1.1.jar 
-rw-r--r--+ 1 ben users 38326 Apr  2 10:21 app/app-1.0-SNAPSHOT/lib/play.templates_2.10-2.1.1.jar

ben@app1:/usr/local/users/app$ getfacl app-1.0-SNAPSHOT/lib/
# file: app-1.0-SNAPSHOT/lib/
# owner: ben
# group: users
user::rwx
group::rwx          #effective:r-x
group:app:rwx       #effective:r-x
mask::r-x
other::r-x
default:user::rwx
default:group::rwx
default:group:app:rwx
default:mask::rwx
default:other::r-x

ben@app1:/usr/local/users$ getfacl app/app-1.0-SNAPSHOT/lib/play.templates_2.10-2.1.1.jar 
# file: app/app-1.0-SNAPSHOT/lib/play.templates_2.10-2.1.1.jar
# owner: ben
# group: users
user::rw-
group::rwx          #effective:r--
group:app:rwx       #effective:r--
mask::r--
other::r--

permissions acl

— Ben McCann
source

Réponses:

Vous remarquerez le commentaire "efficace" que getfacl vous lance. Le problème est que les autorisations sont calculées de sorte que «app» n'obtienne pas le bit d'écriture défini. Cela se produit car le masque du fichier est en lecture seule. Le masque est utilisé pour limiter la quantité d'autorisations qui pourraient éventuellement être accordées sur un fichier ou un répertoire particulier.

Un exemple de la raison pour laquelle vous voudriez que ce comportement soit comme si vous saviez que le fichier pouvait légitimement avoir besoin de différents utilisateurs / groupes pour y avoir accès, mais pour une raison quelconque, les choses se compliquaient avec les autorisations et vous vouliez un moyen de dire «Quel que soit l'autre les autorisations par défaut sont définies sur, quelle que soit leur appartenance à un groupe, ou quel que soit setfacl récursif qui sera exécuté plus tard, NE DONNEZ PAS DEFINITIVEMENT CECI ! " L'utilisateur propriétaire a un statut spécial dans le monde POSIX, il a des droits que les autres utilisateurs n'ont pas, comme la possibilité de ne pas être root et de modifier les autorisations sur un fichier et que ses droits ne soient pas limités par le masque (qui serait inutile de toute façon à cause du premier privilège que le système leur accorde). C'est pourquoi ils obtiennent toujours rwx même si le masque est restreint.

Pour répondre à votre question spécifique, ajoutez le bit d'écriture au masque du fichier et réessayez en tant johnqu'utilisateur.

voici une version en ligne de commande de l'explication ci-dessus, prenez note de la façon dont les droits "effectifs" changent lorsque tout ce que je modifie est le masque.

— Bratchley
source

Je vous remercie. J'apprécie vraiment la réponse. Est-il possible de créer de nouveaux fichiers avec un masque par défaut de rwx? J'ai édité ma question avec quelques détails supplémentaires.

— Ben McCann

Oui, le masque est l'une des catégories (comme les utilisateurs et les groupes) sur lesquelles vous pouvez définir une ACL par défaut. Le masque par défaut doit hériter des sous-répertoires et s'appliquer aux fichiers. EXEMPLE: setfacl -md: m :: rwx / path / to / Dir

— Bratchley

L'ACL par défaut hérite des sous-répertoires, mais pas des fichiers, ce qui rend les ACL complètement inutiles :-(

— Ben McCann

Juste pour vous assurer que nous parlons de la même chose, vous parlez de l'acl par défaut pour l'entrée de masque? C'est ce que j'obtiens dans les tests.

— Bratchley

J'ai également répété le test ci-dessus pour les nouveaux fichiers dans / testBed après avoir changé le masque effectif dans le répertoire parent et obtenu le même résultat (l'entrée de masque par défaut est appliquée au fichier et non au masque efficace du parent).

— Bratchley

C'est impossible. cp, rsync, etc. créent des fichiers en ignorant les ACL par défaut

Pourquoi cp ne respecte-t-il pas les ACL?

— Ben McCann
source

incorrect L'utilisateur rencontrait le même masque que vous rencontriez précédemment et a reçu une réponse incorrecte de quelqu'un d'autre. Ce n'est pas à "cp" ou à tout autre utilitaire d'ignorer les entrées ACL par défaut, ce qui se produit au niveau du système de fichiers lorsque cp va créer le fichier. L'outil a la possibilité d'émettre les appels système pour agréger / ajouter les ACL nécessaires, mais devrait faire un effort pour le faire.

— Bratchley

L'enfer de cela est que vous pouvez voir l'entrée ACL dont ils parlent, c'est juste que les autorisations effectives qu'ils s'attendent à voir ne sont pas là. C'était une occasion parfaite pour dire "Salut mec, vérifie ton masque."

— Bratchley

En fait, je reprends que EvilRyry a posté sur le masque et que l'OP a simplement répondu "ça n'a pas fonctionné" puis a posté une sortie getfacl qui semble montrer que "felles" a bien reçu rwx dans le fichier. À ce rythme, la réponse la plus votée ne correspond pas à mon expérience personnelle et à ce que j'ai illustré ici avec des exemples de commandes.

— Bratchley