Skip to content
Torna al blog
Sicurezza

Permessi dei file Linux spiegati: chmod 755, 644 e 777

Capire i permessi dei file Linux: come funzionano chmod, ottale (755, 644, 777) e rwx, più setuid e umask, con un calcolatore chmod online gratuito.

11 min di lettura

Permessi dei file Linux spiegati: chmod 755, 644 e 777

I permessi dei file Linux decidono chi può leggere, scrivere o eseguire ogni file e cartella del sistema. Ogni elemento ha tre classi di utenti (il proprietario, un gruppo e tutti gli altri), e ogni classe riceve tre bit di permesso: lettura (r), scrittura (w) ed esecuzione (x). Sono nove bit per file. chmod li imposta, e la notazione abbreviata che vedi ovunque è l’ottale: l’rwx di ogni classe si condensa in una singola cifra da 0 a 7 (lettura 4 + scrittura 2 + esecuzione 1).

Tre modalità coprono quasi tutto ciò che digiterai:

  • 755 (rwxr-xr-x) — directory e script: il proprietario può modificarli, tutti gli altri possono leggerli ed eseguirli.
  • 644 (rw-r--r--) — file ordinari: il proprietario scrive, tutti gli altri leggono.
  • 777 (rwxrwxrwx) — accesso completo per tutti. Quasi sempre sbagliato; è una falla di sicurezza, non una soluzione.

Attiva qualsiasi combinazione nel calcolatore chmod gratuito e osserva l’ottale, la stringa rwx e il comando esatto aggiornarsi insieme. Il resto di questa guida spiega come funzionano quei numeri e dove ciascuno trova posto.

I permessi dei file Linux in 30 secondi

OttaleSimbolicoUso tipico
400r--------Chiave privata SSH, sola lettura
600rw-------File privati, chiavi SSH, .env
644rw-r--r--Pagine web, config, gran parte dei file
700rwx------Directory private (~/.ssh)
755rwxr-xr-xScript, binari, directory web
775rwxrwxr-xDirectory condivise nel gruppo
777rwxrwxrwxTutti, tutto — da evitare
1777rwxrwxrwtDirectory temporanee condivise come /tmp

Regola pratica: 644 per i file, 755 per le directory, e restringi da lì. Allenta una modalità solo quando qualcosa di concreto si rompe, mai in via preventiva.

Il modello dei permessi: proprietario, gruppo, altri

Tre classi condividono un file. Il proprietario (di solito chi l’ha creato), un singolo gruppo e gli altri, cioè ogni account che non è né il proprietario né un membro del gruppo. Ogni classe riceve in modo indipendente lettura, scrittura ed esecuzione:

  • lettura (r) — visualizzare il contenuto di un file, o elencare le voci di una directory.
  • scrittura (w) — modificare un file, o aggiungere e rimuovere voci in una directory.
  • esecuzione (x) — eseguire un file come programma, o entrare (cd) in una directory.

Il dettaglio che manda in confusione: su una directory, i bit significano qualcosa di diverso. r ti permette di elencare i nomi, w ti permette di creare ed eliminare voci al suo interno, e x ti permette di attraversarla, raggiungendo i file sottostanti così da poterci entrare con cd. Puoi avere r senza x su una directory, eseguirci ls e ricevere comunque “Permission denied” nel momento in cui provi a entrare. È esattamente per questo che le directory sono 755, non 644.

Leggere una riga di ls -l

Esegui ls -l e ogni voce inizia con un blocco di dieci caratteri:

$ ls -l
-rw-r--r--  1 jack staff  1400 Jul 17 10:00 index.html
drwxr-xr-x  5 jack staff   160 Jul 17 10:00 assets

Leggilo da sinistra a destra. Il primo carattere è il tipo di file, non un permesso: - è un file regolare, d una directory, l un collegamento simbolico, c o b un dispositivo, p una pipe con nome, s un socket. I nove caratteri successivi sono tre gruppi di rwx: proprietario, gruppo, altri. Quindi -rw-r--r-- è un file regolare in cui il proprietario legge e scrive (rw-) mentre gruppo e altri leggono soltanto (r-- r--), cioè 644. drwxr-xr-x è una directory a 755.

