Por que o cp não respeita as ACLs?

Uma maneira comum de configurar um diretório para compartilhamento de arquivos em um grupo é:

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

Isso garante que todos os arquivos criados foosejam legíveis e graváveis ​​pelo grupo 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

No entanto, se você copiar um arquivo foo, as ACLs padrão não serão aplicadas:

$ 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 que isso acontece e existe uma maneira de contornar isso?

( Mover um arquivo para o diretório não respeita as ACLs ou a propriedade do grupo, mas eu entendo o motivo: você pode não querer que as permissões de um arquivo sejam alteradas simplesmente porque você altera o nome.)

Se cpcria o arquivo de destino, ele replica as permissões do arquivo de origem, exceto os bits definidos no umask. Esse é um comportamento padrão (consulte, por exemplo, a etapa 3.b na especificação Single Unix v3 (POSIX 2001) .

Por que o cp foi projetado dessa maneira? Como há muitos casos em que esse comportamento é desejável, por exemplo, preservar a privacidade de um arquivo quando as permissões originais são restritivas e preservar a executabilidade é quase sempre a coisa certa a se fazer. No entanto, é lamentável que nem mesmo o GNU cp tenha uma opção para desativar esse comportamento.

A maioria das ferramentas de cópia (por exemplo, pax, rsync) se comporta da mesma maneira. Você pode garantir que o arquivo seja criado com a permissão padrão, dissociando a fonte do destino, por exemplo, com cat <baz >foo/baz.

Bem, uma criança de três anos e mais perguntas, mas ainda relevante. Para futuros leitores, quero acrescentar que é esperado que os comandos mv, cp não sigam a ACL do diretório de destino. A resposta de Gilles está bem, exceto a última frase. A melhor maneira de aplicar a ACL do destino ao arquivo copiado / movido é a maneira mencionada aqui:

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

Caso o link seja quebrado no futuro, colo o conteúdo aqui:

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

copie a ACL de um arquivo para outro usando getfacl e setfacl

AVISO: A ACL existente será perdida.

Eu tive um problema semelhante com arquivos rsynced sem as ACLs padrão apropriadas no subdiretório de destino. O Cp não tem como definir as permissões no destino. Mas, o rsync faz isso, usando a --chmod=ugo=rwxflag. Veja minha resposta aqui .

Você precisa usar -pou --preservecom cp.

De man 5 acl:

ALTERAÇÕES NAS UTILIDADES DE ARQUIVO

 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.

As ACLs estão se propagando corretamente, mas a máscara padrão não parece estar correta. Você provavelmente deseja que sua máscara padrão seja rwX.

setfacl -dm m::rwX foo

Se isso não funcionar, publique a ACL para foo.

O seu sistema de arquivos está montado com a opção "ACL" ativada?

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

Caso contrário, faça a alteração e remonte novamente.

mount -o remount /wherefolderislocated

Pelo que vejo, você é o proprietário dos arquivos (bhm) antes e depois do cp. Como a lista de diretórios mostra, o proprietário tem acesso de leitura e gravação!