ACL Linux: storia, concetti e uso pratico: differenze tra le versioni
(Nuovo articolo: ACL Linux, uso pratico su WordPress/MediaWiki e storia) |
(Refinement formattazione articolo ACL Linux) |
||
| Riga 1: | Riga 1: | ||
= | == Introduzione == | ||
Le '''ACL''' (''Access Control List'') in Linux servono quando i permessi classici | Le '''ACL''' (''Access Control List'') in Linux servono quando i permessi classici <code>rwx</code> per ''owner/group/others'' non bastano. | ||
In un server con WordPress e MediaWiki, le ACL permettono di assegnare permessi mirati a utenti tecnici (es. deploy) senza aprire tutto con | 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>. | ||
== Cosa sono le ACL Linux == | == Cosa sono le ACL Linux == | ||
| Riga 10: | Riga 10: | ||
Comandi base: | Comandi base: | ||
* | * <code>getfacl</code>: legge ACL correnti | ||
* | * <code>setfacl</code>: aggiunge/modifica/rimuove ACL | ||
== Perche sono utili su WordPress e MediaWiki == | == Perche sono utili su WordPress e MediaWiki == | ||
Scenario tipico: web server con utente | Scenario tipico: web server con utente <code>www-data</code> e uno o piu utenti operativi. | ||
Senza ACL si finisce spesso tra due estremi: | Senza ACL si finisce spesso tra due estremi: | ||
* permessi troppo stretti (operazioni bloccate) | * permessi troppo stretti (operazioni bloccate) | ||
| Riga 24: | Riga 24: | ||
=== Esempio WordPress === | === Esempio WordPress === | ||
Consentire a | Consentire a <code>deploy</code> scrittura solo su uploads: | ||
<syntaxhighlight lang="bash"> | <syntaxhighlight lang="bash"> | ||
| Riga 31: | Riga 31: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
La regola | La regola <code>d:</code> imposta ACL di default per file/cartelle creati in futuro. | ||
=== Esempio MediaWiki === | === Esempio MediaWiki === | ||
Gestire upload in | Gestire upload in <code>images</code> con permessi mirati: | ||
<syntaxhighlight lang="bash"> | <syntaxhighlight lang="bash"> | ||
| Riga 53: | Riga 53: | ||
== Buone pratiche == | == Buone pratiche == | ||
* evitare | * evitare <code>777</code> | ||
* applicare ACL solo dove necessario | * applicare ACL solo dove necessario | ||
* usare ACL di default sulle directory con contenuti dinamici | * usare ACL di default sulle directory con contenuti dinamici | ||
Versione delle 10:04, 20 mar 2026
Introduzione
Le ACL (Access Control List) in Linux servono quando i permessi classici rwx per owner/group/others non bastano.
In un server con WordPress e MediaWiki, le ACL permettono di assegnare permessi mirati a utenti tecnici (es. deploy) senza aprire tutto con chmod 777.
Cosa sono le ACL Linux
Le ACL estendono il modello Unix tradizionale con regole aggiuntive per utenti e gruppi specifici.
Comandi base:
getfacl: legge ACL correntisetfacl: aggiunge/modifica/rimuove ACL
Perche sono utili su WordPress e MediaWiki
Scenario tipico: web server con utente www-data e uno o piu utenti operativi.
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.
Esempio WordPress
Consentire a deploy scrittura solo su uploads:
<syntaxhighlight lang="bash"> sudo setfacl -R -m u:deploy:rwx /var/www/wordpress/wp-content/uploads sudo setfacl -R -m d:u:deploy:rwx /var/www/wordpress/wp-content/uploads </syntaxhighlight>
La regola d: imposta ACL di default per file/cartelle creati in futuro.
Esempio MediaWiki
Gestire upload in images con permessi mirati:
<syntaxhighlight lang="bash"> sudo setfacl -R -m u:deploy:rwx /var/www/mediawiki/images sudo setfacl -R -m d:u:deploy:rwx /var/www/mediawiki/images </syntaxhighlight>
Verifica
<syntaxhighlight lang="bash"> getfacl /var/www/wordpress/wp-content/uploads getfacl /var/www/mediawiki/images </syntaxhighlight>
Nota: controllare sempre la voce mask, perche puo limitare i permessi effettivi.
Buone pratiche
- evitare
777 - applicare ACL solo dove necessario
- usare ACL di default sulle directory con contenuti dinamici
- verificare ACL durante audit periodici
- documentare le regole operative
Storia delle ACL: quando sono nate
Timeline essenziale:
- Anni 60-70: concetti ACL in sistemi multiutente storici
- Anni 90: sviluppo 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
- Novembre 2002: ACL POSIX integrate nel kernel Linux 2.5.46 (ramo di sviluppo)
- Dal 2003 in poi: adozione ampia sui filesystem Linux server (ext*, XFS, altri)
In pratica, anche senza standard finale ratificato, le ACL Linux sono diventate uno strumento stabile e diffuso.