Alcuni sistemi aggiungono un marcatore dopo i nove bit. Un . finale segnala un contesto SELinux, un + significa che una ACL aggiunge regole oltre i bit di base, e su macOS un @ indica attributi estesi. Nessuno di questi cambia l’ottale. Ignora il marcatore e leggi i nove caratteri.

Notazione ottale: come 755 diventa rwxr-xr-x

I permessi dei file in ottale funzionano perché ogni permesso è una potenza di due:

  • lettura = 4
  • scrittura = 2
  • esecuzione = 1

Somma i bit che una classe possiede e ottieni la sua cifra. rwx è 4 + 2 + 1 = 7. r-x è 4 + 1 = 5. r-- è 4. Quindi rwxr-xr-x si legge, a gruppi di tre, come 7 5 5. Fai lo stesso per rw-r--r-- e ottieni 4 + 2, 4, 4 → 644. È tutto qui il trucco; i permessi in ottale non sono altro che tre somme indipendenti.

Le cifre dei permessi da 0 a 7 in sintesi

CifraBinarioPermessi
0000Nessun permesso
1001Solo esecuzione
2010Solo scrittura
3011Scrittura + esecuzione
4100Solo lettura
5101Lettura + esecuzione
6110Lettura + scrittura
7111Lettura + scrittura + esecuzione

L’ottale è semplicemente in base 8, quindi ogni cifra impacchetta tre bit senza sovrapporsi alla classe successiva. Se l’aritmetica posizionale ti sembra arrugginita, il convertitore di basi mostra come la base 8 si mappa sul binario nello stesso modo in cui lo fa ogni cifra di permesso.

chmod 755 vs 644 vs 777: le modalità che digiterai davvero

Ecco il confronto diretto tra chmod 755, 644 e 777:

OttaleSimbolicoProprietarioGruppoAltriUso tipicoRischio
644rw-r--r--lettura/scritturaletturaletturaFile regolariDefault sicuro
755rwxr-xr-xtuttolettura/eseclettura/esecDirectory, scriptDefault sicuro
600rw-------lettura/scritturaFile privati, chiaviMolto sicuro
700rwx------tuttoDirectory privateMolto sicuro
775rwxrwxr-xtuttotuttolettura/esecDirectory condivise nel gruppoIl gruppo può scrivere
777rwxrwxrwxtuttotuttotutto(da evitare)Scrivibile da tutti

La differenza tra 755 e 644 è un singolo bit: l’esecuzione. Directory, script e binari hanno bisogno di x per essere attraversati o eseguiti, quindi finiscono a 755. Un file regolare come una pagina HTML, un’immagine o un file di config non ha motivo di essere eseguibile, quindi resta a 644. Confondere i due sta dietro alla maggior parte degli errori di permessi di tutti i giorni.

Perché 777 è pericoloso. Concede accesso in scrittura a ogni account della macchina, incluso un account di servizio compromesso o un processo web dirottato. Una document root scrivibile da tutti è la via da manuale verso un sito deturpato o malware iniettato, perché chiunque la raggiunga può sovrascrivere il tuo codice. Quando un post su un forum ti dice di fare chmod 777 su qualcosa “per farlo funzionare”, il vero problema è quasi sempre la proprietà, trattata più avanti.

L’eccezione 1777. /tmp è scrivibile da tutti di proposito, ma con una salvaguardia. La modalità 1777 aggiunge lo sticky bit, che permette a tutti di creare file impedendo però agli utenti di eliminare o rinominare file che non possiedono. È per questo che le directory temporanee condivise sono sicure a 1777 ma mai a 777 puro. Digita 777 nel calcolatore chmod e il pannello dei rischi lo segnala immediatamente, mentre 1777 viene riconosciuto come lo schema standard per le directory condivise.

