Pourquoi cp ne respecte-t-il pas les ACL?

Une façon courante de configurer un répertoire pour le partage de fichiers au sein d'un groupe est la suivante:

$ mkdir foo
$ chgrp felles foo
$ chmod g+ws foo
$ setfacl -m group:felles:rwx foo
$ setfacl -dm group:felles:rwx foo

Cela garantit que tous les fichiers créés dans foosont lisibles et inscriptibles par le groupe felles:

$ umask
0022
$ echo hi > foo/bar
$ ls -l foo
total 4
-rw-rw-r--+ 1 bhm felles 3 2010-09-23 00:18 bar

Cependant, si vous copiez un fichier dans foo, les ACL par défaut ne sont pas appliquées:

$ echo you > baz
$ cp baz foo/
$ ls -l foo
total 8
-rw-rw-r--+ 1 bhm felles 3 2010-09-23 00:18 bar
-rw-r--r--+ 1 bhm felles 4 2010-09-23 00:19 baz
$ getfacl foo/baz
# file: foo/baz
# owner: bhm
# group: felles
user::rw-
group::rwx          #effective:r--
group:felles:rwx        #effective:r--
mask::r--
other::r--

Pourquoi cela se produit-il et y a-t-il un moyen de le contourner?

(Le déplacement d' un fichier dans le répertoire ne respecte ni les listes de contrôle d'accès ni la propriété du groupe, mais je peux comprendre pourquoi: vous ne voudrez peut-être pas que les autorisations d'un fichier changent simplement parce que vous changez son nom.)

Si cpcrée le fichier de destination, il réplique les autorisations du fichier source, à l'exception des bits définis dans l'umask. Il s'agit d'un comportement standard (voir par exemple l'étape 3.b de la spécification Single Unix v3 (POSIX 2001) .

Pourquoi cp a-t-il été conçu de cette façon? Parce qu'il existe de nombreux cas où ce comportement est souhaitable, par exemple la préservation de la confidentialité d'un fichier lorsque les autorisations d'origine sont restrictives, et la préservation de l'exécutabilité est presque toujours la bonne chose à faire. Il est cependant regrettable que même GNU cp n'ait pas la possibilité de désactiver ce comportement.

La plupart des outils de copie (par exemple pax, rsync) se comportent de la même manière. Vous pouvez vous assurer que le fichier sera créé avec l'autorisation par défaut en découplant la source de la destination, par exemple avec cat <baz >foo/baz.

Eh bien, une question de trois ans et plus, mais toujours d'actualité. Pour les futurs lecteurs, je veux ajouter qu'il est prévu que les commandes mv, cp ne suivent pas l'ACL du répertoire de destination. La réponse de Gilles est très bien, mais la dernière phrase. La meilleure façon d'appliquer l'ACL de destination au fichier copié / déplacé est la manière mentionnée ici:

http://www.commandlinefu.com/commands/view/4281/copy-acl-of-one-file-to-another-using-getfacl-and-setfacl

Dans le cas où le lien serait rompu à l'avenir, je colle le contenu ici:

getfacl <file-with-acl> | setfacl -f - <file-with-no-acl>

copier l'ACL d'un fichier dans un autre en utilisant getfacl et setfacl

AVERTISSEMENT: l'ACL existante sera perdue.

J'ai eu un problème similaire avec des fichiers rsynced dépourvus des ACL par défaut appropriées dans le sous-répertoire cible. Cp n'a pas de moyen de définir les autorisations sur la cible. Mais rsync le fait en utilisant le --chmod=ugo=rwxdrapeau. Voir ma réponse ici .

Vous devez utiliser -pou --preserveavec cp.

De man 5 acl:

MODIFICATION DES UTILITAIRES DE FICHIER

 On a system that supports ACLs, the file utilities ls(1), cp(1), and
 mv(1) change their behavior in the following way:

 ·   For files that have a default ACL or an access ACL that contains more
     than the three required ACL entries, the ls(1) utility in the long
     form produced by ls -l displays a plus sign (+) after the permission
     string.

 ·   If the -p flag is specified, the cp(1) utility also preserves ACLs.
     If this is not possible, a warning is produced.

 ·     The mv(1) utility always preserves ACLs. If this is not possible, a
     warning is produced.

 The effect of the chmod(1) utility, and of the chmod(2) system call, on
 the access ACL is described in CORRESPONDENCE BETWEEN ACL ENTRIES AND
 FILE PERMISSION BITS.

Les ACL se propagent correctement, mais le masque par défaut ne semble pas être correct. Vous voulez probablement que votre masque par défaut soit rwX.

setfacl -dm m::rwX foo

Si cela ne fonctionne pas, veuillez publier l'ACL pour foo.

Votre système de fichiers est-il monté avec l'option "ACL" activée?

/dev/sda4        /wherefolderislocated         ext3        defaults,acl     1   2

Sinon, effectuez la modification puis remontez.

mount -o remount /wherefolderislocated

D'après ce que je vois, vous êtes le propriétaire des fichiers (bhm) avant et après le cp. Comme le montre la liste des répertoires, le propriétaire dispose d'un accès en lecture et en écriture!