ACL Linux: storia, concetti e uso pratico - Cronologia

Admin: Rollback modifica precedente

2026-03-20T11:07:31Z

Rollback modifica precedente

Mostra modifiche

Admin: Aggiornata pagina originale con rimando a Verifiche rapide

2026-03-20T11:05:24Z

Aggiornata pagina originale con rimando a Verifiche rapide

Mostra modifiche

Admin: Aggiunta spiegazione parametri dei comandi ACL

2026-03-20T10:50:47Z

Aggiunta spiegazione parametri dei comandi ACL

← Versione meno recente		Versione delle 10:50, 20 mar 2026
Riga 146:		Riga 146:
	* [https://man7.org/linux/man-pages/man5/acl.5.html man page acl(5)]		* [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://atc.usenix.org/legacy/events/usenix03/tech/freenix03/full_papers/gruenbacher/gruenbacher_html/index.html USENIX 2003 - POSIX ACLs on Linux]
			== Significato dei parametri usati nei comandi ==

			=== setfacl ===

			<pre>setfacl -m u:deploy:rwx /srv/progetto/shared</pre>

			* <code>-m</code>: modifica (add/update) una ACL entry.
			* <code>u:deploy:rwx</code>: entry ACL per utente `deploy` con permessi `rwx`.
			: `u` = user, `deploy` = utente, `rwx` = read/write/execute.
			* <code>/srv/progetto/shared</code>: path target.

			<pre>setfacl -m d:u:deploy:rwx /srv/progetto/shared</pre>

			* <code>d:</code>: ACL di default (ereditaria, valida su directory).
			* <code>u:deploy:rwx</code>: come sopra, ma applicata ai nuovi file/cartelle creati dentro la directory.

			<pre>setfacl -m m::rwx /percorso</pre>

			* <code>m::rwx</code>: imposta la <code>mask</code> ACL a `rwx`.
			: La mask limita i permessi effettivi di group e named user/group.

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

			* <code>-R</code>: applicazione ricorsiva su tutto l'albero.
			* <code>rwX</code>: `r` read, `w` write, `X` execute solo su directory (e su file che hanno gia execute).

			<pre>setfacl -b /percorso</pre>

			* <code>-b</code>: rimuove ACL estese, mantenendo i permessi base Unix.

			<pre>setfacl -k /directory</pre>

			* <code>-k</code>: rimuove solo le ACL di default dalla directory.

			<pre>setfacl --restore=/root/acl-backup.txt</pre>

			* <code>--restore=FILE</code>: ripristina ACL da backup creato con `getfacl -R`.

			=== getfacl ===

			<pre>getfacl /srv/progetto/shared</pre>

			* stampa ACL (access e default) del path.

			<pre>getfacl -R /srv/shared > /root/acl-backup.txt</pre>

			* <code>-R</code>: output ricorsivo.
			* <code>></code>: redirect su file per backup.

			=== ls / stat / namei ===

			<pre>ls -l /percorso</pre>

			* <code>-l</code>: formato esteso (permessi, owner, group, size, date).
			: Se compare `+` nei permessi (es. `drwxr-xr-x+`) sono presenti ACL estese.

			<pre>stat /percorso</pre>

			* mostra metadata dettagliati del file/directory (mode, uid/gid, inode, timestamp).

			<pre>namei -om /percorso/file</pre>

			* risolve ogni componente del path e mostra permessi/proprietari passo-passo.
			* <code>-o</code>: mostra owner e group.
			* <code>-m</code>: mostra i bit di permesso in stile `ls -l`.

			=== Promemoria rapido sui simboli permesso ===

			* <code>r</code> = read
			* <code>w</code> = write
			* <code>x</code> = execute/traverse
			* <code>X</code> = execute condizionale (utile nelle ricorsioni)

Admin: Fix rendering: sostituiti blocchi syntaxhighlight non supportati e ripristinato contenuto

2026-03-20T10:33:43Z

Fix rendering: sostituiti blocchi syntaxhighlight non supportati e ripristinato contenuto

Mostra modifiche

Admin: Compatibilita wiki: sostituiti syntaxhighlight con blocchi pre

2026-03-20T10:32:32Z

Compatibilita wiki: sostituiti syntaxhighlight con blocchi pre

Mostra modifiche

Admin: Aggiunto approfondimento tecnico ACL (mask, default ACL, chmod/umask, audit, restore, troubleshooting)

2026-03-20T10:28:17Z

Aggiunto approfondimento tecnico ACL (mask, default ACL, chmod/umask, audit, restore, troubleshooting)

← Versione meno recente		Versione delle 10:28, 20 mar 2026
Riga 76:		Riga 76:
	* [https://man7.org/linux/man-pages/man5/acl.5.html man page acl(5)]		* [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://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>

Admin: Admin ha spostato la pagina ACL Linux per WordPress e MediaWiki a ACL Linux: storia, concetti e uso pratico: Titolo reso generico su ACL Linux

2026-03-20T10:08:15Z

Admin ha spostato la pagina ACL Linux per WordPress e MediaWiki a ACL Linux: storia, concetti e uso pratico: Titolo reso generico su ACL Linux

← Versione meno recente	Versione delle 10:08, 20 mar 2026
(Nessuna differenza)

Admin: Contenuto reso generico: storia e uso ACL Linux

2026-03-20T10:08:15Z

Contenuto reso generico: storia e uso ACL Linux

← Versione meno recente		Versione delle 10:08, 20 mar 2026
Riga 1:		Riga 1:
	== Introduzione ==		== 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">		<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>		</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">		<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>		</syntaxhighlight>

	=== ~~Verifica~~ ===		=== Verificare ACL effettive ===

	<syntaxhighlight lang="bash">		<syntaxhighlight lang="bash">
	getfacl /~~var~~/~~www~~/~~wordpress/wp-content/uploads~~		getfacl /srv/progetto/shared
	~~getfacl /var/www/mediawiki/images~~
	</syntaxhighlight>		</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:		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		* '''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 ==		== 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://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]

Admin: Refinement formattazione articolo ACL Linux

2026-03-20T10:04:59Z

Refinement formattazione articolo ACL Linux

← Versione meno recente		Versione delle 10:04, 20 mar 2026
Riga 1:		Riga 1:
	= ~~ACL Linux per WordPress e MediaWiki: guida pratica e storia~~ =		== Introduzione ==

	Le '''ACL''' (''Access Control List'') in Linux servono quando i permessi classici ``rwx`` per ''owner/group/others'' non bastano.		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 ``chmod 777``.		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:
	* ``getfacl``: legge ACL correnti		* <code>getfacl</code>: legge ACL correnti
	* ``setfacl``: aggiunge/modifica/rimuove ACL		* <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 ``www-data`` e uno o piu utenti operativi.		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 ``deploy`` scrittura solo su uploads:		Consentire a <code>deploy</code> scrittura solo su uploads:

	<syntaxhighlight lang="bash">		<syntaxhighlight lang="bash">
Riga 31:		Riga 31:
	</syntaxhighlight>		</syntaxhighlight>

	La regola ``d:`` imposta ACL di default per file/cartelle creati in futuro.		La regola <code>d:</code> imposta ACL di default per file/cartelle creati in futuro.

	=== Esempio MediaWiki ===		=== Esempio MediaWiki ===

	Gestire upload in ``images`` con permessi mirati:		Gestire upload in <code>images</code> con permessi mirati:

	<syntaxhighlight lang="bash">		<syntaxhighlight lang="bash">
Riga 53:		Riga 53:
	== Buone pratiche ==		== Buone pratiche ==

	* evitare ``777``		* 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

Admin: Nuovo articolo: ACL Linux, uso pratico su WordPress/MediaWiki e storia

2026-03-20T10:03:50Z

Nuovo articolo: ACL Linux, uso pratico su WordPress/MediaWiki e storia

Nuova pagina

= ACL Linux per WordPress e MediaWiki: guida pratica e storia =

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 correnti
* ``setfacl``: 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.

== Fonti ==

* [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]