Modalità numerica vs simbolica

chmod accetta gli stessi bit in due modi.

La modalità numerica (assoluta) dichiara il risultato completo. chmod 755 file imposta tutti e nove i bit a rwxr-xr-x indipendentemente da cosa c’era prima. È ciò che vuoi negli script e nel deployment, dove stai imponendo uno stato noto e corretto.

La modalità simbolica (relativa) descrive una modifica. chmod u+x file cambia un solo bit (aggiunge l’esecuzione per il proprietario) e lascia intatto tutto il resto. chmod u=rwx,go=rx file imposta intere classi in modo esplicito. La modalità simbolica è adatta agli aggiustamenti una tantum, dove riscrivere l’intera modalità sarebbe eccessivo.

# Numeric: overwrite the whole mode
$ chmod 644 report.txt

# Symbolic: change only what you name
$ chmod u+x deploy.sh        # add execute for the owner
$ chmod go-w shared.conf     # remove write from group and others
$ chmod u=rw,go=r notes.md   # set each class explicitly → 644

Una trappola della modalità simbolica: chmod +x senza una classe viene filtrato dalla tua umask. Con la comune umask 022, chmod +x script.sh aggiunge l’esecuzione per tutti, quindi corrisponde a chmod a+x. Sotto una umask più restrittiva come 077 riguarda solo il proprietario. Quando vuoi un esito garantito, indica la classe: u+x per il solo proprietario, a+x per tutti.

Permessi speciali: setuid, setgid e sticky bit

Oltre ai nove bit standard, una quarta cifra ottale in testa trasporta tre modalità speciali, il trio setuid, setgid e sticky bit:

  • setuid = 4000 — il programma viene eseguito con i privilegi del proprietario del file, non del chiamante. È così che passwd, di proprietà di root, permette a un utente comune di aggiornare un database di password di proprietà di root.
  • setgid = 2000 — la stessa idea per il gruppo. Su una directory fa anche sì che i nuovi file ereditino il gruppo della directory, il che mantiene un progetto condiviso in modo coerente sotto la proprietà del gruppo.
  • sticky bit = 1000 — su una directory condivisa, limita l’eliminazione così che gli utenti possano rimuovere solo i propri file. /tmp a 1777 è l’esempio canonico.
$ chmod 4755 /usr/local/bin/mytool   # setuid
$ chmod 2775 /srv/shared             # setgid on a shared dir
$ chmod 1777 /tmp                     # sticky bit
$ ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 59976 Jul 17 10:00 /usr/bin/passwd

La regola su maiuscole e minuscole di s/S e t/T

In ls -l, i bit speciali riutilizzano la posizione dell’esecuzione, e il maiuscolo o minuscolo ti dice se anche l’esecuzione è attiva. Una s minuscola (setuid/setgid) o t (sticky) significa che il bit speciale e l’esecuzione sono attivi, il caso normale. Una S o T maiuscola significa che il bit speciale è impostato ma l’esecuzione no, il che di solito è un errore, perché un bit speciale su un file non eseguibile non fa nulla di utile.

Confronta rwsr-xr-x (4755, setuid con esecuzione, corretto) con rwSr--r-- (4644, setuid senza esecuzione, sospetto). Ogni volta che vedi una S o T maiuscola, verifica se qualcuno ha eliminato per sbaglio il bit di esecuzione.

La trappola GNU delle directory di cui nessuno parla

Ecco la differenza di piattaforma che quasi ogni tutorial sbaglia. Su Linux (GNU coreutils), un chmod 755 dir numerico non azzera un bit setuid o setgid esistente su quella directory. Lo preserva. Se una directory è già 2755 (setgid) ed esegui chmod 755 aspettandoti di partire da zero, il bit setgid rimane, e la directory in realtà è ancora 2755.

Per azzerarlo davvero, sii esplicito:

$ chmod 00755 dir      # five-digit form zeroes the special digit
$ chmod =755 dir       # = clears every bit not listed
$ chmod u-s,g-s dir    # remove setuid and setgid by name

