facl, setfacl, partage de répertoire, pourquoi cp met-il les autorisations de fichier dorigine dans le masque facl? ' ne devrait-il pas être un comportement cp -p?

Les utilisateurs de ce système sont prudents et ont leurs umasks définis sur le 0077 très privé. Cependant, les utilisateurs aimeraient avoir des répertoires spécifiques au groupe, où les fichiers peuvent être copiés de manière à les partager explicitement uniquement entre les autres membres du groupe. Il peut y avoir plusieurs répertoires de partage de ce type bien que chacun soit spécifique à un groupe.

Définir le sticky bit de groupe sur un répertoire donné à utiliser pour le partage nest pas suffisant. Bien que la définition du bit sticky entraîne la propriété du groupe sur les fichiers placés dans le répertoire, les autorisations sur lesdits fichiers sont souvent définies de telle sorte que les fichiers ne peuvent pas être lus ou modifiés, cest-à-dire ne peuvent pas être partagés. Ils apparaissent simplement dans la liste du répertoire. Cela est dû au fait que certains utilisateurs ne pensent pas ou ne savent pas comment procéder manuellement au réglage des autorisations de groupe requises pour permettre la lecture et lécriture. Nous pouvons leur donner une pause car les utilisateurs ne sont pas des administrateurs, après tout. acls peut être utilisé pour spécifier quun groupe particulier a accès aux fichiers dans le répertoire de partage, indépendamment de ce que les permissions du groupe auraient été sans acls. Cest la solution parfaite, mais cela ne fonctionne pas tout à fait.

Dans ce qui suit, le groupe partagé est « customer_gateway » et lexemple dutilisateur essayant de partager un fichier est « svw ». Comme on peut le voir dans la transcription, lutilisateur svw est membre du groupe customer_gateway. Le répertoire dans lequel le partage doit avoir lieu est également appelé « customer_gateway / »

Ce qui suit utilise acls. Jai défini les autorisations de groupe, les autorisations de groupe par défaut, le masque et le masque par défaut. Cela fonctionne bien pour les fichiers créés dans le répertoire, ou pour les fichiers qui y sont déplacés via cat (ou tar), mais étrangement, pas pour les fichiers qui « cp » y sont:

# rm -r customer_gateway/ # umask 0077 # cat ~/script1 mkdir customer_gateway chown :customer_gateway customer_gateway/ chmod g+rwx customer_gateway/ setfacl -m group:customer_gateway:rwX customer_gateway/ setfacl -m d:group:customer_gateway:rwX customer_gateway/ setfacl -m m::rwX customer_gateway/ setfacl -m d:m::rwX customer_gateway/ getfacl customer_gateway cd customer_gateway touch cga cat << EOF > cgb c g b EOF ls -l # . ~/script1 # file: customer_gateway # owner: root # group: customer_gateway user::rwx group::rwx group:customer_gateway:rwx mask::rwx other::--- default:user::rwx default:group::rwx default:group:customer_gateway:rwx default:mask::rwx default:other::--- total 4 -rw-rw----+ 1 root root 0 Mar 2 20:43 cga -rw-rw----+ 1 root root 6 Mar 2 20:43 cgb # su - svw /home/svw/bin:/usr/local/bin:/usr/bin:/bin (note umask is 0077) > cd /share/customer_gateway/ > groups svw adm dip video plugdev google-sudoers customer_gateway > cat >> cga e f g > cat > cgc c g c > ls -l total 12 -rw-rw----+ 1 root root 6 Mar 2 20:44 cga -rw-rw----+ 1 root root 6 Mar 2 20:43 cgb -rw-rw----+ 1 svw svw 6 Mar 2 20:44 cgc > ls ~/dat ta tb tc > cat ~/dat/ta > ta > cp ~/dat/tb tb > ls -l total 20 -rw-rw----+ 1 root root 6 Mar 2 20:44 cga -rw-rw----+ 1 root root 6 Mar 2 20:43 cgb -rw-rw----+ 1 svw svw 6 Mar 2 20:44 cgc -rw-rw----+ 1 svw svw 4 Mar 2 20:45 ta -rw-------+ 1 svw svw 4 Mar 2 20:45 tb > getfacl ta # file: ta # owner: svw # group: svw user::rw- group::rwx #effective:rw- group:customer_gateway:rwx #effective:rw- mask::rw- other::--- > getfacl tb # file: tb # owner: svw # group: svw user::rw- group::rwx #effective:--- group:customer_gateway:rwx #effective:--- mask::--- other::--- > 

