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

Question

J'ai un tas de longue durée d'exécution des scripts et des applications qui sont le stockage de la sortie des résultats dans un répertoire partagé entre un petit nombre d'utilisateurs. Je voudrais un moyen de faire en sorte que chaque fichier et chaque répertoire créé en vertu du présent répertoire partagé automatiquement a u=rwxg=rwxo=r des autorisations.

Je sais que je pourrais utiliser umask 006 à la tête de mes différents scripts, mais je n'aime pas cette approche de nombreux utilisateurs d'écrire leurs propres scripts et peut oublier de mettre le umask eux-mêmes.

Vraiment, je veux juste le système de fichiers pour définir les nouveaux fichiers et les répertoires avec une certaine permission si elle est dans un certain dossier. Est-ce possible?

Mise à jour: je pense que cela peut être fait avec les Acl POSIX, à l'aide de l'ACL par Défaut de la fonctionnalité, mais c'est un peu au-dessus de ma tête en ce moment. Si quelqu'un peut expliquer comment utiliser les Acl par Défaut, il serait probablement répondre à cette question bien.

Answer 1

Pour obtenir la bonne propriété, vous pouvez définir le bit setuid de groupe dans le dossier base_dn avec

Cela garantit que les fichiers créés dans le répertoire sont détenues par le groupe. Vous devez ensuite vous assurer tout le monde s’exécute avec umask 002 ou 007 ou quelque chose de cette nature---c’est pourquoi Debian et bien d’autres systèmes de linux est configurés avec des groupes par utilisateur par défaut.

Je ne sais pas d’un moyen de forcer les autorisations que vous souhaitez si umask de l’utilisateur est trop fort.

Answer 2

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

Tout d'abord, vous pourriez avoir besoin de vérifier votre système de fichiers, même s'il semble que ext4 est-il maintenant par défaut. Pour la plupart des autres systèmes de fichiers, vous avez besoin de le monter avec l' acl option. Ajouter à 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 la remonter:

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 dans /shared/directory devez maintenant obtenir les autorisations souhaitées. Bien sûr, cela dépend aussi de l'application de la création du fichier. La plupart des fichiers ne sera pas exécutable par n'importe qui depuis le début (en fonction du mode argument de open(2) ou à créer(2) appel), tout comme lors de l'utilisation de umask.

Espérons que cette aide!

Answer 3

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 qui contient les droits d'accès des utilisateurs et des groupes. Malheureusement, vous avez la liste de tous les utilisateurs (au moins, je ne pouvais pas trouver un moyen de faire fonctionner 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

Nom du fichier acl.lst et remplir vos vrais noms d'utilisateur au lieu de user_X.

Vous pouvez maintenant définir ces listes de contrôle d'accès à votre répertoire en émettant la commande suivante:

setfacl -f acl.lst /your/dir/here

Answer 4

Eh bien, cela dépend vraiment sur le système de fichiers. Vous ne trouverez pas un système de fichiers dans le noyau qui n'a pas obéir à l'umask paramètres donnés par l'utilisateur, sauf dans des cas particuliers comme la gestion des versions des systèmes de fichiers dont les fichiers dans le passé sont traités comme immuable.

Donc, en substance, l'utilisation umask .. ou écrire un FUSIBLE wrapper qui fait ce que vous voulez. Même si vous réglez le sticky bit, le propriétaire du dernier appel de umask est ce que le système de fichiers est décidé à obéir.

Ce que je ne suis pas sûr de l'est, ne le bit setuid/setgid nombre de bits que le propriétaire lors de l'umask est modifié? I. e. si /bin/foo est setuid 0, et l'uid 5003 l'exécute, je pense que le sticky bit aurait préséance sur tous les fichiers que /bin/foo modifie en tant que root pour uid 5003.

Modifier, comme d'autres l'ont mentionné, les Acl POSIX peut être utile. Voici un bon tutoriel sur l'obtention à les connaître et à les utiliser. Le problème avec les ACLS (en particulier sur les vieux installe), c'est qu'ils ne peuvent pas être activé sur n'importe quelle donnée FS qui les prend en charge, de même que certains systèmes de fichiers de support que de très petites listes d'accès.