BSD e macOS fanno l’opposto: un chmod 755 numerico azzera i bit speciali per impostazione predefinita. Perciò uno script di deploy che “reimposta” i permessi con chmod -R 755 si comporta in modo diverso su un portatile Mac rispetto a un server Linux. Questa conservazione è documentata nel manuale di GNU coreutils; nel dubbio, usa la forma a cinque cifre o u-s,g-s così che l’esito sia identico ovunque.

umask: cosa ottengono i file appena creati

Raramente esegui chmod su ogni file a mano; la maggior parte ottiene la propria modalità al momento della creazione, e la decide umask. Una umask è un insieme di bit da disattivare. I nuovi file partono dalla base 666 e le nuove directory da 777, e la umask maschera via i bit:

effective mode = base & ~umask

I file iniziano a 666, non a 777, perché un file appena creato non ha alcun motivo di essere eseguibile per impostazione predefinita. Quel bit viene aggiunto deliberatamente con chmod +x.

umaskNuovi fileNuove directorySignificato
022644755Default — gli altri leggono, non scrivono
077600700Privato al proprietario
002664775Collaborazione di gruppo

Elabora a mano il valore predefinito 022: 666 & ~022 = 666 & 755 = 644, e 777 & ~022 = 755. Controlla il tuo valore attuale con umask, e imposta un default di sessione con, ad esempio, umask 077 su una macchina dove nulla dovrebbe essere leggibile dal gruppo o da tutti.

chmod vs chown: permessi vs proprietà

chmod e chown rispondono a domande diverse. chmod cambia ciò che proprietario, gruppo e altri possono fare: i bit di permesso. chown cambia chi sono effettivamente il proprietario e il gruppo. Ricorrere a 777 è spesso un problema di proprietà travestito da problema di permessi.

Il caso classico: un server web in esecuzione come www-data non riesce a scrivere nella sua directory di upload. chmod 777 fa sparire l’errore lasciando scrivere il mondo intero, e si lascia dietro una falla. La correzione giusta assegna la proprietà al processo che ne ha bisogno:

# Wrong: opens the directory to every account on the box
$ sudo chmod -R 777 /var/www/uploads

# Right: give it to the web user, keep a tight mode
$ sudo chown -R www-data:www-data /var/www/uploads
$ sudo find /var/www/uploads -type d -exec chmod 755 {} +
$ sudo find /var/www/uploads -type f -exec chmod 644 {} +

Ordine diagnostico quando qualcosa è inaspettatamente illeggibile: esegui ls -l per vedere prima chi lo possiede, poi decodifica la modalità, quindi decidi se la correzione è chown, chmod o aggiungere un utente a un gruppo.

Permessi ricorsivi fatti bene

Un chmod -R 755 . indiscriminato marca ogni file regolare come eseguibile, il che è rumore nel migliore dei casi e un rischio silenzioso nel peggiore. Procedi invece in modo ricorsivo per tipo:

$ find . -type d -exec chmod 755 {} +   # directories → 755
$ find . -type f -exec chmod 644 {} +   # files → 644

GNU chmod offre una scorciatoia su una sola riga con la X maiuscola, che aggiunge l’esecuzione solo alle directory e ai file che portano già un bit di esecuzione:

$ chmod -R u+rwX,go+rX .

Il calcolatore chmod genera i comandi find solo-directory e solo-file per qualsiasi modalità tu scelga, così puoi copiare la suddivisione corretta invece di ricorrere a un semplice -R.

