Estou construindo um servidor de backup usando Linux, ZFS e Samba. Todos os clientes que não sejam eu usarão o Windows 10, portanto meu foco é suportar o Windows 10 corretamente, mas isso não significa que as permissões no lado do Linux devam ser permitidas como inseguras (ou seja, legíveis e graváveis pelo mundo).
Depois de remover as ACLs POSIX por engano em todos os arquivos, pensando que eles eram algo definido inicialmente para permitir acesso de grupo, todas as permissões nos arquivos do lado do Windows foram quebradas.
Isso foi corrigido com base em todas as opções do manual e refazendo a configuração. Descobri quais opções definir para obter o comportamento desejado, ou seja, definir as permissões apenas no lado do Windows, mantendo as permissões do UNIX seguras. No entanto, ainda existem duas coisas que eu não entendo sobre como o Samba lida com as permissões do UNIX.
A configuração acl_xattr:ignore system acls = no faz 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, mas quando definido como yes , o proprietário, grupo e permissões ainda parecem impactar as permissões no lado do Windows, eles ainda são impostas pelo Samba. Se um diretório tiver root:backup 0660 permissões, então um Domain User aleatório não terá acesso a esse diretório, mesmo que as ACLs do Windows tenham uma entrada para Domain Users . Mudando o grupo de backup para users onde users mapeia para o grupo NT Domain Users , então ele funcionará. Então, claramente, as permissões do UNIX ainda são aplicadas.
Existe uma configuração para fazer com que as ACLs do Windows vetem o restante, 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 apenas desativar o Samba usando as permissões do UNIX?
A outra pergunta é como o Samba armazena as permissões do UNIX. Na nova configuração eu tive inherit owner = yes . Isso pareceu funcionar como esperado no Windows como UNIX, exceto quando tentei alterar o grupo do UNIX para outra coisa. Inicialmente, o bit setgid foi definido nos compartilhamentos com john como grupo, achando que inherit owner afeta apenas o proprietário, não o grupo. No entanto, ao remover o bit setgid dos compartilhamentos e alterar o grupo para users recursivamente, com inherit owner = yes novos arquivos e diretórios criados a partir de um cliente Windows 10 ainda eram criados com o grupo john . Em nenhum lugar na árvore de diretórios havia um diretório com o grupo john restantes, tentei reiniciar meu cliente Windows e o servidor Samba apenas no caso, mas isso não alterou nada.
O Samba armazena as permissões 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 que o Samba ainda usa esse grupo antigo para novos arquivos e diretórios?
Abaixo, você pode encontrar as opções potencialmente relevantes da configuração do Samba versão 4.7.6. Se mais informações forem necessárias, 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