Permessi Linux che Proteggono i Tuoi Dati — Ownership, Inode e Link Simbolici senza Mal di Testa

Il tuo server Linux va in produzione e qualcuno carica un file con i permessi sbagliati. Il sito si rompe, il cliente ti chiama alle 8 di sera, e tu scopri che il problema è un chmod 777 finito nel posto sbagliato. Succede ogni giorno. E non è un problema di sfortuna: è un problema di comprensione del filesystem. Noi, di Meteora Web, lo vediamo nei progetti che ci arrivano: permessi lasciati per comodità, ownership confuse tra utenti, link simbolici che puntano nel vuoto dopo un deploy. Questa guida ti dà gli strumenti per capire davvero come funzionano permessi, ownership, inode e link simbolici in Linux. Niente teoria fine a se stessa: solo quello che ti serve per non svegliarti con un server offline.

Come funzionano i permessi Linux e perché il chmod 777 è una trappola?

I permessi in Linux sono il tuo sistema di sicurezza di base. Ogni file e directory ha tre gruppi di permessi: lettura (r), scrittura (w) ed esecuzione (x). Questi si applicano a tre categorie di utenti: proprietario (u), gruppo (g) e altri (o). Quando vedi -rw-r--r--, stai leggendo: il proprietario può leggere e scrivere, il gruppo e gli altri possono solo leggere. Semplice, vero? Il problema arriva quando qualcuno applica chmod 777 — tutti possono fare tutto. Su un server condiviso o esposto a internet, è come lasciare la porta di casa aperta. Un attaccante può modificare i file, iniettare codice malevolo o cancellare dati. Noi lo diciamo sempre ai clienti: i permessi sono la prima linea di difesa. Non sacrificarli per comodità.

I tre numeri del chmod e come leggerli senza calcolatrice

Il chmod accetta una notazione numerica: chmod 755 file. Ogni cifra è la somma di valori: 4 per lettura, 2 per scrittura, 1 per esecuzione. Quindi 7 = 4+2+1 (lettura, scrittura, esecuzione), 5 = 4+1 (lettura ed esecuzione), 6 = 4+2 (lettura e scrittura). Per una directory, l'esecuzione significa poterci entrare con cd. Un errore comune è dare chmod 777 a una directory di upload: il server web può scrivere, ma anche chiunque altro. Meglio usare chmod 755 per le directory e chmod 644 per i file. Se devi dare scrittura al gruppo, valuta chmod 775 — ma solo se il gruppo è ristretto.

# Imposta permessi corretti per file e directory
chmod 644 index.php
chmod 755 /var/www/html/uploads
# Verifica i permessi
ls -l index.php
# Output: -rw-r--r-- 1 utente gruppo 1024 gen 1 12:00 index.php

La regola pratica: mai usare 777. Se pensi di averne bisogno, stai sbagliando architettura. Noi, di Meteora Web, risolviamo ogni settimana problemi causati da permessi troppo permissivi. Un attaccante con accesso in scrittura a un file PHP può eseguire codice arbitrario. È così che partono molti attacchi ransomware.

Come gestire ownership e gruppi per evitare conflitti tra utenti e servizi?

L'ownership — chi possiede un file — determina chi può applicare i permessi. In Linux, ogni file ha un proprietario e un gruppo. Quando il server web (es. www-data) deve scrivere in una directory, ma il proprietario è root, il sistema si blocca. Il classico errore: crei un sito con il tuo utente, poi il server non riesce a caricare le immagini. La soluzione non è chmod 777, ma cambiare ownership con chown. Per esempio, chown -R www-data:www-data /var/www/html assegna tutto al server web. Ma attenzione: se devi modificare i file via FTP con un altro utente, crei un conflitto. La strategia giusta è usare i gruppi. Aggiungi il tuo utente al gruppo www-data e imposta i permessi di gruppo a 775. Così sia tu sia il server potete lavorare senza sblocchi.

Il comando chown e la gestione dei gruppi secondari

Per aggiungere un utente a un gruppo: usermod -a -G www-data tuo_utente. Poi verifica con id tuo_utente. Una volta nel gruppo, puoi scrivere nei file di proprietà del gruppo. Ricorda: la modifica richiede il logout e il login per avere effetto. Noi, di Meteora Web, usiamo questa tecnica per i progetti condivisi tra sviluppatori e server. È pulita, sicura e non richiede permessi permissivi.

