Altre indicizzazioni, e inizio di readdir

[gapil.git] / filedir.tex

diff --git a/filedir.tex b/filedir.tex
index 9b4025ec5606dcc71bfb89e66bd2d6addf3d4be0..5b3b0b51fba8491109cb45ddca066d348e5fa48b 100644 (file)
--- a/filedir.tex
+++ b/filedir.tex
@@ -515,7 +515,7 @@ per creare una directory 
 \end{functions}
 
 La funzione crea una nuova directory vuota, che contiene cioè solo le due voci
 \end{functions}
 
 La funzione crea una nuova directory vuota, che contiene cioè solo le due voci

-standard \file{.} e \file{..}, con il nome indicato dall'argomento
+standard (\file{.} e \file{..}), con il nome indicato dall'argomento

 \param{dirname}. Il nome può essere indicato sia come pathname assoluto che
 relativo.
 
 \param{dirname}. Il nome può essere indicato sia come pathname assoluto che
 relativo.
 


@@ -642,9 +642,11 @@ Per creare una fifo (un file speciale, su cui torneremo in dettaglio in
     \errval{EEXIST}, \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOSPC},
     \errval{ENOTDIR} e \errval{EROFS}.}
 \end{functions}
     \errval{EEXIST}, \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOSPC},
     \errval{ENOTDIR} e \errval{EROFS}.}
 \end{functions}

-\noindent come per \func{mknod} il file \param{pathname} non deve esistere
-(neanche come link simbolico); al solito i permessi specificati da
-\param{mode} vengono modificati dal valore di \var{umask}.
+
+La funzione crea la fifo \param{pathname} con i permessi \param{mode}. Come
+per \func{mknod} il file \param{pathname} non deve esistere (neanche come link
+simbolico); al solito i permessi specificati da \param{mode} vengono
+modificati dal valore di \var{umask}.

 
 
 
 
 
 


@@ -652,22 +654,22 @@ Per creare una fifo (un file speciale, su cui torneremo in dettaglio in
 \label{sec:file_dir_read}
 
 Benché le directory siano oggetti del filesystem come tutti gli altri non ha
 \label{sec:file_dir_read}
 
 Benché le directory siano oggetti del filesystem come tutti gli altri non ha

-senso aprirle come fossero dei file di dati. Inoltre si 
-
- Può però essere utile poterne
-leggere il contenuto ad esempio per fare la lista dei file che esse contengono
-o ricerche sui medesimi. Solo il kernel può scrivere direttamente il contenuto
-di una directory (onde evitare inconsistenze all'interno del filesystem), i
-processi devono creare i file usando le apposite funzioni.
-
-Per accedere al contenuto delle directory si usano i cosiddetti
-\textit{directory streams} (chiamati così per l'analogia con i file stream di
-\capref{cha:files_std_interface}); la funzione \funcd{opendir} apre uno di
-questi stream, il suo prototipo è:
+senso aprirle come fossero dei file di dati; per questo solo il kernel può
+scrivere direttamente il contenuto di una directory (onde evitare
+inconsistenze all'interno del filesystem), mentre i processi devono creare i
+file usando le apposite funzioni. Può però essere utile potere leggere il
+contenuto di una directory, ad esempio per fare la lista dei file che contiene
+o per delle ricerche.
+
+Per far questo lo standard POSIX\footnote{le funzioni sono previste pure in
+  BSD e SVID.} ha introdotto i cosiddetti \textit{directory streams} (chiamati
+così per l'analogia con i file stream di \capref{cha:files_std_interface}) ed
+una serie di funzioni per la loro gestione. La prima di queste è
+\funcd{opendir}, il cui prototipo è:

 \begin{functions}
   \headdecl{sys/types.h} \headdecl{dirent.h} 
   
 \begin{functions}
   \headdecl{sys/types.h} \headdecl{dirent.h} 
   

-  \funcdecl{DIR * opendir(const char *name)} 
+  \funcdecl{DIR * opendir(const char *dirname)} 

   
   Apre un \textit{directory stream}.
   
   
   Apre un \textit{directory stream}.
   


@@ -677,13 +679,16 @@ questi stream, il suo prototipo 
     \errval{ENOENT}, \errval{ENOMEM} e \errval{ENOTDIR}.}
 \end{functions}
 
     \errval{ENOENT}, \errval{ENOMEM} e \errval{ENOTDIR}.}
 \end{functions}
 

-La funzione apre un \textit{directory stream} per la directory indicata da
-\param{name}, ritornando il puntatore allo stesso, e posizionandosi sulla
-prima voce della directory. 
+La funzione apre un \textit{directory stream} per la directory
+\param{dirname}, ritornando il puntatore alla relativa struttura \type{DIR}
+(questo è un tipo opaco\index{tipo!opaco} usato dalle librerie per gestire i
+\textit{directory stream}) da usare per le successive operazioni, infine
+posiziona lo stream sulla prima voce contenuta nella directory.

 
 Dato che le directory sono comunque dei file, in alcuni casi può essere utile
 
 Dato che le directory sono comunque dei file, in alcuni casi può essere utile

-conoscere il file descriptor sottostante un \textit{directory stream}, ad
-esempio per utilizzarlo con la funzione \func{fchdir} per cambiare la
+conoscere il \textit{file descriptor} (tratteremo dei \textit{file descriptor}
+in \capref{cha:file_unix_interface}) sottostante un \textit{directory stream},
+ad esempio per utilizzarlo con la funzione \func{fchdir} per cambiare la

 directory di lavoro (vedi \secref{sec:file_work_dir}) a quella relativa allo
 stream che si è aperto. A questo scopo si può usare la funzione \funcd{dirfd},
 il cui prototipo è:
 directory di lavoro (vedi \secref{sec:file_work_dir}) a quella relativa allo
 stream che si è aperto. A questo scopo si può usare la funzione \funcd{dirfd},
 il cui prototipo è:


@@ -698,19 +703,34 @@ il cui prototipo 
     caso di successo e -1 in caso di errore.}
 \end{functions}
 
     caso di successo e -1 in caso di errore.}
 \end{functions}
 

