ArchLinux Small Business Server (14) - File Server (7)

Seeee, abbiamo il nostro nuovo scintillante domain controller Samba su Archlinux, abbiamo sottomesso i creduloni client windows (avete fatto la join al dominio da windows ? Questo non ve lo spiego mica ...) facendoli illudere di giocare in casa. Ah! Con il petto in fuori ci fregiamo a pieno titolo del grado di "sysnetworksuperexpertadmin". Wow, e cosa ci ferma più? --- Vi fermo io, e con un esempio semplice semplice. Ecco un caso pratico che dimostra ancora una volta, se ce ne fosse bisogno, come fra la teoria e la pratica ...

... ci sia di mezzo il vostro zelante capo ufficio tecnico. Raccontiamo una storia.

Gli utenti Windows

Tutti abbiamo abbiamo usato o usiamo tuttora (e perchè no?) Windows. Voglia o no questo sistema operativo rappresenta il motore del 92%-98% (a seconda degli studi) dei PC in questo pianeta. Impossibile non farci i conti.
Un tipico utente di questo sistema operativo (e per tipico intendo chi lo usa per lavoro o per gioco senza conoscenze tecniche informatiche) non ha mai avuto a che fare con diritti di accesso e permessi su file o attività del computer. Probabilmente non sanno nemmeno che esistono dato che il 99% dei PC con windows lavorano con Administrator o con un utente equivalente. (Spesso se ci si sottrae a questa regola addirittura certi software non funzionano, quindi candidamente ammetto che pure io in Windows lavoro come Administrator).

Ma quando però scoprono che esistono è la fine, specie se hanno qualche autorità in azienda. "Io voglio vedere i file di Antonio che può vedere quelli Giovanni che però non può cancellare quelli di Lucia. Ok ? "
Vengono da voi "sysnetworksuperexpertadmin" e cominciano con queste richieste cambiando idea ogni 2 minuti circa. Vi assicuro che capita, capita...

Un caso pratico

Senza andare sul paradossale presentiamo un caso molto frequente e per niente ingiustificato, e vediamo se riusciamo a risolverlo con Samba.
Come dicevo all'inizio, il Responsabile dell'Ufficio Tecnico viene da voi e vi dice:

"Antonio e Giovanni disegnano e amministrano le schede tecniche dei prodotti. Vorrei che salvassero i disegni su L:\prodotti e che Lucia e Maria potessero visualizzarle o inviarle ai clienti senza però poterle cancellare o modificare."

Bhe, richiesta ragionevole direi. Sufficente, però, a metterci in crisi. Vediamo perchè.

Mettamoci la lavoro

Allora, noi abbiamo la condivisione "public" (che i nostri utenti chiamano L:\), creiamo gli utenti, la cartella "prodotti" e un gruppo "Prodotti" che come membri ha Antonio e Giovanni. Cosa già vista, facciamolo il fretta:

sudo netuseradd -a -m Antonio
sudo netpasswd Antonio
sudo netuseradd -a -m Giovanni
sudo netpasswd Giovanni
sudo netgroupadd -a Prodotti
sudo netgroupmod -m Antonio,Giovanni Prodotti
sudo mkdir /samba/public/prodotti
sudo chmod 770 /samba/public/prodotti
sudo chgrp Prodotti /samba/public/prodotti
sudo chmod g+s /samba/public/prodotti

Bene. Ora Antonio e Giovanni hanno a disposizione L:\prodotti su cui possono leggere e scrivere liberamente senza aver minimamente modificato la configurazione di Samba, ho solo agito su utenti gruppi e permessi sul file system.
Andiamo avanti. Per Lucia e Maria creiamo un gruppo "Prodotti-RO" (Read Only):

sudo netuseradd -a -m Lucia
sudo netpasswd Lucia
sudo netuseradd -a -m Maria
sudo netpasswd Maria
sudo netgroupadd -a Prodotti-RO
sudo netgroupmod -m Lucia,Maria Prodotti-RO

E adesso ? Cosa faccio ?

1. Cambio permessi a /samba/public/prodotti in 775 così gli "altri" possono leggerci ma non scriverci. Sbagliato. Così anche gli utenti del gruppo "Commerciale" che non c'entrano nulla possono leggerci.
2. Uso i parametri di smb.conf "Read List" e "Write List". Sbagliato. I parametri agiscono su tutta la share/condivisione "public" e hanno la precedenza su quelle del file system. Lucia e Maria non potrebbero scrivere nemmeno su L:\COMUNE.
3. Faccio una share "prodotti" apposita slegata da "public".Ok, funziona ma a me non piace. Se per ogni caso del genere devo fare una share nuova in breve esaurisco le lettere dell'alfabeto per mapparle e il mio smb.conf diventa un libro. E poi ci hanno richiesto "L:\prodotti", non vorrete mica deluderli ? Con Windows si faceva in due secondi.

