Chapter 28. Le Access Control List in Linux / 28.3. Utilizzare le ACL | ||||
|---|---|---|---|---|
 | 28.2. Definizioni | 28.4. Supporto delle applicazioni |  | |
Chapter 28. Le Access Control List in Linux / 28.3. Utilizzare le ACL | ||||
|---|---|---|---|---|
| 28.2. Definizioni | 28.4. Supporto delle applicazioni | | |
Nel seguente paragrafo vi mostriamo la struttura basilare delle ACL e le loro diverse varianti. Il nesso tra le ACL ed il modello d'assegnazione dei permessi tradizionale nel file system Linux verrà brevemente esposto anche sulla base di diversi grafici. In due esempi vi mostreremo come creare da voi delle ACL e come badare alla correttezza della sintassi. Infine vi mostriamo secondo quale schema il sistema operativo analizza le ACL.
Le ACL si possono suddividere in due categorie. L'ACL minima è composta esclusivamente da registrazioni del tipo owner (proprietario), owning group (gruppo proprietario) ed other (altri) e corrisponde ai tradizionali bit dei permessi per file e directory. Le ACL estese (ingl. extended ) vanno oltre. Esse devono contenere una registrazione mask (maschera) e possono contenere diverse registrazioni del tipo named user e named group. La tabella Table 28.1, “Rassegna: tipi di registrazione ACL” riassume i diversi tipi di registrazioni ACL disponibili.
Table 28.1. Rassegna: tipi di registrazione ACL
Tipo | Forma del testo |
|---|---|
owner | user::rwx |
named user | user:name:rwx |
owning group | group::rwx |
named group | group:name:rwx |
mask | mask::rwx |
other | other::rwx |
I permessi stabiliti sotto owner ed other valgono sempre. Fatta eccezione per mask tutte le altre registrazioni, (ovvero named user, owning group e named group) possono essere rese effettive o mascherate. I permessi sono effettivi se sono stati impostati sia in una delle registrazioni sovramenzionate che nella maschera. I permessi impostati solo nella maschera o presenti solo nella registrazione in sé non sono validi. Con il seguente esempio cerchiamo di chiarire questo concetto (si veda la tabella Table 28.2, “Mascheramento dei permessi di accesso”):
Le due figure illustrano il caso di una ACL minima ed di una estesa (si veda la fig. Figure 28.1, “ACL minima: registrazioni ACL vs. bit dei permessi” e Figure 28.2, “ACL estese: registrazioni ACL vs. bit dei permessi”). Vedete tre blocchi. A sinistra si ha l'indicazione del tipo della registrazione ACL, in centro una ACL esempio e a destra i corrispondenti bit dei permessi secondo il modello dei permessi tradizionale, come visualizzato anche dal comando ls -l.
In entrambi i casi i permessi owner class vengono associati alla registrazione ACL owner. Si ripete anche l'attribuzione dei permessi other class alla registrazione ACL corrispondente. L'attribuzione dei permessi group class varia:
Nel caso di una ACL minima — ovvero senza registrazione mask — i permessi group class vengono assegnati alla voce ACL owning group (si veda la fig. Figure 28.1, “ACL minima: registrazioni ACL vs. bit dei permessi”).
Nel caso di ACL estese — dunque con la registrazione mask — i permessi group class vengono assegnati alla voce mask (vd. la fig. Figure 28.2, “ACL estese: registrazioni ACL vs. bit dei permessi”).
Grazie a questo tipo di assegnazione viene garantito che le applicazioni con e sprovviste di supporto per le ACL possano interagire senza difficoltà alcuna. I permessi di accesso che sono stati stabiliti tramite i bit dei permessi rappresentano il limite massimo per le “impostazioni mirate” effettuate tramite le ACL. Tutti i permessi non riportati qui o non sono stati impostati nella ACL o non sono effettivi. Se si apportono delle modifiche ai bit dei permessi questo si rispecchia chiaramente anche nelle corrispondenti ACL e viceversa.
I seguenti tre passi riportati nell'esempio vi permetteranno di lavorare con le ACL:
Creare un oggetto di file system (nel nostro esempio una directory)
Modificare l'ACL
Utilizzare le maschere
Prima di creare una directory, il comando umask vi permette di stabilire a priori quali diritti di accesso mascherare:
umask 027
Con questo comando il proprietario mantiene tutti i permessi (0, al gruppo non viene concesso l'accesso in lettura (2). Tutti gli altri utenti non hanno nessun permesso di accesso (7 ). Per avere maggiori informazioni su umask, consultate la relativa pagina di manuale (man umask).
mkdir mydir
Viene creata la directory mydir con i permessi stabiliti con umask. Immettendo
ls -dl mydir drwxr-x--- ... tux progetto3 ... mydir
potete verificare se i permessi sono stati assegnati correttamente.
Dopo esservi informati sullo stato originario della ACL, aggiungetevi rispettivamente una nuova registrazione d'utente e di gruppo.
getfacl mydir # file: mydir # owner: tux # group: progetto3 user::rwx group::r-x other::---
L'output di getfacl rispecchia esattamente la correlazione tra i bit dei permessi e le registrazioni ACL descritta nel paragrafo Section 28.3.2, “Le registrazioni ACL ed i bit dei permessi”. Nelle prime tre righe dell'output si ha il nome, il proprietario e il relativo gruppo della directory. Le successive tre righe indicano le tre registrazioni ACL owner, owning group ed other. Complessivamente per quanto riguarda le ACL (minime) il comando getfacl non emette alcuna informazione che non fosse emessa anche dal comando ls.
Il vostro primo intervento sulle ACL mira a concedere ad un ulteriore utente jane ed ad un ulteriore gruppo djungle i permessi di lettura, scrittura ed esecuzione.
setfacl -m user:jane:rwx,group:djungle:rwx mydir
Con l'opzione -m istruite setfacl a modificare le ACL esistenti. Il seguente argomento indica le registrazioni ACL da modificare (se si tratta di diverse registrazioni, esse vanno separata da virgole). Infine indicate il nome della directory per la quale applicare la modifica.
Fatevi mostrare adesso l'ACL immettendo getfacl.
# file: mydir # owner: tux # group: progetto3 user::rwx user:jane:rwx group::r-x group:djungle:rwx mask::rwx other::---
Oltre alle immissioni fatte da voi per l'utente jane ed il gruppo djungle è stata aggiunta una voce mask. mask viene aggiunto automaticamente per avere un comune minimo denominatore per tutte le registrazioni in group class. Inoltre setfacl adatta automaticamente le registrazioni in mask se modificate delle impostazioni, almeno ché non vogliate disabilitare questa funzione con -n. mask stabilisce il limite massimo dei permessi di accesso valido per tutte le voci all'interno di group class, ovvero named user, named group ed owning group. I bit dei permessi di group class che verrebbero emessi dal comando ls -dl mydir corrispondono ora alla voce mask.
ls -dl mydir
drwxrwx---+ ... tux progetto3 ... mydir
In aggiunta nella prima colonna vi è un +, il segno per una ACL estesa.
In accordo con l'output del comando ls i permessi per la voce mask includono anche l'accesso in scrittura. Secondo il modello tradizionale dei permessi di accesso questi bit d'autorizzazione indicherebbero che l'owning group (in questo caso: progetto3) ha anche l'accesso in scrittura per la directory mydir. Comunque i permessi di accesso veramente validi per l'owning group vengono determinati dall'intersezione dei diritti impostati per l' owning group e mask; dunque nel nostro esempio r-x (si veda la tabella Table 28.2, “Mascheramento dei permessi di accesso”). In questo caso anche dopo aver aggiunto le registrazioni delle ACL non è cambiato nulla per quel che riguarda i permessi dell' owning group.
Con setfacl o chmod potete apportare delle modifiche a mask.
chmod g-w mydir ls -dl mydir drwxr-x---+ ... tux progetto3 ... mydir
getfacl mydir # file: mydir # owner: tux # group: progetto3 user::rwx user:jane:rwx # effective: r-x group::r-x group:djungle:rwx # effective: r-x mask::r-x other::---
Dopo aver sottratto l'accesso in scrittura al group class con chmod, l'output del comando ls vi fa notare che tramite chmod i bit di mask sono stati adattati di conseguenza. Più chiaro risulta ciò dall'output di getfacl che aggiunge dei commenti ad ogni registrazione i cui bit dei permessi effettivamente validi non concordano con quelli impostati originariamente, perché eliminati dalla registrazione mask. Naturalmente potrete ripristinare lo stato originario in ogni momento con il relativo comando di chmod:
chmod g+w mydir ls -dl mydir drwxrwx---+ ... tux progetto3 ... mydir
getfacl mydir
# file: mydir
# owner: tux
# group: progetto3
user::rwx
user:jane:rwx
group::r-x
group:djungle:rwx
mask::rwx
other::---
Per le directory vi sono delle ACL particolari: le ACL di default, con cui stabilire quali permessi di accesso erediterranno, al momento della loro creazione, tutti gli sotto-oggetti, cioè le sottodirectory di questa directory. La ACL di default vale sia per le sottodirectory che per i file.
I permessi di accesso di una ACL di default vengono trasmessi ai propri sotto-oggetti principalmente in due modi:
Una sottodirectory eredita l'ACL di default della directory superiore sia come propria ACl di default che ACL di accesso.
Un file eredita l'ACL di default come propria ACL di accesso.
Tutte le chiamate di sistema system calls per la creazione di oggetti di file system utilizzano un parametro mode. Questo parametro mode imposta i permessi di accesso per il file o la directory da creare:
Se la directory superiore non ha una ACL di default, i permessi risulteranno dall'intersezione dei permessi stabiliti nel parametro mode, da cui sono stati sottratti i permessi impostati con umask.
Se esiste una ACL di default per la directory superiore, i bit dei permessi si compongono in base all'intersezione del valore del parametro mode ed dei permessi stabiliti nella ACL di default e quindi assegnati all'oggetto. umask in questo caso non viene considerato.
Nel paragrafo seguente vi indicheremo come:
Creare l'ACL di default per una directory esistente
Creare una sottodirectory in una directory con ACL di default
Creare un file in una directory con ACL di default
Aggiungete alla directory che avete creato prima mydir una ACL di default:
$> setfacl -d -m group:djungle:r-x mydir
L'opzione -d del comando setfacl istruisce setfacl ad applicare le modifiche seguenti (opzione -m) alla ACL di default.
Osservate con attenzione il risultato del comando:
getfacl mydir # file: mydir # owner: tux # group: progetto3 user::rwx user:jane:rwx group::r-x group:djungle:rwx mask::rwx other::--- default:user::rwx default:group::r-x default:group:djungle:r-x default:mask::r-x default:other::---
getfacl ritorna sia l'ACL di accesso che quella di default. Le righe che iniziano con default rappresentano l'ACL di default. Anche se per quanto riguardo l'ACL di default avete passato al comando setfacl solamente la registrazione per il gruppo djungle, setfacl ha copiato automaticamente tutte le altre registrazioni della ACL di accesso per creare una ACL di default valida. Le ACL di default non influiscono direttamente sui permessi di accesso, hanno effetto solo quando si crea un nuovo oggetto di file system, ovvero file o directory. Per quando riguarda la trasmissione dei permessi viene presa in considerazione solo l'ACL di default della directory superiore.
Nel prossimo esempio create con mkdir una sottodirectory in mydir che “ erediterà” l'ACL di default.
mkdir mydir/mysubdir getfacl mydir/mysubdir # file: mydir/mysubdir # owner: tux # group: progetto3 user::rwx group::r-x group:djungle:r-x mask::r-x other::--- default:user::rwx default:group::r-x default:group:djungle:r-x default:mask::r-x default:other::---
Come previsto, la nuova sottodirectory mysubdir ha gli stessi permessi della ACL di default della directory superiore. L'ACL di accesso di mysubdir è una copia perfetta della ACL di default di mydir, come è anche il caso per l'ACL di default che questa directory trasmetterà a sua volta ai propri sotto-oggetti.
Con touch, create un file nella directory mydir:
touch mydir/myfile ls -l mydir/myfile -rw-r-----+ ... tux progetto3 ... mydir/myfile
getfacl mydir/myfile # file: mydir/myfile # owner: tux # group: progetto3 user::rw- group::r-x # effective:r-- group:djungle:r-x # effective:r-- mask::r-- other::---
Da considerare in questo esempio: con touch si ha un mode con il valore 0666 , cioè i nuovi file vengono creati con permesso di accesso in lettura e scrittura per tutte e tre le categorie di utenti, almeno ché umask o l'ACL di default non preveda altre restrizioni (si veda il paragrafo Section 28.3.4.1, “Gli effetti di una ACL di default”).
Concretamente questo significa che tutti i permessi di accesso non contenuti nel valore mode vengono eliminati dalle rispettive registrazioni ACL. Dalla registrazione ACL per group class non sono stati eliminati dei permessi, tuttavia è stata adattata la voce mask in modo che vengano mascherati i bit dei permessi non impostati tramite mode.
In tal maniera si assicura che per esempio un compiler possa interagire senza difficoltà alcuna con le ACL. Potete creare dei file con permessi di accesso limitati ed contrassegnarli in seguito come eseguibili. mask fa sì che gli utenti e i gruppi ottengano anche i permessi concessi loro nella ACL di default.
Dopo aver compreso l'utilizzo dei tool principali di configurazione per le ACL introduciamo ora brevemente l'algoritmo di analisi che viene applicato ad ogni processo o applicazione prima di ottenere il permesso di accesso all'oggetto protetto da una ACL.
In linea di principio le registrazioni ACL vengono analizzate in questa sequenza: owner, named user, owning group o named group ed other. E tramite la voce che più si adatta si regola quindi l'accesso.
Le cose si complicano un pò quando un processo appartiene a più di un gruppo, dunque quando teoreticamente anche più registrazioni group potrebbero essere quelle adatte. Tra le registrazioni adatte con i permessi richiesti viene selezionata una a caso. Infatti per il risultato finale “Accesso consentito ” non fa differenza quale voce è stata scelta. Se nessuna voce group adatta dispone dei permessi corretti, è di nuovo una voce a caso che procura il risultato finale che in questo caso sarà Accesso negato.
