| Indietro | Indice | Home PHC | Avanti |
Come sappiamo bene Linux è un sistema multiutente, il che vuol dire non solo che è possibile utilizzarlo solo avendo una coppia nome_login/password, ma anche che esiste un sistema di permessi che ci impedisce di scrivere dove non dovremmo, in modo che io possa impedire ad un altro utente di cancellarmi i file, ma che soprattutto il sistema possa impedire ad un utente qualsiasi di modificare la configurazione e magari anche l'integrità del sistema stesso.
Questo sistema di permessi è integrato nel kernel, ma per quello che riguarda la memorizzazione dei files deve essere utilizzato un filesystem (ovvero un modo di scrivere le informazioni sul disco) che supporti questo sistema, visto che tutte le informazioni che il kernel scrive riguardo ai permessi e i proprietari dei file devono sopravvivere allo spegnimento della macchina. Il filesystem utilizzato normalmente con Linux si chiama ext2, ed è in genere molto efficiente1.
Il kernel identifica ogni utente con una coppia di numeri: l'UID e il GID, che sono gli identificativi dell'Utente e del Gruppo a cui appartiene un utente (in genere sono uguali, e ognuno fa gruppo a sé). Il nome corrispondente è solo una nostra comodità, e si può cambiare semplicemente editando il file /etc/passwd. Per vedere gli uid/gid di un utente si usa il comando id:
[messina@sophie seminario $] id messina uid=10295(messina) gid=10295(messina) groups=10295(messina)} [messina@sophie seminario $]
Per vedere quali permessi sono associati ad un file è sufficiente aggiungere al comando ls l'opzione `-l' (vi consiglio di usare anche l'opzione `-color', che colora diversamente file, directory, eseguibili ecc...):
[messina@sophie seminario $] ls -l total 25 -rw-rw-r-- 1 messina messina 717 Feb 29 18:42 processi.aux -rw-rw-r-- 1 messina messina 8220 Feb 29 18:42 processi.dvi -rw-rw-r-- 1 messina messina 2362 Feb 29 18:42 processi.log -rw-rw-r-- 1 messina messina 6116 Feb 29 18:42 processi.tex [messina@sophie seminario $]
Leggendo da destra l'output di questo comando vediamo il nome del file, la data e l'ora di ultima modifica, la dimensione (di solito... per le device vengono visualizzati major e minor number) il gruppo e l'utente proprietari del file, e il numero di link riferiti al file. La parte a destra è leggermente più criptica... Da sinistra a destra è idealmente divisa in quattro parti:
| tipo | permessi utente | perm. gruppo | perm. di tutti gli altri | extra |
| -,d,c,b,l,p | tre tra r,w,x,s,- | tre tra r,w,x,s,- | tre tra r,w,x,s,- | uno tra t,- |
Il tipo ci dice se si tratta di un file (-), una device a blocchi (b) come un disco o un cdrom, una device a caratteri (c), come le porte seriali o un terminale, una named pipe (p), una directory (d), o un link simbolico (l). I permessi per i link simbolici sono sempre `lrwxrwxrwx' e non si possono cambiare, mentre negli altri casi il loro significato cambia a seconda che si tratti di una directory o di qualcos'altro. Vediamoli in dettaglio:
| Simbolo | File/device | Directory
|
|---|---|---|
| r | Leggere il file | Listare il contenuto, per esempio con il comando `ls' |
| w | Scrivere sul file o cambiarne gli attributi | Creare o rimuovere file all'interno della directory |
| x | Eseguire il file come programma | Accedere alla directory |
| s (u+s) | bit SUID. Il programma al momento dell'esecizione acquisir\`a l'uid o il gid dell'utente/gruppo proprietario del file | Nessun effetto |
| s (g+s) | bit SGID. Come prima. | I file creati in questa directory non erediano il GID del processo che li crea ma quello della directory. |
| t (sticky) | Mantiene il testo del programma sulla device di swap | Solo il proprietario della directory o del file pu\`o rimuovere un file contenuto nella directory (/tmp \`e un tipico esempio) |
I permessi si possono cambiare tramite il comando chmod, mentre l'utente e il gruppo proprietari possono essere cambiati, da root, con il comando chown e chgrp.
L'uso del comando chmod è semplice: si fa seguire il nome da una o più tra le lettere u,g,o,a, (User, Group, Other, All), che rappresentano i gruppi di persone per le quali si vuole impostare il o i permessi; non separato da spazio si inserisce un `+', se è un permesso che vogliamo aggiungere, o un `-', se è un permesso esistente che vogliamo rimuovere; infine si scelgono i permessi da settare/rimuovere inserendo una o più delle lettere che rappresentano i permessi (escluso `-', ovviamente, che rappresenta la non assegnazione di un permesso). Ultimi vanno messi i file su cui si deve impostare il permesso.
Quando un utente lancia un processo questo mantiene memoria di uid/gid dell'utente che lo ha lanciato, ma possiede anche un'altra coppia di uid/gid che sono quelli effettivi del processo. Di solito sono gli stessi dell'utente, ma non è detto. Per esempio all'avvio ci sono alcuni processi che vengono lanciati da root, ma che non necessitano effettivamente di così alti privilegi, di conseguenza vengono fatti partire come nobody, ovvero un utente fittizio che non ha nessun diritto particolare. D'altro canto esistono programmi come X che necessitano di permessi meno restrittivi ma che devono poter essere lanciati da qualsiasi utente. Notiamo a questo punto che:
[messina@poisson seminario$] ls -l $(which X) -rwsr-xr-x 1 root root 4792 Feb 23 1999 /usr/X11R6/bin/X
Quindi il file è di proprietà di root, ha il bit SUID impostato ed è eseguibile da tutti. Questo significa che chiunque esegua il processo esso acquisità i diritti di root, infatti:
[messina@poisson seminario$] ps aux|grep 'X ' messina 1183 0.0 0.6 928 412 p0 S 12:26 0:00 grep X root 332 4.7 6.8 8464 4320 ? R 11:14 3:25 /usr/bin/X11/X vt11 - [messina@poisson seminario$]
Per capire quanto utili siano i permessi per rendere sicuro il sistema facciamo un piccolo esempio: supponiamo che, siccome sono un pessimo programmatore, ho fatto un programma, sontuttunbuco, che periodicamente va a scrivere uno `0' nel file contenente il kernel. Se lo lancio come utente normale ottengo qualcosa del tipo:
[messina@poisson seminario$] ./sontuttunbuco Segmentation fault [messina@poisson seminario$]
o anche, se faccio:
[messina@poisson seminario$] rm /boot/vmlinuz-2.2.14 -f rm: cannot unlink `/boot/vmlinuz-2.2.14': Permission denied [messina@poisson seminario$]
Se però a questo punto do i comandi (da root) chmod +s sontuttunbuco e chown root sontuttunbuco, rendo il processo suid root, quindi una volta eseguito, da qualsiasi utente, questo potrà scrivere sui file di sistema. (Ed io mi merito un pugno in faccia...)