Por que o cp não respeita as ACLs?

Question

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 em foo sejam 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 para 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 há uma maneira de contornar isso?

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

    

Answer 1

Se cp criar o arquivo de destino, ele replicará as permissões do arquivo de origem, exceto os bits definidos no umask. Este é um comportamento padrão (veja, por exemplo, a etapa 3.b na especificação Unix v3 (POSIX 2001) .

Por que o cp foi projetado dessa maneira? Porque há muitos casos em que esse comportamento é desejável, por exemplo, preservando a privacidade de um arquivo quando as permissões originais são restritivas, e preservar a executabilidade é quase sempre a coisa certa a 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 será criado com a permissão padrão ao desacoplar a origem do destino, por exemplo, com cat <baz >foo/baz .

    

Answer 2

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

link

Caso o link seja quebrado no futuro, eu 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.

    

Answer 3

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

    

Answer 4

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

setfacl -dm m::rwX foo

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

    

Answer 5

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

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

Se não, faça a alteração então remontar.

mount -o remount /wherefolderislocated

    

Answer 6

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

    

Answer 7

Você precisa usar -p ou --preserve com cp .

De man 5 acl :

CHANGES TO THE FILE UTILITIES

 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.