web-dev-qa-db-fra.com

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 ensemble. 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 m'assurer 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 être très d'entretien, car il nécessite un script.

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.

debianpermissionsfilesystems
22
Martin Nielsen

Définir un propriétaire par défaut "automatiquement" nécessiterait un répertoire setuid se 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 bit d'exécution du répertoire --x 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 répertoire group_dir Est ourgroup.
  • Seules les personnes du groupe ourgroup peuvent accéder à group_dir.
  • user1 Et user2 Appartiennent à 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 dans ourgroup. N'importe qui du groupe peut créer, déplacer, supprimer des fichiers n'importe où dans group_dir (Mais pas plus profondément).
  • Quiconque n'est pas dans ourgroup sera bloqué dans 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'autorisation r-- 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:

  • Autorisations rw(x) par défaut pour le propriétaire.
  • Autorisations rw(x) par défaut pour le groupe.
  • Aucune autorisation par défaut pour les autres. Notez que puisque les autres ne peuvent pas accéder à group_dir De toute façon, peu importe quelles sont 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, user1 De supprimer user2_submission (Puisqu'il a l'autorisation -w- Sur group_dir):

$ chmod +t group_dir/

Maintenant, si user1 Essaie de supprimer le répertoire de user2, Il obtiendra un joli Operation not permitted. Notez cependant que bien que cela empêche les modifications de la structure des répertoires dans 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 les 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, user2 Peut 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, étant donné que vous êtes à l'origine prêt à donner un accès complet à rws à n'importe qui dans le groupe, je suppose que vous faites confiance à ces utilisateurs et que vous ne vous attendriez pas à trop d'opérations malveillantes de leur part.

14
John WH Smith

Il existe une façon plus intelligente de procéder. Il utilise une combinaison de set-gid et par défaut acls. 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/grpdir et que les membres du groupe sharing devraient 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 fichier créé dans /var/grpdir aura son groupe défini sur sharing par 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>:sharing et 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 sur le même que leur parent (/var/grpdir), et bien sûr, les bits exécutables sont définis pour l'utilisateur et le groupe. Si vous supprimez un utilisateur du groupe sharing, 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 atomiquement 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 pas de pointe pour IO tout en corrigeant les autorisations d'un seul coup.

6
sirlark

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

Alternatives:

  1. Utilisez la samba. samba a le force user paramè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. Celui-ci doit être configuré pour qu'un certain utilisateur le monte. Les autorisations d'accès doivent être gérées par le répertoire parent.

2
Hauke Laging

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.

ACL peut vous aider à obtenir un contrôle plus fin des grains 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.

0
Baazigar

Vous pouvez utiliser inotify-tools 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 dir création se produira dans le répertoire Web. Il existe de nombreux événements. Vous pouvez le rechercher sur Google ou y avoir accès site

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