-La funzione\footnote{questa funzione è una estensione di BSD introdotta con
-  BSD 4.3-Reno; è presente in Linux con le libc5 (a partire dalla versione
-  5.1.2) e con le \acr{glibc}.} restituisce il file descriptor associato al
-\textit{directory stream} \param{dir}, essa è disponibile solo definendo
-\macro{\_BSD\_SOURCE} o \macro{\_SVID\_SOURCE}.
-
-
+La funzione\footnote{questa funzione è una estensione di BSD non presente in
+  POSIX, introdotta con BSD 4.3-Reno; è presente in Linux con le libc5 (a
+  partire dalla versione 5.1.2) e con le \acr{glibc}.} restituisce il file
+descriptor associato al \textit{directory stream} \param{dir}, essa è
+disponibile solo definendo \macro{\_BSD\_SOURCE} o \macro{\_SVID\_SOURCE}.

 
 

-La funzione \func{readdir} legge il contenuto della directory, i cui elementi
-sono le \textit{directory entry} (da distinguersi da quelle della cache di cui
-parlavamo in \secref{sec:file_vfs}) in un'opportuna struttura \struct{dirent}
-definita in \figref{fig:file_dirent_struct}.
+La lettura di una voce nella directory viene effettuata attraverso la funzione
+\funcd{readdir}; il suo prototipo è:
+\begin{functions}
+  \headdecl{sys/types.h} \headdecl{dirent.h} 
+  
+  \funcdecl{struct dirent *readdir(DIR *dir)}
+  
+  Legge una voce dal \textit{directory stream}.
+  
+  \bodydesc{La funzione restituisce il puntatore alla struttura contentente i
+    dati in caso di successo e \val{NULL} altrimenti, nel qual caso
+    \var{errno} assumerà il valore \errval{EBADF}.}
+\end{functions}

 
 

+La funzione legge una voce dalla directory \textit{directory
+  entry},\footnote{anche questa viene chiamata anche se non ha nulla a che
+  fare con le omonime \textit{directory entry} di cui parlavamo in
+  \secref{sec:file_vfs}).} in un'opportuna struttura \struct{dirent}, la cui
+definizione è riportata in \figref{fig:file_dirent_struct}, che contiene i
+dati relativi al file cui la voce fa riferimento. Si tenga presente che la
+struttura viene sovrascritta tutte le volte che si ripete una lettura sullo
+stesso \textit{directory stream}.

 
 \begin{figure}[!htb]
   \footnotesize
 
 \begin{figure}[!htb]
   \footnotesize


@@ -718,10 +738,11 @@ definita in \figref{fig:file_dirent_struct}.
   \begin{minipage}[c]{15cm}
     \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
 struct dirent {
   \begin{minipage}[c]{15cm}
     \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
 struct dirent {

-    ino_t d_ino;
-    unsigned short int d_reclen;
-    unsigned char d_type;
-    char d_name[256];           /* We must not include limits.h! */
+    ino_t d_ino;                  /* inode number */
+    off_t d_off;                  /* offset to the next dirent */
+    unsigned short int d_reclen;  /* length of this record */
+    unsigned char d_type;         /* type of file */
+    char d_name[256];             /* We must not include limits.h! */

 };
     \end{lstlisting}
   \end{minipage} 
 };
     \end{lstlisting}
   \end{minipage} 


