Forçando Permissões do Linux Stickybits ou ACLs

Question

Eu tenho uma pergunta / confusão sobre forçar permissões herdadas no Linux (ou seja, CentOS 6)

A configuração:

1 x servidor de arquivos do CentOS

2 x clientes NFS do CentOS

Lotes x clientes do Windows Samba

O compartilhamento de arquivos é / srv / share compartilhado com as permissões locais do Samba e do NFS da seguinte forma: h

drwxrwx---. 2 root sharegroup 4.0K Oct 22 14:41 share

Todos os UIDs / GIDs unificados por meio do Active Directory, o grupo principal de todos os usuários é 'sharegroup'.

Cliente NFS montado no fstab como:

tst-lnx03:/srv/share    /mnt/share            nfs     defaults                0 0

Caixa do Windows por meio do caminho UNC:

\tst-lnx03\share

O que eu gostaria:

Qualquer coisa escrita / criada na pasta / srv / share, seja ela do NFS ou do Samba, digamos que seja 770 sharegroup raiz.

O que tentei:

Eu tentei usar ACLs:

setfacl -m d:u:root:rwx,d:g:"sharegroup":rwx,d:other:--- share

Com o resultado:

ls -lah
-rwxrwx---+ 1 testuser11 sharegroup    0 Oct 22 14:25 tu12-smb-win
-rw-rw----+ 1 testuser2  sharegroup    0 Oct 22 14:23 tu2-local-local
-rw-r-----+ 1 testuser4  sharegroup    0 Oct 22 14:24 tu4-NFS-lnx04

Eu tentei usar bits pegajosos:

chmod 2770 share

Com o resultado:

ls -lah
-rwxr--r--  1 testuser11 k8 sharegroup   0 Oct 22 14:38 tu12-smb-win
-rw-r--r--  1 testuser2  k8 sharegroup   0 Oct 22 14:38 tu2-local-local
-rw-r--r--  1 testuser4  k8 sharegroup   0 Oct 22 14:38 tu4-NFS-lnx04

Confusão

Parece que o setfacl é o vencedor, mas está um pouco confuso com a saída, por que a versão pegajosa adiciona uma leitura aleatória e tira o grupo de gravação?

Acho que posso atribuir o arquivo NFS criado sendo diferente devido à umask padrão de 0022, mas não às outras alterações. Eu esperava que as janelas criadas e os arquivos criados localmente correspondessem também às permisões.

Alguém pode explicar o que está acontecendo em cada caso? Estou um pouco perplexo. Se você precisar de algo mais de mim, apenas grite e eu colocarei.

    

Answer 1

Então você fez

setfacl -m d:u:root:rwx,d:g:"sharegroup":rwx,d:other:--- share

Tudo o que você faz com setfacl d: (conhecido como "padrão ACL") não afeta a propriedade, apenas a acessibilidade. Então você pode decidir "quem pode acessar", mas não "quem possui". Você acabou de fazer com que os arquivos de teste tivessem acesso ao rwx para o usuário proprietário e para o root; e rwx access para o grupo proprietário e para o "sharegroup". Mas o usuário proprietário e o grupo proprietário foram determinados exatamente da mesma maneira que sem setfacl.

As permissões dos arquivos são inesperadas, porque com o arquivo setfacl'd, o umask não é mais levado em consideração. Cada arquivo tem sua "própria umask", conhecida simplesmente como máscara (veja getfacl ).

E você fez

chmod 2770 share

Errado novamente. 2770 não é pegajoso, isso é bit setgid. O Sticky teria sido 1770. O setgid alterou o grupo proprietário dos novos arquivos e não afetou suas permissões. As permissões, como de costume, levam em conta umask (veja umask ) e o modo sugerido pelo aplicativo que criou o arquivo. / p>

Não estou ciente de como a coisa que você precisa ser implementada adequadamente com as ferramentas que você tem. Não há "setuid para diretórios" implementados no Linux.