ACL Linux: storia, concetti e uso pratico

Introduzione

Le ACL (Access Control List) in Linux estendono il modello classico dei permessi Unix e consentono un controllo accessi piu granulare.

Quando owner, group e others non bastano, le ACL permettono di assegnare regole specifiche a singoli utenti o gruppi mantenendo il principio del minimo privilegio.

Concetti base

Nel modello standard Unix hai tre classi di permessi:

• proprietario
• gruppo
• altri

Con le ACL puoi aggiungere entry dedicate, ad esempio per dare accesso a un utente tecnico senza cambiare proprietario della risorsa.

Comandi principali:

• getfacl per leggere ACL correnti
• setfacl per creare/modificare/rimuovere ACL

Esempi pratici

Concedere permessi a un utente specifico

<syntaxhighlight lang="bash"> sudo setfacl -m u:deploy:rwx /srv/progetto/shared </syntaxhighlight>

Definire ACL di default su una directory

Le ACL di default vengono ereditate da nuovi file e directory creati al suo interno.

<syntaxhighlight lang="bash"> sudo setfacl -m d:u:deploy:rwx /srv/progetto/shared </syntaxhighlight>

Verificare ACL effettive

<syntaxhighlight lang="bash"> getfacl /srv/progetto/shared </syntaxhighlight>

Nota: la voce mask puo limitare i permessi realmente applicati.

Relazione con chmod

ACL e permessi tradizionali convivono. Dopo modifiche con chmod, e buona pratica controllare sempre il risultato con getfacl per verificare eventuali effetti sulla maschera ACL.

Quando usare le ACL

• ambienti multiutente
• directory condivise con esigenze di accesso diverse
• casi in cui si vogliono evitare permessi eccessivamente ampi (es. 777)
• sistemi in cui serve tracciare policy accessi piu rigorose

Storia delle ACL

Timeline essenziale:

• Anni 60-70: concetti ACL gia presenti in sistemi multiutente storici
• Anni 90: sviluppo delle estensioni sicurezza IEEE POSIX 1003.1e
• Ottobre 1997: riferimento tecnico nella bozza POSIX.1e Draft 17
• Gennaio 1998: standardizzazione POSIX.1e ritirata; il modello ACL continua comunque a essere implementato
• Novembre 2002: supporto ACL POSIX incluso nel kernel Linux 2.5.46 (ramo di sviluppo)
• Dal 2003 in poi: adozione ampia nei filesystem Linux usati in produzione

In sintesi, pur senza standard finale ratificato, le ACL sono diventate uno strumento consolidato nell'amministrazione Linux.

Buone pratiche

• applicare ACL solo dove necessario
• documentare le regole nei runbook operativi
• verificare periodicamente configurazioni e ereditarieta
• mantenere un approccio minimo privilegio

Fonti

• man page acl(5)
• USENIX 2003 - POSIX ACLs on Linux

Approfondimento tecnico ACL Linux

Modello ACL POSIX: entry principali

Le ACL POSIX su file/directory usano tipicamente queste entry:

• user:: permessi del proprietario
• group:: permessi del gruppo proprietario
• other:: permessi per tutti gli altri
• user:nome_utente: eccezioni per singolo utente
• group:nome_gruppo: eccezioni per gruppo specifico
• mask:: limite massimo effettivo per group e named user/group
• default:... ACL ereditarie (solo su directory)

Mask: il punto piu importante da capire

La mask limita i permessi effettivi di:

• group::
• tutte le entry user:... nominate
• tutte le entry group:... nominate

Esempio: se una entry dice rwx ma la mask e r-x, il risultato effettivo e r-x.

Per ricreare la mask in base alle entry correnti:

<syntaxhighlight lang="bash"> setfacl -m m::rwx /percorso

1. oppure ricalcolo automatico durante setfacl senza -n

</syntaxhighlight>

ACL access vs ACL default

• Access ACL: controlla accesso attuale al file/directory.
• Default ACL: template ereditato da nuovi oggetti creati dentro una directory.

Impostazione tipica su directory condivisa:

<syntaxhighlight lang="bash"> setfacl -m u:deploy:rwx /srv/shared setfacl -m d:u:deploy:rwx /srv/shared </syntaxhighlight>

Interazione con chmod e umask

• chmod puo modificare la mask ACL, cambiando i permessi effettivi.
• umask influenza i permessi iniziali alla creazione; se esiste una default ACL, quest'ultima partecipa al risultato finale.

Dopo operazioni massive con chmod -R, e consigliato ricontrollare con getfacl.

Verifica tecnica rapida

<syntaxhighlight lang="bash">

1. ACL estese presenti?

ls -l /percorso # il '+' nei permessi indica ACL estese

1. dettaglio completo

getfacl /percorso

1. proprietario/gruppo/mode classico

stat /percorso </syntaxhighlight>

Policy operativa per directory condivise

Pattern comune in produzione: 1. Proprietario applicativo stabile (es. utente servizio) 2. Gruppo di lavoro dedicato 3. ACL nominate solo per eccezioni reali 4. Default ACL sulle sole directory che generano nuovi file 5. Audit periodico e rimozione entry obsolete

Backup e ripristino ACL

Prima di cambi strutturali conviene salvare ACL:

<syntaxhighlight lang="bash"> getfacl -R /srv/shared > /root/acl-backup.txt setfacl --restore=/root/acl-backup.txt </syntaxhighlight>

Operazioni utili avanzate

<syntaxhighlight lang="bash">

1. rimuove ACL estese (mantiene permessi base)

setfacl -b /percorso

1. rimuove ACL default

setfacl -k /directory

1. modifica ricorsiva

setfacl -R -m u:deploy:rwX /srv/shared </syntaxhighlight>

Nota su X: assegna execute solo a directory (e file che gia avevano execute), utile per evitare execute indiscriminato sui file normali.

Filesystem e compatibilita

Sui filesystem Linux moderni (ext4, XFS) ACL sono normalmente disponibili. In ambienti particolari verificare:

• opzioni di mount
• supporto lato filesystem remoto
• differenze con modelli ACL non POSIX (es. NFSv4 ACL)

Troubleshooting tipico

Se "i permessi sembrano giusti ma non funziona": 1. verificare path completo (permessi su ogni directory padre) 2. controllare mask 3. confermare utente/gruppi reali del processo 4. verificare SELinux/AppArmor se presenti 5. testare accesso con utente reale del servizio

Comando utile per path diagnostics:

<syntaxhighlight lang="bash"> namei -om /percorso/file </syntaxhighlight>