La gestione dei permessi di files e risorse su Linux richiede almeno tre diversi tipi di competenze. Innanzitutto occorre sapere cos’è un utente, cos’è un gruppo di utenti e in che modo utenti e gruppi sono in relazione tra loro (vedi ad esempio il concetto di gruppo primario). Poi dobbiamo conoscere i comandi principali che permettono di assegnare e/o modificare i permessi, come ad esempio chmod e chown. Con questi due strumenti si potrebbe pensare di avere le basi per gestire qualsiasi situazione, ma abbiamo detto “tre competenze”, non due. Cosa manca? Il terzo requisito è ricordarsi che i permessi degli utenti hanno la priorità sui permessi dei gruppi.
Per capirlo vediamo un esempio: consideriamo due gruppi: adm (con id=4) e dialout (con id=20). Assumendo di avere i permessi di amministratore, creiamo due utenti e assegniamoli a questi gruppi
useradd -g 20 -c "Prova permessi" pippo
useradd -g 4 -c "Prova permessi" pluto
Siccome vogliamo loggarci con questi utenti, assegniamo loro una password (trattandosi di una prova, va benissimo usare una password uguale al nome)
passwd pippo
passwd pluto
Sempre come amministratore, creiamo infine una directory dove mettere alcuni files di prova, ad esempio
-rw-rw---- 1 pippo adm 5 2012-05-02 16:57 due.sh
-rw-rw---- 1 pluto adm 14 2012-05-02 16:13 uno.sh
Per creare una situazione come questa, dopo aver creato i due files (uno.txt e due.sh) assegniamo proprietari e permessi tramite i comandi
chmod o-r uno.sh
chmod o-r due.sh
chown pluto:adm uno.sh
chown pippo:adm due.sh
Siamo finalmente pronti per fare qualche prova: entriamo come utente pippo, usando ad esempio “su pippo”, e proviamo a maneggiare il file uno.sh. Com’è giusto che sia, non potremo né leggere, né modificare, né eseguire il file uno.sh. Ovviamente non potremo né cambiare i suoi permessi (comando chmod) né assegnarlo ad altro utente o gruppo (comando chown). Le cose cambiano se ci logghiamo con l’utente pluto (usando “su pluto”) e proviamo a maneggiare il file due.sh. In questo caso potremo leggere e modificare il file (permessi del gruppo), ma non potremo eseguirlo. Anche qui ovviamente non potremo cambiare né permessi né utente o gruppo proprietario.
Proviamo ora a cambiare i permessi, aggiungendo i permessi di esecuzione a livello di gruppo
-rw-rwx--- 1 pippo adm 3 2012-05-02 17:24 due.sh
-rw-rwx--- 1 pluto adm 3 2012-05-02 17:27 uno.sh
Se ci logghiamo come utente pippo, giustamente non potremo eseguire nessuno dei due files. Come invece pluto potremo eseguire il file due.sh, ma non potremo eseguire uno.sh!
Cos’è successo? Nel caso del file due.sh, le operazioni permesse all’utente pluto sono regolamentate dal suo gruppo (ovvero adm), e siccome questo gruppo ha i permessi di esecuzione, anche l’utente pluto potrà eseguire questo file. Le cose sono diverse quando proviamo ad eseguire il file uno.sh. Siccome come utente non ha i permessi di esecuzione, l’utente pluto non potrà eseguire il file uno.sh, anche se potrebbe farlo in quanto membro del gruppo adm!
Se ci pensiamo un attimo, questo è il comportamento giusto: lo scopo dei gruppi è quello di fornire regole generiche, valide per molti utenti e molti tipi di risorse, senza preoccuparci del singolo caso o eccezione. I permessi dei gruppi potrebbero essere sufficienti a regolamentare tutte le risorse del file system, per cui non abbiamo, in teoria, necessità di assegnare anche un utente proprietario ad ogni risorsa. Il vantaggio di decidere che una certa risorsa ha due “padroni” (un utente e un gruppo) è quello di poter gestire delle regole particolari, che potrebbero non andar bene a livello di gruppo. E’ quindi giusto che, là dove ci sia contraddizione tra i permessi come utente proprietario e come gruppo proprietario, i permessi dell’utente siano prioritari: solamente in questo modo saremo in grado di assegnare regole specifiche e puntuali sui singoli utenti.
Per verificare quanto detto basta invertire la situazione, assegnando i permessi di esecuzione (per il file uno.sh) all’utente proprietario anziché il gruppo
-rw-rwx--- 1 pippo adm 3 2012-05-02 17:24 due.sh
-rwxrw---- 1 pluto adm 3 2012-05-02 17:27 uno.sh
se riproviamo adesso, l’utente pluto potrà eseguire uno.sh perché ha il permesso di farlo in quanto utente, ma non potrebbe farlo in qualità di membro del gruppo adm. La situazione appena vista è un ottimo esempio di buon uso dei permessi in combinazione con la distinzione tra gruppi e utenti: in molti casi è bene assegnare dei permessi piuttosto “contenuti” ai gruppi, ed aumentare eventualmente “i poteri” solamente agli utenti giusti.
Come ultima cosa osserviamo che quanto detto vale per qualsiasi gruppo, sia esso primario o secondario. Anche qui, il modo migliore di imparare è fare qualche prova nella shell (usando, se necessario, il comando usermod per assegnare gli utenti già creati ad altri gruppi).