@@ -733,6 +754,19 @@ struct dirent {
 
 
 
 
 
 

+Una volta completate le operazioni si può chiudere il \textit{directory
+  stream} con la funzione \funcd{closedir}, il cui prototipo è:
+\begin{functions}
+  \headdecl{sys/types.h} \headdecl{dirent.h} 
+  
+  \funcdecl{int closedir(DIR * dir)} 
+  
+  Chiude un \textit{directory stream}.
+  
+  \bodydesc{La funzione restituisce 0 in caso di successo e -1 altrimenti, nel
+    qual caso \var{errno} assume il valore \errval{EBADF}.}
+\end{functions}
+

 
 \subsection{La directory di lavoro}
 \label{sec:file_work_dir}
 
 \subsection{La directory di lavoro}
 \label{sec:file_work_dir}


@@ -752,11 +786,9 @@ directory corrente di qualunque comando da essa lanciato.
 
 In genere il kernel tiene traccia per ciascun processo dell'inode\index{inode}
 della directory di lavoro corrente, per ottenere il pathname occorre usare una
 
 In genere il kernel tiene traccia per ciascun processo dell'inode\index{inode}
 della directory di lavoro corrente, per ottenere il pathname occorre usare una

-apposita funzione di libreria, \func{getcwd}, il cui prototipo è:
+apposita funzione di libreria, \funcd{getcwd}, il cui prototipo è:

 \begin{prototype}{unistd.h}{char *getcwd(char *buffer, size\_t size)}
 \begin{prototype}{unistd.h}{char *getcwd(char *buffer, size\_t size)}

-  Restituisce il filename completo della directory di lavoro corrente nella
-  stringa puntata da \param{buffer}, che deve essere precedentemente allocata,
-  per una dimensione massima di \param{size}.
+  Legge il pathname della directory di lavoro corrente.

   
   \bodydesc{La funzione restituisce il puntatore \param{buffer} se riesce,
     \val{NULL} se fallisce, in quest'ultimo caso la variabile
   
   \bodydesc{La funzione restituisce il puntatore \param{buffer} se riesce,
     \val{NULL} se fallisce, in quest'ultimo caso la variabile


@@ -772,15 +804,19 @@ apposita funzione di libreria, \func{getcwd}, il cui prototipo 
   \end{errlist}}
 \end{prototype}
 
   \end{errlist}}
 \end{prototype}
 

-Il buffer deve essere sufficientemente lungo da poter contenere il pathname
+La funzione restituisce il pathname completo della directory di lavoro
+corrente nella stringa puntata da \param{buffer}, che deve essere
+precedentemente allocata, per una dimensione massima di \param{size}.  Il
+buffer deve essere sufficientemente lungo da poter contenere il pathname

 completo più lo zero di terminazione della stringa. Qualora esso ecceda le
 completo più lo zero di terminazione della stringa. Qualora esso ecceda le

-dimensioni specificate con \param{size} la funzione restituisce un errore.  Si
-può anche specificare un puntatore nullo come \param{buffer},\footnote{questa è
-  un'estensione allo standard POSIX.1, supportata da Linux.} nel qual caso la
-stringa sarà allocata automaticamente per una dimensione pari a \param{size}
-qualora questa sia diversa da zero, o della lunghezza esatta del pathname
-altrimenti. In questo caso ci si deve ricordare di disallocare la stringa una
-volta cessato il suo utilizzo.
+dimensioni specificate con \param{size} la funzione restituisce un errore. 
+
+Si può anche specificare un puntatore nullo come
+\param{buffer},\footnote{questa è un'estensione allo standard POSIX.1,
+  supportata da Linux.} nel qual caso la stringa sarà allocata automaticamente
+per una dimensione pari a \param{size} qualora questa sia diversa da zero, o
+della lunghezza esatta del pathname altrimenti. In questo caso ci si deve
+ricordare di disallocare la stringa una volta cessato il suo utilizzo.

 
 Di questa funzione esiste una versione \code{char *getwd(char *buffer)}
 fatta per compatibilità all'indietro con BSD, che non consente di specificare
 
 Di questa funzione esiste una versione \code{char *getwd(char *buffer)}
 fatta per compatibilità all'indietro con BSD, che non consente di specificare


@@ -800,7 +836,7 @@ risalendo all'indietro l'albero della directory, si perderebbe traccia di ogni
 passaggio attraverso eventuali link simbolici.
 
 Per cambiare la directory di lavoro corrente si può usare la funzione
 passaggio attraverso eventuali link simbolici.
 
 Per cambiare la directory di lavoro corrente si può usare la funzione

-\func{chdir} (equivalente del comando di shell \cmd{cd}) il cui nome sta
+\funcd{chdir} (equivalente del comando di shell \cmd{cd}) il cui nome sta

 appunto per \textit{change directory}, il suo prototipo è:
 \begin{prototype}{unistd.h}{int chdir(const char *pathname)} 
   Cambia la directory di lavoro corrente in \param{pathname}.
 appunto per \textit{change directory}, il suo prototipo è:
 \begin{prototype}{unistd.h}{int chdir(const char *pathname)} 
   Cambia la directory di lavoro corrente in \param{pathname}.


@@ -820,7 +856,7 @@ quale si hanno i permessi di accesso.
 
 Dato che anche le directory sono file, è possibile riferirsi ad esse anche
 tramite il file descriptor, e non solo tramite il filename, per fare questo si
 
 Dato che anche le directory sono file, è possibile riferirsi ad esse anche
 tramite il file descriptor, e non solo tramite il filename, per fare questo si

-usa \func{fchdir}, il cui prototipo è:
+usa \funcd{fchdir}, il cui prototipo è:

 \begin{prototype}{unistd.h}{int fchdir(int fd)} 
   Identica a \func{chdir}, ma usa il file descriptor \param{fd} invece del
   pathname.
 \begin{prototype}{unistd.h}{int fchdir(int fd)} 
   Identica a \func{chdir}, ma usa il file descriptor \param{fd} invece del
   pathname.


@@ -849,7 +885,7 @@ controllo e la creazione si ha giusto lo spazio per una possibile \textit{race
 
 Le \acr{glibc} provvedono varie funzioni per generare nomi di file temporanei,
 di cui si abbia certezza di unicità (al momento della generazione); la prima
 
 Le \acr{glibc} provvedono varie funzioni per generare nomi di file temporanei,
 di cui si abbia certezza di unicità (al momento della generazione); la prima

-di queste funzioni è \func{tmpnam} il cui prototipo è:
+di queste funzioni è \funcd{tmpnam} il cui prototipo è:

 \begin{prototype}{stdio.h}{char *tmpnam(char *string)}
   Restituisce il puntatore ad una stringa contente un nome di file valido e
   non esistente al momento dell'invocazione. 
 \begin{prototype}{stdio.h}{char *tmpnam(char *string)}
   Restituisce il puntatore ad una stringa contente un nome di file valido e
   non esistente al momento dell'invocazione. 


@@ -868,7 +904,7 @@ prefisso la directory specificata da \const{P\_tmpdir}.
 
 Di questa funzione esiste una versione rientrante, \func{tmpnam\_r}, che non
 fa nulla quando si passa \val{NULL} come parametro. Una funzione simile,
 
 Di questa funzione esiste una versione rientrante, \func{tmpnam\_r}, che non
 fa nulla quando si passa \val{NULL} come parametro. Una funzione simile,

-\func{tempnam}, permette di specificare un prefisso per il file
+\funcd{tempnam}, permette di specificare un prefisso per il file

 esplicitamente, il suo prototipo è:
 \begin{prototype}{stdio.h}{char *tempnam(const char *dir, const char *pfx)}
   Restituisce il puntatore ad una stringa contente un nome di file valido e
 esplicitamente, il suo prototipo è:
 \begin{prototype}{stdio.h}{char *tempnam(const char *dir, const char *pfx)}
   Restituisce il puntatore ad una stringa contente un nome di file valido e


@@ -904,7 +940,7 @@ queste funzioni occorre sempre aprire il nuovo file in modalit
 esistente.
 
 Per evitare di dovere effettuare a mano tutti questi controlli, lo standard
 esistente.
 
 Per evitare di dovere effettuare a mano tutti questi controlli, lo standard

-POSIX definisce la funzione \func{tempfile}, il cui prototipo è:
+POSIX definisce la funzione \funcd{tempfile}, il cui prototipo è:

 \begin{prototype}{stdio.h}{FILE *tmpfile (void)}
   Restituisce un file temporaneo aperto in lettura/scrittura.
   
 \begin{prototype}{stdio.h}{FILE *tmpfile (void)}
   Restituisce un file temporaneo aperto in lettura/scrittura.
   


@@ -927,10 +963,10 @@ funzione 
   condition}\index{race condition}.
 
 Alcune versioni meno recenti di Unix non supportano queste funzioni; in questo
   condition}\index{race condition}.
 
 Alcune versioni meno recenti di Unix non supportano queste funzioni; in questo

-caso si possono usare le vecchie funzioni \func{mktemp} e \func{mkstemp} che
+caso si possono usare le vecchie funzioni \funcd{mktemp} e \func{mkstemp} che

 modificano una stringa di input che serve da modello e che deve essere
 conclusa da 6 caratteri \code{X} che verranno sostituiti da un codice
 modificano una stringa di input che serve da modello e che deve essere
 conclusa da 6 caratteri \code{X} che verranno sostituiti da un codice

-unico. La prima delle due è analoga a \func{tmpnam} e genera un nome casuale,
+unico. La prima delle due è analoga a \funcd{tmpnam} e genera un nome casuale,

 il suo prototipo è:
 \begin{prototype}{stlib.h}{char *mktemp(char *template)}
   Genera un filename univoco sostituendo le \code{XXXXXX} finali di
 il suo prototipo è:
 \begin{prototype}{stlib.h}{char *mktemp(char *template)}
   Genera un filename univoco sostituendo le \code{XXXXXX} finali di


@@ -953,9 +989,7 @@ possibilit
 indovinare. Per tutti questi motivi la funzione è deprecata e non dovrebbe mai
 essere usata.
 
 indovinare. Per tutti questi motivi la funzione è deprecata e non dovrebbe mai
 essere usata.
 

-
-
-La seconda funzione, \func{mkstemp} è sostanzialmente equivalente a
+La seconda funzione, \funcd{mkstemp} è sostanzialmente equivalente a

 \func{tmpfile}, ma restituisce un file descriptor invece di uno stream; il suo
 prototipo è:
 \begin{prototype}{stlib.h}{int mkstemp(char *template)}
 \func{tmpfile}, ma restituisce un file descriptor invece di uno stream; il suo
 prototipo è:
 \begin{prototype}{stlib.h}{int mkstemp(char *template)}


@@ -982,7 +1016,7 @@ certezza di essere i soli utenti del file. I permessi sono impostati al valore
 
 In OpenBSD è stata introdotta un'altra funzione\footnote{introdotta anche in
   Linux a partire dalle \acr{glibc} 2.1.91.} simile alle precedenti,
 
 In OpenBSD è stata introdotta un'altra funzione\footnote{introdotta anche in
   Linux a partire dalle \acr{glibc} 2.1.91.} simile alle precedenti,

