Samba Ignorando ACLs POSIX

3

Eu tenho um servidor Ubuntu 10.04.4 LTS executando o Samba, e juntou-se ao nosso domínio Active Directory usando PBIS (anteriormente também aberto.) O Samba está configurado para fazer autenticação usando usuários / grupos do AD, e isso está funcionando corretamente. Além disso, as permissões padrão do Linux (usuário, grupo, outros) funcionam corretamente com o Samba. MAS, o Samba parece ignorar totalmente qualquer conjunto de permissões com ACLs estendidas.

Eu tentei várias configurações de smb.conf que eu já vi recomendadas em outros lugares, e nenhuma delas parece ter qualquer efeito.

Configuração da máquina:

  • O compartilhamento de arquivos está em sua própria unidade. Informações de montagem de / etc / fstab para a unidade são:
    • UUID = 372aa637-4b7b-45cc-8340-9d028893c196 / media / news-drive ext4 user_xattr, acl 0 2
  • A máquina ingressou no domínio usando o PBIS (antigamente igualmente aberto)
  • A configuração do Samba para o compartilhamento é:
[shared]
   comment = , 
   nt acl support = yes
   admin users = 
   force user = 
   force group = \domain^users
   create mask = 0770
   directory mask = 0770
  • Configuração global do Samba
workgroup = 
dns proxy = no
server string = 
load printers = no
cups options = raw
guest account = pcguest
log file = /var/log/samba/%m.log
max log size = 50
security = ADS
realm = 
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
interfaces = 172.16.0.20 10.4.1.20 127.0.0.1
bind interfaces only = yes
idmap uid = 16777216-33554431
idmap gid = 16777216-33554431
map to guest = Bad User
  • Eu também usei alguns deles na configuração global, sem sucesso
idmap backend = idmap_rid:=16777216-33554431
nt acl support = yes
inherit acls = Yes
map acl inherit = Yes
map archive = no
map hidden = no
map read only = no
map system = no
store dos attributes = yes
inherit permissions = Yes
template shell = /bin/false
winbind use default domain = no

O que estou perdendo aqui para fazer o Samba trabalhar com as ACLs estendidas?

Um exemplo do que está acontecendo

Eu tenho uma pasta em um compartilhamento de samba. O compartilhamento em si é totalmente aberto em nosso domínio (a configuração de "usuários válidos" é definida como "Usuários do domínio" para o domínio do AD). Nesse compartilhamento, tenho uma pasta com permissões mais restritivas no nível do sistema de arquivos por um usuário do AD, com o grupo configurado para um grupo do AD com apenas algumas pessoas e permissões classificadas para 770)

O problema é que eu preciso dar acesso a essa pasta para outro grupo AD, então eu corro "setfacl -m u :: rwx" para dar-lhes permissão para acessá-lo. Isso funciona dentro do Linux (se eu ssh em que um desses usuários e navegar para a pasta) ... mas se eu me conectar ao compartilhamento SMB com o mesmo usuário e tentar navegar para essa pasta, o acesso é negado.

    
por woodsbw 19.12.2012 / 22:28

2 respostas

2

Chegando tarde a essa pergunta, eu ainda gostaria de chamar a documentação oficial do Samba para suporte de ACLs . Isso é válido para o Samba 4.0.0 em diante, o que certamente não estava disponível no momento em que essa pergunta foi solicitada. Mas, como a pergunta aparece nos mecanismos de pesquisa, esse link pode ser útil.

Os passos básicos são:

1. Assegure-se de que o sistema de arquivos suporte acls (atualmente, o ext4 faz por padrão, não há necessidade de opções adicionais de montagem)

2. Assegure-se de que o Samba foi compilado com o suporte da ACL. (Sim, por padrão no Ubuntu 14.04 LTS):

smbd -b | grep HAVE_LIBACL

3. Ative a ACL definindo o seguinte na seção [global] de /etc/samba/smb.conf :

vfs objects = acl_xattr
map acl inherit = yes
store dos attributes = yes

Para obter detalhes, visite os documentos oficiais como vinculados acima.

    
por 25.02.2016 / 12:55
1

Isso porque force user , force group , create mask e directory mask impõem o uso de permissões de estilo unix tradicionais que não podem ser combinadas com a herança de ACLs. Suas ACLs padrão devem residir no nível de sistema de arquivos da pasta, não no próprio compartilhamento samba, para que a herança funcione, mas esteja ciente de que as permissões contraditórias sempre negarão o acesso, por exemplo. quando um usuário tem permissão como usuário, mas não como grupo, o samba impedirá o acesso ao usar ACLs (o que me parece um bug), por exemplo: o usuário nobody é membro do nogroup então, as ACLs precisam permitir que ninguém & permissão de gravação do nogroup, caso contrário, o acesso de gravação seja negado. Apenas o samba se comporta dessa maneira!

Uma maneira possível de criar uma pasta com permissões padrão herdadas pode ser:

me@myHost:/shares$ getfacl myShare/
# file: myShare/
# owner: JohnDoe
# group: domain0users
user::rwx
group::rwx          #effective:r-x
group:domain0users:rwx   #effective:r-x
group:domain0admins:rwx  #effective:r-x
mask::rwx
other::r-x
default:user::rwx
default:group::rwx
default:group:domain0users:rwx
default:group:domain0admins:rwx
default:mask::rwx
default:other::r-x

A seção com os valores default:* é a parte interessante da herança porque qualquer novo arquivo ou pasta os obterá quando criados dentro da pasta myShare . Veja a página man setfacls para detalhes de configuração dos valores default: em um arquivo ou pasta. Agora, o problema de usar create mask ou directory mask em uma pasta com o conjunto padrão: ACLs é que o samba substituirá esses valores padrão e, na maioria dos casos, essas instruções máscara são úteis apenas enquanto você deseja a pasta inteira e seus arquivos contendo apenas um único proprietário e grupo. As ACLs são mais difíceis de configurar, mas oferecem muito mais flexibilidade, como de costume, nas máquinas com Windows. Para que o samba honre esses default:*:: permissions inherit acls precisa ser definido em [global] section:

[global]
    ; Important if ACLs (eg: setfacl) contain default entries
    ; which samba honors only if this is set to 'yes'.
    inherit acls = yes

[...]

[myShare]
    comment = Put your files here
    path = /shares/myShare
    writeable = yes

Isso permitiria um compartilhamento em que todos pudessem escrever para o compartilhamento ... mas (! ) isso não significa necessariamente que é permitido no nível do sistema de arquivos, porque a pasta myShare permite apenas usuários de domínio . De qualquer forma, para o paranóico, as permissões de compartilhamento podem ser limitadas, permitindo apenas grupos específicos:

    write list = @"domain users"

que implica writeable=yes , mas apenas para grupos definidos em lista de gravação . Certifique-se de que as permissões de compartilhamento e pasta estejam livres de contradições, por exemplo:

    write list = @"other group"

permitiria que outro grupo escrevesse para o compartilhamento, mas como as pastas myShare permitem que somente usuários de domínio escrevam, ele falhará obviamente.

    
por 16.10.2016 / 15:25