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

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

O problema básico é que tenho um QNAP conectado ao domínio e quero publicar os instantâneos do RSnapshot via Samba para que os usuários possam recuperar seus próprios arquivos dos backups. (De acordo com o RSnapshot HowTo original:http://rsnapshot.org/rsnapshot/docs/docbook/rest.html#restoring-backups)

No entanto, a menos que eu defina uma ACL padrão (setfacl -mg: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 horários/diários/semanais/mensais e preserva corretamente as ACLs padrão e estendidas do Linux. Os snapshots são armazenados no seguinte diretório:

/share/CACHEDEV1_DATA/Local Backups

Para evitar que ocorram alterações nas permissões, limpei as ACLs padrão desse diretório e simplesmente configurei 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\domain\040users: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 do snapshot (hourly.0, hourly.1 etc.) são semelhantes a:

# 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 conforme o esperado. (As permissões são bastante liberais para descobrir se as permissões FS ou Samba são o problema.)

Visão geral do Samba

Criei um compartilhamento por meio da WebGUI chamado LocalBackups e, revisando o arquivo smb.conf, espero que funcione sem modificações. Embora eu consiga acessar o diretório LocalBackups sem problemas, toda vez que tento acessar um dos backups, ou seja, hora.0, hora.1 etc., recebo a mensagem de erro "Você não tem permissão para acessar \192.168.1.20\LocalBackups\ por hora.0.

No 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 esta configuração, posso entrar no diretório LocalBackupds, mas não consigo entrar em nenhum dos subdiretórios de snapshot, ou seja, hourly.0, hourly.1 etc.

As linhas comentadas são coisas que tentei ver se fazem diferença, mas o comportamento tem sido consistente com ou sem as linhas comentadas.

Se eu alterar a ACL em um dos diretórios de snapshot (ou seja, por hora.0) para incluir os usuários MYDOM\Domain, posso entrar nesse diretório (ou seja, por hora.0) via 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\domain\040users: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 registro da WebUI, posso ver a solicitação de conexão SMB passando com meu nome de usuário, etc. Estou inclinado a 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á falhando. Alguma ideia?

Responder1

Em vez de tentar resolver isso através do Samba, redefini a configuração do samba para o padrão criado pela QNAP. (Ou seja, descomentei as linhas comentadas. Isso também parece mais seguro no longo prazo, já que a GUI da Web pode potencialmente substituir o smb.confarquivo ajustado se novos compartilhamentos, etc., forem criados por mim ou por outros administradores.)

Em seguida, altero as permissões do sistema de arquivos para adicionar a ACL estendida para o MYDOM\Domain Usersgrupo com leitura r+xpara os diretórios:

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

Dessa forma, quando o backup dos arquivos for feito, os usuários do domínio poderão navegar até o homesdiretório. Entretanto, 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, apenas os usuários originais podem acessar seus próprios diretórios iniciais.

Alterações no RSnapshot

Achei que as ACLs estendidas foram preservadas. Eles não estavam, apenas parecia certo porque as ACLs padrão dos diretórios iniciais foram configuradas com um usuário e grupo de domínio. Assim, as ACLs padrão foram preservadas, mas não as estendidas. Para corrigir isso, editei o script rsnapshot e adicionei o -Asinalizador 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, hourly.0, etc), também adicionei uma alteração de permissão à create_backup_point_dirfunção adicionando logo na parte inferior da função:

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

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

Vou tentar implementar isso em um patch para rsnapshot depois de fazer mais alguns testes.

informação relacionada