-\func{mkdtemp}, che crea una directory temporanea; il suo prototipo è:
+\funcd{mkdtemp}, che crea una directory temporanea; il suo prototipo è:

 \begin{prototype}{stlib.h}{char *mkdtemp(char *template)}
   Genera una directory temporaneo il cui nome è ottenuto sostituendo le
   \code{XXXXXX} finali di \param{template}.
 \begin{prototype}{stlib.h}{char *mkdtemp(char *template)}
   Genera una directory temporaneo il cui nome è ottenuto sostituendo le
   \code{XXXXXX} finali di \param{template}.


@@ -1410,7 +1444,7 @@ avr
 \label{sec:file_utime}
 
 I tempi di ultimo accesso e modifica possono essere cambiati usando la
 \label{sec:file_utime}
 
 I tempi di ultimo accesso e modifica possono essere cambiati usando la

-funzione \func{utime}, il cui prototipo è:
+funzione \funcd{utime}, il cui prototipo è:

 \begin{prototype}{utime.h}
 {int utime(const char *filename, struct utimbuf *times)} 
 
 \begin{prototype}{utime.h}
 {int utime(const char *filename, struct utimbuf *times)} 
 


@@ -1500,33 +1534,27 @@ Esistono varie estensioni a questo modello,\footnote{come le \textit{Access
   come il \textit{mandatory access control} di SE-Linux.} ma nella maggior
 parte dei casi il meccanismo standard è più che sufficiente a soddisfare tutte
 le necessità più comuni.  I tre permessi di base associati ad ogni file sono:
   come il \textit{mandatory access control} di SE-Linux.} ma nella maggior
 parte dei casi il meccanismo standard è più che sufficiente a soddisfare tutte
 le necessità più comuni.  I tre permessi di base associati ad ogni file sono:

-\begin{itemize*}
+\begin{itemize}

 \item il permesso di lettura (indicato con la lettera \texttt{r}, dall'inglese
   \textit{read}).
 \item il permesso di scrittura (indicato con la lettera \texttt{w},
   dall'inglese \textit{write}).
 \item il permesso di esecuzione (indicato con la lettera \texttt{x},
   dall'inglese \textit{execute}).
 \item il permesso di lettura (indicato con la lettera \texttt{r}, dall'inglese
   \textit{read}).
 \item il permesso di scrittura (indicato con la lettera \texttt{w},
   dall'inglese \textit{write}).
 \item il permesso di esecuzione (indicato con la lettera \texttt{x},
   dall'inglese \textit{execute}).

-\end{itemize*}
+\end{itemize}

 mentre i tre livelli su cui sono divisi i privilegi sono:
 mentre i tre livelli su cui sono divisi i privilegi sono:

-\begin{itemize*}
+\begin{itemize}

 \item i privilegi per l'utente proprietario del file.
 \item i privilegi per un qualunque utente faccia parte del gruppo cui
   appartiene il file.
 \item i privilegi per tutti gli altri utenti.
 \item i privilegi per l'utente proprietario del file.
 \item i privilegi per un qualunque utente faccia parte del gruppo cui
   appartiene il file.
 \item i privilegi per tutti gli altri utenti.

-\end{itemize*}
+\end{itemize}

 
 L'insieme dei permessi viene espresso con un numero a 12 bit; di questi i nove
 meno significativi sono usati a gruppi di tre per indicare i permessi base di
 lettura, scrittura ed esecuzione e sono applicati rispettivamente
 rispettivamente al proprietario, al gruppo, a tutti gli altri.
 
 
 L'insieme dei permessi viene espresso con un numero a 12 bit; di questi i nove
 meno significativi sono usati a gruppi di tre per indicare i permessi base di
 lettura, scrittura ed esecuzione e sono applicati rispettivamente
 rispettivamente al proprietario, al gruppo, a tutti gli altri.
 

-I restanti tre bit (noti come \acr{suid}, \acr{sgid}, e \textsl{sticky}) sono
-usati per indicare alcune caratteristiche più complesse del meccanismo del
-controllo di accesso su cui torneremo in seguito (in
-\secref{sec:file_suid_sgid} e \secref{sec:file_sticky}); lo schema di
-allocazione dei bit è riportato in \figref{fig:file_perm_bit}.
-

 \begin{figure}[htb]
   \centering
   \includegraphics[width=6cm]{img/fileperm}
 \begin{figure}[htb]
   \centering
   \includegraphics[width=6cm]{img/fileperm}


@@ -1535,6 +1563,12 @@ allocazione dei bit 
   \label{fig:file_perm_bit}
 \end{figure}
 
   \label{fig:file_perm_bit}
 \end{figure}
 

+I restanti tre bit (noti come \acr{suid}, \acr{sgid}, e \textsl{sticky}) sono
+usati per indicare alcune caratteristiche più complesse del meccanismo del
+controllo di accesso su cui torneremo in seguito (in
+\secref{sec:file_suid_sgid} e \secref{sec:file_sticky}); lo schema di
+allocazione dei bit è riportato in \figref{fig:file_perm_bit}.
+

 Anche i permessi, come tutte le altre informazioni pertinenti al file, sono
 memorizzati nell'inode\index{inode}; in particolare essi sono contenuti in
 alcuni bit del campo \var{st\_mode} della struttura \struct{stat} (si veda di
 Anche i permessi, come tutte le altre informazioni pertinenti al file, sono
 memorizzati nell'inode\index{inode}; in particolare essi sono contenuti in
 alcuni bit del campo \var{st\_mode} della struttura \struct{stat} (si veda di


@@ -1589,6 +1623,7 @@ la quale appunto serve il diritto di esecuzione).
 Per una directory infatti il permesso di esecuzione significa che essa può
 essere attraversata nella risoluzione del pathname, ed è distinto dal permesso
 di lettura che invece implica che si può leggere il contenuto della directory.
 Per una directory infatti il permesso di esecuzione significa che essa può
 essere attraversata nella risoluzione del pathname, ed è distinto dal permesso
 di lettura che invece implica che si può leggere il contenuto della directory.

+

 Questo significa che se si ha il permesso di esecuzione senza permesso di
 lettura si potrà lo stesso aprire un file in una directory (se si hanno i
 permessi opportuni per il medesimo) ma non si potrà vederlo con \cmd{ls}
 Questo significa che se si ha il permesso di esecuzione senza permesso di
 lettura si potrà lo stesso aprire un file in una directory (se si hanno i
 permessi opportuni per il medesimo) ma non si potrà vederlo con \cmd{ls}


@@ -1768,22 +1803,23 @@ invece assunto un uso importante per le directory;\footnote{lo \textsl{sticky
 impostato un file potrà essere rimosso dalla directory soltanto se l'utente ha
 il permesso di scrittura su di essa ed inoltre è vera una delle seguenti
 condizioni:
 impostato un file potrà essere rimosso dalla directory soltanto se l'utente ha
 il permesso di scrittura su di essa ed inoltre è vera una delle seguenti
 condizioni:

-\begin{itemize*}
+\begin{itemize}

 \item l'utente è proprietario del file
 \item l'utente è proprietario della directory
 \item l'utente è l'amministratore 
 \item l'utente è proprietario del file
 \item l'utente è proprietario della directory
 \item l'utente è l'amministratore 

-\end{itemize*}
+\end{itemize}

 un classico esempio di directory che ha questo bit impostato è \file{/tmp}, i
 un classico esempio di directory che ha questo bit impostato è \file{/tmp}, i

-permessi infatti di solito sono impostati come:
+permessi infatti di solito sono i seguenti:

 \begin{verbatim}
 $ ls -ld /tmp
 drwxrwxrwt    6 root     root         1024 Aug 10 01:03 /tmp
 \end{verbatim}%$
 \begin{verbatim}
 $ ls -ld /tmp
 drwxrwxrwt    6 root     root         1024 Aug 10 01:03 /tmp
 \end{verbatim}%$

-in questo modo chiunque può creare file in questa directory (che infatti è
-normalmente utilizzata per la creazione di file temporanei), ma solo l'utente
-che ha creato un certo file potrà cancellarlo o rinominarlo. In questo modo si
-evita che un utente possa, più o meno consapevolmente, cancellare i file degli
-altri.
+quindi con lo \textsl{sticky bit} bit impostato. In questo modo qualunque
+utente nel sistema può creare dei file in questa directory (che, come
+suggerisce il nome, è normalmente utilizzata per la creazione di file
+temporanei), ma solo l'utente che ha creato un certo file potrà cancellarlo o
+rinominarlo. In questo modo si evita che un utente possa, più o meno
+consapevolmente, cancellare i file temporanei creati degli altri utenti.

 
 
 \subsection{La titolarità di nuovi file e directory}
 
 
 \subsection{La titolarità di nuovi file e directory}


@@ -1799,11 +1835,11 @@ per la creazione di nuove directory (procedimento descritto in
 Lo standard POSIX prescrive che l'\acr{uid} del nuovo file corrisponda
 all'userid effettivo del processo che lo crea; per il \acr{gid} invece prevede
 due diverse possibilità:
 Lo standard POSIX prescrive che l'\acr{uid} del nuovo file corrisponda
 all'userid effettivo del processo che lo crea; per il \acr{gid} invece prevede
 due diverse possibilità:

-\begin{itemize*}
+\begin{itemize}

 \item il \acr{gid} del file corrisponde al groupid effettivo del processo.
 \item il \acr{gid} del file corrisponde al \acr{gid} della directory in cui
   esso è creato.
 \item il \acr{gid} del file corrisponde al groupid effettivo del processo.
 \item il \acr{gid} del file corrisponde al \acr{gid} della directory in cui
   esso è creato.

-\end{itemize*}
+\end{itemize}

 in genere BSD usa sempre la seconda possibilità, che viene per questo chiamata
 semantica BSD. Linux invece segue quella che viene chiamata semantica SVr4; di
 norma cioè il nuovo file viene creato, seguendo la prima opzione, con il
 in genere BSD usa sempre la seconda possibilità, che viene per questo chiamata
 semantica BSD. Linux invece segue quella che viene chiamata semantica SVr4; di
 norma cioè il nuovo file viene creato, seguendo la prima opzione, con il


@@ -1812,13 +1848,14 @@ bit \acr{sgid} impostato allora viene usata la seconda opzione.
 
 Usare la semantica BSD ha il vantaggio che il \acr{gid} viene sempre
 automaticamente propagato, restando coerente a quello della directory di
 
 Usare la semantica BSD ha il vantaggio che il \acr{gid} viene sempre
 automaticamente propagato, restando coerente a quello della directory di

-partenza, in tutte le sottodirectory. La semantica SVr4 offre la possibilità
-di scegliere, ma per ottenere lo stesso risultato di coerenza che si ha con
-BSD necessita che per le nuove directory venga anche propagato anche il bit
-\acr{sgid}. Questo è il comportamento predefinito di \cmd{mkdir}, ed è in
-questo modo ad esempio che Debian assicura che le sottodirectory create nella
-home di un utente restino sempre con il \acr{gid} del gruppo primario dello
-stesso.
+partenza, in tutte le sottodirectory. 
+
+La semantica SVr4 offre la possibilità di scegliere, ma per ottenere lo stesso
+risultato di coerenza che si ha con BSD necessita che per le nuove directory
+venga anche propagato anche il bit \acr{sgid}. Questo è il comportamento
+predefinito del comando \cmd{mkdir}, ed è in questo modo ad esempio che Debian
+assicura che le sottodirectory create nella home di un utente restino sempre
+con il \acr{gid} del gruppo primario dello stesso.

 
 
 \subsection{La funzione \func{access}}
 
 
 \subsection{La funzione \func{access}}


@@ -1830,13 +1867,13 @@ sono casi per
 ed il groupid reale, vale a dire usando i valori di \acr{uid} e \acr{gid}
 relativi all'utente che ha lanciato il programma, e che, come accennato in
 \secref{sec:file_suid_sgid} e spiegato in dettaglio in
 ed il groupid reale, vale a dire usando i valori di \acr{uid} e \acr{gid}
 relativi all'utente che ha lanciato il programma, e che, come accennato in
 \secref{sec:file_suid_sgid} e spiegato in dettaglio in

-\secref{sec:proc_perms}, non è detto siano uguali a quelli effettivi.  Per far
-questo si può usare la funzione \func{access}, il cui prototipo è:
+\secref{sec:proc_perms}, non è detto siano uguali a quelli effettivi.  
+
+Per far questo si può usare la funzione \funcd{access}, il cui prototipo è:

 \begin{prototype}{unistd.h}
 {int access(const char *pathname, int mode)}
 
 \begin{prototype}{unistd.h}
 {int access(const char *pathname, int mode)}
 

-Verifica i permessi di accesso, indicati da \param{mode}, per il file indicato
-da \param{pathname}.
+Verifica i permessi di accesso.

   
 \bodydesc{La funzione ritorna 0 se l'accesso è consentito, -1 se l'accesso non
   è consentito ed in caso di errore; nel qual caso la variabile \var{errno}
   
 \bodydesc{La funzione ritorna 0 se l'accesso è consentito, -1 se l'accesso non
   è consentito ed in caso di errore; nel qual caso la variabile \var{errno}


@@ -1852,14 +1889,15 @@ da \param{pathname}.
   \errval{ENOTDIR}, \errval{ELOOP}, \errval{EIO}.}
 \end{prototype}
 
   \errval{ENOTDIR}, \errval{ELOOP}, \errval{EIO}.}
 \end{prototype}
 

-I valori possibili per l'argomento \param{mode} sono esprimibili come
-combinazione delle costanti numeriche riportate in
-\tabref{tab:file_access_mode_val} (attraverso un OR binario delle stesse). I
-primi tre valori implicano anche la verifica dell'esistenza del file, se si
-vuole verificare solo quest'ultima si può usare \const{F\_OK}, o anche
-direttamente \func{stat}. Nel caso in cui \param{pathname} si riferisca ad un
-link simbolico, questo viene seguito ed il controllo è fatto sul file a cui
-esso fa riferimento.
+La funzione verifica i permessi di accesso, indicati da \param{mode}, per il
+file indicato da \param{pathname}. I valori possibili per l'argomento
+\param{mode} sono esprimibili come combinazione delle costanti numeriche
+riportate in \tabref{tab:file_access_mode_val} (attraverso un OR binario delle
+stesse). I primi tre valori implicano anche la verifica dell'esistenza del
+file, se si vuole verificare solo quest'ultima si può usare \const{F\_OK}, o
+anche direttamente \func{stat}. Nel caso in cui \param{pathname} si riferisca
+ad un link simbolico, questo viene seguito ed il controllo è fatto sul file a
+cui esso fa riferimento.

 
 La funzione controlla solo i bit dei permessi di accesso, si ricordi che il
 fatto che una directory abbia permesso di scrittura non significa che ci si
 
 La funzione controlla solo i bit dei permessi di accesso, si ricordi che il
 fatto che una directory abbia permesso di scrittura non significa che ci si


@@ -2011,7 +2049,7 @@ perdita di questo privilegio.
 
 Oltre che dai valori indicati in sede di creazione, i permessi assegnati ai
 nuovi file sono controllati anche da una maschera di bit impostata con la
 
 Oltre che dai valori indicati in sede di creazione, i permessi assegnati ai
 nuovi file sono controllati anche da una maschera di bit impostata con la

-funzione \func{umask}, il cui prototipo è:
+funzione \funcd{umask}, il cui prototipo è:

 \begin{prototype}{stat.h}
 {mode\_t umask(mode\_t mask)}
 
 \begin{prototype}{stat.h}
 {mode\_t umask(mode\_t mask)}
 


@@ -2220,7 +2258,7 @@ processo figlio, e quindi di norma coincide con la \file{/} del sistema.
 
 In certe situazioni però per motivi di sicurezza non si vuole che un processo
 possa accedere a tutto il filesystem; per questo si può cambiare la directory
 
 In certe situazioni però per motivi di sicurezza non si vuole che un processo
 possa accedere a tutto il filesystem; per questo si può cambiare la directory

-radice con la funzione \func{chroot}, il cui prototipo è:
+radice con la funzione \funcd{chroot}, il cui prototipo è:

 \begin{prototype}{unistd.h}{int chroot(const char *path)}
   Cambia la directory radice del processo a quella specificata da
   \param{path}.
 \begin{prototype}{unistd.h}{int chroot(const char *path)}
   Cambia la directory radice del processo a quella specificata da
   \param{path}.