Permessi dei file in Linux: chmod, chown e sudo con esempi

I permessi dei file in Linux stabiliscono chi può fare cosa con un file. Ogni file ha un proprietario, un gruppo e tre insiemi di permessi: per il proprietario, per il gruppo e per tutti gli altri. I permessi si cambiano con chmod, il proprietario con chown, e le azioni da amministratore si eseguono con sudo. In questo articolo vediamo come leggere i permessi, come modificarli e come risolvere l'errore Permission denied.

Come vedere i permessi di un file

I permessi compaiono nell'output di ls -l:

$ ls -l
-rw-r--r-- 1 alice developers  1204 Oct 10 14:02 notes.txt
-rwxr-xr-x 1 alice developers   356 Oct 10 14:05 deploy.sh
drwxr-x--- 2 alice developers  4096 Oct 10 13:50 secrets

I primi dieci caratteri si leggono così:

• Primo carattere — tipo: - file normale, d directory, l collegamento simbolico.
• Caratteri 2–4 — permessi del proprietario (user).
• Caratteri 5–7 — permessi del gruppo (group).
• Caratteri 8–10 — permessi degli altri (others).

Seguono il numero di hard link, il proprietario (alice), il gruppo (developers), la dimensione, la data e il nome. Per un solo file è comodo il comando stat:

$ stat -c '%A %a %U:%G %n' deploy.sh
-rwxr-xr-x 755 alice:developers deploy.sh

Il significato di r, w e x

Il significato dei permessi cambia tra file e directory: è la principale fonte di confusione.

Attenzione: un utente che non può scrivere in un file può comunque eliminarlo, se ha w e x sulla directory che lo contiene. Senza x sulla directory, invece, non si può aprire nessun file al suo interno, anche se il file consente la lettura.

Il sistema verifica i permessi in ordine: se sei il proprietario si applicano i permessi del proprietario; altrimenti, se appartieni al gruppo del file, si applicano quelli del gruppo; in tutti gli altri casi quelli degli altri. L'utente root salta i controlli di lettura e scrittura.

Notazione numerica: 755, 644, 600

Ogni permesso ha un peso: r = 4, w = 2, x = 1. La somma dei pesi per ciascuno dei tre insiemi dà una cifra da 0 a 7.

Combinazioni comuni da ricordare a memoria:

Il comando chmod: come cambiare i permessi

Modo numerico

La forma numerica imposta tutti i permessi in una volta:

chmod 644 index.html
chmod 755 deploy.sh
chmod 600 ~/.ssh/id_ed25519

Modo simbolico

La forma simbolica modifica solo i permessi indicati, senza toccare gli altri. A chi: u proprietario, g gruppo, o altri, a tutti. Azione: + aggiunge, - toglie, = imposta esattamente.

chmod +x deploy.sh        # consente l'esecuzione
chmod u+x,g-w file        # esecuzione per il proprietario, toglie la scrittura al gruppo
chmod o-rwx secrets/      # nessun permesso per gli altri
chmod g=rx app/           # il gruppo può solo leggere ed entrare

Ricorsivo: file e directory in modo diverso

L'opzione -R applica i permessi a tutto l'albero. Ma chmod -R 755 rende eseguibili tutti i file, cosa di solito non voluta. Meglio separare file e directory con find:

find /srv/site -type d -exec chmod 755 {} +
find /srv/site -type f -exec chmod 644 {} +

Esiste anche una scorciatoia: la X maiuscola aggiunge l'esecuzione solo alle directory e ai file che già la possiedono.

chmod -R u=rwX,go=rX /srv/site

Il comando chown: cambiare proprietario e gruppo

Solo root può cambiare il proprietario di un file, quindi chown si usa quasi sempre con sudo.

sudo chown alice report.txt               # proprietario
sudo chown alice:developers report.txt    # proprietario e gruppo
sudo chown :www-data index.html           # solo il gruppo
sudo chown -R www-data:www-data /var/www/site

Per cambiare solo il gruppo esiste il comando dedicato chgrp: sudo chgrp developers report.txt. I propri gruppi si vedono con id o groups.

$ id
uid=1000(alice) gid=1000(alice) groups=1000(alice),27(sudo),1001(developers)

Per aggiungere un utente a un gruppo: sudo usermod -aG developers bob. L'opzione -a è obbligatoria: senza di essa l'utente viene rimosso da tutti gli altri gruppi secondari. Il nuovo gruppo diventa effettivo dopo un nuovo accesso.

sudo: agire come amministratore

