In samba, se usato come domain controller AD, gli share fanno affidamento sulle ACL posix e su alcune ACL tipiche di Windows, non replicabili con le ACL posix, le quali vengono salvate da Samba negli attributi estesi (user_xattrs) dei files. Questi attributi sono gestiti dal modulo vfs_acl_xattr che viene caricato di default (e non e` disabilitabile) su un domain controller AD samba 4. Su un domain member, invece, è facoltativo.
Questo significa che un domain member potrà, volendo, usare una "vecchia" gestione dei permessi sugli shares, usando concetti tipici di samba 3 quali per esempio "force user" o "valid users" o "force directory mode", e NON USARE le funzioni estese del modulo vfs_acl_xattr. Su un domain member, se vogliamo usare le funzioni estese di vfs_acl_xattr, dovremo abilitarlo manualmente.
Su un domain controller, invece, e` impossibile non usare vfs_acl_xattr, e sebbene conosca almeno un setup nel quale il domain controller usa shares "alla samba 3" con abbondante uso di force user e valid users, questa sarebbeuna strada da non seguire mai.
Per riferimento:
Vale la pena di notare che sebbene il Wiki di Samba dica che usare le ACL Posix "a mano" ovvero non dai tool di Windows ma direttamente con "setfacl" sia da evitarsi nel caso in cui si usi il modulo vfs_acl_xattr (ovvero per esempio su un domain controller), in realtà sembra che sia possibile farlo, accontentandosi di alcuni comportamenti di default (vedi il man di vfs_acl_xattr), sempre ovviamente se questi comportamenti ci stanno bene.
mkdir /srv/documenti chown root:"AD\Domain Admins" /srv/sdocumenti chmod 0770 /srv/documenti
# share di esempio [documenti] path = /srv/documenti read only = no
smbcontrol all reload-config
Ora possiamo gestire i permessi usando un client Windows joinato al dominio, ovviamente loggandoci come un utente che e` parte del gruppo "Domain Admins" o di un gruppo che abbia il privilegio SeDiskOperatorPrivilege
Nota: Se quando applichiamo le modifiche riceviamo questo errore assurdo qui: Il criterio di controllo corrente per il computer specificato non ha attivato il controllo. Se il criterio di protezione dei computer proviene dal dominio, chiedere a un amministratore di dominio di attivare l' Editor criteri di gruppo. In caso contrario, utilizzare l' Editor criteri del computer locale per configurare i criteri di controllo del computer localmente.
allora ci manca un permesso nel path precedente a quello su cui stiamo lavorando, oppure stiamo cercando di togliere un permesso che è implicito nel file system (per esempio, lo user "root" che coincide con administrator, e che e` owner del file su Linux). In questo caso, proviamo a dare all'utente "administrator" il controllo completo su "la cartella selezionata".
Le modifiche che apportiamo qui, compariranno sia nelle ACL del file system sotto linux (verificabili con un getfacl) sia dentro degli appositi attributi estesi, che conterranno quelle caratteristiche che non sono proprie delle ACL Posix. Questi attributi estesi possono essere letti da Linux con il comando samba-tool ntacl get /path/che/ci/interessa --as-sddl
. Stando al Wiki di Samba, l'output di questo comando sarebbe "comprensibile". A me non sembra che lo sia, ma forse sono ignorante in materia di gestione dei file system di Windows.
Scavando nei menù delle proprietà avanzate, e cliccando ulteriormente su "Mostra autorizzazioni avanzate" (tipico di Windows avere funzioni utili nascosti sotto diversi click su "Avanzate") troviamo i permessi speciali elencati in forma completa. Questi permessi comprendono alcune funzionalità utili per fare dei "magheggi" non ovvi. Uno dei possibili scenari in cui viene utile è se vogliamo creare diverse directory con diversi permessi sotto lo stesso share, e vogliamo che l'azione di spostare un file da una di queste directory all'altra faccia si che i permessi del file cambino rispecchiando i permessi di default della nuova directory e non quelli di origine del file stesso.
Una piccola spiegazione è necessaria: quando un file viene copiato, la nuova copia assume i permessi di default della directory dove viene creata, e questo è nel 99% dei casi esattamente quello che vogliamo che succeda. Quando un file viene spostato invece questo non succede, il file mantiene tutti i permessi originali. Se il file viene spostato a cavallo fra due directory che hanno permessi diversi (ovviamente occorre che l'operazione venga fatta da un utente che ha i permessi per farlo, ovvero permessi di modifica sia nella directory di partenza che in quella di destinazione) allora il file manterrà i permessi originali. Samba cercherà di applicare i permessi della nuova directory al file (ovvero di applicare l'ereditarietà) ma nella configurazione classica degli share, nella quale gli utenti non amministratori non hanno "full control", non riuscirà a farlo perché l'utente che sta spostando il file non ha il permesso per modificarne i permessi. Il risultato è che il file viene spostato nella destinazione, ma mantiene tutti i permessi che aveva in origine, cosa che molto probabilmente NON vogliamo che succeda; noi vogliamo che il file assuma i permessi di default della directory di destinazine.
Per ottenere questo risultato, abbiamo due possibilità: la prima è copiare e non spostare il file. La seconda è dare un permesso speciale agli utenti, quello di modificare i permessi dei files, ovvero "Cambia Autorizzazioni". È chiaro che questo permesso è potenzialmente una bomba in mano a un bambino, purtroppo. Gli utenti possono riuscire a fare ogni tipo di disastro se si mettono a modificare i permessi senza sapere cosa stanno facendo.
Se vogliamo gestire le ACL da Linux, possiamo provare cosi` (e casomai poi da Windows vediamo cosa esce):
mkdir /ud0/documenti chown root /ud0/documenti chgrp "AD\Domain Admins" /ud0/documenti chmod 0770 /ud0/documenti
# configurazione di base con solo domain admins: setfacl -m g:"AD\domain admins":rwx documenti setfacl -m d:g:"AD\domain admins":rwx documenti # aggiunta dei permssi per domain users: setfacl -m g:"AD\domain users":rwx documenti setfacl -m d:g:"AD\domain users":rwx documenti # impediamo a tutti gli altri di fare qualsiasi cosa: setfacl -m other:--- documenti setfacl -m d:other:--- documenti
In Samba esiste un comando (smbcacls) che permette di gestire le ACL di uno share (non dei files sul filesystem). Questo comando si interfaccia con Samba esattamente allo stesso modo in cui si interfaccia con Samba la gestione delle ACL da un client Windows, quindi permette di gestire tutte le ACL native di Windows. La parte difficile è che è assai poco user friendly, specie quando si vanno a manipolare i permessi speciali che sono proprio quelli che in Posix ci mancano e che rendono appetibili le ACL native Windows.
Qui la man page: https://www.samba.org/samba/docs/current/man-html/smbcacls.1.html
Qui mostro alcuni esempio di uso di detto comando per leggere le ACL su uno share e poi su una directory che ha permessi speciali (impostati da Windows).
# chiede la password ogni volta: smbcacls //fileserver/documenti / -U administrator # metto la password in command line: smbcacls //fileserver/documenti / -U administrator%Otto88@88 # uso kerberos: prima lo inizializzo (e chiede la pw) e poi uso le credenziali salvate kinit administrator smbcacls //fileserver/documenti / --use-winbind-ccache
smbcacls //fileserver/documenti / --use-winbind-ccache REVISION:1 CONTROL:SR|PD|SI|DI|DP OWNER:Unix User\root GROUP:AD\Domain Admins ACL:Unix User\root:ALLOWED/0x0/FULL ACL:Creator Owner:ALLOWED/OI|CI|IO/FULL ACL:AD\Domain Users:ALLOWED/OI|CI/READ ACL:AD\Domain Admins:ALLOWED/OI|CI/FULL smbcacls //fileserver/documenti / --use-winbind-ccache --sddl O:S-1-22-1-0G:S-1-5-21-2435491250-758963225-146791338-512D:PAI(A;;FA;;;S-1-22-1-0)(A;OICIIO;FA;;;CO)(A;OICI;0x1200a9;;;S-1-5-21-2435491250-758963225-146791338-513)(A;OICI;FA;;;S-1-5-21-2435491250-758963225-146791338-512)
ACL:AD\g1:ALLOWED/OI|CI/0x001601ff
)smbcacls //fileserver/documenti /share1 --use-winbind-ccache REVISION:1 CONTROL:SR|PD|SI|DI|DP OWNER:AD\Administrator GROUP:AD\Domain Users ACL:AD\Domain Admins:ALLOWED/OI|CI/FULL ACL:AD\g1:ALLOWED/OI|CI/0x001601ff smbcacls //fileserver/documenti /share1 --use-winbind-ccache --sddl O:S-1-5-21-2435491250-758963225-146791338-500G:S-1-5-21-2435491250-758963225-146791338-513D:PAI(A;OICI;FA;;;S-1-5-21-2435491250-758963225-146791338-512)(A;OICI;0x1601ff;;;S-1-5-21-2435491250-758963225-146791338-1108)