Linux: diagnosticare permessi e proprietà dei file in modo sicuro

Quando un file o una cartella su Linux “non funziona”, la causa non è quasi mai magica: di solito c’è un permesso troppo stretto, una proprietà sbagliata, un gruppo mancante o un contesto applicativo che non coincide con ciò che il servizio si aspetta. La cosa importante è non agire a tentativi. Prima si legge lo stato reale, poi si corregge con il minimo intervento possibile.

Questo approccio è utile su server web, ambienti WordPress, directory di upload, job cron, script PHP, repository di deploy e cartelle condivise tra utenti o servizi. Il principio è semplice: capire chi deve accedere, cosa deve fare e con quale livello di accesso, poi verificare se il filesystem rispetta quel modello.

Il modello mentale corretto

Su Linux i permessi classici si leggono su tre livelli: utente proprietario, gruppo e altri. A questi si aggiungono spesso ACL, attributi estesi, SELinux o AppArmor, che possono bloccare anche quando i permessi sembrano giusti. Per questo una diagnosi seria non si ferma a un semplice ls -l.

Le domande da porsi sono sempre le stesse:

• Chi è il proprietario del file o della directory?
• Quale gruppo è associato?
• Il processo che deve accedere gira con quale utente?
• Serve solo lettura, oppure scrittura, oppure esecuzione?
• Ci sono ACL o contesti di sicurezza che sovrascrivono il comportamento base?

Controllo rapido dello stato reale

Il primo passo è fotografare la situazione senza modificare nulla. Su una shell Linux, i controlli più utili sono questi:

ls -ld /percorso/della/cartella

Questo mostra proprietario, gruppo e permessi della directory. L’esito atteso è una riga leggibile che ti dica subito se il contenuto è accessibile o no.

ls -l /percorso/del/file

Serve per vedere chi possiede il file e quali bit sono impostati. Se il file non è leggibile dal processo giusto, qui spesso si vede già l’anomalia.

stat /percorso/del/file

Questo controllo è più preciso perché mostra UID, GID, permessi numerici e timestamp. È utile quando il nome utente o gruppo non basta a chiarire il problema.

Se il problema riguarda una directory, ricordati che per attraversarla serve il bit di esecuzione sulla cartella, non sul file. Molti errori apparentemente “di lettura” sono in realtà problemi di accesso alla directory padre.

Capire l’utente che esegue il servizio

Un errore classico è correggere i permessi del file senza sapere quale utente li deve usare. Un web server, un cron job o un demone possono girare con utenti diversi: www-data, apache, nginx, php-fpm, un utente di deployment o un account dedicato.

Per verificare l’utente effettivo di un processo:

ps aux | grep nome_servizio

L’esito atteso è individuare l’utente reale con cui gira il processo. Se il servizio usa un pool PHP-FPM o un worker specifico, controlla anche la configurazione del pool, perché spesso è lì che si trova il vero account di esecuzione.

Se vuoi vedere a chi appartiene una directory usata da un servizio, confronta sempre il proprietario con l’utente del processo. Quando non coincidono, il problema può essere risolto con proprietà, gruppo o ACL, non necessariamente con permessi più larghi.

Interpretare i permessi senza confondersi

I permessi standard si leggono in tre blocchi: lettura r, scrittura w ed esecuzione x. Su file, x serve per eseguire uno script o un binario; su directory, x serve per entrare nella cartella e raggiungere i contenuti. Questo dettaglio è fondamentale.

Una directory con r ma senza x può sembrare leggibile, ma in pratica non è attraversabile. Un file con r ma senza x non può essere lanciato come programma. Un file con w ma senza r può essere riscritto da chi ha il permesso, ma non letto normalmente.

Per leggere il formato numerico:

• 7 = lettura, scrittura, esecuzione
• 6 = lettura, scrittura
• 5 = lettura, esecuzione
• 4 = sola lettura
• 0 = nessun accesso

In produzione, la correzione migliore è quasi sempre la più stretta possibile: concedere solo ciò che serve, non di più.

Uso corretto di chmod e chown

Quando hai identificato il problema, scegli la modifica meno invasiva. In molti casi il vero fix non è cambiare i permessi, ma cambiare il proprietario o il gruppo.

Se il file appartiene all’utente sbagliato:

chown utente:gruppo /percorso/del/file

Se devi correggere una directory e il contenuto deve restare coerente:

chown -R utente:gruppo /percorso/della/cartella

Usa la ricorsione con cautela: è pratica, ma può cambiare anche file che non avresti voluto toccare. Prima verifica sempre il percorso esatto.

Se invece il problema è il livello di accesso:

chmod 644 /percorso/del/file

per file leggibili e non eseguibili, oppure:

chmod 755 /percorso/della/cartella

per directory che devono essere attraversabili e lette da altri processi. L’esito atteso è che il servizio riesca a raggiungere il contenuto senza aprire troppo la superficie di scrittura.

Per script eseguibili:

chmod 755 /percorso/dello/script

e verifica che lo script abbia anche lo shebang corretto, altrimenti l’esecuzione fallisce comunque.

Quando i permessi sembrano corretti ma il problema resta

Se i classici permessi sono corretti e l’errore continua, entra in gioco il livello successivo. Le cause più comuni sono ACL, SELinux, AppArmor o mount con opzioni restrittive.

Per controllare eventuali ACL:

getfacl /percorso/del/file

