Définition des autorisations par défaut pour les fichiers et sous-répertoires nouvellement créés dans un répertoire sous Linux?

99

J'ai un tas de scripts et d'applications de longue durée qui stockent les résultats de sortie dans un répertoire partagé entre quelques utilisateurs. Je voudrais un moyen de m'assurer que chaque fichier et répertoire créé sous ce répertoire partagé avait automatiquement des u=rwxg=rwxo=rautorisations.

Je sais que je pourrais utiliser umask 006en tête mes différents scripts, mais je n'aime pas cette approche car de nombreux utilisateurs écrivent leurs propres scripts et peuvent oublier de définir eux-mêmes l'umask.

Je veux vraiment juste que le système de fichiers définisse les fichiers et répertoires nouvellement créés avec une certaine autorisation s'il se trouve dans un certain dossier. Est-ce possible?

Mise à jour : Je pense que cela peut être fait avec les ACL POSIX , en utilisant la fonctionnalité ACL par défaut, mais c'est un peu au-dessus de ma tête pour le moment. Si quelqu'un peut expliquer comment utiliser les ACL par défaut, il répondra probablement bien à cette question.

David Dean
la source
1
Les ACL POSIX sont bien, cependant 60% des machines que vous rencontrez ne les auront pas activées pour certains systèmes de fichiers, selon la distribution. Voici une très bonne introduction et exemple: suse.de/~agruen/acl/linux-acls/online
Tim Post
1
Vous voulez dire le même document que j'ai lié :) Je n'ai pas encore eu de changement pour le lire mais merci pour la tête sur le problème de disponibilité.
David Dean
1
Le lien dans le commentaire de Tim Post semble être mort, mais grâce à Internet Archive, j'ai pu le consulter et vérifier que vanemery.com/Linux/ACL/POSIX_ACL_on_Linux.html contient exactement le même document. Je modifierai la question pour mettre à jour le lien.
rmunn

Réponses:

78

Pour obtenir la bonne propriété, vous pouvez définir le bit setuid de groupe sur le répertoire avec

chmod g+rwxs dirname

Cela garantira que les fichiers créés dans le répertoire appartiennent au groupe. Vous devriez alors vous assurer que tout le monde fonctionne avec umask 002 ou 007 ou quelque chose de ce genre - c'est pourquoi Debian et de nombreux autres systèmes Linux sont configurés par défaut avec des groupes par utilisateur.

Je ne connais pas de moyen de forcer les autorisations souhaitées si l'umask de l'utilisateur est trop fort.

Norman Ramsey
la source
23
Cela ne fournit pas vraiment de solution - il pose des questions sur les autorisations et non sur la propriété, et la seule façon de le faire est avec les ACL
Yarin
3
"... assurez-vous que tout le monde fonctionne avec umask 002 ou 007 ou quelque chose de ce genre" - c'est un peu exagéré .... Comment faites-vous pour que Postfix, Dovecot, Clam et Spam Assassin fassent cela?
jww
2
Que fait la +spièce? Merci.
tommy.carstensen
1
Dans ce cas, cela signifie définir l'ID de groupe. C'est-à-dire que nous utilisons g + s pour définir le bit SGID. Je dis "dans ce cas" parce que + s a été combiné avec g pour le groupe. + s peut également être utilisé pour régler le bit SUID (setuid).
Bastion
57

Voici comment le faire en utilisant les ACL par défaut, au moins sous Linux.

Tout d'abord, vous devrez peut- être activer la prise en charge de l'ACL sur votre système de fichiers. Si vous utilisez ext4, il est déjà activé. D'autres systèmes de fichiers (par exemple, ext3) doivent être montés avec l' acloption. Dans ce cas, ajoutez l'option à votre /etc/fstab. Par exemple, si le répertoire se trouve sur votre système de fichiers racine:

/dev/mapper/qz-root   /    ext3    errors=remount-ro,acl   0  1

Puis remontez-le:

mount -oremount /

Maintenant, utilisez la commande suivante pour définir l'ACL par défaut:

setfacl -dm u::rwx,g::rwx,o::r /shared/directory

