Indice dei contenuti dell'articolo:
Gli elenchi di controllo degli accessi di Linux, o ACL, possono richiedere un po’ di tempo per abituarsi, ma sono inestimabili per ottenere un controllo più dettagliato delle autorizzazioni del file system Linux.
Tra le sfide dell’amministrazione di Linux nel moderno ambiente aziendale c’è l’aspettativa che possiamo e dobbiamo gestire chi ha accesso a quali informazioni. C’era una volta, le uniche persone che avevano bisogno di accedere ai filesystem Linux potevano essere classificate in modo generale: attraverso i permessi del filesystem Linux.
La sigla «ACL» sta per Access control list e si riferisce qui a un’estensione della gestione dei permessi, rispetto alla tradizione dei sistemi Unix.
Come succede spesso, i nomi che rappresentano acronimi possono indicare cose differenti in contesti diversi. Nel caso particolare della sigla ACL, questa si usa anche in altre situazioni, specie nella gestione dell’accesso a servizi HTTP, dove si vuole regolare l’accesso al servizio o a delle risorse particolari. Ciò che si deve intendere è che la sigla ACL, anche se, come acronimo, fa riferimento alle stesse parole, rappresenta situazioni differenti in base al contesto.
POSIX ha prodotto alcune bozze sulla possibilità di estendere la gestione dei permessi dei sistemi Unix (POSIX 1003.1e e POSIX 1003.2c), ma tali lavori sono rimasti incompiuti. Queste bozze sono pubbliche e diversi sistemi Unix mettono a disposizione alcune di queste estensioni. Le estensioni a cui si fa riferimento con la sigla ACL, o eventualmente con «ACL POSIX» (benché si tratti solo di bozze), sono solo una porzione dell’insieme complessivo e in questo capitolo si vuole descrivere in particolare la realizzazione relativa ai sistemi GNU/Linux.
Rivedere le basi
Il filesystem di Linux ci offre tre tipi di permessi. Ecco una recensione semplificata:
- U ser (o proprietario dell’utente)
- G ruppo (o gruppo proprietario)
- Altri (tutti gli altri)
Con queste autorizzazioni, possiamo concedere tre (in realtà cinque, ma ci arriveremo tra un minuto) tipi di accesso:
- Read _
- Write _
- e X ecute
Questi livelli di accesso sono spesso adeguati in molti casi. Supponi di avere una directory in cui risiedono i file del reparto contabilità. Puoi impostare queste autorizzazioni su:
drwxrwxr-x 2 accounting accounting 12 Jan 8 15:13
L’utente del servizio di contabilità (il proprietario dell’utente) può leggere e scrivere nella directory e i membri del accounting
gruppo (o gruppo proprietario) possono leggere e scrivere. Altri (utenti non nel reparto contabilità) possono, tuttavia, vedere ed eseguire ciò che c’è dentro, cosa che alcuni potrebbero pensare sia una cattiva idea.
Quindi, potremmo cambiare le autorizzazioni in questo:
drwxrwx--- 2 accounting accounting 12 Jan 8 15:13 .
In questo modo gli altri utenti che non sono proprietari della cartella, ne appratenti al gruppo potranno fare nulla, in quanto non è specificato nessun permesso read, write od execute.
Visualizzazione dell’ACL corrente
E se hai uno stagista contabile (Kenny) che deve essere in grado di leggere determinati file (o anche solo i file di proprietà di Fred, il suo manager)? O forse anche le persone nel reparto vendite devono accedere ai accounting
file del proprietario per creare fatture per il team di Fred al fine di fatturare i clienti, ma non si desidera che il team di vendita veda gli altri report generati dal team di Fred. Questa situazione può essere complicata perché, con autorizzazioni regolari, ogni file e directory può avere un solo proprietario di utente e gruppo alla volta. Questo tipo di situazione è ciò che le Linux Access Control List (ACL) dovevano risolvere.
Gli ACL ci consentono di applicare un insieme più specifico di autorizzazioni a un file o una directory senza (necessariamente) modificare la proprietà e le autorizzazioni di base. Ci consentono di “aggiungere” l’accesso per altri utenti o gruppi.
Possiamo visualizzare l’ACL corrente usando il getfacl
comando:
[root]# getfacl /accounting
getfacl: Removing leading '/' from absolute path names
# file: accounting
# owner: accounting
# group: accounting
user::rwx
group::rwx
other::---
Possiamo vedere che in questo momento non ci sono ACL in questa directory perché le uniche autorizzazioni elencate sono per l’utente, il gruppo e altro. In questo caso, c’era da aspettarselo, perché ho appena creato questa directory in laboratorio e non ho fatto altro che assegnare la proprietà.
Quindi, iniziamo aggiungendo un ACL predefinito:
Impostazione di un ACL
La sintassi per l’impostazione di un ACL è simile alla seguente:
setfacl [option] [action/specification] file
L'”azione” sarebbe -m
(modifica) o -x
(rimuovi) e la specifica sarebbe l’utente o il gruppo seguito dai permessi che vogliamo impostare. In questo caso, useremo l’opzione -d
(default). Quindi, per impostare l’ACL predefinito per questa directory, eseguiremo:
[root]# setfacl -d -m accounting:rwx /accounting
Dopo di che ora possiamo vedere le informazioni ACL predefinite per quella directory:
[root]# getfacl /accounting
[root]# getfacl: Removing leading '/' from absolute path names
# file: accounting
# owner: accounting
# group: accounting
user::rwx
group::rwx
other::---
default:user::rwx
default:user:accounting:rwx
default:group::rwx
default:mask::rwx
default:other::---
Cosa succede se Fred crea un file in quella directory?
[fred]$ touch test
[fred]$ ls -la
drwxrwx---+ 2 accounting accounting 18 Jan 8 17:51 .
dr-xr-xr-x. 18 root root 262 Jan 8 15:13 ..
-rw-rw----+ 1 fred accounting 0 Jan 8 17:51 test
[fred]$ getfacl test
# file: test
# owner: fred
# group: accounting
user::rw-
user:accounting:rwx #effective:rw-
group::rwx #effective:rw-
Cosa succede se Kenny tenta di creare un file? Potresti essere in grado di indovinare che poiché kenny
non è nel accounting
gruppo, non avrà il permesso. Ma vogliamo che Kenny abbia una buona esperienza lavorando con noi, quindi dobbiamo dargli la possibilità di vedere quali file sono nella accounting
directory e vogliamo che sia in grado di creare nuovi file:
[root@lab1 accounting]setfacl -m kenny:rwx /accounting
[root]getfacl ./
# file: .
# owner: accounting
# group: accounting
user::rwx
user:kenny:rwx
Fin qui tutto bene. Ma cosa succede se non vogliamo che questo utente crei file nella accounting
directory? Invece, vogliamo solo fargli leggere i file lì e può creare nuovi file nella sua cartella.
Possiamo impostare l’accesso di Kenny sulla accounting
cartella in questo modo:
[root@lab1 accounting]# setfacl -m kenny:r-x /accounting
[root]# getfacl ./
# file: .
# owner: accounting
# group: accounting
user::rwx
User:kenny:r-x
Ora rendiamo Kenny la sua cartella, gli assegniamo la proprietà e quindi rendiamo il accounting
gruppo il proprietario del gruppo in modo che le altre persone nel accounting
gruppo possano vedere cosa c’è dentro:
[root@lab1 accounting]# mkdir ./kenny
[root]# chown kenny:accounting ./kenny
[root]# getfacl ./kenny
# file: kenny
# owner: kenny
# group: accounting
user::rwx
user:accounting:rwx
group::rwx
Hai creato una cartella all’interno del accounting
gruppo di proprietà dell’utente kenny
. Ora è in grado di vedere la cartella della contabilità, ma crea solo file nella sua cartella:
[root@lab1 accounting]# su kenny
[kenny]$ touch test
touch: cannot touch ‘test’: Permission denied
[kenny]$ cd ./kenny
[kenny]$ touch test
[kenny]$ ls
test
Si noti che poiché la cartella è di proprietà del accounting
gruppo, chiunque in quel gruppo può inserire file lì. Poiché abbiamo a che fare con uno stagista, questo fattore probabilmente va bene. Tuttavia, cosa succede se diamo a Kenny una promozione a capo revisore e vogliamo tenere segreto il suo lavoro a Fred?
[root]# setfacl -m fred:- ./kenny
[root]# getfacl ./kenny
# file: kenny
# owner: kenny
# group: accounting
user::rwx
user:accounting:---
user:fred:---
E se non volessimo che nessuno vedesse a cosa sta lavorando Kenny?
[root]# setfacl -m g:accounting:- ./kenny
Nota: quando vogliamo impostare un ACL di gruppo , dobbiamo specificarlo anteponendo g:
il nome del gruppo. Per gli utenti, cambia semplicemente g
in a u
, ma setfacl
supponiamo che stiamo parlando di un utente se non metti nulla in quel punto.
Dobbiamo ancora rimuovere le autorizzazioni di base per il proprietario del gruppo in modo che il resto del team contabile non possa curiosare nei rapporti di Kenny:
[root]# chmod g-rwx ./kenny
[root]# ls -al
total 0
drwxrwx-wx+ 3 accounting accounting 44 Jan 9 16:38 .
dr-xr-xr-x. 18 root root 262 Jan 8 15:13 ..
drwx------+ 2 kenny accounting 18 Jan 9 17:07 kenny
-rw-rw----+ 1 root root 0 Jan 9 16:33 test
-rw-rw----+ 1 kenny accounting 0 Jan 9 16:27 test2
[root]# getfacl ./kenny
# file: kenny
# owner: kenny
# group: accounting
user::rwx
user:accounting:---
user:fred:---
group::rwx #effective:---
[root]# su jan
[jan]$ touch ./kenny/test
touch: cannot touch ‘./kenny/test’: Permission denied
Ora possiamo gestire chi altro può vedere o scrivere nella cartella di Kenny senza cambiare la proprietà. Diamo all’amministratore delegato (Lisa, che non è un membro del team contabile e non avrà accesso al resto della cartella) l’accesso alle cose di Kenny:
[root@lab1 accounting]# useradd lisa
[root]# setfacl -m u:lisa:rwx ./kenny
[root]# su lisa
[lisa]$ touch ./kenny/lisa
[lisa]$ ls ./kenny
lisa test
[lisa]$ touch test
touch: cannot touch ‘test’: Permission denied
[root]# getfacl ./kenny
# file: kenny
# owner: kenny
# group: accounting
user::rwx
user:accounting:---
user:fred:---
user:lisa:rwx
group::rwx
group:accounting:---
Si noti ancora che le autorizzazioni del proprietario del gruppo rimangono completamente aperte, ma il gruppo di contabilità (che è ancora il proprietario) non ha più accesso a quella cartella. Quindi, chi lo possiede?
drwxrwx---+ 2 kenny accounting 30 Jan 9 17:16 kenny
Questa parte è complicata. È utile sapere che possiamo rimuovere le autorizzazioni del proprietario senza modificare la proprietà, ma potresti valutare se questo è il risultato che desideri.
Conclusione
Quindi queste sono le basi. Gli ACL possono creare confusione, quindi ti incoraggio a dare le pagine man setfacl
e getfacl
una buona lettura. Ci sono molte altre cose interessanti e utili che puoi fare con questi strumenti, ma si spera che ora tu capisca abbastanza per iniziare.