|
|
| Riga 1: |
Riga 1: |
| == Introduzione ==
| | null |
| | |
| 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:
| |
| * <code>getfacl</code> per leggere ACL correnti
| |
| * <code>setfacl</code> 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 <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 ==
| |
| | |
| * ambienti multiutente
| |
| * directory condivise con esigenze di accesso diverse
| |
| * casi in cui si vogliono evitare permessi eccessivamente ampi (es. <code>777</code>)
| |
| * 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 ==
| |
| | |
| * [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]
| |
| == Approfondimento tecnico ACL Linux ==
| |
| | |
| === Modello ACL POSIX: entry principali ===
| |
| | |
| Le ACL POSIX su file/directory usano tipicamente queste entry:
| |
| * <code>user::</code> permessi del proprietario
| |
| * <code>group::</code> permessi del gruppo proprietario
| |
| * <code>other::</code> permessi per tutti gli altri
| |
| * <code>user:nome_utente:</code> eccezioni per singolo utente
| |
| * <code>group:nome_gruppo:</code> eccezioni per gruppo specifico
| |
| * <code>mask::</code> limite massimo effettivo per group e named user/group
| |
| * <code>default:...</code> ACL ereditarie (solo su directory)
| |
| | |
| === Mask: il punto piu importante da capire ===
| |
| | |
| La <code>mask</code> limita i permessi effettivi di:
| |
| * <code>group::</code>
| |
| * tutte le entry <code>user:...</code> nominate
| |
| * tutte le entry <code>group:...</code> nominate
| |
| | |
| Esempio: se una entry dice <code>rwx</code> ma la mask e <code>r-x</code>, il risultato effettivo e <code>r-x</code>.
| |
| | |
| Per ricreare la mask in base alle entry correnti:
| |
| | |
| <syntaxhighlight lang="bash">
| |
| setfacl -m m::rwx /percorso
| |
| # 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 ===
| |
| | |
| * <code>chmod</code> puo modificare la mask ACL, cambiando i permessi effettivi.
| |
| * <code>umask</code> influenza i permessi iniziali alla creazione; se esiste una default ACL, quest'ultima partecipa al risultato finale.
| |
| | |
| Dopo operazioni massive con <code>chmod -R</code>, e consigliato ricontrollare con <code>getfacl</code>.
| |
| | |
| === Verifica tecnica rapida ===
| |
| | |
| <syntaxhighlight lang="bash">
| |
| # ACL estese presenti?
| |
| ls -l /percorso # il '+' nei permessi indica ACL estese
| |
| | |
| # dettaglio completo
| |
| getfacl /percorso
| |
| | |
| # 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">
| |
| # rimuove ACL estese (mantiene permessi base)
| |
| setfacl -b /percorso
| |
| | |
| # rimuove ACL default
| |
| setfacl -k /directory
| |
| | |
| # modifica ricorsiva
| |
| setfacl -R -m u:deploy:rwX /srv/shared
| |
| </syntaxhighlight>
| |
| | |
| Nota su <code>X</code>: 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 <code>mask</code>
| |
| 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>
| |