Forcer le propriétaire sur les fichiers et dossiers créés

J'ai un répertoire qui contient des données partagées entre plusieurs utilisateurs. L'accès à ce répertoire et à tout ce qui se trouve en dessous, sera contrôlé par le groupe du répertoire, qui sera ajouté aux utilisateurs en question. En tant que tel, j'ai créé le dossier "groupe collant" chmod g+s. Le répertoire contiendra une arborescence avec des répertoires et des fichiers, le nombre total de fichiers étant probablement de quelques millions. Les fichiers seront assez petits, je ne prévois rien de plus de 50 Mo.

Mon problème est que le propriétaire du fichier ou du répertoire est toujours l'utilisateur qui l'a créé. En tant que tel, même si je supprimais cet utilisateur du groupe d'accès, je ne supprimerais pas complètement son accès.

Donc:

Y a-t-il d'autres options que j'ai manquées pour garantir que tous les fichiers et sous-répertoires ont le même propriétaire?

Je m'attends à ce que je puisse périodiquement parcourir tout le répertoire avec un cron-job, mais cela me semble inefficace pour ce qui est essentiellement une commande une fois pr-file.

J'ai trouvé un exemple en utilisant INotify, mais cela me semble nécessitant une maintenance élevée, car il nécessite des scripts.

Je n'ai pas été en mesure de déterminer si ACL peut m'aider avec la propriété forcée.

Existe-t-il un moyen plus intelligent de le faire?

Ce que je veux, c'est avoir un répertoire qui peut être partagé en ajoutant un groupe à un utilisateur. Tout ce qui est créé dans ce répertoire hérite du schéma d'autorisation de son parent. S'il y a un meilleur moyen que ce que j'essaie, je suis tout ouïe.

Définir un propriétaire par défaut "automatiquement" nécessiterait un répertoire setuidse comportant comme setgid. Cependant, bien que cela puisse être configuré sur FreeBSD, d'autres systèmes UNIX et Linux ignorent simplement u+s. Dans votre cas cependant, il pourrait y avoir une autre solution.

Ce que je veux, c'est avoir un répertoire qui peut être partagé en ajoutant un groupe à un utilisateur. Tout ce qui est créé dans ce répertoire hérite du schéma d'autorisation de son parent. S'il y a un meilleur moyen que ce que j'essaie, je suis tout ouïe.

Donc, fondamentalement, d'après ce que je vois, vous voulez contrôler l'accès à un répertoire en utilisant le mécanisme des groupes. Toutefois, cela ne vous oblige pas à restreindre les autorisations dans la structure de répertoires entière. En fait, le --xbit d'exécution du répertoire pourrait être exactement ce dont vous avez besoin. Laisse moi te donner un exemple. En admettant que...

• Le groupe contrôlant l'accès au group_dirrépertoire est ourgroup.
• Seules les personnes du ourgroupgroupe peuvent y accéder group_dir.
• user1et user2appartiennent à ourgroup.
• L'umask par défaut est 0022.

... considérez la configuration suivante:

drwxrws---    root:ourgroup   |- group_dir/
drwxr-sr-x    user1:ourgroup  |---- group_dir/user1_submission/
drwxr-sr-x    user2:ourgroup  |---- group_dir/user2_submission/
-rw-r--r--    user2:ourgroup  |-------- group_dir/user2_submission/README

^{Ici, supposons que chaque élément a été créé par son propriétaire.}

Maintenant, dans cette configuration:

• Tous les répertoires peuvent être consultés librement par tout le monde ourgroup. N'importe qui du groupe peut créer, déplacer, supprimer des fichiers n'importe où à l'intérieur group_dir(mais pas plus profondément).
• Toute personne non ourgroupprésente sera bloquée à group_dir, et ne pourra donc pas manipuler quoi que ce soit en dessous. Par exemple, user3(qui n'est pas membre de ourgroup), ne peut pas lire group_dir/user2_submission/README(même s'il a l' r--autorisation sur le fichier lui-même).

Cependant, il y a un petit problème dans ce cas: en raison de l'umask typique, les éléments créés par les utilisateurs ne peuvent pas être manipulés par d'autres membres du groupe. C'est là que les ACL entrent en jeu. En définissant des autorisations par défaut, vous vous assurerez que tout va bien malgré la valeur umask:

$ setfacl -dRm u::rwX,g::rwX,o::0 group_dir/

Cet appel définit:

• rw(x)Autorisations par défaut pour le propriétaire.
• rw(x)Autorisations par défaut pour le groupe.
• Aucune autorisation par défaut pour les autres. Notez que puisque les autres ne peuvent pas accéder de group_dirtoute façon, peu importe leurs autorisations en dessous.

Maintenant, si je crée un élément en tant que user2:

$ touch group_dir/user2_submission/AUTHORS
$ ls -l group_dir/user2_submission/AUTHORS
rw-rw----    user2:ourgroup    group_dir/user2_submission/AUTHORS

Avec cette ACL en place, nous pouvons essayer de reconstruire notre structure précédente:

drwxrws---+    root:ourgroup   |- group_dir/
drwxrws---+    user1:ourgroup  |---- group_dir/user1_submission/
drwxrws---+    user2:ourgroup  |---- group_dir/user2_submission/
-rw-rw----+    user2:ourgroup  |-------- group_dir/user2_submission/README

^{Là encore, chaque élément est créé par son propriétaire.}

De plus, si vous souhaitez donner un peu plus de puissance / sécurité à ceux qui utilisent le répertoire, vous voudrez peut-être envisager un peu collant. Cela empêcherait, par exemple, user1de supprimer user2_submission(puisqu'il a l' -w-autorisation sur group_dir):

$ chmod +t group_dir/

Maintenant, si user1essaie de supprimer user2le répertoire de, il obtiendra une belle Operation not permitted. Notez cependant que bien que cela empêche les modifications de la structure des répertoires group_dir, les fichiers et répertoires en dessous sont toujours accessibles:

user1@host $ rm -r user2_submission
Operation not permitted

user1@host $ cat /dev/null > user2_submission/README

user1@host $ file user2_submission/README
user2_submission/README: empty (uh-oh)

Une autre chose à prendre en compte est que les ACL que nous avons utilisées configurent des autorisations par défaut . Il est donc possible pour le propriétaire d'un élément de modifier les autorisations qui lui sont associées. Par exemple, user2peut parfaitement fonctionner ...

$ chown g= user2_submission/ -R
or
$ chgrp nobody user2_submission -R

... rendant ainsi son répertoire de soumission complet inaccessible à tous les membres du groupe.

Cependant, puisque vous êtes à l'origine prêt à donner un rwsaccès complet à n'importe qui dans le groupe, je suppose que vous faites confiance à ces utilisateurs et que vous ne vous attendez pas à trop d'opérations malveillantes de leur part.

Il existe une façon plus intelligente de procéder. Il utilise une combinaison de set-gid et acls par défaut . De toute évidence, vous aurez besoin d'un système de fichiers compatible acl. Supposons que le répertoire que vous souhaitez partager se trouve /var/grpdiret que les membres du groupe sharingdevraient pouvoir y accéder.

chown root:sharing /var/grpdir
chmod 2770 /var/grpdir #other can't read or traverse into the directory, set-gid is set
setfacl -d -m u::rwX,g::rwX,o::0 /var/grpdir

Les ACL par défaut sont héritées par des sous-répertoires créés dans un répertoire avec des ACL par défaut. Cela signifie donc que tout groupe créé dans /var/grpdiraura son groupe défini sharingpar le bit setgid du répertoire. De plus, il héritera des acls par défaut, qui remplaceront les prémisses de style linux par défaut, car nous n'avons pas spécifié d'ACL avec des utilisateurs ou des groupes spécifiques. Cela signifie que tous les fichiers seront créés avec la propriété <user>:sharinget les autorisations rw-rw----. Les répertoires seront les mêmes, sauf qu'ils auront également leurs propres listes de contrôle d'accès par défaut définies de la même manière que leur parent ( /var/grpdir), et bien sûr les bits exécutables définis pour l'utilisateur et le groupe. Si vous supprimez un utilisateur du sharinggroupe, il ne pourra pas accéder au répertoire (ni aux fichiers qu'il contient, même s'il les possède).

Contrairement aux corrections périodiques des autorisations avec un cronjob, les autorisations sont toujours synchronisées, car elles sont mises à jour de manière atomique avec les fichiers et répertoires nouvellement créés. Cette solution est légère; aucun démon n'est nécessaire, et il n'y a aucun pic à IO lors de la correction des autorisations d'un seul coup.

Je ne connais aucune bonne façon de procéder. Le moyen le plus propre techniquement serait un système de fichiers FUSE qui fait cela. Bien sûr, beaucoup de travail si personne ne l'a encore fait.

Alternatives:

1. Utilisez la samba. samba a le force userparamètre. Vous pouvez exporter un répertoire localement et le monter localement. Ne rend pas les accès plus rapides mais peut être acceptable car seule la mise en réseau en boucle est impliquée.

2. Utilisez un système de fichiers non Linux comme FAT32. Cela doit être configuré pour un certain utilisateur pour le monter. Les autorisations d'accès doivent être gérées par le répertoire parent.

Je n'ai entendu parler d'aucun moyen de changer automatiquement la propriété d'un fichier de telle sorte que le propriétaire du fichier soit changé lorsque le fichier est déplacé dans un certain répertoire. La chose la plus proche est la partie collante, mais il semble que vous ayez indiqué que la propriété du groupe ne suffit pas, la propriété réelle de l'utilisateur doit changer.

Dans ce cas, je pense que votre meilleur pari est le travail cron avec le drapeau chown -R, comme Pandya l'a mentionné. Mettez-le sur un cron pour courir toutes les minutes ou toutes les cinq minutes.

Si vous pouvez expliquer comment vos utilisateurs l'utilisent, il peut y avoir une meilleure solution.

L'ACL peut vous aider à obtenir un contrôle plus précis du grain sur qui est autorisé à faire quoi, il ne changera pas automatiquement la propriété réelle du fichier pour vous. Je pense que vous devez obtenir une vue plus élevée et évaluer / repenser votre solution sur cette base.

Vous pouvez utiliser les outils inotify et écrire un simple script bash comme ci-dessous. Inotify gardera un œil sur le répertoire web et fera quelque chose chaque fois qu'un événement comme la création de dir se produira dans le répertoire web. Il existe de nombreux événements. Vous pouvez le rechercher sur google ou peut-être sur ce site

while inotifywait -m -e CREATE web; do echo "A new directory has been created"; done