Prima che buttiate dalla finestra la vostra spilla di Samba vi dico che la soluzione c'e'. Poco usata e pubblicizzata ma c'e'.

Samba non c'entra

E sì. Samba non c'entra con questa limitazione. Samba poggia i suoi servizi sul file system che trova (ext3 nel mio caso) e fà il possibile per "mascherarlo" ma in questo caso non può nulla.
Semplicemente abbiamo scoperto la forte limitazione del meccanismo "tripletta" rwxrwxrwx tipico di unix. Fanno quasi tenerezza se confrontati con la granularità di permessi che riesco a raggiungere con NTFS. Inadeguati. Completamente inadeguati.
Ma non penserete mica che nessuno ci abbia fatto caso a questo ? Naturalmente sì, e un bel po' di anni fà.

ACL POSIX

La soluzione al nostro problema passa attraverso una estensione della gestione dei permessi chiamate ACL POSIX. Ancora una bozza, non facili da capire e gestire ma perfettamente funzionanti su Linux.
La cosa simpatica è che sulla nostra Arch (su tutte le distro che io sappia) sono già installate e supportate, basta solo attivarle.
Editiamo il nostro /etc/fstab :

sudo nano /etc/fstab

e abilitamole specificando il flag "acl" nel mount del nostro file system:

/dev/sda3 / ext3 defaults,acl 0 1

Riavviamo e siamo a posto. Abbiamo le estensioni attivate.

setfacl & getfacl

Questi sono i nostri due nuovi amici, setfacl per settare i permessi estesi e getfacl per visualizzarli. Non stò a spiegare come funzionano in dettaglio le acl posix, c'e' chi lo ha già fatto in modo ottimale. Per approfondire leggete ad esempio , oppure se preferite la lingua italiana.
Questa è la nostra situazione:

drwxrws---  2 root Prodotti     4096 21 dic 15:46 prodotti

Visualizziamola con :

sudo getfacl /samba/public/prodotti

e ottengo questo, non ho attivato alcuna estensione e quindi corrispondono ai normali flag che tutti conosciamo :

# file: samba/public/prodotti



    
owner: root
    
group: Prodotti


user::rwx

group::rwx

other::---

Ora impostamo i nostri sospirati permessi al gruppo "Prodotti-RO":

sudo setfacl -d -m group:Prodotti-RO:r-x /samba/public/prodotti
sudo setfacl -m group:Prodotti-RO:r-x /samba/public/prodotti

Visualizziamo di nuovo:

sudo getfacl /samba/public/prodotti

e stavolta ottengo questo:

# file: prodotti



    
owner: root
    
group: Prodotti


user::rwx

group::rwx

group:Prodotti-RO:r-x

mask::rwx

other::---

default:user::rwx

default:group::rwx

default:group:Prodotti-RO:r-x

default:mask::rwx

default:other::---

Bene. Abbiamo dato i permessi di lettura al gruppo "Permessi-RO", impostandoli anche come default. Riappuntiamoci sul petto la nostra spilla di "sysnetworksuperexpertadmin" :).
Se adesso riguardiamo la situazione con ls -al vedo questo :

drwxrws---+  2 root Prodotti     4096 21 dic 15:46 prodotti

Il segno + alla fine indica che nella cartella prodotti sono attive le estensioni acl posix.

Conclusioni

Questo post non era proprio specifico di Arch, ma serve sopratutto per capire come anche problemi semplici a volte possono farci traballare e desistere se non si hanno delle basi. E se ne potrebbe fare una montagna di esempi come questo, anche qualcuno da cui non se ne esce ...
I manuali di Samba in PDF hanno oltre 1200 pagine, e nessuna scritta per niente. La cosa divertente è che leggendoli e studiandoli capite pure come funziona Windows meglio di molti altri.
Le ACL Posix sono importanti e hanno un piacevole effetto collaterale (voluto ovviamente):

Si avete visto bene. Mi sono collegato con "Administrator" sul dominio da una macchina Windows e con pulsante destro->proprieta->protezione sulla cartella "prodotti" vedo le permissions ACL Posix che posso pure cambiare: Samba si occuperà del comando setfacl corrispondente.

Ma voi preferite la shell vero ?

A presto.