# Cambia ownership ricorsivamente
chown -R www-data:www-data /var/www/miosito
# Aggiungi il tuo utente al gruppo del server
usermod -a -G www-data tuo_utente
# Verifica i gruppi
id tuo_utente

Un altro errore comune: usare chown -R su tutto il filesystem o su directory di sistema. Puoi rompere il boot. Limita il comando alle directory dei tuoi progetti. E quando fai un deploy, pensa a chi deve scrivere: se usi un utente deploy separato, non dargli accesso a tutto, solo a ciò che serve.

Cosa sono gli inode e perché non puoi ignorarli quando il disco si riempie?

Gli inode sono le schede anagrafiche dei file. Ogni file e directory ha un inode che memorizza metadati: permessi, proprietario, dimensioni, timestamp e la posizione dei blocchi dati. Il nome del file è solo un'etichetta che punta all'inode. Quando copi un file, crei un nuovo inode; quando lo sposti, riutilizzi lo stesso. Il problema pratico: il filesystem ha un numero finito di inode. Se crei milioni di file piccoli (es. cache, sessioni), esaurisci gli inode anche se il disco ha spazio libero. Il server va in errore con messaggi tipo "No space left on device" anche se df -h mostra GB liberi. Noi lo abbiamo visto su server con cache mal configurata. La soluzione è monitorare gli inode con df -i e pulire i file temporanei.

Come controllare e liberare inode esauriti

Usa df -i per vedere l'uso degli inode. Se la percentuale è alta, trova le directory con troppi file: find /var/www -type f | wc -l. Per eliminare file vecchi, find /tmp -type f -mtime +7 -delete. Attenzione a non cancellare file di sistema. Un'altra strategia: configura il logrotate per i log di sistema e limita le sessioni PHP con session.gc_maxlifetime. Prevenire è meglio che curare.

# Controlla l'uso degli inode
df -i
# Trova directory con molti file
find /var/www -type f | wc -l
# Elimina file temporanei più vecchi di 7 giorni
find /tmp -type f -mtime +7 -delete

Ricorda: gli inode non si espandono. Se il tuo filesystem è quasi pieno di inode, devi ripulire o ridimensionare. Noi, di Meteora Web, consigliamo di monitorare sia lo spazio sia gli inode nei sistemi di alerting. Un disco con inode esauriti è un server che si blocca senza preavviso.

Come funzionano i link simbolici e quando usarli per non rompere i deploys?

I link simbolici (symlink) sono scorciatoie: un file che punta a un altro file o directory. Sono fondamentali per i deploy: invece di sovrascrivere i file, crei una nuova versione e cambi il link. Il downtime è zero. Il comando è ln -s /percorso/reale /percorso/link. Un errore comune: creare link relativi sbagliati. Se usi ln -s con un percorso relativo, il link punta a un posto inesistente. Meglio usare percorsi assoluti. Un altro errore: eliminare il file originale. Il link diventa rotto e l'applicazione va in errore. Noi lo vediamo spesso con i file di configurazione: qualcuno sposta il file e il symlink resta appeso.

Link simbolici vs hard link — cosa cambia e quando scegliere

Gli hard link sono un altro nome per lo stesso inode. Se modifichi un hard link, modifichi anche l'originale. Ma non puoi creare hard link per directory o tra filesystem diversi. I link simbolici, invece, puntano al nome del file, non all'inode. Se elimini l'originale, il symlink si rompe. Per i deploy, i symlink sono la scelta giusta: puoi cambiare la versione attiva con un solo comando. Gli hard link servono per deduplicare file identici, ma sono meno flessibili.

# Crea un link simbolico con percorso assoluto
ln -s /var/www/releases/v2.1 /var/www/attuale
# Verifica il link
ls -l /var/www/attuale
# Output: lrwxrwxrwx 1 root root 22 gen 1 12:00 /var/www/attuale -> /var/www/releases/v2.1
# Rimuovi un link simbolico (non il file originale)
unlink /var/www/attuale

Attenzione: quando fai un deploy con symlink, assicurati che il link punti alla directory giusta. Un comando ln -sfn aggiorna il link senza errori. E non dimenticare: i permessi del link non contano, contano quelli del file puntato. Se il file ha permessi 600 e il server web non può leggerlo, il symlink non aiuta.

Come diagnosticare problemi di permessi e link con strumenti da terminale?

