Não é possível explorar o subdiretório no compartilhamento do Samba com as ACLs do Linux

1

Os problemas básicos são que eu tenho um QNAP de Domínio Conectado e quero publicar os instantâneos do RSnapshot via Samba para que os usuários possam recuperar seus próprios arquivos dos backups. (Como no original do RSnapshot: link )

No entanto, a menos que eu defina uma ACL padrão (setfacl -m g: MYDOM \ Domain \ Users: rx) que os novos instantâneos herdarão, simplesmente não consigo navegar pelo conteúdo dos instantâneos compartilhados.

Visão geral do RSnapshot

Ele cria instantâneos por hora / dia / semana / mês e preserva as ACLs Linux padrão e estendidas corretamente. Os instantâneos são armazenados no seguinte diretório:

/share/CACHEDEV1_DATA/Local Backups

Para evitar a ocorrência de alterações nas permissões, limpei as ACLs padrão desse diretório e simplesmente defino as permissões padrão. As permissões são:

# ls -al
drwxrwxrwx    4 admin    administ      4096 Nov 22 17:00 Local Backups/

# getfacl Local\ Backups/
# file: Local Backups/
# owner: admin
# group: administrators
user::rwx
user:admin:rwx
user:guest:---
group::rwx
group:MYDOM\domain0users:r-x
mask::rwx
other::rwx
default:user::rwx
default:group::rwx
default:mask::rwx
default:other::rwx

Isso significa que as permissões padrão dos subdiretórios de snapshots (hourly.0, hourly.1 etc) se parecem com:

# cd hourly.0

# ls -al
drwxrwxrwx    3 admin    administ      4096 Nov 22 16:02 ./

# getfacl .
# file: .
# owner: admin
# group: administrators
user::rwx
group::rwx
mask::rwx
other::rwx
default:user::rwx
default:group::rwx
default:mask::rwx
default:other::rwx

Neste ponto, o RSnapshot está totalmente testado e funcionando como esperado. (As permissões são bastante liberais para trabalhar se as permissões do FS ou o Samba forem o problema.)

Visão geral do Samba

Eu criei um compartilhamento através do WebGUI chamado LocalBackups e revisando o arquivo smb.conf Eu esperaria que ele funcionasse sem modificações. Embora eu possa acessar o diretório LocalBackups bem, toda vez que eu tento acessar nos backups, ou seja, hour.0, hourly.1 etc, recebo a mensagem de erro "Você não tem permissões para acessar \ 192.168.1.20 \ LocalBackups \ por hora.0.

Do smb.conf, a seção [global] é:

[global]
# Add this, apparently Windows 7 Bug.
# acl allow execute always = yes
log level = 3
passdb backend = smbpasswd
workgroup = MYDOM
security = ADS
server string =
encrypt passwords = Yes
username level = 0
#map to guest = Bad User
null passwords = yes
max log size = 10
socket options = TCP_NODELAY SO_KEEPALIVE
os level = 20
preferred master = no
dns proxy = No
smb passwd file=/etc/config/smbpasswd
username map = /etc/config/smbusers
guest account = guest
directory mask = 0777
create mask = 0777
oplocks = yes
locking = yes
disable spoolss = no
load printers = yes
veto files = /.AppleDB/.AppleDouble/.AppleDesktop/:2eDS_Store/Network Trash Folder/Temporary Items/TheVolumeSettingsFolder/.@__thumb/.@__desc/:2e*/.@__qini/.Qsync/.@upload_cache/.qsync/.qsync_sn/.@qsys/.streams/.digest/
delete veto files = yes
map archive = no
map system = no
map hidden = no
map read only = no
deadtime = 10
server role = auto
use sendfile = yes
unix extensions = no
store dos attributes = yes
client ntlmv2 auth = yes
dos filetime resolution = no
wide links = yes
#force unknown acl user = yes
force unknown acl user = yes
template homedir = /share/homes/DOMAIN=%D/%U
inherit acls = yes
domain logons = no
min receivefile size = 256
case sensitive = auto
domain master = auto
local master = no
enhance acl v1 = yes
remove everyone = yes
conn log = no
kernel oplocks = no
max protocol = SMB2_10
smb2 leases = yes
durable handles = yes
kernel share modes = no
posix locking = no
lock directory = /share/CACHEDEV1_DATA/.samba/lock
state directory = /share/CACHEDEV1_DATA/.samba/state
cache directory = /share/CACHEDEV1_DATA/.samba/cache
printcap cache time = 0
acl allow execute always = yes
server signing = disabled
aio read size = 1
aio write size = 0
streams_depot:delete_lost = yes
streams_depot:check_valid = no
fruit:nfs_aces = no
fruit:veto_appledouble = no
winbind expand groups = 1
pid directory = /var/lock
printcap name = /etc/printcap
printing = cups
show add printer wizard = no
realm = mydom.local
ldap timeout = 5
password server = mydc001.mydom.local
pam password change = yes
winbind enum users = Yes
winbind enum groups = Yes
winbind cache time = 3600
idmap config * : backend = tdb
idmap config * : range = 400001-500000
idmap config MYDOM : backend = rid
idmap config MYDOM : range = 10000001-20000000
host msdfs = yes
vfs objects =  shadow_copy2 acl_xattr catia fruit qnap_macea streams_depot aio_pthread

