Un rifiuto di accesso sotto Linux non viene sempre da un chmod dimenticato. Il comando che fallisce può essere eseguito con un altro UID, oppure il suo account non appartiene al gruppo previsto. Prima di modificare un proprietario, iniziate identificando l’account realmente utilizzato.
Il comando id mostra l’UID, il gruppo principale e i gruppi secondari del processo corrente. È il punto di partenza quando uno script, un servizio o una sessione SSH non vede lo stesso file che voi.

Leggere l’UID, il GID e i gruppi con id
Avviate id senza argomento nella sessione che presenta problemi:
id
Un’uscita come uid=1000(alex) gid=1000(alex) groups=1000(alex),27(sudo),999(docker) descrive l’identità del processo. uid è l’identificatore utente. gid è il gruppo principale. groups aggiunge i gruppi secondari, spesso quelli che aprono accesso a Docker, ai log o a una condivisione.
Per recuperare solo un valore, utilizzate le seguenti opzioni:
id -umostra l’UID effettivo.id -gmostra il GID effettivo.id -Gnelenca i nomi dei gruppi.id -unmostra il nome dell’account effettivo.
La differenza tra identificatore reale ed effettivo appare soprattutto dopo sudo, in un binario SUID o con alcuni strumenti che cambiano utente. Per una verifica rapida del solo nome, consultate anche il nostro articolo su whoami e l’utente effettivo.
Ispezionare un account senza aprire la sua sessione
Aggiungete il nome dell’account per interrogare la sua scheda locale. Questo comando legge il database utenti e non vi connette sotto questo account:
id www-data
id -Gn www-data
Su Debian e Ubuntu, www-data è spesso l’account dei servizi web. Su un’altra distribuzione, il servizio può utilizzare apache, nginx o un account applicativo. Controllate il file di unità o la configurazione del servizio invece di riprendere questo esempio così com’è.
Dopo aver aggiunto un utente a un gruppo, una sessione già aperta può mantenere la sua vecchia lista di gruppi. Disconnettetevi e poi riconnettetevi prima di concludere che la modifica è fallita. Il comando id utente rilegge il database, ma id da solo descrive sempre il vostro processo attuale.
Confrontare l’identità dell’account e i diritti del file
Conoscere i gruppi non è sufficiente. Bisogna poi leggere il proprietario, il gruppo e i permessi del percorso interessato:
id
stat -c '%U %G %A %n' /percorso/verso/il/file
namei -l /percorso/verso/il/file
stat indica a chi appartiene il file. namei -l mostra anche i diritti di ciascuna directory del percorso. Un file leggibile non serve a nulla se l’account non può attraversare la cartella padre, il che richiede il diritto x su questa directory.
Non correggete un rifiuto con chmod 777. Confrontate prima il gruppo del file con id -Gn, poi regolate il proprietario, il gruppo o i permessi necessari. Per rivedere i gruppi e i loro usi, leggete la gestione dei gruppi sotto Linux. Se dovete modificare i permessi, la nostra guida su chmod ricorsivo spiega perché un comando troppo ampio può toccare molti più file del previsto.
Testare sotto l’account interessato prima di modificare sudo
Quando avete i diritti di amministrazione, eseguite solo il controllo sotto l’account che incontra il problema:
sudo -u www-data id
sudo -u www-data test -r /percorso/verso/il/file && echo leggibile
sudo -u www-data test -x /percorso/verso/la/cartella && echo attraversabile
Il primo richiamo conferma l’identità effettiva. I due successivi rispondono a una domanda specifica, lettura del file o attraversamento della cartella. Sostituite www-data e i percorsi prima di eseguire. Non utilizzate sudo -u per avviare un’applicazione di produzione solo per testare i suoi diritti.
Se l’accesso rimane rifiutato anche se UID, gruppo e permessi Unix sembrano corretti, verificate anche le ACL con getfacl, i montaggi di rete e SELinux o AppArmor a seconda della vostra distribuzione. Questi meccanismi possono aggiungere una regola al di sopra dei diritti classici.
Con id, stat e un test sotto il giusto account, sapete dove cercare prima di modificare diritti alla cieca.