¿Por qué cp no respeta las ACL?

Una forma común de configurar un directorio para compartir archivos dentro de un grupo es:

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

Esto garantiza que el grupo pueda fooleer y escribir cualquier archivo creado en 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

Sin embargo, si copia un archivo foo, no se aplican las ACL predeterminadas:

$ 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--

¿Por qué sucede esto? ¿Hay alguna forma de evitarlo?

( Mover un archivo al directorio no respeta las ACL ni la propiedad del grupo, pero puedo entender por qué: es posible que no desee que cambien los permisos de un archivo simplemente porque cambia su nombre).

Si cpcrea el archivo de destino, replica los permisos del archivo de origen, excepto los bits que se establecen en la máscara de usuario. Este es el comportamiento estándar (consulte, por ejemplo, el paso 3.b en la especificación Single Unix v3 (POSIX 2001) .

¿Por qué se diseñó CP de esta manera? Debido a que hay muchos casos en los que este comportamiento es deseable, por ejemplo, preservar la privacidad de un archivo cuando los permisos originales son restrictivos, y preservar la capacidad de ejecución es casi siempre lo correcto. Sin embargo, es lamentable que ni siquiera GNU cp tenga una opción para desactivar este comportamiento.

La mayoría de las herramientas de copia (por ejemplo, pax, rsync) se comportan de la misma manera. Puede asegurarse de que el archivo se creará con el permiso predeterminado desacoplando el origen del destino, por ejemplo con cat <baz >foo/baz.

Bueno, una pregunta de tres años y más pero aún relevante. Para futuros lectores, quiero agregar que se espera que los comandos mv, cp no sigan la ACL del directorio de destino. La respuesta de Gilles está bien, pero la última oración. La mejor manera de aplicar la ACL del destino al archivo copiado / movido es la manera mencionada aquí:

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

En caso de que el enlace se rompa en el futuro, pego el contenido aquí:

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

copie ACL de un archivo a otro usando getfacl y setfacl

ADVERTENCIA: la ACL existente se perderá.

Tuve un problema similar con los archivos rsynced que carecen de las ACL predeterminadas adecuadas en el subdirectorio de destino. Cp no tiene una forma de establecer los permisos en el objetivo. Pero, rsync sí, usando la --chmod=ugo=rwxbandera. Mira mi respuesta aquí .

Necesitas usar -po --preservecon cp.

De man 5 acl:

CAMBIOS A LAS UTILIDADES DE ARCHIVO

 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.

Las ACL se propagan correctamente, pero la máscara predeterminada no parece ser correcta. Probablemente desee que su máscara predeterminada sea rwX.

setfacl -dm m::rwX foo

Si eso no funciona, publique la ACL para foo.

¿Su sistema de archivos está montado con la opción "ACL" habilitada?

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

Si no, realice el cambio y luego vuelva a montar.

mount -o remount /wherefolderislocated

Por lo que veo, usted es el propietario de los archivos (bhm) antes y después del cp. Como muestra la lista del directorio, el propietario tiene acceso de lectura y escritura.