Nos serveurs sont donc configurés comme ceci :
Structure des dossiers

/asicest le dossier de notre grand projet, /200Test un sous-projet de ce grand projet, et les dossiers juste en dessous /200Ttels que /lbhles répertoires personnels de chaque travailleur qui travaillent sur le sous-projet. /asic, /200T, /lbhont tous été créés par rootet ont ensuite vu leurs propriétés reconfigurées par root via chmod -Ret chown -R. /asicet /200Tsont détenus par rootet appartiennent aux groupes asicet 200Trespectivement, tandis que appartient au /lbhcompte d'utilisateur du travailleur lbhet appartient au groupe asic.

L'idée est que le contenu à l'intérieur /asicet /200Tpeut être vu par tout le personnel travaillant sur asicet 200Tpourtant ils ne peuvent pas avoir accès en écriture à ces 2 répertoires - s'ils veulent créer quelque chose, ils devront le faire dans leurs propres répertoires ( /lbhet autres ). Lorsqu'un travailleur crée quelque chose dans son propre répertoire, nous voulons que les autres travailleurs du même sous-projet puissent lire cette nouvelle chose, mais pas la modifier par accident. Par exemple, vous lbhvenez de créer un fichier testbench.vet un dossier /resultssous /asic/200T/lbh. Une autre personne ( glj) sur le 200Tsous - projet devrait être en mesure de lire /asic/200T/lbh/testbench.vet /asic/200T/lbh/resultsmais pas écrire en eux. S'il gljveut les modifier, il devra les copier dans son propre répertoire /asic/200T/gljet ensuite le faire.

Pour atteindre les objectifs ci-dessus, nous avons besoin des autorisations des répertoires créés par lbhto be drwxr-s---et des fichiers rwxr-s---par défaut, cependant la réalité ressemble à ceci :
Fichiers et dossiers créés par lbh et root

Résultat : chaque travailleur est capable d'écrire dans les dossiers et fichiers de chacun, ce qui est exactement ce que nous essayons d'éviter. Le umaskde rootest 0022, et le umaskdes utilisateurs normaux est 0002.

Mes questions:

  1. Pourquoi les fichiers créés par les utilisateurs (comme /lbh) sous leurs répertoires personnels (comme lbh) ignorent-ils l' drwxr-s--- autorisation du dossier personnel et sont-ils par défaut (d)rwxrwsr-x?
  2. Existe-t-il une méthode sûre pour permettre aux travailleurs de créer des fichiers et des dossiers avec (d)rwxr-s--- par défaut ? Demander à chaque utilisateur de chmodtout faire manuellement à chaque fois est trop compliqué, et je crains que la modification de la umaskvaleur par défaut puisse entraîner de nouveaux problèmes surprises sur toute la ligne.

Merci beaucoup!


Modifier : La structure des dossiers et l'autorisation des fichiers créés par lbh et root ressemblent à ceci :

[[email protected]<machine> lbh]$ ls -al
total 16
drwxr-s---. 4 lbh  200T 4096 Oct  1 02:40 .
drwxr-sr-x. 4 root 200T 4096 Oct  1 02:18 ..
drwxrwsr-x. 2 lbh  200T 4096 Oct  1 02:26 aaa_lbh
drwxr-sr-x. 2 root 200T 4096 Oct  1 02:26 aaa_root
-rw-rw-r--. 1 lbh  200T    0 Oct  1 02:38 file_lbh.txt
-rw-r--r--. 1 root 200T    0 Oct  1 02:40 file_root.txt
[[email protected]<machine> lbh]$ pwd
/asic/200T/lbh
[[email protected]<machine> lbh]$ cd ..
[[email protected]<machine> 200T]$ ls -al
total 16
drwxr-sr-x. 4 root 200T 4096 Oct  1 02:18 .
drwxr-x---. 3 root asic 4096 Oct  1 02:16 ..
drwxr-sr-x. 2 root 200T 4096 Oct  1 02:18 aaa
drwxr-s---. 4 lbh  200T 4096 Oct  1 02:40 lbh
[[email protected]<machine> 200T]$ pwd
/asic/200T
[[email protected]<machine> 200T]$ 

Et les getfaclrésultats des répertoires et des fichiers sont les suivants :

[[email protected]<machine> Desktop]$ getfacl /asic
getfacl: Removing leading '/' from absolute path names
# file: asic
# owner: root
# group: asic
user::rwx
group::r-x
other::---

[[email protected]<machine> Desktop]$ getfacl /asic/200T/
getfacl: Removing leading '/' from absolute path names
# file: asic/200T/
# owner: root
# group: 200T
# flags: -s-
user::rwx
group::r-x
other::r-x

[[email protected]<machine> Desktop]$ getfacl /asic/200T/lbh
getfacl: Removing leading '/' from absolute path names
# file: asic/200T/lbh
# owner: lbh
# group: 200T
# flags: -s-
user::rwx
group::r-x
other::---

[[email protected]<machine> Desktop]$ getfacl /asic/200T/lbh/aaa_lbh/
getfacl: Removing leading '/' from absolute path names
# file: asic/200T/lbh/aaa_lbh/
# owner: lbh
# group: 200T
# flags: -s-
user::rwx
group::rwx
other::r-x