A seção [LocalBackups] é:

[LocalBackups]
comment =
path = /share/CACHEDEV1_DATA/Local Backups
browsable = yes
oplocks = yes
ftp write only = no
recycle bin = no
recycle bin administrators only = no
qbox = no
public = yes
#invalid users = "guest"
#read list = @"MYDOM\Domain Users"
#write list = "admin"
#valid users = "root","admin",@"MYDOM\Domain Users"
guest ok = yes
read only = yes
inherit permissions = no
shadow:snapdir = /share/CACHEDEV1_DATA/_.share/LocalBackups/.snapshot
shadow:basedir = /share/CACHEDEV1_DATA/Local Backups
shadow:sort = desc
shadow:format = @GMT-%Y.%m.%d-%H:%M:%S
smb encrypt = disabled
strict allocate = yes
streams_depot:check_valid = yes
mangled names = yes
admin users =
admin only = "admin"
#nt acl support = no

Usando essa configuração, posso inserir o diretório LocalBackupds, mas não posso inserir nenhum dos subdiretórios de snapshot, por exemplo, hourly.0, hourly.1 etc.

As linhas comentadas são coisas que tentei ver se isso faz diferença, mas o comportamento foi consistente com ou sem as linhas comentadas.

Se eu alterar a ACL em um dos diretórios de captura instantânea (por exemplo, horário.0) para incluir os usuários MYDOM \ Domain, posso inserir esse diretório (por exemplo, por hora) pelo Samba. As permissões do diretório são então:

# cd hourly.0

# ls -al
drwxrwxrwx    3 admin    administ      4096 Nov 22 18:00 ./

# getfacl .
# file: .
# owner: admin
# group: administrators
user::rwx
group::rwx
group:MYDOM\domain0users:rwx
mask::rwx
other::rwx
default:user::rwx
default:group::rwx
default:mask::rwx
default:other::rwx

Neste ponto, não consegui descobrir como ativar o registro adequado no QNAP. A partir das informações básicas de log da WebUI, posso ver a solicitação de conexão SMB passando com meu nome de usuário, etc. Estou me inclinando para que a configuração do Samba seja mais rigorosa do que as Permissões FS, mas estou supondo.

Neste estágio, não tenho certeza se meu conhecimento de ACLs, Samba ou ambos estão falhando comigo. Alguma idéia?

    
por Vinnie 22.11.2017 / 10:07

1 resposta

0

Em vez de tentar resolver isso através do Samba, eu restaurei a configuração do samba para o padrão que o QNAP criou. (Isto é, não comentou as linhas comentadas. Isso também parece mais seguro a longo prazo, já que a GUI da Web pode potencialmente substituir o arquivo sintonizado smb.conf se novos compartilhamentos, etc. forem criados por mim ou por outros administradores).

Altero as permissões do sistema de arquivos para adicionar a ACL estendida para o grupo MYDOM\Domain Users com leitura r+x para os diretórios:

/share
/share/CACHEDEV1_DATA
/share/CACHEDEV1_DATA/homes

Dessa forma, quando os arquivos são submetidos a backup, os usuários do domínio podem navegar até o diretório homes . No entanto, como não há nenhuma ACL padrão herdada do diretório de snapshots ( /share/CACHEDEV1_DATA/Local Backups ) e nenhuma alteração nos diretórios iniciais do usuário, somente os usuários originais podem acessar seus próprios diretórios iniciais.

Alterações no RSnapshot

Acredito que as ACLs estendidas foram preservadas. Eles não eram, apenas pareciam corretos porque as ACLs padrão dos diretórios pessoais eram configuradas com um usuário e grupo de domínio. Portanto, as ACLs padrão foram preservadas, mas não as estendidas. Para corrigir isso, editei o script rsnapshot e adicionei o sinal -A ao rsync alterando:

my $default_rsync_short_args = '-a';

para

my $default_rsync_short_args = '-aA';

Para corrigir o acesso, aos diretórios de snapshots (ou seja, por hora, etc.), também adicionei uma alteração de permissão à função create_backup_point_dir , adicionando o direito na parte inferior da função:

system("setfacl -m g:MYDOM\\Domain\ Users:rx \"$destpath\"");

Agora funciona como esperado e os usuários podem recuperar seus próprios arquivos privados dos backups. :)

Vou testar e aplicar isso em um patch para o rsnapshot depois de fazer mais alguns testes.

    
por 23.11.2017 / 05:09