Buone pratiche per i permessi dei file Linux

  • Concedi il privilegio minimo che funziona. Parti dalla modalità più restrittiva e apri solo ciò che si rompe. Ogni bit di scrittura in più è superficie d’attacco.
  • Usa come default file a 644 dentro directory a 755. Questo abbinamento serve quasi ogni web root e checkout di repository. I file regolari raramente hanno bisogno dell’esecuzione; le directory sempre.
  • Non lasciare mai 777 su qualcosa che un server può raggiungere. Se più account devono scrivere, usa un gruppo condiviso con 775 o 2775 (setgid mantiene coerente la proprietà del gruppo) invece di aprire la modalità a tutti.
  • Tieni le chiavi private SSH a 600, o a 400 una volta definitive. OpenSSH rifiuta categoricamente le chiavi private leggibili dal gruppo o da tutti. Consulta il manuale di OpenSSH per il requisito esatto sul file della chiave. Le chiavi pubbliche e authorized_keys vanno bene a 644.
  • Stratifica le modalità dei file con altri controlli. I permessi sono la base; abbinali all’autenticazione di base del generatore htpasswd quando una cartella ha bisogno di un login, e considera le modalità dei file come un tassello del quadro trattato nella nostra guida sicurezza web essenziale.

FAQ

Cosa significa la d o la l all’inizio di drwxr-xr-x?

Il primo carattere in una riga di ls -l è il tipo di file, non un permesso. d indica una directory, l un collegamento simbolico, - un file regolare, c o b un dispositivo, p una pipe con nome e s un socket. Solo i nove caratteri successivi codificano gli effettivi bit di lettura, scrittura ed esecuzione.

Qual è la differenza tra una s minuscola e una S maiuscola nei permessi?

Sia una s minuscola sia una S maiuscola significano che il bit setuid o setgid è impostato. La s minuscola significa che l’esecuzione è anch’essa attiva, il normale caso di funzionamento. La S maiuscola significa che il bit speciale è attivo ma l’esecuzione è disattivata (come in 4644), il che è quasi sempre una configurazione errata, dato che un bit speciale è privo di senso senza l’esecuzione.

Cos’è umask e come decide i permessi predefiniti?

umask è l’insieme di bit di permesso disattivati quando un file viene creato. I nuovi file partono dalla base 666 e le directory da 777, poi effective = base & ~umask rimuove i bit mascherati. Il valore predefinito 022 produce file a 644 e directory a 755; esegui umask per vedere il tuo, o umask 077 per un default più privato.

Quando dovrei usare 400 o 700 invece di 644 o 755?

Usa 400 o 700 quando un file o una directory deve restare completamente privato. 400 (r--------) è un file privato in sola lettura, ideale per una chiave privata SSH definitiva che non modifichi mai. 700 (rwx------) è una directory in cui solo il proprietario può entrare, come ~/.ssh o ~/.gnupg. A differenza di 644 e 755, non concedono nulla a nessun altro.

Perché posso elencare una directory ma non entrarci con cd?

I permessi delle directory separano l’elenco dall’attraversamento: il bit r ti permette di elencare i nomi, il bit x ti permette di entrare. Una directory con r ma senza x (una directory a 644) mostra i suoi nomi con ls ma blocca cd e qualsiasi accesso ai file al suo interno. Aggiungi l’esecuzione (portala a 755) per renderla accessibile.

I permessi dei file funzionano allo stesso modo su macOS e su Linux?

I permessi dei file condividono su entrambi lo stesso modello di base rwx e ottale, perché entrambi seguono POSIX, ma i dettagli differiscono. BSD e macOS azzerano per impostazione predefinita il setuid/setgid di una directory con un chmod numerico, mentre Linux lo preserva. Anche leggere una modalità è diverso: stat -c '%a' file su Linux, stat -f '%Lp' file su macOS, e macOS aggiunge ACL e flag di file.

Posso cambiare i permessi dei file senza la riga di comando?

Puoi calcolare e decodificare i permessi senza un terminale. Il calcolatore chmod gratuito ti permette di spuntare una matrice di permessi, digitare un valore ottale o incollare una riga di ls -l, poi ti restituisce il comando chmod esatto. Applicarlo a un file reale richiede comunque quel comando sul server, o un client GUI o FTP che esponga i campi dei permessi.

Tag: linux chmod file-permissions permissions security

Articoli correlati

Vedi tutti gli articoli