[[email protected]<machine> Desktop]$ getfacl /asic/200T/lbh/aaa_root/
getfacl: Removing leading '/' from absolute path names
# file: asic/200T/lbh/aaa_root/
# owner: root
# group: 200T
# flags: -s-
user::rwx
group::r-x
other::r-x

[[email protected]<machine> Desktop]$ getfacl /asic/200T/lbh/file_lbh.txt 
getfacl: Removing leading '/' from absolute path names
# file: asic/200T/lbh/file_lbh.txt
# owner: lbh
# group: 200T
user::rw-
group::rw-
other::r--

[[email protected]<machine> Desktop]$ getfacl /asic/200T/lbh/file_root.txt 
getfacl: Removing leading '/' from absolute path names
# file: asic/200T/lbh/file_root.txt
# owner: root
# group: 200T
user::rw-
group::r--
other::r--

[[email protected]<machine> Desktop]$ touch hello.txt
[[email protected]<machine> Desktop]$ mkdir hi 
[[email protected]<machine> Desktop]$ ls -al
total 12
drwxr-xr-x.  3 lbh lbh 4096 Oct  9 17:28 .
drwx------. 36 lbh lbh 4096 Oct  9 17:21 ..
-rw-rw-r--.  1 lbh lbh    0 Oct  9 17:27 hello.txt
drwxrwxr-x.  2 lbh lbh 4096 Oct  9 17:28 hi
[[email protected]<machine> Desktop]$ getfacl hi
# file: hi
# owner: lbh
# group: lbh
user::rwx
group::rwx
other::r-x

[[email protected]<machine> Desktop]$ getfacl hello.txt 
# file: hello.txt
# owner: lbh
# group: lbh
user::rw-
group::rw-
other::r--

[[email protected]<machine> Desktop]$ 
answer

Linux ne prend pas en charge l'héritage des autorisations, vous ne pouvez donc pas faire ce que vous avez demandé dans le sujet de la question.

Le mieux que vous puissiez faire est de définir l' ACL POSIX par défaut qui s'appliquera à tous les fichiers et répertoires nouvellement créés. Ce n'est pas l'héritage, juste la valeur par défaut :

setfacl -m default:user:<username>:rwx <dir>
setfacl -m default:group:<groupname>:rwx <dir>

Après cela, si quelqu'un crée un fichier ou un répertoire dans (s'il est autorisé à y créer des objets, bien sûr), cet objet recevra des ACL user:<username>:rwxet des fichiers group:<groupname>:rwx. Vous pouvez définir des autorisations par défaut pour le propriétaire et le propriétaire du groupe en définissant <username>et <groupname>vide.

Ce "par défaut" ne peut être défini que sur un répertoire, car il ne sert à rien de l'appliquer aux fichiers. Les autorisations définies de cette manière sont également masquées par des umasks, donc si un bit est supprimé dans umask, ce bit sera supprimé d'une autorisation. Par exemple, lorsque vous créez un fichier, si vous ne lui donnez pas de bit exécutable, il ne sera pas rendu exécutable (comme prévu). Les sous-répertoires créés auront également les mêmes ACL "par défaut", donc ses descendants auront également ces ACL définies. Vous devez supprimer ou modifier les ACL sur les sous-répertoires après la création pour arrêter cette propagation.

Vérifiez l'ACL avec getfacl <dir>. Bien sûr, il pourrait y avoir plusieurs de ces valeurs par défaut (et il semble que vous deviez vous retrouver avec plusieurs règles) ; au moins, les exigences que j'ai rencontrées imposaient toujours la présence d'au moins deux ACL de groupe par défaut).


Vous ne pouvez pas définir les "propriétaires de fichiers par défaut" de cette façon, le propriétaire sera toujours configuré pour créer un uid effectif de processus. Par défaut, group-owner sera configuré pour traiter gid, mais vous pouvez changer cela en utilisant le bit setgid sur le répertoire parent :

    chmod g+s <dir>

après cela, tout objet créé dans ce répertoire copiera son propriétaire de groupe par défaut, même si l'utilisateur créateur n'appartient pas à ce groupe. Ce bit setgit se propage dans les sous-répertoires.

Les propriétaires peuvent définir le propriétaire du groupe sur n'importe quel groupe auquel ils appartiennent. S'ils n'appartenaient pas à ce groupe dérivé de setgid, ils peuvent changer leur propriétaire de groupe de fichiers en n'importe quel groupe auquel ils appartiennent, mais après cela, ils ne pourront plus le reconfigurer en valeur setgid.


Je tiens à noter à nouveau explicitement, ce n'est pas un héritage, il s'agit de paramètres par défaut qui ne sont pas exactement les mêmes. Si vous modifiez quelque chose sur l'objet parent par la suite, les objets déjà créés conserveront toujours leurs autorisations sous Linux.

Alors que, par exemple, dans Windows, lorsque vous définissez les ACL de sous-objet sur « hériter », le chaînage des ACL parentes affectera les descendants, ce qui est l'héritage approprié.