Tous les nouveaux fichiers /shared/directorydoivent maintenant obtenir les autorisations souhaitées. Bien sûr, cela dépend également de l'application qui crée le fichier. Par exemple, la plupart des fichiers ne seront exécutables par personne dès le début (en fonction de l'argument mode de l'appel open (2) ou creat (2)), tout comme lors de l'utilisation d'umask. Certains utilitaires comme cp, taret rsyncessaieront de conserver les autorisations du ou des fichiers source qui masqueront votre ACL par défaut si le fichier source n'était pas accessible en écriture de groupe.

J'espère que cela t'aides!

pelle
la source
Il semble que cela nécessite toujours approprié umaskpour tous les utilisateurs. = / unix.stackexchange.com/questions/71743/…
anatoly techtonik
1
@techtonik Comme je l'ai écrit, cela dépend de l'application qui crée le fichier. Par exemple, si vous utilisez, cpil essaiera de copier les autorisations du fichier source. N'aide même pas umasklors de l'utilisation cp. J'ai vu le même problème avec tar. Voir cette question .
pelle
@techtonik J'ai ajouté une phrase à ce sujet dans ma réponse maintenant.
pelle
1
oui, il semble que le problème était dans l'application définissant de force les droits sur 644 alors que ma configuration correcte ACL et POSIX était tout pour 664. Ce serait bien de clarifier ce mécanisme de secours pour les personnes qui résolvent le problème. Beaucoup ne le savent même pas umask.
anatoly techtonik
Je veux dire que j'ai perdu du temps à essayer de voir si les indicateurs de montage ne sont pas correctement définis (et sur ext4, ils ne peuvent pas être définis, car il semble qu'ils fonctionnent automatiquement). Il n'y a aucune information sur la façon de vérifier si setfacl works correctly- je suppose que cela devrait échouer, mais je ne suis pas sûr, car la réponse passe à côté de ce point.
anatoly techtonik
4

C'est moche, mais vous pouvez utiliser la commande setfacl pour obtenir exactement ce que vous voulez.

Sur une machine Solaris, j'ai un fichier contenant les acls des utilisateurs et des groupes. Malheureusement, vous devez lister tous les utilisateurs (au moins je ne pourrais pas trouver un moyen de faire fonctionner cela autrement):

user::rwx
user:user_a:rwx
user:user_b:rwx
...
group::rwx
mask:rwx
other:r-x
default:user:user_a:rwx
default:user:user_b:rwx
....
default:group::rwx
default:user::rwx
default:mask:rwx
default:other:r-x

Nommez le fichier acl.lst et remplissez vos vrais noms d'utilisateur au lieu de user_X.

Vous pouvez maintenant définir ces acl sur votre répertoire en exécutant la commande suivante:

setfacl -f acl.lst /your/dir/here
innaM
la source
pouvez-vous supprimer la liste des utilisateurs s'ils sont tous membres du même groupe et utiliser simplement les autorisations du groupe?
David Dean
Je me posais la même question. Cela fait un moment que j'ai mis cela en place. Mais chaque fois que j'ai un nouvel utilisateur (dans le même groupe que les autres), j'oublie de mettre à jour la liste et je reçois des plaintes concernant le nouvel utilisateur ne pouvant pas écrire / supprimer des fichiers. La réponse est donc: non, vous ne pouvez pas.
innaM
4

dans votre script shell (ou .bashrc) vous pouvez utiliser quelque chose comme:

umask 022

umask est une commande qui détermine les paramètres d'un masque qui contrôle la façon dont les autorisations de fichier sont définies pour les fichiers nouvellement créés.

user3270784
la source
1
Ce n'est pas correct car umask limite les autorisations qu'il ne peut pas ajouter
ACV
@ACV pouvez-vous élaborer? Cela fonctionne pour moi, les fichiers nouvellement créés permettent désormais aux membres du groupe d'avoir des autorisations rw lorsque je le fais umask 002dans mon .bashrc.
Arthur Dent
3
@ArthurDent umask 002limite l'accès aux autres, laissant le groupe inchangé. Rappelez-vous, c'est ugo- c'est le groupe d'utilisateurs des autres. Souvenez-vous également que umask signifie essentiellement soustraire des valeurs par défaut. Pour les fichiers: 666 - 002signifierait 664 ce qui signifie que le groupe n'est pas affecté.
ACV