Por que o rsync está recebendo erros de “permissão negada” no Mac OS X quando as ACLs estão definidas para o usuário correto?

Question

Estou fazendo a transição de uma ferramenta antiga que inicia um rsync (copiando de um caminho local para um caminho remoto com teclas host SSH) por meio de um formulário web (completamente atrás de um firewall com várias camadas de autenticação, não isso é uma desculpa) hospedada no Mac OS X 10.6 Snow Leopard Server. Para contornar o fato de que rsync é executado por _www , mas os arquivos são de propriedade de someuser (mais as chaves host SSH são para someuser ), o autor original fez uma cópia do rsync binário w / permissões de 4755 & someuser como o proprietário (assim, qualquer pessoa que executar essa cópia de rsync executará como o usuário someuser ). Um hack sujo, com certeza, mas funciona (e foi escrito antes mesmo do Mac OS X ter suporte para ACLs, então é pelo menos um pouco compreensível, embora ainda seja atroz do ponto de vista da segurança). / p>

Como meu primeiro passo para me afastar dessa solução, alterei as permissões desses arquivos de 777 (de propriedade de someuser ) para 755 (ainda de propriedade de someuser ) e, em seguida, defino ACLs para _www para ter acesso total a esses arquivos, da seguinte maneira:

chmod -R +a "_www allow read,write,delete,add_file,add_subdirectory,file_inherit,directory_inherit" /path/to/directory

Infelizmente, apesar de ainda usar o mesmo binário rsync com o bit set-user-ID-on-execution definido para someuser , rsync agora gera o seguinte erro:

building file list ... rsync: link_stat "/path/to/directory/subdir/." failed: Permission denied (13)
done

sent 332 bytes  received 20 bytes  704.00 bytes/sec
total size is 0  speedup is 0.00
rsync error: some files could not be transferred (code 23) at /SourceCache/rsync/rsync-30/rsync/main.c(717)

Se eu verificar as permissões desse diretório, elas parecem corretas:

$ ls -ael /path/to/directory/
total 0
drwxr-x---+  3 someuser  admin  102 Jun 23 19:00 .
 0: user:_www allow list,add_file,delete,add_subdirectory,file_inherit,directory_inherit
drwxr-xr-x   8 someuser  admin  272 Jun 23 18:57 ..
drwxr-xr-x+ 17 someuser  admin  578 Jun 23 17:15 subdir
 0: user:_www allow list,add_file,delete,add_subdirectory,file_inherit,directory_inherit

O mesmo vale para um arquivo no diretório:

$ ls -ael /path/to/directory/subdir/file.txt 
-rwxr-xr-x+ 1 someuser  admin  107 Jun 23 17:15 subdir/file.txt
 0: user:_www allow read,write,delete,append

O que causaria esse erro de permissão, pois os arquivos ainda são de propriedade do usuário que o binário rsync executa, mais o usuário _www deve ter ACLs completas para o diretório & arquivos?

Atualização: parece que é um problema de ACL, pois a execução de sudo -u _www ls -ael /path/to/directory/ resulta também em erros de "permissão negada":

ls: .: Permission denied
ls: ..: Permission denied
ls: subdir: Permission denied'

Então, o que há de errado com as ACLs que eu defini?

    

Answer 1

No Server Admin.app, ativei a preferência "Mostrar contas do sistema no navegador de grupos de usuários e grupos" e, em seguida, acesse o Compartilhamento de arquivos e navegue até /path/to/directory/ (w / "Volumes" e "Navegar" selecionado em a barra de ferramentas) Eu adicionei um "Custom" ACL (sem "Administração", mas todos os "Read", "Write" e "Aplica-se a") para o usuário '_www' e propagou as permissões.

Isso resultou no seguinte ao executar ls como o usuário '_www':

$ sudo -u _www ls -ale /path/to/directory
total 0
drwxr-x---+  3 someuser  admin  102 Jun 23 19:00 .
 0: user:_www allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit
drwxr-xr-x   8 someuser  admin  272 Jun 23 18:57 ..
drwxr-xr-x+ 17 someuser  admin  578 Jun 23 17:15 subdir
 0: user:_www inherited allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit

Então, isso resolveu o problema. Ao olhar para as ACLs que foram definidas, parece que foi provavelmente o acesso de 'procura' em falta que estava causando as falhas (talvez algumas das outras, embora pareçam estar relacionadas apenas a atributos estendidos).

    

Answer 2

Se você transferir arquivos para armazenamento remoto (como FreeNAS, etc) - não se esqueça de definir regras corretas. Não apenas defina proprietário , mas inclua esta própria lista de leitura / gravação também.

Estou viciado nisso.