Question Comment faire pour que les nouvelles autorisations de fichiers héritent du répertoire parent?


J'ai un répertoire appelé data. Ensuite, je lance un script sous l'ID utilisateur 'robot'. robot écrit à la data répertoire et mettre à jour les fichiers à l'intérieur. L'idée est data est ouvert pour moi et le robot pour mettre à jour.

Donc, je configure la permission et le groupe de propriétaires comme ceci

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

où moi et le robot appartiennent tous deux au «robot-grp». Je change la permission et le groupe propriétaire récursivement comme le répertoire parent.

Je télécharge régulièrement de nouveaux fichiers dans le data répertoire 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

Quand le robot tente de mettre à jour new-file.txt, il échoue en raison d'un manque d'autorisation de fichier.

Je ne suis pas sûr si le réglage de umask aide. Dans tous les cas, les nouveaux fichiers ne le suivent pas vraiment.

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

Je suis souvent confondu par la permission de fichier Unix. Est-ce que j'ai même un bon plan? J'utilise Debian Lenny.


80
2018-06-12 04:06


origine




Réponses:


Vous ne voulez pas modifier le umask par défaut de votre système, ce qui constitue un risque de sécurité. L'option sticky bit fonctionnera dans une certaine mesure, mais l'utilisation d'ACL est la meilleure solution. C'est plus facile que vous ne le pensez. 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 contenus dans ce répertoire héritent de la liste de contrôle d'accès. Si vous créez un sous-répertoire, il ne reçoit pas la liste de contrôle d'accès parent sauf si la liste de contrôle d'accès est définie sur récursive.

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 tu as tune2fs, vous pouvez effectuer les opérations suivantes:

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

Si vous n'avez pas tune2fs, puis 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 indiquant "par défaut" signifie sur mon système (CentOS 5.5), les ACL sont activés. En cas de doute, laissez-le comme défaut. Si vous essayez de définir la liste de contrôle d'accès et les erreurs, revenez en arrière et ajoutez l'option acl à / etc / fstab immédiatement après les valeurs par défaut: defaults,acl.

D'après ce que j'ai compris, vous voulez que tout le monde dans le groupe d'utilisateurs ait un accès en écriture au répertoire de données. Cela est accompli par ce qui suit:

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

50
2018-06-13 02:10



J'ai utilisé cette commande mais elle n'a pas résolu mon problème, comment puis-je annuler cette commande s'il vous plaît? - Itai Ganot
Le tour sur Ubuntu avec sudo setfacl -Rm g:users:rwX,d:g:users:rwX /var/www/logs_or_something. Problème avec les tests PHPUnit. Après avoir créé des fichiers journaux à partir des tests en cours, l'utilisateur apache www-data ne pouvait pas les écrire / lire. - s3m3n
@Itai Ganot - selon le setfacl page de manuel, -b ou --remove-all supprime les listes de contrôle d'accès étendues. - jww
Donc, vous venez d'ajouter setfacl -Rm g:users:rwX,d:g:users:rwX data/ au bout du /etc/fstab? - 425nesp
@ piña no. le seul changement que vous apportez à / etc / fstab est de changer defaults à defaults,acl. setfacl est une commande que vous devez exécuter depuis le terminal. data/ devrait être remplacé par le chemin d'accès au répertoire que vous souhaitez modifier. - Segfault


Marquer un répertoire setgid (g+s) fera que les nouveaux fichiers héritent de la propriété du groupe du répertoire, mais -g L'option de rsync tentera de remplacer ceci.


31
2018-06-12 04:13



Le bit setgid ne fait qu'hériter les fichiers créés du groupe / si / la personne qui crée le nouveau fichier est membre de ce groupe; Si l'utilisateur créateur est le propriétaire mais pas le membre du groupe, ou si le répertoire est accessible en écriture, le bit setgid ne fera rien. Et le umask pour tous les utilisateurs de création de fichiers doit encore être défini pour permettre un accès de groupe approprié. - dannysauer


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

Pour commencer, le populaire -a flag rend les droits de copie rsync; utilisation -r au lieu de -a ou ajouter -no-p (pour aucune synchronisation de permission) et -no-g (pour aucune synchronisation de groupe). Aussi supporte rsync --chmod flag pour modifier les autorisations sur les fichiers nouvellement créés.


4
2017-09-03 15:36





Votre umask est incorrect pour les autorisations que vous souhaitez. Vous voulez un umask de 002. Vous avez actuellement un umask de 022. En outre, le commentaire concernant la création du répertoire setgid est correct, mais je ne suis pas sûr que la propriété du groupe de fichiers soit quelque chose que vous souhaitez modifier.

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


3
2018-06-12 04:43



"Les autorisations de fichiers Unix sont en réalité un modèle très simple. Je trouve les ACL complètement confuses." - Je ressens un peu le contraire (mais +1 de toute façon). Les ACL (et Autoriser / Refuser les ACE) 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