Como fazer com que a nova permissão de arquivo seja herdada do diretório pai?

85

Eu tenho um diretório chamado data. Então, eu estou executando um script com o ID do usuário 'robot'. O robô grava no datadiretório e atualiza os arquivos. A ideia é dataabrir para eu e o robô atualizarmos.

Então eu configurei a permissão e o grupo de proprietários como este

drwxrwxr-x  2 me robot-grp 4096 Jun 11 20:50 data

onde eu e o robô pertencemos ao 'robot-grp'. Altero a permissão e o grupo de proprietários recursivamente como o diretório pai.

Eu carrego regularmente novos arquivos no datadiretório usando rsync. Infelizmente, novos arquivos enviados não herdam a permissão do diretório pai, como espero. Em vez disso, parece com isso

-rw-r--r-- 1 me users       6 Jun 11 20:50 new-file.txt

Quando o robô tenta atualizar new-file.txt, ele falha devido à falta de permissão de arquivo.

Não tenho certeza se a configuração do umask ajuda. Em qualquer caso, os novos arquivos realmente não o seguem.

$ umask -S
u=rwx,g=rx,o=rx

Muitas vezes fico confuso com a permissão de arquivo Unix. Eu tenho mesmo um plano certo? Estou usando o Debian lenny.

— Wai Yip Tung
fonte

53

Você não deseja alterar o umask padrão do seu sistema, que é um risco à segurança. A opção de bit pegajoso funcionará até certo ponto, mas usar ACLs é o melhor caminho a percorrer. Isso é mais fácil do que você pensa. O problema com as ACLs básicas é que elas não são recursivas por padrão. Se você definir uma ACL em um diretório, apenas os arquivos dentro desse diretório herdarão a ACL. Se você criar um subdiretório, ele não obterá a ACL pai, a menos que a ACL esteja definida como recursiva.

Primeiro, verifique se as ACLs estão ativadas para o volume em que o diretório está. Se você tiver tune2fs, você pode executar o seguinte:

# tune2fs -l /dev/sda1 | grep acl
Default mount options:    user_xattr acl

Se você não tiver tune2fs, examine fstabs:

# cat /etc/fstab 
/dev/system/root        /                       ext3    defaults        1 1
/dev/system/home        /home                   ext3    defaults        1 2
/dev/storage/data       /data                   ext3    defaults        1 2
LABEL=/boot             /boot                   ext3    defaults        1 2

A quarta coluna que diz "padrões" significa que, no meu sistema (CentOS 5.5), as ACLs estão ativadas. Em caso de dúvida, deixe como padrão. Se você tentar definir a ACL e ele erros fora, voltar e adicionar a opção acl para / etc / fstab logo após padrões: defaults,acl.

Pelo que entendi, você deseja que todos no grupo de usuários tenham acesso de gravação ao diretório de dados. Isso é realizado pelo seguinte:

setfacl -Rm g:users:rwX,d:g:users:rwX data/

— churnd
fonte

Eu usei esse comando, mas ele não resolveu o meu problema, como posso desfazer esse comando?

— Itai Ganot 15/08/13

Fiz o truque no ubuntu com sudo setfacl -Rm g:users:rwX,d:g:users:rwX /var/www/logs_or_something. Teve problema com os testes PHPUnit. Após criar os arquivos de log dos testes em execução, o usuário do apache www-datanão pôde gravá-los / lê-los.

— S3m3n

2

@Itai Ganot - de acordo com a setfaclpágina do manual , -bou --remove-allremove as ACLs estendidas.

— JWW

Então, você apenas acrescentaria setfacl -Rm g:users:rwX,d:g:users:rwX data/no final de /etc/fstab?

— precisa saber é o seguinte

@ piña no. a única alteração que você faz no / etc / fstab é mudar defaultspara defaults,acl. setfaclé um comando que você deve executar a partir do terminal. data/deve ser substituído pelo caminho para o diretório que você deseja alterar.

— Segfault

32

Marcar um diretório setgid ( g+s) fará com que novos arquivos herdem a propriedade do grupo no diretório, mas a -gopção do rsync tentará substituir isso.

— Ignacio Vazquez-Abrams
fonte

11

O bit setgid apenas faz com que os arquivos criados herdem o grupo / se / a pessoa que cria o novo arquivo for membro desse grupo; se o usuário criador for o proprietário, mas não um membro do grupo, ou o diretório for gravável no mundo, o bit setgid não fará nada. E o umask para todos os usuários criadores de arquivos ainda precisa ser definido para permitir o acesso apropriado ao grupo.

— dannysauer

1

@dannysauer "se o usuário criador for o proprietário, mas não um membro do grupo ... o bit setgid não fará nada" - obrigado. Faz sentido agora - mas sem o feedback do rsync, estava se perguntando por que não estava funcionando.

— user12345 5/02

4

Outras respostas se aplicam em um caso geral, mas como você menciona que o rsync é uma fonte do problema, pode ser necessário ajustar sua chamada.

Para começar, o -asinalizador popular concede permissões de cópia ao rsync; use -ristead -aou add -no-p(para sincronização sem permissão) e -no-g(para sincronização sem grupo). O rsync também suporta --chmodsinalizador para alterar as permissões nos arquivos recém-criados.

— mbq
fonte

3

Seu umask está errado para as permissões que você deseja. Você deseja uma umask de 002. Atualmente, você tem uma umask de 022. Além disso, o comentário sobre como definir o diretório setgid está correto, mas não tenho certeza se a propriedade do grupo de arquivos é algo que você deseja alterar ou não.

Permissões de arquivo Unix são na verdade um modelo muito simples. Acho ACLs completamente me confundindo. :-)

— Omniforme
fonte

4

"As permissões de arquivo Unix são na verdade um modelo muito simples. Acho as ACLs completamente confusas." - Eu meio que sinto o contrário (mas +1 de qualquer maneira). As ACLs (e Permitir / Negar ACEs) são simples, e as permissões Unix não fazem sentido. Mas isso é proveniente de um cara que está sofrendo uma instalação do Postfix / Dovecot / Clam / SpamAssassin.

— JWW