Comment faire pour que la nouvelle autorisation de fichier hérite du répertoire parent?

85

J'ai un répertoire appelé data. Ensuite, j'exécute un script sous l'ID utilisateur 'robot'. robot écrit dans le datarépertoire et met à jour les fichiers qu'il contient. L'idée est dataouverte pour moi et le robot de mettre à jour.

J'ai donc configuré le groupe de permissions et de propriétaires comme ceci

drwxrwxr-x  2 me robot-grp 4096 Jun 11 20:50 data

où robot et moi appartenons tous deux au "robot-grp". Je modifie l'autorisation et le groupe de propriétaires de manière récursive comme le répertoire parent.

Je télécharge régulièrement de nouveaux fichiers dans le datarépertoire en utilisant rsync. Malheureusement, les nouveaux fichiers téléchargés n'héritent pas de la permission du répertoire parent, comme je l'espère. Au lieu de cela, il ressemble à ceci

-rw-r--r-- 1 me users       6 Jun 11 20:50 new-file.txt

Lorsque le robot tente de se mettre à jour new-file.txt, il échoue faute d'autorisations de fichiers.

Je ne suis pas sûr que le réglage d'umask aide. En tout cas, les nouveaux fichiers ne le suivent pas vraiment.

$ umask -S
u=rwx,g=rx,o=rx

Je suis souvent dérouté par les autorisations de fichiers Unix. Ai-je même un bon plan? J'utilise Debian Lenny.

— Wai Yip Tung
source

53

Vous ne voulez pas changer le umask par défaut de votre système, c'est un risque pour la sécurité. L'option sticky bit fonctionnera dans une certaine mesure, mais l'utilisation des listes de contrôle d'accès est la meilleure solution. C'est plus facile que tu ne le penses. Le problème avec les listes de contrôle d'accès de base est qu'elles ne sont pas récursives par défaut. Si vous définissez une liste de contrôle d'accès sur un répertoire, seuls les fichiers de ce répertoire héritent de la liste de contrôle d'accès. Si vous créez un sous-répertoire, la liste de contrôle d'accès mère ne sera pas obtenue à moins que celle-ci ne soit définie sur récursion.

Tout d'abord, assurez-vous que les listes de contrôle d'accès sont activées pour le volume sur lequel se trouve le répertoire. Si vous avez tune2fs, vous pouvez effectuer les opérations suivantes:

# tune2fs -l /dev/sda1 | grep acl
Default mount options:    user_xattr acl

Si vous n'en avez pas tune2fs, alors examinez fstabs:

# cat /etc/fstab 
/dev/system/root        /                       ext3    defaults        1 1
/dev/system/home        /home                   ext3    defaults        1 2
/dev/storage/data       /data                   ext3    defaults        1 2
LABEL=/boot             /boot                   ext3    defaults        1 2

La 4ème colonne qui dit "par défaut" signifie sur mon système (CentOS 5.5), les ACL sont activés. En cas de doute, laissez les valeurs par défaut. Si vous essayez de définir l'ACL et il des erreurs sur, revenir en arrière et ajouter l'option acl / etc / fstab juste après défaut: defaults,acl.

D'après ce que j'ai compris, vous voulez que tous les utilisateurs du groupe d'utilisateurs aient un accès en écriture au répertoire de données. C'est accompli par ce qui suit:

setfacl -Rm g:users:rwX,d:g:users:rwX data/

— churnd
source

J'ai utilisé cette commande mais cela n'a pas résolu mon problème, comment puis-je annuler cette commande s'il vous plaît?

— Itai Ganot

Fait le tour sur Ubuntu avec sudo setfacl -Rm g:users:rwX,d:g:users:rwX /var/www/logs_or_something. Avait un problème avec les tests PHPUnit. Après avoir créé des fichiers journaux à partir de tests en cours, l’utilisateur Apache www-datan’a pas pu les écrire / lire.

— s3m3n

2

@Itai Ganot - selon la setfaclpage de manuel , -bou --remove-allsupprime les ACL étendues.

— jww

Donc, vous souhaitez simplement ajouter setfacl -Rm g:users:rwX,d:g:users:rwX data/à la fin de /etc/fstab?

— 425nesp

@ piña no. le seul changement que vous apportez à / etc / fstab est de changer defaultspour defaults,acl. setfaclest une commande à exécuter depuis le terminal. data/doit être remplacé par le chemin du répertoire que vous souhaitez modifier.

— Segfault

32

En marquant un répertoire, setgid ( g+s) fera en sorte que les nouveaux fichiers héritent de la propriété du groupe sur le répertoire, mais l' -goption de rsync tentera de le remplacer.

— Ignacio Vazquez-Abrams
source

11

Le bit setgid permet uniquement aux fichiers créés d'hériter du groupe / si / la personne créant le nouveau fichier est membre de ce groupe; Si l'utilisateur créateur est le propriétaire mais n'est pas membre du groupe, ou si le répertoire est accessible en écriture, le bit setgid ne fera rien. Et umask pour tous les utilisateurs créant des fichiers doit encore être défini pour permettre l’accès au groupe approprié.

— dannysauer

1

@dannysauer "si l'utilisateur créateur est le propriétaire mais n'est pas membre du groupe ... le bit setgid ne fera rien" - merci. Cela a du sens maintenant - mais sans le retour de rsync, je me demandais pourquoi cela ne fonctionnait pas.

— user12345

4

D'autres réponses s'appliquent dans un cas général, mais comme vous mentionnez que rsync est une source du problème, il vous suffira peut-être de régler son invocation.

Pour commencer, le -adrapeau populaire accorde des autorisations de copie à rsync; utilisez -ristead of -aou add -no-p(pour aucune synchronisation des autorisations) et -no-g(pour aucune synchronisation de groupe). De plus, rsync supporte --chmodflag pour modifier les permissions sur les fichiers nouvellement créés.

— mbq
source

3

Votre umask n’est pas conforme aux autorisations que vous souhaitez. Vous voulez un umask de 002. Vous avez actuellement un umask de 022. En outre, le commentaire sur la création du répertoire setgid est correct, mais je ne suis pas sûr si la propriété du groupe de fichiers est quelque chose que vous souhaitez modifier ou non.

Les autorisations de fichiers Unix sont en réalité un modèle très simple. Je trouve les ACL complètement déroutant. :-)

— Très varié
source

4

"Les autorisations de fichiers Unix sont en fait un modèle très simple. Je trouve les listes de contrôle d'accès complètement déroutantes." - Je ressens plutôt le contraire (mais +1 quand même). Les ACL (et les entrées de contrôle d'accès autorisées / refusées) sont simples et les autorisations Unix n'ont aucun sens. Mais cela vient d'un gars qui souffre d'une installation Postfix / Dovecot / Clam / SpamAssassin.

— jww le