sudo esegue un singolo comando con i privilegi di root (o di un altro utente) e chiede la propria password, non quella di root. Ogni chiamata viene registrata nel log, così si sa chi ha fatto cosa.

sudo apt update
sudo systemctl restart nginx
sudo -u postgres psql       # come utente postgres
sudo -i                     # shell interattiva di root
sudo -l                     # che cosa mi è permesso fare

Chi può fare cosa è definito in /etc/sudoers e nei file della directory /etc/sudoers.d/. Modifica questi file solo con sudo visudo: controlla la sintassi prima di salvare, così un errore non ti toglie l'accesso a sudo. In Ubuntu il privilegio sudo si ottiene facendo parte del gruppo sudo; nelle distribuzioni tipo RHEL del gruppo wheel.

# /etc/sudoers.d/deploy — l'utente deploy può solo riavviare nginx
deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx

Perché sudo echo > file non funziona

Un tranello frequente:

$ sudo echo "127.0.0.1 test.local" >> /etc/hosts
bash: /etc/hosts: Permission denied

Il reindirizzamento >> lo esegue la tua shell, non sudo, quindi il file viene aperto senza privilegi di root. Il modo corretto è usare tee:

echo "127.0.0.1 test.local" | sudo tee -a /etc/hosts

Permission denied: cause e rimedi

Permission denied significa che il kernel ha negato al tuo processo l'operazione richiesta. L'analisi segue sempre lo stesso schema: chi sono io (id), chi è il proprietario e quali permessi ha il file (ls -l), quali permessi ha ogni directory del percorso (namei -l).

$ namei -l /srv/app/config/app.env
f: /srv/app/config/app.env
drwxr-xr-x root  root  /
drwxr-xr-x root  root  srv
drwxr-x--- deploy deploy app
drwxr-xr-x deploy deploy config
-rw-r----- deploy deploy app.env

Qui si vede che la directory app è chiusa agli altri: un utente che non appartiene al gruppo deploy non può andare oltre, qualunque siano i permessi del file.

Lo script non si avvia

$ ./deploy.sh
bash: ./deploy.sh: Permission denied

Il file non ha il permesso di esecuzione. Soluzione: chmod +x deploy.sh, oppure eseguirlo con l'interprete: bash deploy.sh. Se la partizione è montata con l'opzione noexec (succede spesso con /tmp), il file non può essere eseguito direttamente, e funziona solo il secondo metodo.

Non si può scrivere in una directory di sistema

I file in /etc, /usr, /var/www appartengono a root o agli utenti di sistema. Per modifiche occasionali usa sudo; per un lavoro continuativo assegna i permessi a un gruppo, non a tutti.

Il server web risponde 403

Nginx o Apache, in Debian e Ubuntu, girano con l'utente www-data. Serve che possa leggere i file e avere x su tutte le directory del percorso. Rimedio: sudo chown -R www-data:www-data /var/www/site, oppure 755 sulle directory e 644 sui file.

SSH non accetta la chiave

SSH rifiuta le chiavi con permessi troppo aperti. La chiave privata deve avere 600, la directory ~/.ssh 700, il file authorized_keys sul server 600.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519 ~/.ssh/authorized_keys

Nessun accesso a Docker

Il messaggio permission denied while trying to connect to the Docker daemon socket indica che non fai parte del gruppo docker. Esegui sudo usermod -aG docker $USER e riconnettiti. Ricorda che appartenere a questo gruppo equivale quasi a essere root.

Perché chmod 777 è una pessima idea

Il consiglio «basta fare chmod 777» elimina l'errore, ma rende il file scrivibile da ogni utente e da ogni processo del sistema. Se un'applicazione web viene compromessa, un attaccante può modificare questi file. La strada giusta è capire quale utente ha bisogno dell'accesso e darglielo esattamente: tramite il proprietario o il gruppo.

umask: i permessi predefiniti

I nuovi file vengono creati tenendo conto della maschera umask. Con il valore tipico 022, i file nascono con 644 e le directory con 755.

$ umask
0022

Conclusioni

I permessi in Linux sono tre insiemi rwx per proprietario, gruppo e altri. chmod li modifica in forma numerica (755, 644, 600) o simbolica, chown cambia il proprietario, e sudo permette di eseguire un singolo comando come root. Davanti a Permission denied verifica l'utente, i permessi del file e quelli di ogni directory del percorso, e non risolvere con 777. Utenti, gruppi, permessi e sudo sono trattati in dettaglio nel corso con esercizi pratici.