Più volte nei capitoli precedenti abbiamo parlato di permessi per gli utenti. Ovvero permessi di compiere quella o questa azione all'interno dell'OS, ma mai abbiamo specificato come questo può avvenire. In questo capitolo, ci occuperemo appunto di ricostruire il modo in cui Linux concede ad un utente il permesso di fare questa o quella azione.
Appare ovvio che concedere un potere ad un utente significa operare sulla possibilità che esso possa o meno accedere ad un dato o eseguire un programma. Sia i dati che i programmi sono rappresentati in forma fisica da file, quindi è senz'altro una buona intuizione quella di pensare che un utente possa compiere una certa azione solo se il file su cui va ad operare è disposto a compiere quella determinata operazione. Per cui in realtà assegnare dei permessi ad un utente significa stabilire su quali file possa operare e come.
Ciascun file è dotato di:
Sembrerebbe un po' complicato, in realtà non lo è affatto.
Vediamo un po' come ci appare un file quando lo visualizziamo con
ls -l:
-rw-r--r-- 1 root root 872 Feb 23 12:04 prg.culturale.7
|________| |_____| |____|
| | |___Identificatore di gruppo (GID)
| |
| |____ Identificatore del proprietario (UID)
|
|___________permessi del file
Quando un utente tenta di accedere ad un file, Linux controlla che il nome dell'utente corrisponda al nome del proprietario del file, se non corrisponde controlla che almeno l'utente appartenga al gruppo a cui appartiene anche il file, se ancora non corrisponde identifica quell'accesso come altro.
I permessi -rw-r--r-- sono divisi in 3 gruppi di 3 bit ciascuno.
Permessi del proprietario
- read
- write
- execute
Permessi del gruppo
- read
- write
- execute
Permessi degli altri
- read
- write
- execute
Ciascun bit può essere naturalmente settato a 0 o a 1, quando il bit vale 0 il permesso è negato, quando il bit vale 1 il permesso è concesso.
Quando un utente accede ad un file, se tale utente è anche il proprietario del file allora si applicano i permessi del proprietario, se l'utente appartiene al gruppo allora si applicano i permessi del gruppo, se l'utente non è il proprietario e non appartiene al gruppo si applicano i permessi degli altri.
Vediamo qualche esempio.
Supponiamo che l'utente jaco appartenente al gruppo mail voglia accedere al file:
-rw-r--r-- 1 root root 111279 Sep 10 21:48 linux-faq.ascii
I permessi di tale file sono per il proprietario che è root: rw-,
ovvero read on, write on, execute off; per il
gruppo che è root: r--, ovvero read on, write off,
execute off; per gli altri: r--, ovvero read on,
write off, execute off.
Per cui jaco avrebbe, non essendo né il proprietario né un appartenente del gruppo, si vedrebbe applicato i permessi degli altri e ciò implica che avrebbe accesso in sola lettura.
Dato che si tratta di un insieme di bit, la stringa rw-r--r-- può
anche essere codificata come un numero ottale, ad esempio in questo
caso il permesso del file è 644.
(Ottale perché ogni cifra corrisponde ad uno dei tre gruppi di
permessi.)
Es: rw-r--r-- si codifica in binario come 110100100, in ottale
abbiamo 110=6, 100=4, 100=4 che dà luogo alla stringa ottale
644.
Avrete notato che in realtà quando visualizziamo un file con
ls -l:
-rw-r--r-- 1 root root 111279 Sep 10 21:48 linux-faq.ascii
Il numero dei permessi non è 9 come abbiamo detto fino ad ora, ma 10, in realta il primo bit non è un permesso ma serve ad indicare se l'oggetto in questione è un file o una directory.
Ad esempio:
total 132
drwxr-xr-x 2 root root 1024 Feb 23 12:04 RCS
-rw-r--r-- 1 root root 111279 Sep 10 21:48 linux-faq.ascii
-rw-r--r-- 1 root root 3110 Feb 23 12:35 prg.culturale.7
-rw------- 1 root root 16384 Feb 23 12:56 prg.culturale.7.swp
Indica che RCS è una directory, per quanto in linea teorica il modo
di applicare i permessi per una directory sia uguale a quello dei file,
il tipo di permessi si discosta un po', vedremo succesivamente come.
Al gruppo di attributi che si possono applicare ad un file, ne
mancano ancora 3, ovvero gli attributi speciali che non compaiono
quando facciamo ls e che sono:
Questi sono 3 flag applicabili ad un file, vediamo un po' a cosa servono.
Il flag set-uid significa che se applicato ad un file, ogni volta che
un utente qualunque accederà a quel file, acquisterà momentaneamente
i poteri del proprietario del file, se il file ha come proprietario
root, in quel momento assumerete i poteri del superuser.
Tutto ciò potrebbe sembrare strano ed in contrasto con la filosofia Unix, in realtà c'è un motivo ben valido del perché sia stato messo a disposizione questo meccanismo. Per esempio serve a quei programmi che hanno bisogno di accedere all'hardware, ad esempio le svgalib o simili. Se il flag set-uid viene applicato ad uno script, non ha nessun effetto.
Il flag set-gid funziona in modo analogo al flag set-uid solo che accedendo ad un file con questo permesso settato ad 1 si assumono i poteri del gruppo del proprietario.
Il flag sticky è veramente molto interessante in realtà questa è solo una abbreviazione, il nome per intero è save-text-image, quando ad un file eseguibile è assegnato questo flag, la parte istruzione del programma viene conservata in memoria anche dopo che il programma è stato runnato e viene riutilizzata di nuovo alla prossima esecuzione del programma. Questo è molto interessante per le prestazioni generali del sistema.
I flag set-uid, set-gid e sticky sono mostrati con una s sopra la
x dell'user, una s sopra la x del group, una x sopra la
t degli altri.
Ad esempio:
-rwsr-xr-x 1 root bin 417917 Aug 7 1995 /usr/bin/gs*
^
indica che il flag set-uid è attivo.
L'unica eccezione al concetto di file system gerarchico viene rappresentata dai symlinks. Un symlink è in parole povere un puntatore a un file realmente esistente sull'hd.
Prendiamo in considerazione ad esempio il file /etc/smail/aliases:
-rw-r--r-- 1 root root 93 Mar 7 21:33 /etc/smail/aliases
questo file deve, per motivi di tuning, essere presente anche nella
directory /etc, ma ovviamente copiarlo semplicemente in quella dir,
significherebbe occupare più spazio sull'Hard Disk, inoltre se facessi
una modifica ad uno dei due file, dovrei farla manualmente anche
all'altro, mentre io per esempio, desidererei che venissero
aggiornati automaticamente.
A questo scopo nascono i symlink, posso praticamente creare un
puntatore al file reale, nella directory /etc, in modo che non
occupi molto spazio su HD e che ogni modifica sia anche riportata nel file
d'origine.
Il symlink viene visualizzato nella dir /etc in questo modo:
lrwxrwxrwx 1 root root 13 Mar 7 21:35 /etc/aliases -> smail/aliases
Come vedete è un puntatore, la dimensione è molto ridotta e ovviamente ogni
modifica nel file /etc/aliases si ripercuoterà anche su
smail/aliases.
Il numero dei link hardware verso un certo file viene riportato nel campo subito a destra dei permessi, il fatto che un oggetto sia un symlink viene riportato nel primo bit a sinistra dei permessi.
Tipicamente per le directory il numero dei link è 2 , perché vi puntano sia
la directory . che la voce della dir precedente, quando ci sono
subdirs, il numero aumenta di 1 per ogni subdir.
lrwxrwxrwx 1 root root 14 Mar 7 20:09 linux -> /usr/src/linux
^
indica che è un symlink
drwxr-xr-x 6 root root 1024 Mar 17 23:27 usr
| |
| |______ il numero degli HardLink a questa dir è 6
|
|_________ è una directory
ln
Il comando che serve per creare un symlink è:
ln [options] source [dest]
L'opzione più comune è -s che crea un symbolik link anziché un link
hardware.
Le operazione di cambiamento di modo (chmod) o di gruppo (chown)
non si ripercuotono sui link simbolici, il cui permesso rimane sempre
777, mentre invece si ripercuotono su tutti i link hardware.
Abbiamo spesso fino ad ora parlato di gruppi, ma non abbiamo ancora specificato esattamente a cosa servono e come si creano. A cosa servono sembra abbastanza palese, ovvero a concedere a gruppi di utenti lo stesso tipo di permesso su di un file.
Immaginate per esempio che ci sia un gruppo di lavoro che sta lavorando ad un progetto comune, ciascuno dovrà poter accedere ai vari file, però gli utenti degli altri gruppi non devono poterlo fare, così come una fotocopia del mondo reale è stata creato il concetto di gruppo nel mondo Linux.
I gruppi vengono creati dal file /etc/group. Ciascuna linea nel
file /etc/group avrà la seguente forma:
group_name:passwd:GID:user_list
Un nome da attribuire al gruppo
Una password per gli utenti del gruppo.
Un numero che identifica il gruppo.
Gli utenti appartenenti al gruppo.
Ad esempio il mio /etc/group è il seguente:
root::0:root
bin::1:root,bin,daemon
daemon::2:root,bin,daemon
sys::3:root,bin,adm
adm::4:root,adm,daemon
tty::5:
disk::6:root,adm
lp::7:lp
mem::8:
kmem::9:
wheel::10:root
floppy::11:root
mail::12:mail
news::13:news
man::15:man
users::100:games
nogroup::-1:
uucp::14:uucp,fnet
fido::101:fido,root,uucp
Affinché la discussione non rimanga astratta è ora necessario vedere quali sono i comandi che operano sui permessi dei file. Il primo che andiamo a vedere è il comando per cambiare il gruppo e/o il proprietario ad un file.
Il comando in questione è:
chown [options] [user].[group] nomefile
dove options può essere una delle tante messe a disposizione dal
comando chown (vedere per i dettagli ``man chown'').
user indica il nome del nuovo proprietario che si vuole assegnare al
file
group indica il nome del nuovo gruppo che si vuole assegnare al file
nomefile è il file su cui si va ad operare.
Ad esempio
chown guest.users introduction
assegna al file introduction il proprietario guest e il gruppo
users.
chown -R root.wheel /home/ftp assegna alla directory
/home/ftp e a tutti le sue sottodirectory e i loro file, come
proprietario root e come gruppo wheel.
Esiste anche il comando chgrp, che consente di cambiare solo il
gruppo e lasciare inalterato il proprietario.
Il comando per cambiare i permessi ad un file è:
chmod [options] mode nomefile
dove options è come al solito una delle numerose opzioni da andare a
vedere su ``man chmod''.
mode è il modo che si vuole assegnare al file.
nomefile è il file su cui si va ad operare.
Ad esempio
chmod 755 mioscript
imposta i seguenti permessi per il file mioscript:
rwxr-xr-x
7 5 5
ovvero per il proprietario permesso in lettura, scrittura, esecuzione, per il gruppo permesso in lettura, esecuzione, e per gli altri permesso in lettura, esecuzione.
Oppure
chmod 640 questodoc
cambiano come segue i permessi del file questodoc:
rw-r-----
6 4 0
ovvero permesso in lettura e scrittura per il proprietario, permesso di sola lettura per il gruppo e nessun accesso per gli altri.
I permessi di un file possono essere cambiati anche in maniera relativa, ad esempio:
chmod g+w nomefile
fa sì che venga impostato a on il permesso in scrittura per il gruppo
al file nomefile.
Come già detto in precedenza, i permessi delle directory, sono molto simili a quelli dei file ordinari, e tuttavia per motivi che appaiono del tutto logici, qualcosa deve differire.
Ad esempio apparirebbe del tutto senza senso continuare a mantenere un bit per il permesso di esecuzione, in quanto una directory non può certamente essere eseguita.
Infatti il bit che tipicamente identifica il permesso di esecuzione se assegnato ad una directory, diventa permesso di accesso. Ovvero se il bit di accesso è uguale ad 1, il processo richiedente avrà la possibilità di accedere a un file in quella directory, altrimenti no.
Supponiamo per esempio di avere la seguente situazione:
drwx--x--x 2 root root 1024 Feb 20 15:31 document.spool
Se entrassimo come utente pippo e gruppo pluto, potremmo entrare nella
directory /tmp/document.spool, ma non potremmo visualizzarne il
contenuto.
In quest'altra situazione:
drwxr-xr-x 2 root root 1024 Feb 20 15:31 document.spool
potremmo entrare nella directory /tmp/document.spool, visualizzarne
il contenuto ma non potremmo scrivere niente.
Infine ad esempio
drwxrw-rw- 2 root root 1024 Feb 20 15:31 document.spool
pur avendo il permesso sia in lettura che in scrittura, non potremmo
neppure entrare nella directory /tmp/document.spool perché non
abbiamo il permesso di accesso.