Ce que cela montre, cest que lorsquun fichier est créé dans le répertoire, il reçoit les autorisations par défaut et est partageable. Mais les utilisateurs ne créent pas toujours leurs fichiers là-bas, généralement ils les copient là-bas.

Mais faire une copie est la même chose, car pour faire une copie, nous devons dabord créer un nouveau fichier. Nous parlons de une copie simple ici, pas une copie des permissions de conservation. Cest le même que le formulaire suivant, qui, btw fonctionne et copie un fichier qui sera partageable dans le répertoire indépendamment de ses permissions de groupe dorigine:

cat < data.in > shared/data.out 

fonctionne très bien, le piping via tar fonctionne également, mais la forme

cp data.in shared/data.out 

échoue. cat ed le fichier obtient le masque par défaut et les permissions par défaut. Le fichier cp ed préserve ses permissions dans le masque acl et les permissions de groupe, comme sil létait un cp -p (mais ce nétait pas « t), et donc les permissions effectives se lisent comme le fichier original, pas ce sur quoi les acl ont été définies.

Dans un deuxième essai, jai lancé cette expérience avec le groupe sticky bit, chmod g + rwxs, avec le facl ch anges, et a obtenu exactement les mêmes résultats. Bien que les listes de répertoires soient plus jolies en raison de la propriété du groupe affichée pour tous les fichiers partagés. Je lai aussi exécuté avec uniquement le sticky bit du groupe défini, sans setfacl. Il a également eu le même résultat pour les fichiers copiés (donc les facls semblent assez inutiles pour un répertoire où les fichiers sont copiés pour être partagés).

Sur quelle base et avec quelle justification les facls linux distinguent-ils les différentes formes de créer des données? Pourquoi forcer cp à conserver les permissions alors quon ne lui a pas dit de faire ça? Quelle raison justifierait la confusion causée par cette distinction entre chat et piping par le biais de tar fonctionnant mais cp ne fonctionnant pas? Est-ce que je manque une incantation magique qui ferait cette distinction sévaporer?

Ce résumé est-il correct: les facls vous permettront de surmonter la propriété de partager des fichiers, cela rendra les autorisations plus permissives que lumask lors de la « création » de fichiers, à moins que cette création ne soit due à la commande cp et pour une bonne raison parce que … parce que pourquoi?

Commentaires

• Quel système dexploitation (distribution et version Linux) et quel système de fichiers utilisez-vous? Serait-il acceptable de faire en sorte que les gens utilisent cat, peut-être via un shellscript dédié à cet effet?
• Avez-vous lintention que nimporte quel utilisateur du groupe puisse modifier ou supprimer nimporte quel fichier, ou est-ce que seul le créateur devrait avoir de telles autorisations?
• Debian 10. Parce que la création de fichiers fonctionne, ‘ ai envoyé des copies via tar. Je ‘ je le paquet comme une commande proj_cp dans / usr / local / bin. Cependant, si un utilisateur doit utiliser une commande de copie spéciale, alors on peut simplement utiliser le sticky bit de groupe sans facls et définir les autorisations. Je veux savoir comment paramétrer les acl pour que cat tar et cp fonctionnent.Je ‘ m pense quil y a un problème avec acls avec cp, car ils font le comportement cp -p au lieu du comportement cp. Jai ‘ hâte dentendre des experts en autorisations.
• Le partage de groupe est un problème récurrent avec des variantes, comme vous le faites remarquer. Dans ce cas, les développeurs de logiciels ont accès au répertoire des versions de test. Cest à eux de jouer avec. Ils peuvent travailler dans ce répertoire, pousser, tirer, installer dans lenvironnement virtuel, etc. Le problème survient lorsquils copient des choses depuis une autre zone dans laquelle ils ont travaillé et que leurs umasks ne sont pas définis avec des autorisations de groupe. Cest déroutant pour eux car la création et la copie de fichiers par tar fonctionnent bien. Cest aussi drôle que je doive leur donner un script de copie qui fait exactement ce que fait cp. ‘ acls ‘ ils sont magiques je dis LOL
• Je ne suis pas un expert en permissions, mais jespère que mes questions et vos réponses peuvent aider les experts à vous apporter des réponses pertinentes.