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:

• man vfs_acl_xattr
• https://wiki.samba.org/index.php/Setting_up_a_Share_Using_POSIX_ACLs
• https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_ACLs

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.

• Creare la directory sul disco e darle dei permessi minimi di default. Notare che nel comando chown uso il nome del dominio Samba (in questo caso "AD"):

mkdir /srv/documenti
chown root:"AD\Domain Admins" /srv/sdocumenti
chmod 0770 /srv/documenti

• Creare la entry per lo share in smb.conf. Notare la voluta semplicita` della entry. Si suppone che sia caricato il modulo acl_xattr globalmente.

# share di esempio
[documenti]
        path = /srv/documenti
        read only = no

• Fare rileggere la config a Samba:

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

• Aprire "Gestione computer", scegliere "Azione", e poi "connetti ad un altro Computer", quindi inserire il nome del server Samba.
• Probabilmente avreo un errore che dice che non e` possibile connettersi: e` il modulo dell visualizzatore eventi che non riesci a collegarsi al server Samba (non e` supportato). Non e` un problema, il resto funziona.
• Sotto "Utilità di sistema" / "Cartelle condivise" / "Condivisioni" troveremo elencati i nostri share del server Samba.
• Facendo doppio click sullo share, si apre una maschera.
• Verificare sotto "Autorizzazioni Condivisione" che "Everyone" abbia tutto selezionato, ovvero "controllo completo", "modifica" e "lettura". Qui non ci serve altro.
• Cliccare sul tab "Sicurezza", qui dobbiamo definire i diritti di accesso
  • Diamo al gruppo "Domain Users", o ad altro gruppo che userà lo share, tutti i permessi escluso "Full Control", su tutti gli oggetti (la cartella selezionata, sottocartelle, files). Nota: è necessario che abbia permessi anche su "la cartella selezionata" altrimenti non riesce ad accedere al contenuto. Non deve avere "Full control" altrimenti può sfasciare tutto.
  • Assicuriamoci che "Domain admins" abbia tutto, compreso "full control", ed escluso "Autorizzazioni speciali", su tutti gli oggetti (la cartella selezionata, sottocartelle, files)
  • Facoltativo: Se non c'è già, aggiungiamo l'utente speciale "system" con tutto escluso sempre "Autorizzazioni speciali". (Vedi https://wiki.samba.org/index.php/The_SYSTEM_Account)
  • L'utente speciale "CREATOR OWNER" dovrebbe avere "full control" su tutto tranne "questa cartella"

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 cerchrà 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):

• Prima di tutto creiamo la directory come definita nello share, e diamo il permesso di base al gruppo "Domain Admins". La logica e` che il gruppo in questione deve avere "rwx" sulla directory.

mkdir /ud0/documenti
chown root /ud0/documenti
chgrp "AD\Domain Admins" /ud0/documenti
chmod 0770 /ud0/documenti

• Poi diamo i permessi per mezzo delle ACL Posix, cosi`

# 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).

• Per autenticarmi devo usare un account di dominio, e devo farlo ogni volta. Per evitare di farlo ogni volta posso scrivere la password nella command line, oppure nell'environment, oppure posso usare Kerberos (se sono su una macchina joinata al dominio) così ho un ticket riutilizzabile enne volte. Ecco alcuni esempi:

# 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

• Posso vedere i permessi dello share usando "/" come "path" oppure i permessi di un singolo file o directory dentro lo share indicandolo (sempre relativamente alla root dello share stesso)
• Posso impostare i permessi ma non ci sono messo per ora.
• Qui c'è un esempio di permessi dello share (la root dello share) che non comprendono permessi speciali. Li leggo visualizzandoli in due modi, cambia l'output ma il contenuto è il medesimo

root@fileserver:~# 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

root@fileserver:~# 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)

• Qui c'è un esempio di permessi di una directory sotto lo share che comprende permessi speciali, anche questa visualizzata in due modi. Noterete come purtroppo i permessi speciali siano indicati con un numero che immagino sia bitmapped,il che è sicuramente corretto ma decisamente poco utile per capire che permessi sono stati assegnati (ACL:AD\g1:ALLOWED/OI|CI/0x001601ff)

root@fileserver:~# 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

root@fileserver:~# 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)