Il risultato atteso è capire se c’è una regola extra che concede o nega accesso oltre ai permessi classici. Se trovi una ACL inattesa, quella può essere la vera causa.

Per SELinux, se la distribuzione lo usa, controlla il contesto:

ls -Z /percorso/del/file

Se il contesto non è quello previsto dal servizio, il file può risultare inaccessibile anche con permessi perfetti. In quel caso la correzione va fatta sul contesto, non con un chmod più permissivo.

Per AppArmor, l’errore spesso compare nei log del servizio o del kernel. Se il processo viene bloccato, i permessi del filesystem non bastano: serve un profilo corretto o una modifica al profilo stesso.

Verificare i mount e le opzioni del filesystem

Una cartella può risultare “strana” anche per il modo in cui è montato il filesystem. Opzioni come noexec, nosuid o nodev non sono errori, ma possono impedire comportamenti specifici.

Controlla così:

mount | grep ' /percorso '

oppure:

findmnt /percorso

L’esito atteso è capire se il filesystem ha restrizioni che bloccano l’esecuzione di script o binari. Se una directory di upload è montata con noexec, per esempio, è normale che i file lì dentro non vengano eseguiti: ed è spesso una scelta di sicurezza corretta.

In questi casi non bisogna forzare il filesystem, ma spostare lo script in un percorso adatto o adattare l’architettura applicativa.

Metodo pratico per trovare il punto esatto di blocco

Quando un percorso lungo non è accessibile, il trucco è controllare i permessi su ogni segmento della path, non solo sull’ultimo elemento. Basta un padre con permessi errati per bloccare tutto.

Per ispezionare in sequenza:

namei -l /percorso/completo/al/file

Questo comando è molto utile perché mostra tutti i passaggi della path e i relativi permessi. L’esito atteso è individuare esattamente la directory che interrompe l’accesso.

Se non hai namei, puoi fare un controllo manuale con:

ls -ld /percorso

su ogni livello della gerarchia. È meno comodo, ma porta allo stesso risultato.

Casi frequenti su server web

Su siti web e CMS i problemi più comuni sono quasi sempre gli stessi: upload non scrivibili, cache che non si aggiorna, log non creati, immagini che non si generano, backup che falliscono, plugin che non installano file.

In questi casi il modello corretto è:

• il web server deve leggere i file del sito;
• il processo applicativo deve scrivere solo nelle directory necessarie;
• i file di configurazione devono restare non scrivibili dall’utente sbagliato;
• le directory di cache e upload devono avere proprietà coerenti con il runtime applicativo.

Se correggi tutto con permessi troppo larghi, il sito magari riparte, ma introduci un rischio inutile. Meglio distinguere tra file statici, directory scrivibili e configurazioni sensibili.

Quando usare ACL invece dei permessi classici

Le ACL servono quando più utenti o processi devono condividere una directory senza cambiare proprietario ogni volta. È una soluzione utile in ambienti con deploy automatici, editor condivisi o servizi separati che devono collaborare sullo stesso tree.

Prima di introdurle, però, chiediti se il problema non si risolve meglio con un gruppo dedicato. Il gruppo è più semplice da mantenere e da documentare. Le ACL vanno usate quando il modello semplice non basta.

Per aggiungere una ACL di lettura o scrittura, si può intervenire con strumenti dedicati, ma conviene farlo solo dopo aver verificato che i permessi base non siano già sufficienti. Se no, rischi di creare una configurazione difficile da leggere e da supportare nel tempo.

Buone pratiche per non rompere il server

La regola più importante è questa: non usare chmod -R 777 come soluzione standard. È una scorciatoia che spesso nasconde il problema invece di risolverlo, e allarga troppo la superficie di rischio.

Prima di cambiare proprietà o permessi su una cartella importante, fai sempre un backup della configurazione o almeno annota lo stato corrente. Se il percorso è critico, salva l’output di ls -l, stat e, se serve, getfacl. In caso di errore, potrai tornare indietro con precisione.

Inoltre, dopo ogni modifica controlla subito se il servizio torna operativo. Non aspettare troppo: una verifica immediata ti dice se il fix è corretto o se hai toccato il livello sbagliato.

Procedura sintetica di diagnosi

1. Identifica il file o la directory che fallisce e l’errore concreto che compare.
2. Controlla proprietario, gruppo e permessi con ls -ld e stat, con esito atteso coerente con il servizio.
3. Verifica l’utente reale del processo con ps aux o con la configurazione del servizio.
4. Se necessario, correggi prima il proprietario o il gruppo, poi i permessi minimi richiesti.
5. Se il problema resta, controlla ACL, SELinux, AppArmor e opzioni di mount.
6. Riesegui il test del servizio e conferma che il comportamento sia tornato normale.

Controlli finali

Dopo il fix, verifica sempre tre cose: il file o la directory sono accessibili dall’utente giusto, il servizio non produce più errori nei log e i permessi non sono diventati più larghi del necessario. Se hai dovuto cambiare proprietà o ACL, annota la modifica per future manutenzioni.

Rollback consigliato: se il comportamento peggiora o il servizio inizia a fallire in un’area diversa, ripristina lo stato precedente usando i permessi annotati prima dell’intervento. Se hai usato un cambio ricorsivo, controlla subito i file più sensibili e verifica che non siano stati toccati oltre il previsto.

Assunzione operativa: i controlli proposti sono pensati per un ambiente Linux standard con accesso shell e senza policy aziendali che impongano strumenti diversi.