Quando qualcosa non funziona, il terminale è il tuo migliore amico. Comandi come ls -l, stat, namei e readlink ti dicono tutto. stat mostra inode, permessi, ownership e timestamp. namei risolve i percorsi e mostra se un link è rotto. readlink ti dice dove punta un symlink. Noi, di Meteora Web, usiamo questi comandi ogni giorno per debuggare i server dei clienti. Un esempio: il sito non carica le immagini. ls -l sulla directory mostra permessi 755, ma il file è 644 e di proprietà di root. Il server web non può scrivere. La soluzione è cambiare ownership o permessi, non il link.

La checklist di diagnosi rapida

Ecco i passi che facciamo sempre: 1) ls -l per vedere permessi e ownership. 2) stat file per dettagli su inode e timestamp. 3) namei -l /percorso/completo per verificare ogni componente del percorso. 4) readlink link per controllare la destinazione. Se il link punta a un file inesistente, ls -l mostra un punto interrogativo. Questo ti dice subito che il problema è un link rotto.

# Diagnosi completa di un file
stat index.php
# Risolvi il percorso e verifica i permessi
namei -l /var/www/attuale/config.php
# Controlla la destinazione di un link
readlink /var/www/attuale

Un altro strumento potente è find con opzioni di permessi: find /var/www -perm 777 trova file pericolosi. Oppure find /var/www -type l ! -exec test -e {} \; -print per trovare link rotti. Questi comandi ti salvano la giornata. Noi li includiamo in script di audit per i nostri clienti.

Come proteggere il filesystem con ACL e attributi estesi?

I permessi base non bastano sempre. Le ACL (Access Control Lists) permettono di dare permessi specifici a più utenti e gruppi, oltre al proprietario e al gruppo. Per esempio, puoi dare a un utente solo lettura su una directory, e a un altro lettura e scrittura. Il comando è setfacl -m u:utente:rwx directory. Gli attributi estesi, come chattr +i, rendono un file immutabile: non può essere modificato, nemmeno da root. Questo è utile per file di configurazione critici o per proteggere da ransomware. Noi usiamo chattr +i su file di backup e chiavi private. Ma attenzione: per rimuovere l'attributo serve chattr -i, e non funziona su tutti i filesystem.

Quando usare le ACL rispetto ai permessi tradizionali

Le ACL sono utili in ambienti con più utenti che condividono directory (es. progetti di team). I permessi tradizionali bastano per la maggior parte dei casi. Ma se hai bisogno di un controllo granulare, le ACL sono la risposta. Un esempio: il server web deve scrivere in una directory, ma un utente di sviluppo deve solo leggere. Con i permessi base, se il gruppo ha scrittura, tutti i membri scrivono. Con le ACL, dai al server web scrittura e all'utente solo lettura. La gestione è più complessa, ma il controllo è totale.

# Imposta un'ACL per un utente
setfacl -m u:sviluppatore:r-x /var/www/progetto
# Verifica le ACL
getfacl /var/www/progetto
# Rendi immutabile un file critico
chattr +i /etc/nginx/nginx.conf
# Rimuovi l'immutabilità
chattr -i /etc/nginx/nginx.conf

Le ACL sono una feature potente, ma non usarle se non serve. Complessità inutile è un costo. Noi, di Meteora Web, le consigliamo solo quando i permessi base non bastano. E per gli attributi estesi, testa prima su un file di prova: un chattr +i su un file di sistema può bloccare aggiornamenti e servizi.

Cosa fare adesso

Non aspettare che il server si rompa. Metti in pratica subito queste azioni: 1) Controlla i permessi dei tuoi file con find /var/www -perm 777 e correggi quelli pericolosi. 2) Verifica l'ownership delle directory dei tuoi progetti: ls -l /var/www e cambia con chown se serve. 3) Monitora gli inode con df -i e configura un alert se la percentuale supera l'80%. 4) Usa link simbolici per i deploy: crea una struttura releases/ e un link attuale. 5) Proteggi i file critici con chattr +i e documenta le eccezioni. Se hai bisogno di una mano, noi di Meteora Web lavoriamo su questi temi ogni giorno: la nostra guida pillar su shell scripting e automazione Linux è un buon punto di partenza per approfondire. E se vuoi capire come le minacce informatiche stanno evolvendo, leggi il nostro articolo su il primo virus creato dall'AI: la sicurezza del filesystem è la tua prima trincea.