Spécifiez le groupe par défaut et les autorisations pour les nouveaux fichiers dans un certain répertoire

J'ai un certain répertoire dans lequel il y a un projet partagé par plusieurs utilisateurs. Ces utilisateurs utilisent SSH pour accéder à ce répertoire et modifier / créer des fichiers.

Ce projet ne doit être accessible en écriture qu'à un certain groupe d'utilisateurs: appelons-le "mon groupe". Au cours d'une session SSH, tous les fichiers / répertoires créés par l'utilisateur actuel doivent par défaut appartenir au groupe "mygroup" et disposer d'autorisations d'écriture de groupe.

Je peux résoudre le problème des autorisations avec umask:

$ cd project
$ umask 002
$ touch test.txt

Le fichier "test.txt" est désormais accessible en écriture de groupe, mais appartient toujours à mon groupe par défaut ("mislav", identique à mon nom d'utilisateur) et non à "mon groupe". Je peux chgrprécursivement définir le groupe souhaité, mais je voulais savoir s'il existe un moyen de définir un groupe implicitement comme umask change les autorisations par défaut pendant une session.

Ce répertoire spécifique est un dépôt git partagé avec une copie de travail et je souhaite git checkoutque les git resetopérations définissent le masque et le groupe corrects pour les nouveaux fichiers créés dans la copie de travail. Le système d'exploitation est Ubuntu Linux.

Mise à jour: un collègue suggère que je devrais regarder getfacl / setfacl de POSIX ACL mais la solution ci-dessous combinée avec umask 002dans la session en cours est assez bonne pour moi et est beaucoup plus simple.

Pour que tous les fichiers d'un répertoire donné héritent des droits du groupe, vous devez utiliser le bit setgid sur votre répertoire. Voir ce lien .

 $ mkdir test
 $ sudo chown raphink.staff test
 $ ls -lhd test
     drwxr-xr-x 2 raphink staff 4.0K 2009-12-21 16:19 test
 $ sudo chmod g+s test # Set the setgid bit
 $ ls -lhd test
     drwxr-sr-x 2 raphink staff 4.0K 2009-12-21 16:21 test
 $ touch test/foo
 $ ls -lh test
     total 0
     -rw-r--r-- 1 raphink staff 0 2009-12-21 16:23 foo

Si vous souhaitez le faire avec un dossier existant, vous devez vous assurer que le bit setgid est également activé pour tous les sous-dossiers. Cependant, vous n'en avez pas besoin sur les fichiers, et vous ne le voulez probablement pas non plus sur les fichiers. Voici comment le définir de manière récursive pour tous les sous-dossiers.

find /path/to/base/dir -type d -exec chmod g+s {} +

Je ne peux pas retrouver la source, mais utiliser setgidpour résoudre ce problème pour les référentiels nus git, qui, je suppose, est votre cas, est obsolète et peut causer des problèmes dans certains cas.

Git peut s'occuper de tout cela via le core.sharedRepositorydrapeau. J'ai eu le même problème et l'ai résolu comme suit:

En supposant que repogroupc'est votre groupe, et vous devez cdle répertoire repo:

Modifiez d'abord le drapeau partagé en group:

git config core.sharedRepository group 

Remarque: ici, vous devez utiliser le mot-clé group, pas le nom du groupe. Cela revient à créer le référentiel nu avec option --shared=group.

Modifiez ensuite le groupe pour l'ensemble du référentiel:

chgrp -R repogroup .

Pour vous assurer que les répertoires existants sont accessibles en écriture de groupe ( g+w) et que les exécutables existants deviennent également des exécutables de groupe ( g+X), vous devez également:

chmod -R g+wX .

Une fois que vous avez fait cela, git honorera l' shared=groupindicateur et prendra en charge les autorisations de groupe dans les éléments suivants, à la fois pour les fichiers existants et nouveaux, de sorte que vous n'aurez plus jamais besoin de umaskou chgrp.

Je mettrai la source dans un commentaire si je la retrouve.

Je ne suis pas vraiment un expert en ce qui concerne le côté * nix, mais je pense que ce que vous recherchez s'appelle setgid.

Voyez ici .

Il est difficile d'hériter des autorisations de répertoire parent sous Linux / UNIX sans utiliser de listes de contrôle d'accès. mais il existe un moyen d'attribuer des autorisations de fichier par défaut, consultez le lien ci-dessous

Pouvez-vous hériter des autorisations du répertoire parent.