Aggiunte funzioni di gestione per le varibili di ambiente
[gapil.git] / filedir.tex
1 \chapter{File e directory}
2 \label{cha:files_and_dirs}
3
4 In questo capitolo tratteremo in dettaglio le modalità con cui si gestiscono
5 file e directory, iniziando dalle funzioni di libreria che si usano per
6 copiarli, spostarli e cambiarne i nomi. Esamineremo poi l'interfaccia che
7 permette la manipolazione dei vari attributi di file e directory ed alla
8 fine faremo una trattazione dettagliata su come è strutturato il sistema base
9 di protezioni e controllo di accesso ai file e sulle funzioni che ne
10 permettono la gestione. Tutto quello che riguarda invece la manipolazione del
11 contenuto dei file è lasciato ai capitoli successivi.
12
13
14
15 \section{La gestione di file e directory}
16
17 Come già accennato in \secref{sec:file_filesystem} in un sistema unix-like la
18 gestione dei file ha delle caratteristiche specifiche che derivano
19 direttamente dall'architettura del sistema; in questa sezione esamineremo le
20 funzioni usate per manipolazione nel filesytem di file e directory, per la
21 creazione di link simbolici e diretti, per la gestione e la lettura delle
22 directory; il tutto mettendo in evidenza le conseguenze della struttura
23 standard della gestione dei file in un sistema unix-like, già accennate al
24 capitolo precedente.
25
26
27 \subsection{Le funzioni \func{link} e \func{unlink}}
28 \label{sec:file_link}
29
30 Una caratteristica comune a diversi sistemi operativi è quella di poter creare
31 dei nomi fittizi (come gli alias del MacOS o i collegamenti di Windows) che
32 permettono di fare riferimento allo stesso file chiamandolo con nomi diversi
33 o accedendovi da directory diverse.
34
35 Questo è possibile anche in ambiente unix, dove tali collegamenti sono
36 usualmente chiamati \textit{link}; ma data la struttura del sistema di
37 gestione dei file (ed in particolare quanto trattato in
38 \secref{sec:file_architecture}) ci sono due metodi sostanzialmente diversi per
39 fare questa operazione.
40
41 Come spiegato in \secref{sec:file_filesystem} l'accesso al contenuto di
42 un file su disco avviene attraverso il suo inode, e il nome che si trova in
43 una directory è solo una etichetta associata ad un puntatore a che fa
44 riferimento al suddetto inode.
45
46 Questo significa che la realizzazione di un link è immediata in quanto uno
47 stesso file può avere tanti nomi diversi allo stesso tempo, dati da
48 altrettante diverse associazioni allo stesso inode; si noti poi che nessuno di
49 questi nomi viene ad assumere una particolare preferenza rispetto agli altri.
50
51 Per aggiungere un nome ad un inode si utilizza la funzione \func{link}; si
52 suole chiamare questo tipo di associazione un collegamento diretto (o
53 \textit{hard link}).  Il prototipo della funzione e le sue caratteristiche
54 principali, come risultano dalla man page, sono le seguenti:
55 \begin{prototype}{unistd.h}
56 {int link(const char * oldpath, const char * newpath)}
57   Crea un nuovo collegamento diretto al file indicato da \var{oldpath}
58   dandogli nome \var{newpath}.
59   
60   La funzione restituisce zero in caso di successo e -1 in caso di errore. La
61   variabile \var{errno} viene settata opportunamente, i principali codici di
62   errore sono:
63   \begin{errlist}
64   \item \macro{EXDEV} \var{oldpath} e \var{newpath} non sono sullo
65     stesso filesystem.
66   \item \macro{EPERM} il filesystem che contiene \var{oldpath} e
67     \macro{newpath} non supporta i link diretti o è una directory.
68   \item \macro{EEXIST} un file (o una directory) con quel nome esiste di
69     già.
70   \item \macro{EMLINK} ci sono troppi link al file \var{oldpath} (il
71     numero massimo è specificato dalla variabile \macro{LINK\_MAX}, vedi
72     \secref{sec:sys_limits}).
73   \end{errlist}
74   ed inoltre \macro{EACCES}, \macro{ENAMETOOLONG}, \macro{ENOTDIR},
75   \macro{EFAULT}, \macro{ENOMEM}, \macro{EROFS}, \macro{ELOOP},
76   \macro{ENOSPC}, \macro{EIO}.
77 \end{prototype}
78
79 La creazione di un nuovo collegamento diretto non copia il contenuto del file,
80 ma si limita a creare una voce nella directory specificata con \var{newpath} e
81 ad aumentare di uno il numero di referenze al file (riportato nel campo
82 \var{st\_nlink} della struttura \var{stat}, vedi \secref{sec:file_stat})
83 aggiungendo il nuovo nome ai precedenti. Si noti che uno stesso file può
84 essere così chiamato con vari nomi in diverse directory.
85  
86 Per quanto dicevamo in \secref{sec:file_filesystem} la creazione di un
87 collegamento diretto è possibile solo se entrambi i pathname sono nello stesso
88 filesystem; inoltre il filesystem deve supportare i collegamenti diretti (il
89 meccanismo non è disponibile ad esempio con il filesystem \acr{vfat} di
90 Windows). 
91
92 La funzione inoltre opera sia sui file ordinari che sugli altri oggetti del
93 filesystem, con l'eccezione delle directory. In alcuni versioni di unix solo
94 l'amministratore è in grado di creare un collegamento diretto ad un'altra
95 directory, questo viene fatto perché con una tale operazione è possibile
96 creare dei circoli nel filesystem (vedi l'esempio mostrato in
97 \secref{sec:file_symlink}, dove riprenderemo il discorso) che molti programmi
98 non sono in grado di gestire e la cui rimozione diventerebbe estremamente
99 complicata (in genere per questo tipo di errori occorre far girare il
100 programma \cmd{fsck} per riparare il filesystem).
101
102 Data la pericolosità di questa operazione e la disponibilità dei link
103 simbolici che possono fornire la stessa funzionalità senza questi problemi,
104 nei filesystem usati in Linux questa caratteristica è stata completamente
105 disabilitata, e al tentativo di creare un link diretto ad una directory la
106 funzione restituisce l'errore \macro{EPERM}.
107
108 La rimozione di un file (o più precisamente della voce che lo referenzia
109 all'interno di una directory) si effettua con la funzione \func{unlink}; il
110 suo prototipo è il seguente:
111 \begin{prototype}{unistd.h}{int unlink(const char * pathname)}
112   Cancella il nome specificato dal pathname nella relativa directory e
113   decrementa il numero di riferimenti nel relativo inode. Nel caso di link
114   simbolico cancella il link simbolico; nel caso di socket, fifo o file di
115   dispositivo rimuove il nome, ma come per i file i processi che hanno aperto
116   uno di questi oggetti possono continuare ad utilizzarlo.
117   
118   La funzione restituisce zero in caso di successo e -1 per un errore, nel
119   qual caso il file non viene toccato. La variabile \var{errno} viene
120   settata secondo i seguenti codici di errore:
121   \begin{errlist}
122   \item \macro{EISDIR} \var{pathname} si riferisce ad una directory
123     (valore specifico ritornato da Linux che non consente l'uso di
124     \var{unlink} con le directory, e non conforme allo standard POSIX, che
125     prescrive invece l'uso di \macro{EPERM} in caso l'operazione non sia
126     consentita o il processo non abbia privilegi sufficienti).
127   \item \macro{EROFS} \var{pathname} è su un filesystem montato in sola
128   lettura.
129   \item \macro{EISDIR} \var{pathname} fa riferimento a una directory.
130   \end{errlist}
131   ed inoltre: \macro{EACCES}, \macro{EFAULT}, \macro{ENOENT}, \macro{ENOTDIR},
132   \macro{ENOMEM}, \macro{EROFS}, \macro{ELOOP}, \macro{EIO}.
133 \end{prototype}
134
135 Per cancellare una voce in una directory è necessario avere il permesso di
136 scrittura su di essa (dato che si va a rimuovere una voce dal suo contenuto) e
137 il diritto di esecuzione sulla directory che la contiene (torneremo in
138 dettaglio sui permessi e gli attributi in \secref{sec:file_access_control}),
139 se inoltre lo \textit{sticky} bit è settato occorrerà anche essere proprietari
140 del file o proprietari della directory (o root, per cui nessuna delle
141 restrizioni è applicata).
142
143 Una delle caratteristiche di queste funzioni è che la creazione/rimozione
144 della nome dalla directory e l'incremento/decremento del numero di riferimenti
145 nell'inode deve essere una operazione atomica (si veda
146 \secref{sec:proc_atom_oper}), per questo entrambe queste funzioni sono
147 realizzate tramite una singola system call.
148
149 Si ricordi infine che il file non viene eliminato dal disco fintanto che tutti
150 i riferimenti ad esso sono stati cancellati, solo quando il \textit{link
151   count} mantenuto nell'inode diventa zero lo spazio occupato viene rimosso. A
152 questo però si aggiunge una altra condizione, e cioè che non ci siano processi
153 che abbiano detto file aperto.  
154
155 Questa proprietà viene spesso usata per essere sicuri di non lasciare file
156 temporanei su disco in caso di crash dei programmi; la tecnica è quella di
157 aprire il file e chiamare \func{unlink} subito dopo, in questo modo il
158 contenuto del file è sempre disponibile all'interno del processo attraverso il
159 suo file descriptor (vedi \secref{sec:file_fd}) fintanto che il processo non
160 chiude il file, ma non ne resta traccia in nessuna directory, e lo spazio
161 occupato su disco viene immediatamente rilasciato alla conclusione del
162 processo (quando tutti i file vengono chiusi).
163
164
165 \subsection{Le funzioni \func{remove} e \func{rename}}
166 \label{sec:file_remove}
167
168 Al contrario di quanto avviene con altri unix in Linux non è possibile usare
169 \func{unlink} sulle directory; per cancellare una directory si può usare la
170 funzione \func{rmdir} (vedi \secref{sec:file_dir_creat_rem}), oppure la
171 funzione \func{remove}. Questa è la funzione prevista dallo standard ANSI C
172 per cancellare un file o una directory (e funziona anche per i sistemi che non
173 supportano i link diretti). Per i file è identica a \func{unlink} e per le
174 directory è identica a \func{rmdir}:
175 \begin{prototype}{stdio.h}{int remove(const char *pathname)}
176   Cancella un nome dal filesystem. Usa \func{unlink} per i file e
177   \func{rmdir} per le directory.
178   
179   La funzione restituisce zero in caso di successo e -1 per un errore, nel
180   qual caso il file non viene toccato. Per i codici di errore vedi quanto
181   riportato nelle descrizioni di \func{unlink} e \func{rmdir}.
182 \end{prototype}
183
184 Per cambiare nome ad un file o a una directory (che devono comunque essere
185 nello stesso filesystem) si usa invece la funzione \func{rename}\footnote{la
186   funzione è definita dallo standard ANSI C solo per i file, POSIX estende la
187   funzione anche alle directory}, il cui prototipo è:
188 \begin{prototype}{stdio.h}
189   {int rename(const char *oldpath, const char *newpath)} 
190   
191   Rinomina \var{oldpath} in \var{newpath}, eseguendo se necessario lo
192   spostamento di un file fra directory diverse. Eventuali altri link diretti
193   allo stesso file non vengono influenzati.
194   
195   La funzione restituisce zero in caso di successo e -1 per un errore, nel
196   qual caso il file non viene toccato. La variabile \var{errno} viene settata
197   secondo i seguenti codici di errore:
198   \begin{errlist} 
199   \item \macro{EISDIR} \var{newpath} è una directory mentre \var{oldpath} non
200     è una directory.
201   \item \macro{EXDEV} \var{oldpath} e \var{newpath} non sono sullo stesso
202     filesystem.
203   \item \macro{ENOTEMPTY} \var{newpath} è una directory già esistente e non
204     vuota.
205   \item \macro{EBUSY} o \var{oldpath} o \var{newpath} sono in uso da parte di
206     qualche processo (come directory di lavoro o come radice) o del sistema
207     (come mount point).
208   \item \macro{EINVAL} \var{newpath} contiene un prefisso di \var{oldpath} o
209     più in generale si è cercato di creare una directory come sottodirectory
210     di se stessa.
211   \item \macro{ENOTDIR} Uno dei componenti dei pathname non è una directory o
212     \var{oldpath} è una directory e \var{newpath} esiste e non è una
213     directory.
214   \end{errlist} 
215   ed inoltre \macro{EACCESS}, \macro{EPERM}, \macro{EMLINK}, \macro{ENOENT},
216   \macro{ENOMEM}, \macro{EROFS}, \macro{ELOOP} e \macro{ENOSPC}.
217 \end{prototype}
218
219 Il comportamento della funzione è diverso a seconda che si voglia rinominare
220 un file o una directory; se ci riferisce a un file allora \var{newpath}, se
221 esiste, non deve essere una directory (altrimenti si ha l'errore
222 \macro{EISDIR}). Nel caso \var{newpath} indichi un file esistente questo viene
223 cancellato e rimpiazzato (atomicamente).
224
225 Se \var{oldpath} è una directory allora \var{newpath} se esiste deve essere
226 una directory vuota, altrimenti si avranno gli errori \macro{ENOTDIR} (se non
227 è una directory) o \macro{ENOTEMPTY} (se non è vuota). Chiaramente
228 \var{newpath} non può contenere \var{oldpath} altrimenti si avrà un errore
229 \macro{EINVAL}.
230
231 Se \var{oldpath} si riferisce a un link simbolico questo sarà rinominato; se
232 \var{newpath} è un link simbolico verrà cancellato come qualunque altro file.
233 Infine qualora \var{oldpath} e \var{newpath} siano due nomi dello stesso file
234 lo standard POSIX prevede che la funzione non dia errore, e non faccia nulla,
235 lasciando entrambi i nomi; Linux segue questo standard, anche se come fatto
236 notare dal manuale delle glibc, il comportamento più ragionevole sarebbe
237 quello di cancellare \var{oldpath}.
238
239 Il vantaggio nell'uso di questa funzione al posto della chiamata successiva di
240 \func{link} e \func{unlink} è che l'operazione è eseguita atomicamente, non
241 può esistere cioè nessun istante in cui un altro processo può trovare attivi
242 entrambi i nomi dello stesso file, o, in caso di sostituzione di un file
243 esistente, non trovare quest'ultimo prima che la sostituzione sia stata
244 eseguita.
245
246 In ogni caso se \var{newpath} esiste e l'operazione fallisce per un qualche
247 motivo (come un crash del kernel), \func{rename} garantisce di lasciare
248 presente una istanza di \var{newpath}, tuttavia nella sovrascrittura potrà
249 esistere una finestra in cui sia \var{oldpath} che \var{newpath} fanno
250 riferimento allo stesso file.
251
252
253 \subsection{I link simbolici}
254 \label{sec:file_symlink}
255
256 Come abbiamo visto in \secref{sec:file_link} la funzione \func{link} crea
257 riferimenti agli inodes, pertanto può funzionare soltanto per file che
258 risiedono sullo stesso filesystem e solo per un filesystem di tipo unix.
259 Inoltre abbiamo visto che in Linux non è consentito eseguire un link diretto
260 ad una directory.
261
262 Per ovviare a queste limitazioni i sistemi unix supportano un'altra forma di
263 link (i cosiddetti \textit{soft link} o \textit{symbolic link}), che sono,
264 come avviene in altri sistemi operativi, dei file speciali che contengono il
265 semplicemente il riferimento ad un altro file (o directory). In questo modo è
266 possibile effettuare link anche attraverso filesystem diversi, a file posti in
267 filesystem che non supportano i link diretti, a delle directory, e anche a
268 file che non esistono ancora.
269
270 Il sistema funziona in quanto i link simbolici sono contrassegnati come tali
271 al kernel (analogamente a quanto avviene per le directory) per cui per alcune
272 funzioni di libreria (come \func{open} o \func{stat}) dare come parametro un
273 link simbolico comporta l'applicazione della funzione al file da esso
274 specificato. La funzione che permette di creare un nuovo link simbolico è
275 \func{symlink}; il suo prototipo è:
276 \begin{prototype}{unistd.h}
277   {int symlink(const char * oldpath, const char * newpath)} 
278   Crea un nuovo link simbolico di nome \func{newpath} il cui contenuto è
279   \func{oldpath}.
280   
281   La funzione restituisce zero in caso di successo e -1 per un errore, nel
282   qual caso la variabile \var{errno} restituisce i valori:
283   \begin{errlist}
284   \item \macro{EPERM} il filesystem che contiene \var{newpath} non supporta i
285     link simbolici.
286   \item \macro{ENOENT} una componente di \var{newpath} non esiste o
287     \func{oldpath} è una stringa vuota.
288   \item \macro{EEXIST} esiste già un file \var{newpath}.
289   \item \macro{EROFS} \var{newpath} è su un filesystem montato in sola lettura.
290   \end{errlist}
291   ed inoltre \macro{EFAULT}, \macro{EACCES}, \macro{ENAMETOOLONG},
292   \macro{ENOTDIR}, \macro{ENOMEM}, \macro{ELOOP}, \macro{ENOSPC} e
293   \macro{EIO}.
294 \end{prototype}
295
296 Si tenga presente che la funzione non effettua nessun controllo sull'esistenza
297 di un file di nome \var{oldpath}, ma si limita ad inserire quella stringa nel
298 link simbolico. Pertanto un link simbolico può anche riferirsi ad un file che
299 non esiste: quello che viene chiamato un \textit{dangling link}, letteralmente
300 \textsl{link ciondolante}.
301
302
303 Come accennato i link simbolici sono risolti automaticamente dal kernel
304 all'invocazione delle varie system call; in \ntab\ si è riportato un elenco
305 dei comportamenti delle varie funzioni di libreria che operano sui file nei
306 confronti della risoluzione dei link simbolici, specificando quali seguono il
307 link simbolico e quali invece possono operare direttamente sul suo contenuto.
308 \begin{table}[htb]
309   \centering
310   \footnotesize
311   \begin{tabular}[c]{|l|c|c|}
312     \hline
313     \textbf{Funzione} & \textbf{Segue il link} & \textbf{Non segue il link} \\
314     \hline 
315     \hline 
316     \func{access}   & $\bullet$ &           \\
317     \func{chdir}    & $\bullet$ &           \\
318     \func{chmod}    & $\bullet$ &           \\
319     \func{chown}    &           & $\bullet$ \\
320     \func{creat}    & $\bullet$ &           \\
321     \func{exec}     & $\bullet$ &           \\
322     \func{lchown}   & $\bullet$ & $\bullet$ \\
323     \func{link}     &           &           \\
324     \func{lstat}    &           & $\bullet$ \\
325     \func{mkdir}    & $\bullet$ &           \\
326     \func{mkfifo}   & $\bullet$ &           \\
327     \func{mknod}    & $\bullet$ &           \\
328     \func{open}     & $\bullet$ &           \\
329     \func{opendir}  & $\bullet$ &           \\
330     \func{pathconf} & $\bullet$ &           \\
331     \func{readlink} &           & $\bullet$ \\
332     \func{remove}   &           & $\bullet$ \\
333     \func{rename}   &           & $\bullet$ \\
334     \func{stat}     & $\bullet$ &           \\
335     \func{truncate} & $\bullet$ &           \\
336     \func{unlink}   &           & $\bullet$ \\
337     \hline 
338   \end{tabular}
339   \caption{Uso dei link simbolici da parte di alcune funzioni.}
340   \label{tab:file_symb_effect}
341 \end{table}
342
343 Si noti che non si è specificato il comportamento delle funzioni che operano
344 con i file descriptor, in quanto la risoluzione del link simbolico viene in
345 genere effettuata dalla funzione che restituisce il file descriptor
346 (normalmente la \func{open}) e tutte le operazioni seguenti fanno riferimento
347 solo a quest'ultimo.
348
349 Dato che, come indicato in \tabref{tab:file_symb_effect}, funzioni come la
350 \func{open} seguono i link simbolici, occorrono funzioni apposite per accedere
351 alle informazioni del link invece che a quelle del file a cui esso fa
352 riferimento. Quando si vuole leggere il contenuto di un link simbolico si usa
353 la funzione \func{readlink}, il cui prototipo è:
354 \begin{prototype}{unistd.h}
355 {int readlink(const char * path, char * buff, size\_t size)} 
356   Legge il contenuto del link simbolico indicato da \var{path} nel buffer
357   \var{buff} di dimensione \var{size}.
358   
359   La funzione restituisce il numero di caratteri letti dentro \var{buff} o -1
360   per un errore, nel qual caso la variabile \var{errno} viene settata a:
361   \begin{errlist}
362   \item \macro{EINVAL} \var{file} non è un link simbolico o \var{size} non è
363     positiva. 
364   \item \macro{EROFS} La directory su cui si vuole inserire il nuovo link è
365     su un filesystem montato in sola lettura.
366   \item \macro{ENOSPC} La directory o il filesystem in cui si vuole creare il
367     link è piena e non c'è ulteriore spazio disponibile.
368   \end{errlist}
369   ed inoltre \macro{ENOTDIR}, \macro{ENAMETOOLONG}, \macro{ENOENT},
370   \macro{EACCES}, \macro{ELOOP}, \macro{EIO}, \macro{EFAULT} e \macro{ENOMEM}.
371 \end{prototype}
372
373 La funzione apre il link simbolico, ne legge il contenuto, lo scrive nel
374 buffer, e lo richiude. Si tenga presente che la funzione non termina la
375 stringa con un carattere nullo e la tronca alla dimensione specificata da
376 \var{size} per evitare di sovrascrivere oltre le dimensioni del buffer.
377
378
379 \begin{figure}[htb]
380   \centering
381   \includegraphics[width=5cm]{img/link_loop}
382   \caption{Esempio di loop nel filesystem creato con un link simbolico.}
383   \label{fig:file_link_loop}
384 \end{figure}
385
386 Un caso comune che si può avere con i link simbolici è la creazione dei
387 cosiddetti \textit{loop}. La situazione è illustrata in \curfig, che riporta
388 la struttura della directory \file{/boot}. Come si vede si è creato al suo
389 interno un link simbolico che punta di nuovo a \file{/boot}\footnote{Questo
390   tipo di loop è stato effettuato per poter permettere a \cmd{grub} (un
391   bootloader estremamente avanzato in grado di accedere direttamente
392   attraverso vari filesystem al file da lanciare come sistema operativo) di
393   vedere i file in questa directory, che è montata su una partizione separata
394   (e che grub vedrebbe come radice), con lo stesso path con cui verrebbero
395   visti dal sistema operativo.}. 
396
397 Questo può causare problemi per tutti quei programmi che effettuano la
398 scansione di una directory senza tener conto dei link simbolici, ad esempio se
399 lanciassimo un comando del tipo \cmd{grep -r linux *}, il loop nella directory
400 porterebbe il comando ad esaminare \file{/boot}, \file/{boot/boot},
401 \file/{boot/boot/boot} e così via.
402
403 Per questo motivo il kernel e le librerie prevedono che nella risoluzione di
404 un pathname possano essere seguiti un numero limitato di link simbolici, il
405 cui valore limite è specificato dalla costante \macro{MAXSYMLINKS}; qualora
406 questo limite venga superato viene generato un errore ed \var{errno} viene
407 settata al valore \macro{ELOOP}.
408
409 Un punto da tenere sempre presente è il fatto che un link simbolico può fare
410 riferimento anche ad un file che non esiste; ad esempio possiamo creare un
411 file temporaneo nella nostra directory con un link del tipo:
412 \begin{verbatim}
413 $ ln -s /tmp/tmp_file temporaneo
414 \end{verbatim}%$
415 anche se \file{/tmp/tmp\_file} non esiste. Questo può generare confusione, in
416 quanto aprendo in scrittura \file{temporaneo} verrà creato
417 \file{/tmp/tmp\_file} e scritto; ma accedendo in sola lettura a
418 \file{temporaneo}, ad esempio con \cmd{cat}, otterremmo:
419 \begin{verbatim}
420 $ cat temporaneo
421 cat: temporaneo: No such file or directory
422 \end{verbatim}%$
423 con un errore che può sembrare sbagliato, dato che invece \cmd{ls} ci
424 mostrerebbe l'esistenza di \file{temporaneo}.
425
426
427 \subsection{Le funzioni \func{mkdir} e \func{rmdir}} 
428 \label{sec:file_dir_creat_rem}
429
430 Queste due funzioni servono per creare e cancellare delle directory e sono
431 omonime degli analoghi comandi di shell.  Per poter accedere ai tipi usati
432 da queste funzioni si deve includere il file \file{sys/types.h}, il
433 prototipo della prima è:
434 \begin{prototype}{sys/stat.h}
435   {int mkdir (const char * dirname, mode\_t mode)} 
436   Crea una nuova directory vuota con il nome indicato da \var{dirname},
437   assegnandole i permessi indicati da \var{mode}. Il nome può essere indicato
438   con il pathname assoluto o relativo.
439   
440   La funzione restituisce zero in caso di successo e -1 per un errore, nel
441   qual caso \var{errno} assumerà i valori:
442   \begin{errlist}
443   \item \macro{EEXIST} Un file (o una directory) con quel nome esiste di già. 
444   \item \macro{EACCESS} 
445     Non c'è il permesso di scrittura per la directory in cui si vuole inserire
446     la nuova directory.
447   \item \macro{EMLINK} La directory in cui si vuole creare la nuova directory
448     contiene troppi file. Sotto Linux questo normalmente non avviene perché il
449     filesystem standard consente la creazione di un numero di file maggiore di
450     quelli che possono essere contenuti nel disco, ma potendo avere a che
451     fare anche con filesystem di altri sistemi questo errore può presentarsi.
452   \item \macro{ENOSPC} Non c'è abbastanza spazio sul file system per creare
453     la nuova directory o si è esaurita la quota disco dell'utente.
454   \end{errlist}
455   ed inoltre anche \macro{EPERM}, \macro{EFAULT}, \macro{ENAMETOOLONG},
456   \macro{ENOENT}, \macro{ENOTDIR}, \macro{ENOMEM}, \macro{ELOOP},
457   \macro{EROFS}.
458 \end{prototype}
459  
460 La funzione crea una nuova directory vuota (che contiene solo le due voci
461 standard \file{.} e \file{..}). I permessi di accesso (vedi la trattazione in
462 \secref{sec:file_access_control}) specificati da \var{mode} (i cui possibili
463 valori sono riportati in \tabref{tab:file_permission_const}) sono modificati
464 dalla maschera di creazione dei file (si veda \secref{sec:file_umask}).  La
465 titolarità della nuova directory è settata secondo quanto riportato in
466 \secref{sec:file_ownership}.
467
468 La seconda funzione serve ad eliminare una directory già vuota (la directory
469 deve cioè contenere soltanto le due voci standard \file{.} e \file{..}); il
470 suo prototipo è:
471 \begin{prototype}{sys/stat.h}
472   {int rmdir (const char * dirname)} Cancella la directory \var{dirname}, che
473   deve essere vuota.  Il nome può essere indicato con il pathname assoluto o
474   relativo.
475   
476   La funzione restituisce zero in caso di successo e -1 per un errore, nel
477   qual caso \var{errno} assumerà i valori:
478   \begin{errlist}
479   \item \macro{EPERM} Il filesystem non supporta la cancellazione di
480     directory, oppure la directory che contiene \var{dirname} ha lo sticky bit
481     settato e l'\textit{effective user id} del processo non corrisponde al
482     proprietario della directory. 
483   \item \macro{EACCESS} Non c'è il permesso di scrittura per la directory che
484     contiene la directory che si vuole cancellare, o non c'è il permesso di
485     attraversare (esecuzione) una delle directory specificate in
486     \var{dirname}.
487   \item \macro{EBUSY} La directory specificata è la directory di lavoro o la
488     radice di qualche processo.
489   \item \macro{ENOTEMPTY} La directory non è vuota.
490   \end{errlist}
491   ed inoltre anche \macro{EFAULT}, \macro{ENAMETOOLONG}, \macro{ENOENT},
492   \macro{ENOTDIR}, \macro{ENOMEM}, \macro{ELOOP}, \macro{EROFS}.
493 \end{prototype}
494
495 La modalità con cui avviene la cancellazione è analoga a quella di
496 \func{unlink}, fintanto che il numero di link all'inode della directory non
497 diventa nullo e nessun processo ha la directory aperta lo spazio occupato su
498 disco non viene rilasciato. Se un processo ha la directory aperta la funzione
499 rimuove il link all'inode e nel caso sia l'ultimo, pure le voci standard
500 \file{.} e \file{..}, ed il kernel non consentirà di creare più nuovi file
501 nella directory.
502
503
504 \subsection{Accesso alle directory}
505 \label{sec:file_dir_read}
506
507 Benché le directory siano oggetti del filesystem come tutti gli altri non ha
508 ovviamente senso aprirle come fossero dei file di dati. Può però essere utile
509 poterne leggere il contenuto ad esempio per fare la lista dei file che esse
510 contengono o ricerche sui medesimi. Solo il kernel scrivere direttamente in
511 una directory (onde evitare inconsistenze all'interno del filesystem), i
512 processi devono creare i file usando le apposite funzioni.
513
514 Per accedere al contenuto delle directory si usano i cosiddetti
515 \textit{directory streams} (chiamati così per l'analogia con i file stream);
516 la funzione \func{opendir} apre uno di questi stream e la funzione
517 \func{readdir} legge il contenuto della directory, i cui elementi sono le
518 \textit{directory entry} (da distinguersi da quelle della cache di cui
519 parlavamo in \secref{sec:file_vfs}) in una opportuna struttura \var{struct
520   dirent}.
521
522 (NdA Il resto va scritto!!! É noioso e lo farò più avanti).
523
524
525 \subsection{La directory di lavoro}
526 \label{sec:file_work_dir}
527
528 A ciascun processo è associato ad una directory nel filesystem che è chiamata
529 directory corrente o directory di lavoro (\textit{current working directory})
530 che è quella a cui si fa riferimento quando un filename è espresso in forma
531 relativa, dove il relativa fa riferimento appunto a questa directory.
532
533 Quando un utente effettua il login questa directory viene settata alla
534 \textit{home directory} del suo account. Il comando \cmd{cd} della shell
535 consente di cambiarla a piacere, spostandosi da una directory ad un'altra, il
536 comando \cmd{pwd} la stampa sul terminale.  Siccome la directory corrente
537 resta la stessa quando viene creato un processo figlio (vedi
538 \secref{sec:proc_fork}), la directory corrente della shell diventa anche la
539 directory corrente di qualunque comando da essa lanciato.
540
541 In genere il kernel tiene traccia per ciascun processo dell'inode della
542 directory di lavoro corrente, per ottenere il pathname occorre usare una
543 apposita funzione di libreria,  \func{getcwd}, il cui prototipo è:
544 \begin{prototype}{unistd.h}{char * getcwd (char * buffer, size\_t size)}
545   Restituisce il filename completo della directory di lavoro corrente nella
546   stringa puntata da \var{buffer}, che deve essere precedentemente
547   allocata, per una dimensione massima di \var{size}.
548   
549   La funzione restituisce il puntatore \var{buffer} se riesce, \macro{NULL} se
550   fallisce, in quest'ultimo caso la variabile \var{errno} è settata con i
551   seguenti codici di errore:
552   \begin{errlist}
553   \item \macro{EINVAL} L'argomento \var{size} è zero e \var{buffer} non
554     è nullo.
555   \item \macro{ERANGE} L'argomento \var{size} è più piccolo della
556     lunghezza del pathname. 
557   \item \macro{EACCESS} Manca il permesso di lettura o di ricerca su uno dei
558     componenti del pathname (cioè su una delle directory superiori alla
559     corrente).
560   \end{errlist}
561 \end{prototype}
562
563 Il buffer deve essere sufficientemente lungo da poter contenere il pathname
564 completo più lo zero di terminazione della stringa. Qualora esso ecceda le
565 dimensioni specificate con \var{size} la funzione restituisce un errore.  Si
566 può anche specificare un puntatore nullo come \var{buffer}\footnote{questa è
567   una estensione allo standard POSIX.1, supportata da Linux}, nel qual caso la
568 stringa sarà allocata automaticamente per una dimensione pari a \var{size}
569 qualora questa sia diversa da zero, o della lunghezza esatta del pathname
570 altrimenti. In questo caso ci si deve ricordare di disallocare la stringa una
571 volta cessato il suo utilizzo.
572
573 Di questa funzione esiste una versione \func{char * getwd(char * buffer)}
574 fatta per compatibilità all'indietro con BSD, che non consente di specificare
575 la dimensione del buffer; esso deve essere allocato in precedenza ed avere una
576 dimensione superiore a \macro{PATH\_MAX} (di solito 256 byte, vedi
577 \secref{sec:sys_limits}); il problema è che in Linux non esiste una dimensione
578 superiore per un pathname, per cui non è detto che il buffer sia sufficiente a
579 contenere il nome del file, e questa è la ragione principale per cui questa
580 funzione è deprecata.
581
582 Una seconda funzione simile è \func{char * get\_current\_dir\_name(void)} che
583 è sostanzialmente equivalente ad una \func{getcwd(NULL, 0)}, con la sola
584 differenza che essa ritorna il valore della variabile di ambiente \macro{PWD},
585 che essendo costruita dalla shell può contenere anche dei riferimenti
586 simbolici; nel caso di  \func{getcwd} infatti, essendo il pathname ricavato
587 risalendo all'indietro l'albero della directory, si perderebbe traccia di ogni
588 passaggio attraverso eventuali pathname.
589
590 Altre due funzioni, \func{chdir} e \func{fchdir}, vengono usate, come dice il
591 nome (che deriva da \textit{change directory}), per cambiare la directory di
592 lavoro corrente. Dato che anche le directory sono file, è possibile riferirsi
593 ad esse anche tramite il file descriptor dell'interfaccia a basso livello, e
594 non solo tramite il filename, i prototipi di queste funzioni sono:
595 \begin{functions}
596   \headdecl{unistd.h} 
597   \funcdecl{int chdir (const char * path)} 
598   Cambia la directory di lavoro corrente a quella specificata dal pathname
599   contenuto nella stringa \var{path}.
600   
601   \funcdecl{int fchdir (int fd)} Analoga alla precedente, ma
602   usa un file descriptor invece del pathname.
603   
604   Entrambe le funzioni restituiscono zero in caso di successo e -1 per un
605   errore, in caso di errore \var{errno} viene settata per \func{chdir} ai
606   valori:
607   \begin{errlist}
608   \item \macro{ENOTDIR} Uno dei componenti di \var{path} non è una directory. 
609   \item \macro{EACCESS} Manca il permesso di ricerca su uno dei componenti di
610     \func{path}.
611   \end{errlist}
612   ed inoltre \macro{EFAULT}, \macro{ENAMETOOLONG}, \macro{ENOENT},
613   \macro{ENOMEM}, \macro{ELOOP} e \macro{EIO}. Per \func{fchdir} invece gli
614   errori sono \macro{EBADF} e \macro{EACCES}.
615 \end{functions}
616
617
618
619 \section{La manipolazione delle caratteristiche dei files}
620 \label{sec:file_infos}
621
622 Come spiegato in \secref{sec:file_filesystem} tutte le informazioni
623 generali relative alle caratteristiche di ciascun file, a partire dalle
624 informazioni relative al controllo di accesso, sono mantenute nell'inode.
625
626 Vedremo in questa sezione come sia possibile leggere tutte queste informazioni
627 usando la funzione \func{stat}, che permette l'accesso a tutti i dati
628 memorizzati nell'inode; esamineremo poi le varie funzioni usate per manipolare
629 tutte queste informazioni (eccetto quelle che riguardano la gestione del
630 controllo di accesso, trattate in in \secref{sec:file_access_control}).
631
632
633 \subsection{Le funzioni \func{stat}, \func{fstat} e \func{lstat}}
634 \label{sec:file_stat}
635
636 La lettura delle informazioni relative ai file è fatta attraverso la famiglia
637 delle funzioni \func{stat}; questa è la funzione che ad esempio usa il comando
638 \cmd{ls} per poter ottenere e mostrare tutti i dati dei files. I prototipi di
639 queste funzioni sono i seguenti:
640 \begin{functions}
641   \headdecl{sys/types.h} 
642   \headdecl{sys/stat.h} 
643   \headdecl{unistd.h}
644
645   \funcdecl{int stat(const char *file\_name, struct stat *buf)} Legge le
646   informazione del file specificato da \var{file\_name} e le inserisce in
647   \var{buf}.
648   
649   \funcdecl{int lstat(const char *file\_name, struct stat *buf)} Identica a
650   \func{stat} eccetto che se il \var{file\_name} è un link simbolico vengono
651   lette le informazioni relativa ad esso e non al file a cui fa riferimento.
652   
653   \funcdecl{int fstat(int filedes, struct stat *buf)} Identica a \func{stat}
654   eccetto che si usa con un file aperto, specificato tramite il suo file
655   descriptor \var{filedes}.
656   
657   Le funzioni restituiscono zero in caso di successo e -1 per un errore, in
658   caso di errore \var{errno} può assumere uno dei valori: \macro{EBADF},
659   \macro{ENOENT}, \macro{ENOTDIR}, \macro{ELOOP}, \macro{EFAULT},
660   \macro{EACCESS}, \macro{ENOMEM}, \macro{ENAMETOOLONG}.
661 \end{functions}
662
663 La struttura \var{stat} è definita nell'header \file{sys/stat.h} e in
664 generale dipende dall'implementazione, la versione usata da Linux è mostrata
665 in \nfig, così come riportata dalla man page (in realtà la definizione
666 effettivamente usata nel kernel dipende dall'architettura e ha altri campi
667 riservati per estensioni come tempi più precisi, o per il padding dei campi).
668
669 \begin{figure}[!htb]
670   \footnotesize
671   \centering
672   \begin{minipage}[c]{15cm}
673     \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
674 struct stat {
675     dev_t         st_dev;      /* device */
676     ino_t         st_ino;      /* inode */
677     mode_t        st_mode;     /* protection */
678     nlink_t       st_nlink;    /* number of hard links */
679     uid_t         st_uid;      /* user ID of owner */
680     gid_t         st_gid;      /* group ID of owner */
681     dev_t         st_rdev;     /* device type (if inode device) */
682     off_t         st_size;     /* total size, in bytes */
683     unsigned long st_blksize;  /* blocksize for filesystem I/O */
684     unsigned long st_blocks;   /* number of blocks allocated */
685     time_t        st_atime;    /* time of last access */
686     time_t        st_mtime;    /* time of last modification */
687     time_t        st_ctime;    /* time of last change */
688 };
689     \end{lstlisting}
690   \end{minipage} 
691   \normalsize 
692   \caption{La struttura \var{stat} per la lettura delle informazioni dei 
693     file}
694   \label{fig:file_stat_struct}
695 \end{figure}
696
697 Si noti come i vari membri della struttura siano specificati come tipi nativi
698 del sistema (di quelli definiti in \tabref{tab:xxx_sys_types}, e dichiarati in
699 \file{sys/types.h}). 
700
701
702 \subsection{I tipi di file}
703 \label{sec:file_types}
704
705 Come riportato in \tabref{tab:file_file_types} in Linux oltre ai file e
706 alle directory esistono vari altri oggetti che possono stare su un filesystem;
707 il tipo di file è ritornato dalla \func{stat} nel campo \var{st\_mode}
708 (che è quello che contiene anche le informazioni relative ai permessi).
709
710 Dato che il valore numerico può variare a seconda delle implementazioni, lo
711 standard POSIX definisce un insieme di macro per verificare il tipo di files,
712 queste vengono usate anche da Linux che supporta pure le estensioni per link
713 simbolici e socket definite da BSD, l'elenco completo di tutte le macro è
714 riportato in \ntab.
715 \begin{table}[htb]
716   \centering
717   \footnotesize
718   \begin{tabular}[c]{|l|l|}
719     \hline
720     \textbf{Macro} & \textbf{Tipo del file} \\
721     \hline
722     \hline
723     \macro{S\_ISREG(m)}  & file regolare \\
724     \macro{S\_ISDIR(m)}  & directory \\
725     \macro{S\_ISCHR(m)}  & device a caratteri \\
726     \macro{S\_ISBLK(m)}  & device a blocchi\\
727     \macro{S\_ISFIFO(m)} & fifo \\
728     \macro{S\_ISLNK(m)}  & link simbolico \\
729     \macro{S\_ISSOCK(m)} & socket \\
730     \hline    
731   \end{tabular}
732   \caption{Macro per i tipi di file (definite in \texttt{sys/stat.h})}
733   \label{tab:file_type_macro}
734 \end{table}
735
736 Oltre a queste macro è possibile usare direttamente il valore di
737 \var{st\_mode} per ricavare il significato dei vari bit in esso memorizzati,
738 per questo sempre in \file{sys/stat.h} sono definiti i flag riportati in
739 \ntab:
740 \begin{table}[htb]
741   \centering
742   \footnotesize
743   \begin{tabular}[c]{|l|c|l|}
744     \hline
745     \textbf{Flag} & \textbf{Valore} & \textbf{Significato} \\
746     \hline
747     \hline
748     \macro{S\_IFMT}   &  0170000 & bitmask per i bit del tipo di file \\
749     \macro{S\_IFSOCK} &  0140000 & socket             \\
750     \macro{S\_IFLNK}  &  0120000 & link simbolico     \\
751     \macro{S\_IFREG}  &  0100000 & file regolare      \\ 
752     \macro{S\_IFBLK}  &  0060000 & device a blocchi   \\
753     \macro{S\_IFDIR}  &  0040000 & directory          \\ 
754     \macro{S\_IFCHR}  &  0020000 & device a caratteri \\
755     \macro{S\_IFIFO}  &  0010000 & fifo               \\
756     \hline
757     \macro{S\_ISUID}  &  0004000 & set UID bit   \\
758     \macro{S\_ISGID}  &  0002000 & set GID bit   \\
759     \macro{S\_ISVTX}  &  0001000 & sticky bit    \\
760     \hline
761 %    \macro{S\_IRWXU}  &  00700   & bitmask per i permessi del proprietario  \\
762     \macro{S\_IRUSR}  &  00400   & il proprietario ha permesso di lettura   \\
763     \macro{S\_IWUSR}  &  00200   & il proprietario ha permesso di scrittura \\
764     \macro{S\_IXUSR}  &  00100   & il proprietario ha permesso di esecuzione\\
765     \hline
766 %    \macro{S\_IRWXG}  &  00070   & bitmask per i permessi del gruppo        \\
767     \macro{S\_IRGRP}  &  00040   & il gruppo ha permesso di lettura         \\
768     \macro{S\_IWGRP}  &  00020   & il gruppo ha permesso di scrittura       \\
769     \macro{S\_IXGRP}  &  00010   & il gruppo ha permesso di esecuzione      \\
770     \hline
771 %    \macro{S\_IRWXO}  &  00007   & bitmask per i permessi di tutti gli altri\\
772     \macro{S\_IROTH}  &  00004   & gli altri hanno permesso di lettura      \\
773     \macro{S\_IWOTH}  &  00002   & gli altri hanno permesso di esecuzione   \\
774     \macro{S\_IXOTH}  &  00001   & gli altri hanno permesso di esecuzione   \\
775     \hline    
776   \end{tabular}
777   \caption{Costanti per l'identificazione dei vari bit che compongono il campo
778     \var{st\_mode} (definite in \file{sys/stat.h})}
779   \label{tab:file_mode_flags}
780 \end{table}
781
782 Il primo valore definisce la maschera dei bit usati nei quali viene
783 memorizzato il tipo di files, mentre gli altri possono essere usati per
784 effettuare delle selezioni sul tipo di file voluto, combinando opportunamente
785 i vari flag; ad esempio se si volesse controllare se un file è una directory o
786 un file ordinario si potrebbe definire la condizione:
787 \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
788 #define IS_FILE_DIR(x) (((x) & S_IFMT) & (S_IFDIR | S_IFREG))
789 \end{lstlisting}
790 in cui prima si estraggono da \var{st\_mode} i bit relativi al tipo di file e
791 poi si effettua il confronto con la combinazione di tipi scelta.
792
793
794 \subsection{La dimensione dei file}
795 \label{sec:file_file_size}
796
797 Il membro \var{st\_size} contiene la dimensione del file in byte (se il file
798 è un file normale, nel caso di un link simbolico al dimensione è quella del
799 pathname che contiene). 
800
801 Il campo \var{st\_blocks} definisce la lunghezza del file in blocchi di 512
802 byte. Il campo \var{st\_blksize} infine definisce la dimensione preferita per
803 i trasferimenti sui file (che è la dimensione usata anche dalle librerie del C
804 per l'interfaccia degli stream); scrivere sul file a blocchi di dati di
805 dimensione inferiore sarebbe inefficiente.
806
807 Si tenga conto che lunghezza del file riportata in \var{st\_size} non è detto
808 che corrisponda all'occupazione dello spazio su disco per via della possibile
809 esistenza dei cosiddetti \textsl{buchi} (detti normalmente \textit{holes}) che
810 si formano tutte le volte che si va a scrivere su un file dopo aver eseguito
811 una \func{seek} (vedi \secref{sec:file_lseek}) oltre la sua conclusione
812 corrente.
813
814 In tal caso si avranno differenti risultati a seconda del modi in cui si
815 calcola la lunghezza del file, ad esempio il comando \cmd{du}, (che riporta il
816 numero di blocchi occupati) potrà dare una dimensione inferiore, mentre se si
817 legge dal file (ad esempio usando il comando \cmd{wc -c}), dato che in tal
818 caso per le parti non scritte vengono restituiti degli zeri, si avrà lo stesso
819 risultato di \cmd{ls}.
820
821 Se è sempre possibile allargare un file, scrivendoci sopra od usando la
822 funzione \func{seek} per spostarsi oltre la sua fine, esistono anche casi in
823 cui si può avere bisogno di effettuare un troncamento, scartando i dati
824 presenti al di là della dimensione scelta come nuova fine del file.
825
826 Un file può sempre essere troncato a zero aprendolo con il flag
827 \macro{O\_TRUNC}, ma questo è un caso particolare; per qualunque altra
828 dimensione si possono usare le due funzioni:
829 \begin{functions}
830   \headdecl{unistd.h} \funcdecl{int truncate(const char *file\_name, off\_t
831     length)} Fa si che la dimensione del file \var{file\_name} sia troncata ad
832     un valore massimo specificato da \var{lenght}. 
833   
834   \funcdecl{int ftruncate(int fd, off\_t length))} Identica a \func{truncate}
835   eccetto che si usa con un file aperto, specificato tramite il suo file
836   descriptor \var{fd}.
837   
838   Le funzioni restituiscono zero in caso di successo e -1 per un errore, nel
839   qual caso \var{errno} viene settato opportunamente; per \func{ftruncate} si
840   hanno i valori:
841   \begin{errlist}
842   \item \macro{EBADF} \var{fd}  non è un file descriptor.
843   \item \macro{EINVAL} \var{fd} è un riferimento ad un socket, non a un file
844     o non è aperto in scrittura.
845   \end{errlist}
846   per \func{truncate} si hanno:
847   \begin{errlist}
848   \item \macro{EACCES} il file non ha permesso di scrittura o non si ha il
849     permesso di esecuzione una delle directory del pathname. 
850   \item \macro{ETXTBSY} Il file è un programma in esecuzione.
851   \end{errlist}
852   ed anche \macro{ENOTDIR}, \macro{ENAMETOOLONG}, \macro{ENOENT},
853   \macro{EROFS}, \macro{EIO}, \macro{EFAULT}, \macro{ELOOP}.
854 \end{functions}
855
856 Se il file è più lungo della lunghezza specificata i dati in eccesso saranno
857 perduti; il comportamento in caso di lunghezza inferiore non è specificato e
858 dipende dall'implementazione: il file può essere lasciato invariato o esteso
859 fino alla lunghezza scelta; in quest'ultimo caso lo spazio viene riempito con
860 zeri (e in genere si ha la creazione di un \textit{hole} nel file).
861
862
863 \subsection{I tempi dei file}
864 \label{sec:file_file_times}
865
866 Il sistema mantiene per ciascun file tre tempi. Questi sono registrati
867 nell'inode insieme agli altri attributi del file e possono essere letti
868 tramite la funzione \func{stat}, che li restituisce attraverso tre campi della
869 struttura \var{stat} di \figref{fig:file_stat_struct}. Il significato di detti
870 tempi e dei relativi campi è riportato nello schema in \ntab:
871
872 \begin{table}[htb]
873   \centering
874   \footnotesize
875   \begin{tabular}[c]{|c|l|l|c|}
876     \hline
877     \textbf{Membro} & \textbf{Significato} & \textbf{Funzione} 
878     & \textbf{Opzione} \\
879     \hline
880     \hline
881     \var{st\_atime}& ultimo accesso ai dati del file &\func{read}& \cmd{-u}\\ 
882     \var{st\_mtime}& ultima modifica ai dati del file &\func{write}& default\\ 
883     \var{st\_ctime}& ultima modifica ai dati dell'inode&\func{chmod}, 
884     \func{utime} & \cmd{-c} \\ 
885     \hline
886   \end{tabular}
887   \caption{I tre tempi associati a ciascun file}
888   \label{tab:file_file_times}
889 \end{table}
890
891 Il primo punto da tenere presente è la differenza fra il cosiddetto tempo di
892 modifica (il \textit{modification time} \var{st\_mtime}) e il tempo di
893 cambiamento di stato (il \textit{change time} \var{st\_ctime}). Il primo
894 infatti fa riferimento ad una modifica del contenuto di un file, mentre il
895 secondo ad una modifica dell'inode; siccome esistono molte operazioni (come la
896 funzione \func{link} e molte altre che vedremo in seguito) che modificano solo
897 le informazioni contenute nell'inode senza toccare il file, diventa necessario
898 l'utilizzo di un altro tempo.
899
900 Il sistema non tiene conto dell'ultimo accesso all'inode, pertanto funzioni
901 come \func{access} o \func{stat} non hanno alcuna influenza sui tre tempi. Il
902 tempo di ultimo accesso (ai dati) viene di solito usato per cancellare i file
903 che non servono più dopo un certo lasso di tempo (ad esempio \cmd{leafnode}
904 cancella i vecchi articoli sulla base di questo tempo).
905
906 Il tempo di ultima modifica invece viene usato da \cmd{make} per decidere
907 quali file necessitano di essere ricompilati o (talvolta insieme anche al
908 tempo di cambiamento di stato) per decidere quali file devono essere
909 archiviati per il backup. Il comando \cmd{ls} (quando usato con le opzioni
910 \cmd{-l} o \cmd{-t}) mostra i tempi dei file secondo lo schema riportato
911 nell'ultima colonna di \curtab.
912
913 L'effetto delle varie funzioni di manipolazione dei file sui tempi è
914 illustrato in \ntab. Si sono riportati gli effetti sia per il file a cui si fa
915 riferimento, sia per la directory che lo contiene; questi ultimi possono
916 essere capiti se si tiene conto di quanto già detto, e cioè che anche le
917 directory sono file (che contengono una lista di nomi) che il sistema tratta
918 in maniera del tutto analoga a tutti gli altri.
919
920 Per questo motivo tutte le volte che compiremo una operazione su un file che
921 comporta una modifica del nome contenuto nella directory, andremo anche a
922 scrivere sulla directory che lo contiene cambiandone il tempo di modifica. Un
923 esempio di questo può essere la cancellazione di un file, invece leggere o
924 scrivere o cambiare i permessi di un file ha effetti solo sui tempi di
925 quest'ultimo.
926
927 \begin{table}[htb]
928   \centering
929   \footnotesize
930   \begin{tabular}[c]{|l|c|c|c|c|c|c|l|}
931     \hline
932     \multicolumn{1}{|p{3cm}|}{\centering{\vspace{6pt}\textbf{Funzione}}} &
933     \multicolumn{3}{|p{3cm}|}{\centering{File o directory di riferimento}}&
934     \multicolumn{3}{|p{3cm}|}{\centering{Directory genitrice del riferimento}} 
935     &\multicolumn{1}{|p{3.6cm}|}{\centering{\vspace{6pt}\textbf{Note}}} \\
936     \cline{2-7}
937     \cline{2-7}
938     \multicolumn{1}{|p{3cm}|}{} 
939     &\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(a)}}}
940     &\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(m)}}}
941     &\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(c)}}}
942     &\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(a)}}}
943     &\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(m)}}}
944     &\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(c)}}}
945     &\multicolumn{1}{|p{3cm}|}{} \\
946     \hline
947     \hline
948     \func{chmod}, \func{fchmod} 
949     &         &         &$\bullet$&         &         &         & \\
950     \func{chown}, \func{fchown} 
951     &         &         &$\bullet$&         &         &         & \\
952     \func{creat}  
953     &$\bullet$&$\bullet$&$\bullet$&         &$\bullet$&$\bullet$&  con 
954     \macro{O\_CREATE} \\    \func{creat}  
955     &         &$\bullet$&$\bullet$&         &$\bullet$&$\bullet$&   
956     con \macro{O\_TRUNC} \\    \func{exec}  
957     &$\bullet$&         &         &         &         &         & \\
958     \func{lchown}  
959     &         &         &$\bullet$&         &         &         & \\
960     \func{link}
961     &         &         &$\bullet$&         &$\bullet$&$\bullet$& \\
962     \func{mkdir}
963     &$\bullet$&$\bullet$&$\bullet$&         &$\bullet$&$\bullet$& \\
964     \func{mkfifo}
965     &$\bullet$&$\bullet$&$\bullet$&         &$\bullet$&$\bullet$& \\
966     \func{open}
967     &$\bullet$&$\bullet$&$\bullet$&         &$\bullet$&$\bullet$& con 
968     \macro{O\_CREATE} \\    \func{open}
969     &         &$\bullet$&$\bullet$&         &         &         & con 
970     \macro{O\_TRUNC}  \\    \func{pipe}
971     &$\bullet$&$\bullet$&$\bullet$&         &         &         & \\
972     \func{read}
973     &$\bullet$&         &         &         &         &         & \\
974     \func{remove}
975     &         &         &$\bullet$&         &$\bullet$&$\bullet$& using 
976     \func{unlink}\\    \func{remove}
977     &         &         &         &         &$\bullet$&$\bullet$& using 
978     \func{rmdir}\\ \func{rename}
979     &         &         &$\bullet$&         &$\bullet$&$\bullet$& per entrambi
980     gli argomenti\\ \func{rmdir}
981     &         &         &         &         &$\bullet$&$\bullet$& \\ 
982     \func{truncate}, \func{ftruncate}
983     &         &$\bullet$&$\bullet$&         &         &         & \\ 
984     \func{unlink}
985     &         &         &$\bullet$&         &$\bullet$&$\bullet$& \\ 
986     \func{utime}
987     &$\bullet$&$\bullet$&$\bullet$&         &         &         & \\ 
988     \func{write}
989     &         &$\bullet$&$\bullet$&         &         &         & \\ 
990     \hline
991   \end{tabular}
992   \caption{Prospetto dei cambiamenti effettuati sui tempi di ultimo 
993     accesso \textsl{(a)}, ultima modifica \textsl{(m)} e ultimo cambiamento
994     \textsl{(c)} dalle varie funzioni operanti su file e directory.}
995   \label{tab:file_times_effects}  
996 \end{table}
997
998 Si noti infine come \var{st\_ctime} non abbia nulla a che fare con il tempo di
999 creazione del file, usato in molti altri sistemi operativi, ma che in unix non
1000 esiste.
1001
1002
1003 \subsection{La funzione \func{utime}}
1004 \label{sec:file_utime}
1005
1006 I tempi di ultimo accesso e modifica possono essere cambiati usando la
1007 funzione \func{utime}, il cui prototipo è:
1008 \begin{prototype}{utime.h}
1009 {int utime(const char * filename, struct utimbuf *times)} 
1010
1011 Cambia i tempi di ultimo accesso e modifica dell'inode specificato da
1012 \var{filename} secondo i campi \var{actime} e \var{modtime} di \var{times}. Se
1013 questa è \macro{NULL} allora viene usato il tempo corrente.
1014
1015 La funzione restituisce zero in caso di successo e -1 in caso di errore, nel
1016 qual caso \var{errno} è settata opportunamente.
1017 \begin{errlist}
1018 \item \macro{EACCESS} non si ha il permesso di scrittura sul file.
1019 \item \macro{ENOENT} \var{filename} non esiste.
1020 \end{errlist}
1021 \end{prototype}
1022  
1023 La struttura \var{utimebuf} usata da \func{utime} è definita come:
1024 \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
1025 struct utimbuf {
1026         time_t actime;  /* access time */
1027         time_t modtime; /* modification time */
1028 };
1029 \end{lstlisting}
1030
1031 L'effetto della funzione e i privilegi necessari per eseguirla dipendono da
1032 cosa è l'argomento \var{times}; se è \macro{NULL} la funzione setta il tempo
1033 corrente ed è sufficiente avere accesso in scrittura al file; se invece si è
1034 specificato un valore la funzione avrà successo solo se si è proprietari del
1035 file (o si hanno i privilegi di amministratore).
1036
1037 Si tenga presente che non è comunque possibile specificare il tempo di
1038 cambiamento di stato del file, che viene comunque cambiato dal kernel tutte le
1039 volte che si modifica l'inode (quindi anche alla chiamata di \func{utime}).
1040 Questo serve anche come misura di sicurezza per evitare che si possa
1041 modificare un file nascondendo completamente le proprie tracce.  In realtà la
1042 cosa resta possibile, se si è in grado di accedere al device, scrivendo
1043 direttamente sul disco senza passare attraverso il filesystem, ma ovviamente
1044 in questo modo la cosa è molto più complicata da realizzare.
1045
1046
1047
1048 \section{Il controllo di accesso ai file}
1049 \label{sec:file_access_control}
1050
1051 Una delle caratteristiche fondamentali di tutti i sistemi unix-like è quella
1052 del controllo di accesso ai file, che viene implementato per qualunque
1053 filesystem standard. In questa sezione ne esamineremo i concetti essenziali e
1054 le funzioni usate per gestirne i vari aspetti.
1055
1056
1057 \subsection{I permessi per l'accesso ai file}
1058 \label{sec:file_perm_overview}
1059
1060 Il controllo di accesso ai file in unix segue un modello abbastanza semplice
1061 (ma adatto alla gran parte delle esigenze) in cui si dividono i permessi su
1062 tre livelli. Si tenga conto poi che quanto diremo è vero solo per filesystem
1063 di tipo unix, e non è detto che sia applicabile a un filesystem
1064 qualunque\footnote{ed infatti non è vero per il filesystem vfat di Windows,
1065   per il quale i permessi vengono assegnati in maniera fissa con un opzione in
1066   fase di montaggio}.  Esistono inoltre estensioni che permettono di
1067 implementare le ACL (\textit{Access Control List}) che sono un meccanismo di
1068 controllo di accesso molto più sofisticato.
1069
1070 Ad ogni file unix associa sempre l'utente che ne è proprietario (il cosiddetto
1071 \textit{owner}) e il gruppo di appartenenza, secondo il meccanismo degli
1072 identificatori di utenti e gruppi (\acr{uid} e \acr{gid}). Questi valori
1073 sono accessibili da programma tramite i campi \var{st\_uid} e \var{st\_gid}
1074 della struttura \var{stat} (si veda \secref{sec:file_stat}). Ad ogni file
1075 viene inoltre associato un insieme di permessi che sono divisi in tre classi,
1076 e cioè attribuiti rispettivamente all'utente proprietario del file, a un
1077 qualunque utente faccia parte del gruppo cui appartiene il file, e a tutti gli
1078 altri utenti.
1079
1080 I permessi, così come vengono presi dai comandi e dalle routine di sistema,
1081 sono espressi da un numero di 12 bit; di questi i nove meno significativi sono
1082 usati a gruppi di tre per indicare i permessi base di lettura, scrittura ed
1083 esecuzione (indicati nei comandi di sistema con le lettere \cmd{w}, \cmd{r} e
1084 \cmd{x}) ed applicabili rispettivamente al proprietario, al gruppo, a tutti
1085 gli altri.  I restanti tre bit (\acr{suid}, \acr{sgid}, e
1086 \textsl{sticky}) sono usati per indicare alcune caratteristiche più complesse
1087 su cui torneremo in seguito (vedi \secref{sec:file_suid_sgid} e
1088 \secref{sec:file_sticky}).
1089
1090 Anche i permessi, come tutte le altre informazioni generali, sono tenuti per
1091 ciascun file nell'inode; in particolare essi sono contenuti in alcuni bit
1092 del campo \var{st\_mode} della struttura letta da \func{stat} (di nuovo si veda
1093 \secref{sec:file_stat} per i dettagli).
1094
1095 In genere ci si riferisce a questo raggruppamento dei permessi usando le
1096 lettere \cmd{u} (per \textit{user}), \cmd{g} (per \textit{group}) e \cmd{o}
1097 (per \textit{other}), inoltre se si vuole indicare tutti i raggruppamenti
1098 insieme si usa la lettera \cmd{a} (per \textit{all}). Si tenga ben presente
1099 questa distinzione dato che in certi casi, mutuando la terminologia in uso nel
1100 VMS, si parla dei permessi base come di permessi per \textit{owner},
1101 \textit{group} ed \textit{all}, le cui iniziali possono dar luogo a confusione.
1102 Le costanti che permettono di accedere al valore numerico di questi bit nel
1103 campo \var{st\_mode} sono riportate in \ntab.
1104
1105 \begin{table}[htb]
1106   \centering
1107     \footnotesize
1108   \begin{tabular}[c]{|c|l|}
1109     \hline
1110     \textbf{\var{st\_mode}} bit & \textbf{Significato} \\
1111     \hline 
1112     \hline 
1113     \macro{S\_IRUSR}  &  \textit{user-read}, l'utente può leggere     \\
1114     \macro{S\_IWUSR}  &  \textit{user-write}, l'utente può scrivere   \\
1115     \macro{S\_IXUSR}  &  \textit{user-execute}, l'utente può eseguire \\ 
1116     \hline              
1117     \macro{S\_IRGRP}  &  \textit{group-read}, il gruppo può leggere    \\
1118     \macro{S\_IWGRP}  &  \textit{group-write}, il gruppo può scrivere  \\
1119     \macro{S\_IXGRP}  &  \textit{group-execute}, il gruppo può eseguire\\
1120     \hline              
1121     \macro{S\_IROTH}  &  \textit{other-read}, tutti possono leggere    \\
1122     \macro{S\_IWOTH}  &  \textit{other-write}, tutti possono scrivere  \\
1123     \macro{S\_IXOTH}  &  \textit{other-execute}, tutti possono eseguire\\
1124     \hline              
1125   \end{tabular}
1126   \caption{I bit dei permessi di accesso ai file, come definiti in 
1127     \texttt{<sys/stat.h>}}
1128   \label{tab:file_bit_perm}
1129 \end{table}
1130
1131 Questi permessi vengono usati in maniera diversa dalle varie funzioni, e a
1132 seconda che si riferiscano a file, link simbolici o directory, qui ci
1133 limiteremo ad un riassunto delle regole generali, entrando nei dettagli più
1134 avanti.
1135
1136 La prima regola è che per poter accedere ad un file attraverso il suo pathname
1137 occorre il permesso di esecuzione in ciascuna delle directory che compongono
1138 il pathname, e lo stesso vale per aprire un file nella directory corrente (per
1139 la quale appunto serve il diritto di esecuzione).
1140
1141 Per una directory infatti il permesso di esecuzione ha il significato
1142 specifico che essa può essere attraversata nella risoluzione del pathname, ed
1143 è distinto dal permesso di lettura che invece implica che si può leggere il
1144 contenuto della directory. Questo significa che se si ha il permesso di
1145 esecuzione senza permesso di lettura si potrà lo stesso aprire un file in una
1146 directory (se si hanno i permessi opportuni per il medesimo) ma non si potrà
1147 vederlo con \cmd{ls} (per crearlo occorrerà anche il permesso di scrittura per
1148 la directory).
1149
1150 Avere il permesso di lettura per un file consente di aprirlo con le opzioni di
1151 sola lettura (\macro{O\_RDONLY}) o di lettura/scrittura (\macro{O\_RDWR}) e
1152 leggerne il contenuto. Avere il permesso di scrittura consente di aprire un
1153 file in sola scrittura (\macro{O\_WRONLY}) o lettura/scrittura
1154 (\macro{O\_RDWR}) e modificarne il contenuto, lo stesso permesso è necessario
1155 per poter troncare il file con l'opzione \macro{O\_TRUNC}.
1156
1157 Non si può creare un file fintanto che non si disponga del permesso di
1158 esecuzione e di quello di scrittura per la directory di destinazione; gli
1159 stessi permessi occorrono per cancellare un file da una directory (si ricordi
1160 che questo non implica necessariamente la rimozione del contenuto del file dal
1161 disco), non è necessario nessun tipo di permesso per il file stesso (infatti
1162 esso non viene toccato, viene solo modificato il contenuto della directory,
1163 rimuovendo la voce che ad esso fa rifermento).
1164
1165 Per poter eseguire un file (che sia un programma compilato od uno script di
1166 shell, od un altro tipo di file eseguibile riconosciuto dal kernel), occorre
1167 avere il permesso di esecuzione, inoltre solo i file regolari possono essere
1168 eseguiti.
1169
1170 I permessi per un link simbolico sono ignorati, contano quelli del file a cui
1171 fa riferimento; per questo in genere \cmd{ls} per un link simbolico riporta
1172 tutti i permessi come concessi; utente e gruppo a cui esso appartiene vengono
1173 ignorati quando il link viene risolto, vengono controllati solo quando viene
1174 richiesta la rimozione del link e quest'ultimo è in una directory con lo
1175 \textsl{sticky bit} settato (si veda \secref{sec:file_sticky}).
1176
1177 La procedura con cui il kernel stabilisce se un processo possiede un certo
1178 permesso (di lettura, scrittura o esecuzione) si basa sul confronto fra
1179 l'utente e il gruppo a cui il file appartiene (i valori di \var{st\_uid} e
1180 \var{st\_gid} accennati in precedenza) e l'\textit{effective user id},
1181 l'\textit{effective group id} e gli eventuali \textit{supplementary group id}
1182 del processo\footnote{in realtà Linux per quanto riguarda l'accesso ai file
1183   utilizza al posto degli \textit{effective id} i \textit{filesystem id} (si
1184   veda \secref{sec:proc_perms}), ma essendo questi del tutto equivalenti ai
1185   primi, eccetto il caso in cui si voglia scrivere un server NFS, ignoreremo
1186   questa differenza}.
1187
1188 Per una spiegazione dettagliata degli identificatori associati ai processi si
1189 veda \secref{sec:proc_perms}; normalmente, a parte quanto vedremo in
1190 \secref{sec:file_suid_sgid}, l'\textit{effective user id} e
1191 l'\textit{effective group id} corrispondono a \acr{uid} e \acr{gid}
1192 dell'utente che ha lanciato il processo, mentre i \textit{supplementary group
1193   id} sono quelli dei gruppi cui l'utente appartiene.
1194
1195 I passi attraverso i quali viene stabilito se il processo possiede il diritto
1196 di accesso sono i seguenti:
1197 \begin{itemize}
1198 \item Se l'\textit{effective user id} del processo è zero (corrispondente
1199   all'amministratore) l'accesso è sempre garantito senza nessun ulteriore
1200   controllo. Per questo motivo \textsl{root} ha piena libertà di accesso a
1201   tutti i file.
1202 \item Se l'\textit{effective user id} del processo è uguale all'\acr{uid} del
1203   proprietario del file (nel qual caso si dice che il processo è proprietario
1204   del file) allora:
1205   \begin{itemize}
1206   \item se il relativo\footnote{per relativo si intende il bit di user-read se
1207       il processo vuole accedere in scrittura, quello di user-write per
1208       l'accesso in scrittura, etc.} bit dei permessi d'accesso dell'utente è
1209     settato, l'accesso è consentito
1210   \item altrimenti l'accesso è negato
1211   \end{itemize}
1212 \item Se l'\textit{effective group id} del processo o uno dei
1213   \textit{supplementary group id} dei processi corrispondono al \acr{gid} del
1214   file allora:
1215   \begin{itemize}
1216   \item se il bit dei permessi d'accesso del gruppo è settato, l'accesso è
1217     consentito, 
1218   \item altrimenti l'accesso è negato
1219   \end{itemize}
1220 \item se il bit dei permessi d'accesso per tutti gli altri è settato,
1221   l'accesso è consentito, altrimenti l'accesso è negato.
1222 \end{itemize}
1223
1224 Si tenga presente che questi passi vengono eseguiti esattamente in
1225 quest'ordine. Questo vuol dire che se un processo è il proprietario di un file
1226 l'accesso è consentito o negato solo sulla base dei permessi per l'utente; i
1227 permessi per il gruppo non vengono neanche controllati; lo stesso vale se il
1228 processo appartiene ad un gruppo appropriato, in questo caso i permessi per
1229 tutti gli altri non vengono controllati.
1230
1231
1232 \subsection{I bit \acr{suid} e \acr{sgid}}
1233 \label{sec:file_suid_sgid}
1234
1235 Come si è accennato (in \secref{sec:file_perm_overview}) nei dodici bit del
1236 campo \var{st\_mode} usati per il controllo di accesso oltre ai bit dei
1237 permessi veri e propri, ci sono altri tre bit che vengono usati per indicare
1238 alcune proprietà speciali dei file.  Due di questi sono i bit detti
1239 \acr{suid} (o \textit{set-user-ID bit}) e \acr{sgid} (o
1240 \textit{set-group-ID bit}) che sono identificati dalle costanti
1241 \macro{S\_ISUID} e \macro{S\_ISGID}.
1242
1243 Come spiegato in dettaglio in \secref{sec:proc_exec}, quando si lancia un
1244 programma il comportamento normale del kernel è quello di settare
1245 l'\textit{effective user id} e l'\textit{effective group id} del nuovo
1246 processo all'\acr{uid} e al \acr{gid} del processo corrente, che normalmente
1247 corrispondono dell'utente con cui si è entrati nel sistema.
1248
1249 Se però il file del programma\footnote{per motivi di sicurezza il kernel
1250   ignora i bit \acr{suid} e \acr{sgid} per gli script eseguibili} (che
1251 ovviamente deve essere eseguibile) ha il bit \acr{suid} settato, il kernel
1252 assegnerà come \textit{effective user id} al nuovo processo l'\acr{uid} del
1253 proprietario del file al posto dell'\acr{uid} del processo originario.  Avere
1254 il bit \acr{sgid} settato ha lo stesso effetto sull'\textit{effective group
1255   id} del processo.
1256
1257 I bit \acr{suid} e \acr{sgid} vengono usati per permettere agli utenti normali
1258 di usare programmi che abbisognano di privilegi speciali; l'esempio classico è
1259 il comando \cmd{passwd} che ha la necessità di modificare il file delle
1260 password, quest'ultimo ovviamente può essere scritto solo dall'amministratore,
1261 ma non è necessario chiamare l'amministratore per cambiare la propria
1262 password. Infatti il comando \cmd{passwd} appartiene a root ma ha il bit
1263 \acr{suid} settato per cui quando viene lanciato da un utente normale parte
1264 con i privilegi di root.
1265
1266 Chiaramente avere un processo che ha privilegi superiori a quelli che avrebbe
1267 normalmente l'utente che lo ha lanciato comporta vari rischi, e questo tipo di
1268 programmi devono essere scritti accuratamente per evitare che possano essere
1269 usati per guadagnare privilegi non consentiti (torneremo sull'argomento in
1270 \secref{sec:proc_perms}).
1271
1272 La presenza dei bit \acr{suid} e \acr{sgid} su un file può essere
1273 rilevata con il comando \cmd{ls -l}, in tal caso comparirà la lettera \cmd{s}
1274 al posto della \cmd{x} in corrispondenza dei permessi di utente o gruppo. La
1275 stessa lettera \cmd{s} può essere usata nel comando \cmd{chmod} per settare
1276 questi bit. Infine questi bit possono essere controllati all'interno di
1277 \var{st\_mode} con l'uso delle due costanti \macro{S\_ISUID} e
1278 \macro{S\_IGID}, i cui valori sono riportati in
1279 \tabref{tab:file_mode_flags}.
1280
1281 Gli stessi bit vengono ad assumere in significato completamente diverso per le
1282 directory, normalmente infatti Linux usa la convenzione di SVR4 per indicare
1283 con questi bit l'uso della semantica BSD nella creazione di nuovi file (si
1284 veda \secref{sec:file_ownership} per una spiegazione dettagliata al
1285 proposito).
1286
1287 Infine Linux utilizza il bit \acr{sgid} per una ulteriore estensione
1288 mutuata da SVR4. Il caso in cui il file abbia il bit \acr{sgid} settato ma
1289 non il corrispondente bit di esecuzione viene utilizzato per attivare per
1290 quel file il \textit{mandatory locking} (argomento che affronteremo nei
1291 dettagli in \secref{sec:file_mand_locking}).
1292
1293
1294 \subsection{Il bit \textsl{sticky}}
1295 \label{sec:file_sticky}
1296
1297 L'ultimo dei bit rimanenti, identificato dalla costante \macro{S\_ISVTX}, è in
1298 parte un rimasuglio delle origini dei sistemi unix. A quell'epoca infatti la
1299 memoria virtuale e l'accesso ai files erano molto meno sofisticati e per
1300 ottenere la massima velocità possibile per i programmi usati più comunemente
1301 si poteva settare questo bit.
1302
1303 L'effetto di questo bit era che il segmento di testo del programma (si veda
1304 \secref{sec:proc_mem_layout} per i dettagli) veniva scritto nella swap la
1305 prima volta che questo veniva lanciato, e vi permaneva fino al riavvio della
1306 macchina (da questo il nome di \textsl{sticky bit}); essendo la swap un file
1307 continuo indicizzato direttamente in questo modo si poteva risparmiare in
1308 tempo di caricamento rispetto alla ricerca del file su disco. Lo
1309 \textsl{sticky bit} è indicato usando la lettera \cmd{t} al posto della
1310 \cmd{x} nei permessi per gli altri.
1311
1312 Ovviamente per evitare che gli utenti potessero intasare la swap solo
1313 l'amministratore era in grado di settare questo bit, che venne chiamato anche
1314 con il nome di \textit{saved text bit}, da cui deriva quello della costante.
1315 Le attuali implementazioni di memoria virtuale e filesystem rendono
1316 sostanzialmente inutile questo procedimento.
1317
1318 Benché ormai non venga più utilizzato per i file, lo \textsl{sticky bit} ha
1319 assunto un uso corrente per le directory\footnote{lo \textsl{sticky bit} per
1320   le directory è una estensione non definita nello standard POSIX, Linux però
1321   la supporta, così come BSD e SVR4}, in questo caso se il bit è settato un
1322 file potrà essere rimosso dalla directory soltanto se l'utente ha il permesso
1323 di scrittura ed inoltre è vera una delle seguenti condizioni:
1324 \begin{itemize}
1325 \item l'utente è proprietario del file
1326 \item l'utente è proprietario della directory
1327 \item l'utente è l'amministratore 
1328 \end{itemize}
1329 un classico esempio di directory che ha questo bit settato è \file{/tmp}, i
1330 permessi infatti di solito sono settati come:
1331 \begin{verbatim}
1332 $ ls -ld /tmp
1333 drwxrwxrwt    6 root     root         1024 Aug 10 01:03 /tmp
1334 \end{verbatim}%$
1335 in questo modo chiunque può leggere, scrivere ed eseguire i file temporanei
1336 ivi memorizzati, sia crearne di nuovi, ma solo l'utente che ha creato un file
1337 nella directory potrà cancellarlo o rinominarlo, così si può evitare che un
1338 utente possa, più o meno consapevolmente, cancellare i file degli altri.
1339
1340
1341 \subsection{La titolarità di nuovi file e directory}
1342 \label{sec:file_ownership}
1343
1344 Vedremo in \secref{sec:file_base_func} come creare nuovi file, ma se è
1345 possibile specificare in sede di creazione quali permessi applicare ad un
1346 file, non si può indicare a quale utente e gruppo esso deve appartenere.  Lo
1347 stesso problema di presenta per la creazione di nuove directory (procedimento
1348 descritto in \secref{sec:file_dir_creat_rem}).
1349
1350 Lo standard POSIX prescrive che l'\acr{uid} del nuovo file corrisponda
1351 all'\textit{effective user id} del processo che lo crea; per il \acr{gid}
1352 invece prevede due diverse possibilità:
1353 \begin{itemize}
1354 \item il \acr{gid} del file corrisponde all'\textit{effective group id} del
1355   processo.
1356 \item il \acr{gid} del file corrisponde al \acr{gid} della directory in cui
1357   esso è creato.
1358 \end{itemize}
1359 in genere BSD usa sempre la seconda possibilità, che viene per questo chiamata
1360 semantica BSD. Linux invece segue quella che viene chiamata semantica SVr4; di
1361 norma cioè il nuovo file viene creato, seguendo la prima opzione, con il
1362 \acr{gid} del processo, se però la directory in cui viene creato il file ha il
1363 bit \acr{sgid} settato allora viene usata la seconda opzione.
1364
1365 Usare la semantica BSD ha il vantaggio che il \acr{gid} viene sempre
1366 automaticamente propagato, restando coerente a quello della directory di
1367 partenza, in tutte le sottodirectory. La semantica SVR4 offre una maggiore
1368 possibilità di scelta, ma per ottenere lo stesso risultato necessita che per
1369 le nuove directory venga anche propagato anche il bit \acr{sgid}. Questo è
1370 comunque il comportamento di default di \func{mkdir}, ed é in questo modo ad
1371 esempio che Debian assicura che le sottodirectory create nelle home di un
1372 utente restino sempre con il \acr{gid} del gruppo primario dello stesso.
1373
1374
1375 \subsection{La funzione \func{access}}
1376 \label{sec:file_access}
1377
1378 Come detto in \secref{sec:file_access_control} il controllo di accesso ad
1379 un file viene fatto usando \textit{effective user id} e \textit{effective
1380   group id} del processo, ma ci sono casi in cui si può voler effettuare il
1381 controllo usando il \textit{real user id} e il \textit{real group id} (cioè
1382 l'\acr{uid} dell'utente che ha lanciato il programma, che, come accennato in
1383 \secref{sec:file_suid_sgid} e spiegato in \secref{sec:proc_perms} non è
1384 detto sia uguale all'\textit{effective user id}). Per far questo si può usare
1385 la funzione \func{access}, il cui prototipo è:
1386 \begin{prototype}{unistd.h}
1387 {int access(const char *pathname, int mode)}
1388
1389   La funzione verifica i permessi di accesso, indicati da \var{mode}, per il
1390   file indicato da \var{pathname}. 
1391   
1392   La funzione ritorna 0 se l'accesso è consentito, -1 altrimenti; in
1393   quest'ultimo caso la variabile \var{errno} viene settata secondo i codici
1394   di errore: \macro{EACCES}, \macro{EROFS}, \macro{EFAULT}, \macro{EINVAL},
1395   \macro{ENAMETOOLONG}, \macro{ENOENT}, \macro{ENOTDIR}, \macro{ELOOP},
1396   \macro{EIO}.
1397 \end{prototype}
1398
1399 I valori possibili per il parametro \var{mode} sono esprimibili come
1400 combinazione delle costanti numeriche riportate in \ntab\ (attraverso un OR
1401 binario). I primi tre valori implicano anche la verifica dell'esistenza del
1402 file, se si vuole verificare solo quest'ultima si può usare \macro{F\_OK}, o
1403 anche direttamente \func{stat}. In caso \var{pathname} si riferisca ad un link
1404 simbolico il controllo è fatto sul file a cui esso fa riferimento.
1405
1406 La funzione controlla solo i bit dei permessi di accesso, si ricordi che il
1407 fatto che una directory abbia permesso di scrittura non significa che ci si
1408 possa scrivere come in un file, e il fatto che un file abbia permesso di
1409 esecuzione non comporta che contenga un programma eseguibile. La funzione
1410 ritorna zero solo se tutte i permessi controllati sono disponibili, in caso
1411 contrario (o di errore) ritorna -1.
1412 \begin{table}[htb]
1413   \centering
1414   \footnotesize
1415   \begin{tabular}{|c|l|}
1416     \hline
1417     \textbf{\var{mode}} & \textbf{Significato} \\
1418     \hline
1419     \hline
1420     \macro{R\_OK} & verifica il permesso di lettura \\
1421     \macro{W\_OK} & verifica il permesso di scritture \\
1422     \macro{X\_OK} & verifica il permesso di esecuzione \\
1423     \macro{F\_OK} & verifica l'esistenza del file \\
1424     \hline
1425   \end{tabular}
1426   \caption{Valori possibile per il parametro \var{mode} della funzione 
1427     \func{access}}
1428   \label{tab:file_access_mode_val}
1429 \end{table}
1430
1431 Un esempio tipico per l'uso di questa funzione è quello di un processo che sta
1432 eseguendo un programma coi privilegi di un altro utente (attraverso l'uso del
1433 \acr{suid} bit) che vuole controllare se l'utente originale ha i permessi per
1434 accedere ad un certo file.
1435
1436
1437 \subsection{Le funzioni \func{chmod} e \func{fchmod}}
1438 \label{sec:file_chmod}
1439
1440 Per cambiare i permessi di un file il sistema mette ad disposizione due
1441 funzioni, che operano rispettivamente su un filename e su un file descriptor,
1442 i loro prototipi sono:
1443 \begin{functions}
1444   \headdecl{sys/types.h} 
1445   \headdecl{sys/stat.h} 
1446   
1447   \funcdecl{int chmod(const char *path, mode\_t mode)} Cambia i permessi del
1448   file indicato da \var{path} al valore indicato da \var{mode}.
1449   
1450   \funcdecl{int fchmod(int fd, mode\_t mode)} Analoga alla precedente, ma usa
1451   il file descriptor \var{fd} per indicare il file.
1452   
1453   Le funzioni restituiscono zero in caso di successo e -1 per un errore, in
1454   caso di errore \var{errno} può assumere i valori:
1455   \begin{errlist}
1456   \item \macro{EPERM} L'\textit{effective user id} non corrisponde a quello
1457     del proprietario del file o non è zero.
1458   \end{errlist}
1459   ed inoltre \macro{EROFS} e \macro{EIO}; \func{chmod} restituisce anche
1460   \macro{EFAULT}, \macro{ENAMETOOLONG}, \macro{ENOENT}, \macro{ENOMEM},
1461   \macro{ENOTDIR}, \macro{EACCES}, \macro{ELOOP}; \func{fchmod} anche
1462   \macro{EBADF}.
1463 \end{functions}
1464
1465 I valori possibili per \var{mode} sono indicati in \ntab. I valori possono
1466 esser combinati con l'OR binario delle relative costanti simboliche, o
1467 specificati direttamente, come per l'analogo comando di shell, con il valore
1468 numerico (la shell lo vuole in ottale, dato che i bit dei permessi sono
1469 divisibili in gruppi di tre). Ad esempio i permessi standard assegnati ai
1470 nuovi file (lettura e scrittura per il proprietario, sola lettura per il
1471 gruppo e gli altri) sono corrispondenti al valore ottale $0644$, un programma
1472 invece avrebbe anche il bit di esecuzione attivo, con un valore di $0755$, se
1473 si volesse attivare il bit \acr{suid} il valore da fornire sarebbe $4755$.
1474
1475 \begin{table}[!htb]
1476   \centering
1477   \footnotesize
1478   \begin{tabular}[c]{|c|c|l|}
1479     \hline
1480     \textbf{\var{mode}} & \textbf{Valore} & \textbf{Significato} \\
1481     \hline
1482     \hline
1483     \macro{S\_ISUID} & 04000 & set user ID \\
1484     \macro{S\_ISGID} & 02000 & set group ID \\
1485     \macro{S\_ISVTX} & 01000 & sticky bit \\
1486     \hline
1487     \macro{S\_IRWXU} & 00700 & l'utente ha tutti i permessi \\
1488     \macro{S\_IRUSR} & 00400 & l'utente ha il permesso di lettura  \\
1489     \macro{S\_IWUSR} & 00200 & l'utente ha il permesso di scrittura \\
1490     \macro{S\_IXUSR} & 00100 & l'utente ha il permesso di esecuzione \\
1491     \hline
1492     \macro{S\_IRWXG} & 00070 & il gruppo ha tutti i permessi  \\
1493     \macro{S\_IRGRP} & 00040 & il gruppo ha il permesso di lettura  \\
1494     \macro{S\_IWGRP} & 00020 & il gruppo ha il permesso di scrittura \\
1495     \macro{S\_IXGRP} & 00010 & il gruppo ha il permesso di esecuzione \\
1496     \hline
1497     \macro{S\_IRWXO} & 00007 & gli altri hanno tutti i permessi \\
1498     \macro{S\_IROTH} & 00004 & gli altri hanno il permesso di lettura  \\
1499     \macro{S\_IWOTH} & 00002 & gli altri hanno il permesso di scrittura \\
1500     \macro{S\_IXOTH} & 00001 & gli altri hanno il permesso di esecuzione \\
1501     \hline
1502   \end{tabular}
1503   \caption{I valori delle costanti usate per indicare i permessi dei file.}
1504   \label{tab:file_permission_const}
1505 \end{table}
1506
1507 Il cambiamento dei permessi di un file attraverso queste funzioni ha comunque
1508 alcune limitazioni, provviste per motivi di sicurezza. Questo significa che
1509 anche se si è proprietari del file non tutte le operazioni sono permesse, in
1510 particolare:
1511 \begin{itemize}
1512 \item siccome solo l'amministratore può settare lo \textit{sticky bit}; se
1513   l'\textit{effective user id} del processo non è zero esso viene
1514   automaticamente cancellato (senza notifica di errore) qualora sia stato
1515   indicato in \var{mode}.
1516 \item per via della semantica SVR4 nella creazione dei nuovi file, si può
1517   avere il caso in cui il file creato da un processo è assegnato a un gruppo
1518   per il quale il processo non ha privilegi. Per evitare che si possa
1519   assegnare il bit \acr{sgid} ad un file appartenente a un gruppo per cui
1520   non si hanno diritti, questo viene automaticamente cancellato (senza
1521   notifica di errore) da \var{mode} qualora il gruppo del file non corrisponda
1522   a quelli associati al processo (la cosa non avviene quando
1523   l'\textit{effective user id} del processo è zero).
1524 \end{itemize}
1525
1526 Per alcuni filesystem\footnote{il filesystem \acr{ext2} supporta questa
1527   caratteristica, che è mutuata da BSD.} è inoltre prevista una ulteriore
1528 misura di sicurezza, volta ad scongiurare l'abuso dei bit \acr{suid} e
1529 \acr{sgid}; essa consiste nel cancellare automaticamente questi bit qualora un
1530 processo che non appartenga all'amministratore scriva su un file. In questo
1531 modo anche se un utente malizioso scopre un file \acr{suid} su cui può
1532 scrivere, un eventuale modifica comporterà la perdita di ogni ulteriore
1533 privilegio.
1534
1535 \subsection{La funzione \func{umask}}
1536 \label{sec:file_umask}
1537
1538 Oltre che dai valori indicati in sede di creazione, i permessi assegnati ai
1539 nuovi file sono controllati anche da una maschera di bit settata con la
1540 funzione \func{umask}, il cui prototipo è:
1541 \begin{prototype}{stat.h}
1542 {mode\_t umask(mode\_t mask)}
1543
1544   Setta la maschera dei permessi dei bit al valore specificato da \var{mask}
1545   (di cui vengono presi solo i 9 bit meno significativi).
1546   
1547   La funzione ritorna il precedente valore della maschera. È una delle poche
1548   funzioni che non restituisce codici di errore.
1549 \end{prototype}
1550
1551 Questa maschera è una caratteristica di ogni processo e viene utilizzata per
1552 impedire che alcuni permessi possano essere assegnati ai nuovi file in sede di
1553 creazione, i bit indicati nella maschera vengono infatti esclusi quando un
1554 nuovo file viene creato.
1555
1556 In genere questa maschera serve per impostare un default che escluda alcuni
1557 permessi (usualmente quello di scrittura per il gruppo e gli altri,
1558 corrispondente ad un valore di $022$). Essa è utile perché le routine
1559 dell'interfaccia ANSI C degli stream non prevedono l'esistenza dei permessi, e
1560 pertanto tutti i nuovi file vengono sempre creati con un default di $666$
1561 (cioè permessi di lettura e scrittura per tutti, si veda
1562 \tabref{tab:file_permission_const} per un confronto); in questo modo è
1563 possibile cancellare automaticamente i permessi non voluti, senza doverlo fare
1564 esplicitamente.
1565
1566 In genere il valore di \func{umask} viene stabilito una volta per tutte al
1567 login a $022$, e di norma gli utenti non hanno motivi per modificarlo. Se però
1568 si vuole che un processo possa creare un file che chiunque possa leggere
1569 allora occorrerà cambiare il valore di \func{umask}.
1570
1571 \subsection{Le funzioni \func{chown}, \func{fchown} e \func{lchown}}
1572 \label{sec:file_chown}
1573
1574 Come per i permessi, il sistema fornisce anche delle funzioni che permettano
1575 di cambiare utente e gruppo cui il file appartiene; le funzioni in questione
1576 sono tre e i loro prototipi sono i seguenti:
1577 \begin{functions}
1578   \headdecl{sys/types.h} 
1579   \headdecl{sys/stat.h} 
1580   
1581   \funcdecl{int chown(const char *path, uid\_t owner, gid\_t group)}
1582   \funcdecl{int fchown(int fd, uid\_t owner, gid\_t group)}
1583   \funcdecl{int lchown(const char *path, uid\_t owner, gid\_t group)}
1584
1585   Le funzioni cambiano utente e gruppo di appartenenza di un file ai valori
1586   specificati dalle variabili \var{owner} e \var{group}. 
1587
1588   Le funzioni restituiscono zero in caso di successo e -1 per un errore, in
1589   caso di errore \texttt{errno} viene settato ai valori:
1590   \begin{errlist}
1591   \item \macro{EPERM} L'\textit{effective user id} non corrisponde a quello
1592     del proprietario del file o non è zero, o utente e gruppo non sono validi
1593   \end{errlist}
1594   Oltre a questi entrambe restituiscono gli errori \macro{EROFS} e
1595   \macro{EIO}; \func{chown} restituisce anche \macro{EFAULT},
1596   \macro{ENAMETOOLONG}, \macro{ENOENT}, \macro{ENOMEM}, \macro{ENOTDIR},
1597   \macro{EACCES}, \macro{ELOOP}; \func{fchown} anche \macro{EBADF}.
1598 \end{functions}
1599
1600 In Linux soltanto l'amministratore può cambiare il proprietario di un file,
1601 seguendo la semantica di BSD che non consente agli utenti di assegnare i loro
1602 file ad altri (per evitare eventuali aggiramenti delle quote).
1603 L'amministratore può cambiare il gruppo di un file, il proprietario può
1604 cambiare il gruppo dei file che gli appartengono solo se il nuovo gruppo è il
1605 suo gruppo primario o uno dei gruppi a cui appartiene.
1606
1607 La funzione \func{chown} segue i link simbolici, per operare direttamente su
1608 in link simbolico si deve usare la funzione \func{lchown}\footnote{fino alla
1609   versione 2.1.81 in Linux \func{chown} non seguiva i link simbolici, da
1610   allora questo comportamento è stato assegnato alla funzione \func{lchown},
1611   introdotta per l'occasione, ed è stata creata una nuova system call per
1612   \func{chown} che seguisse i link simbolici}. La funzione \func{fchown} opera
1613 su un file aperto, essa è mutuata da BSD, ma non è nello standard POSIX.
1614 Un'altra estensione rispetto allo standard POSIX è che specificando -1 come
1615 valore per \var{owner} e \var{group} i valori restano immutati. 
1616
1617 Quando queste funzioni sono chiamate con successo da un processo senza i
1618 privilegi di root entrambi i bit \acr{suid} e \acr{sgid} vengono
1619 cancellati. Questo non avviene per il bit \acr{sgid} nel caso in cui esso
1620 sia usato (in assenza del corrispondente permesso di esecuzione) per indicare
1621 che per il file è attivo il \textit{mandatory locking}.
1622
1623 %La struttura fondamentale che contiene i dati essenziali relativi ai file è il
1624 %cosiddetto \textit{inode}; questo conterrà informazioni come il
1625 %tipo di file (file di dispositivo, directory, file di dati, per un elenco
1626 %completo vedi \ntab), i permessi (vedi \secref{sec:file_perms}), le date (vedi
1627 %\secref{sec:file_times}).
1628
1629