ACL Linux: storia, concetti e uso pratico: differenze tra le versioni

Versione delle 10:08, 20 mar 2026

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

@@ Riga 1: / Riga 1: @@
 == Introduzione ==
-Le '''ACL''' (''Access Control List'') in Linux servono quando i permessi classici <code>rwx</code> per ''owner/group/others'' non bastano.
+Le '''ACL''' (''Access Control List'') in Linux estendono il modello classico dei permessi Unix e consentono un controllo accessi piu granulare.
-In un server con WordPress e MediaWiki, le ACL permettono di assegnare permessi mirati a utenti tecnici (es. deploy) senza aprire tutto con <code>chmod 777</code>.
+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.
-== Cosa sono le ACL Linux ==
+== Concetti base ==
-Le ACL estendono il modello Unix tradizionale con regole aggiuntive per utenti e gruppi specifici.
+Nel modello standard Unix hai tre classi di permessi:
+* proprietario
+* gruppo
+* altri
-Comandi base:
+Con le ACL puoi aggiungere entry dedicate, ad esempio per dare accesso a un utente tecnico senza cambiare proprietario della risorsa.
-* <code>getfacl</code>: legge ACL correnti
-* <code>setfacl</code>: aggiunge/modifica/rimuove ACL
-== Perche sono utili su WordPress e MediaWiki ==
+Comandi principali:
+* <code>getfacl</code> per leggere ACL correnti
+* <code>setfacl</code> per creare/modificare/rimuovere ACL
-Scenario tipico: web server con utente <code>www-data</code> e uno o piu utenti operativi.
+== Esempi pratici ==
-Senza ACL si finisce spesso tra due estremi:
-* permessi troppo stretti (operazioni bloccate)
-* permessi troppo larghi (rischio sicurezza)
-Con ACL si applica il principio del minimo privilegio.
+=== Concedere permessi a un utente specifico ===
-=== Esempio WordPress ===
-Consentire a <code>deploy</code> scrittura solo su uploads:
 <syntaxhighlight lang="bash">
-sudo setfacl -R -m u:deploy:rwx /var/www/wordpress/wp-content/uploads
+sudo setfacl -m u:deploy:rwx /srv/progetto/shared
-sudo setfacl -R -m d:u:deploy:rwx /var/www/wordpress/wp-content/uploads
 </syntaxhighlight>
-La regola <code>d:</code> imposta ACL di default per file/cartelle creati in futuro.
+=== Definire ACL di default su una directory ===
-=== Esempio MediaWiki ===
-Gestire upload in <code>images</code> con permessi mirati:
+Le ACL di default vengono ereditate da nuovi file e directory creati al suo interno.
 <syntaxhighlight lang="bash">
-sudo setfacl -R -m u:deploy:rwx /var/www/mediawiki/images
+sudo setfacl -m d:u:deploy:rwx /srv/progetto/shared
-sudo setfacl -R -m d:u:deploy:rwx /var/www/mediawiki/images
 </syntaxhighlight>
-=== Verifica ===
+=== Verificare ACL effettive ===
 <syntaxhighlight lang="bash">
-getfacl /var/www/wordpress/wp-content/uploads
+getfacl /srv/progetto/shared
-getfacl /var/www/mediawiki/images
 </syntaxhighlight>
-Nota: controllare sempre la voce '''mask''', perche puo limitare i permessi effettivi.
+Nota: la voce '''mask''' puo limitare i permessi realmente applicati.
-== Buone pratiche ==
+== Relazione con chmod ==
+ACL e permessi tradizionali convivono. Dopo modifiche con <code>chmod</code>, e buona pratica controllare sempre il risultato con <code>getfacl</code> per verificare eventuali effetti sulla maschera ACL.
+== Quando usare le ACL ==
-* evitare <code>777</code>
+* ambienti multiutente
-* applicare ACL solo dove necessario
+* directory condivise con esigenze di accesso diverse
-* usare ACL di default sulle directory con contenuti dinamici
+* casi in cui si vogliono evitare permessi eccessivamente ampi (es. <code>777</code>)
-* verificare ACL durante audit periodici
+* sistemi in cui serve tracciare policy accessi piu rigorose
-* documentare le regole operative
-== Storia delle ACL: quando sono nate ==
+== Storia delle ACL ==
 Timeline essenziale:
-* '''Anni 60-70''': concetti ACL in sistemi multiutente storici
+* '''Anni 60-70''': concetti ACL gia presenti in sistemi multiutente storici
-* '''Anni 90''': sviluppo estensioni sicurezza IEEE POSIX 1003.1e
+* '''Anni 90''': sviluppo delle estensioni sicurezza IEEE POSIX 1003.1e
 * '''Ottobre 1997''': riferimento tecnico nella bozza POSIX.1e Draft 17
-* '''Gennaio 1998''': processo standard POSIX.1e ritirato, ma il modello ACL continua a essere usato
+* '''Gennaio 1998''': standardizzazione POSIX.1e ritirata; il modello ACL continua comunque a essere implementato
-* '''Novembre 2002''': ACL POSIX integrate nel kernel Linux 2.5.46 (ramo di sviluppo)
+* '''Novembre 2002''': supporto ACL POSIX incluso nel kernel Linux 2.5.46 (ramo di sviluppo)
-* '''Dal 2003 in poi''': adozione ampia sui filesystem Linux server (ext*, XFS, altri)
+* '''Dal 2003 in poi''': adozione ampia nei filesystem Linux usati in produzione
-In pratica, anche senza standard finale ratificato, le ACL Linux sono diventate uno strumento stabile e diffuso.
+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 ==
+* [https://man7.org/linux/man-pages/man5/acl.5.html man page acl(5)]
 * [https://atc.usenix.org/legacy/events/usenix03/tech/freenix03/full_papers/gruenbacher/gruenbacher_html/index.html USENIX 2003 - POSIX ACLs on Linux]
-* [https://man7.org/linux/man-pages/man5/acl.5.html man page acl(5)]
-* [https://lwn.net/Articles/660867/ LWN - contesto evoluzione ACL Linux]