Estou construindo um servidor de backup usando Linux, ZFS e Samba. Todos os clientes, exceto eu, usarão o Windows 10, portanto, meu foco é oferecer suporte adequado ao Windows 10, mas isso não significa que as permissões no lado do Linux devam ser inseguras (ou seja, legíveis e graváveis em todo o mundo).
Depois de remover por engano as ACLs POSIX de todos os arquivos, pensando que eram algo inicialmente configurado para permitir acesso de grupo, todas as permissões nos arquivos do lado do Windows foram quebradas.
Isso foi corrigido examinando todas as opções do manual e refazendo a configuração. Eu descobri quais opções definir para obter o comportamento que desejo, ou seja, definir as permissões apenas no lado do Windows, mantendo as permissões do UNIX seguras, no entanto, existem ainda há duas coisas que não entendo sobre como o Samba lida com permissões UNIX.
A configuração acl_xattr:ignore system acls = nofaz com que as permissões do UNIX se tornem entradas nas ACLs do Windows (entradas CREATOR, GROUP e EVERYONE), o que eu não queria, no entanto, quando definido como yes, o proprietário, o grupo e as permissões ainda parecem impactar as permissões no lado do Windows, eles ainda são aplicados pelo Samba. Se um diretório tiver root:backup 0660permissões, um aleatório Domain Usernão terá acesso a esse diretório, mesmo que as ACLs do Windows tenham uma entrada para Domain Users. Alterando o grupo de backuppara usersonde usersmapeia para o grupo NT Domain Users, então funcionará. Claramente, as permissões do UNIX ainda são aplicadas.
Existe uma configuração para fazer com que as ACLs do Windows vetem o resto, ou seja, se as ACLs do Windows permitirem Domain Users, elas serão permitidas independentemente do que as permissões do UNIX possam dizer? Ou eu poderia simplesmente desabilitar o Samba usando as permissões do UNIX?
A outra questão é como o Samba armazena as permissões do UNIX. Na nova configuração eu tinha inherit owner = yes. Isso pareceu funcionar conforme o esperado tanto no Windows quanto no UNIX, exceto quando tentei mudar o grupo UNIX para outro. Inicialmente o bit setgid foi definido nos compartilhamentos johncomo grupo, pensando inherit ownerque afeta apenas o proprietário, não o grupo. Porém ao remover o bit setgid dos compartilhamentos e alterar o grupo para usersrecursivamente, com inherit owner = yesnovos arquivos e diretórios feitos a partir de um cliente Windows 10 ainda foram criados com o grupo john. Em nenhum lugar da árvore de diretórios havia um diretório com grupo johnrestante, tentei reiniciar meu cliente Windows e o servidor Samba por precaução, mas isso não mudou nada.
O Samba armazena as permissões do UNIX em outro lugar, então minha alteração do grupo UNIX diretamente do sistema de arquivos não afeta o grupo rastreado pelo Samba? Ou qual pode ser a causa do Samba ainda usar esse grupo antigo para novos arquivos e diretórios?
Abaixo você encontra as opções potencialmente relevantes da configuração do Samba versão 4.7.6. Se precisar de mais informações, me avise.
[global]
access based share enum = yes
acl group control = no
acl map full control = yes
acl_xattr:ignore system acls = yes
acl_xattr:default acl style = windows
create mask = 0775
directory mask = 0775
dos filemode = yes
dos filetime resolution = no
dos filetimes = yes
ea support = no
force create mode = 0600
force directory mode = 0600
force unknown acl user = no
guest account = nobody
guest ok = no
guest only = no
inherit acls = no
inherit owner = unix only
inherit permissions = no
invalid users = root
map acl inherit = yes
map archive = no
map hidden = no
map readonly = no
map system = no
map to guest = never
nt acl support = yes
obey pam restrictions = no
read only = yes
restrict anonymous = 2
security = user
server role = active directory domain controller
store dos attributes = yes
unix extensions = yes
vfs objects = dfs_samba4 acl_xattr shadow_copy2
[backups]
create mask = 0660
directory mask = 0770
ea support = yes
path = /mnt/pool/backups
read only = no
Responder1
O Samba armazena as permissões do UNIX em outro lugar, então minha alteração do grupo UNIX diretamente do sistema de arquivos não afeta o grupo rastreado pelo Samba? Ou qual pode ser a causa do Samba ainda usar esse grupo antigo para novos arquivos e diretórios?
Só consegui encontrar uma resposta para esta segunda pergunta. Durante minha experiência com inherit ownereu, em determinado momento, quis saber quais eram os valores armazenados como parte das ACLs do NT, então inspecionei um diretório com samba-tool ntacl get /path/to/dire, para minha surpresa, vi o GID antigo como o valor do arquivo group_sid. E como eu não tinha mais nenhuma outra referência ao antigo GID em nenhum outro lugar do sistema de arquivos, esta parece ser a causa provável para o Samba manter o antigo grupo UNIX, especialmente porque sempre que eu definir herdar proprietário como unix onlyou no, ele não terá o antigo grupo UNIX. Então, aparentemente, definir inherit ownercomo yes(ou seja unix and windows), faz com que o Samba defina o grupo UNIX para o grupo armazenado nas ACLs do NT.
Eu ainda adoraria uma resposta para a primeira pergunta, mas encontrei uma solução alternativa ao encontrar uma maneira demapear o grupo NT Domain Userspara o meu grupo UNIX preferidoe definir as permissões de outras pessoas como 0 por meio de ACLs POSIX: setfacl -Rm d:o:---,o:--- /my/share.