Ulteriore revisione della sezione, in particolare per quanto riguarda

i file temporanei.

Spostata la sottosezione sulle capabilities in fondo alla relativa
sezione.

diff --git a/filedir.tex b/filedir.tex
index 814f6d44431004940c46cfdaa22a929d2a1bb477..23991abd0d942551b5bc2ab03559ab87dee33d97 100644 (file)
--- a/filedir.tex
+++ b/filedir.tex
@@ -1381,31 +1381,36 @@ controllo e la creazione si ha giusto lo spazio per una possibile
 sez.~\ref{sec:proc_race_cond}).
 
 Le \acr{glibc} provvedono varie funzioni per generare nomi di file temporanei,
 sez.~\ref{sec:proc_race_cond}).
 
 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 è \funcd{tmpnam} il cui prototipo è:
+di cui si abbia certezza di unicità al momento della generazione; storicamente
+la prima di queste funzioni create a questo scopo era
+\funcd{tmpnam},\footnote{la funzione è stata deprecata nella revisione
+  POSIX.1-2008 dello standard POSIX.} il cui prototipo è:

 \begin{prototype}{stdio.h}{char *tmpnam(char *string)}
 \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. 
-
+  Genera un nome univoco per un file temporaneo.
+ 

   \bodydesc{La funzione ritorna il puntatore alla stringa con il nome o
   \val{NULL} in caso di fallimento. Non sono definiti errori.}
 \end{prototype}
   \bodydesc{La funzione ritorna il puntatore alla stringa con il nome o
   \val{NULL} in caso di fallimento. Non sono definiti errori.}
 \end{prototype}

-\noindent se si è passato un puntatore \param{string} non nullo questo deve
-essere di dimensione \const{L\_tmpnam} (costante definita in \file{stdio.h},
-come \const{P\_tmpdir} e \const{TMP\_MAX}) ed il nome generato vi verrà
-copiato automaticamente; altrimenti il nome sarà generato in un buffer statico
-interno che verrà sovrascritto ad una chiamata successiva.  Successive
+
+La funzione restituisce il puntatore ad una stringa contente un nome di file
+valido e non esistente al momento dell'invocazione; se si è passato come
+argomento \param{string} un puntatore non nullo ad un buffer di caratteri
+questo deve essere di dimensione \const{L\_tmpnam} ed il nome generato vi
+verrà copiato automaticamente; altrimenti il nome sarà generato in un buffer
+statico interno che verrà sovrascritto ad una chiamata successiva.  Successive

 invocazioni della funzione continueranno a restituire nomi unici fino ad un
 invocazioni della funzione continueranno a restituire nomi unici fino ad un

-massimo di \const{TMP\_MAX} volte. Al nome viene automaticamente aggiunto come
-prefisso la directory specificata da \const{P\_tmpdir}.
+massimo di \const{TMP\_MAX} volte, limite oltre il quale il comportamento è
+indefinito. Al nome viene automaticamente aggiunto come prefisso la directory
+specificata dalla costante \const{P\_tmpdir}.\footnote{le costanti
+  \const{L\_tmpnam}, \const{P\_tmpdir} e \const{TMP\_MAX} sono definite in
+  \file{stdio.h}.}

 
 Di questa funzione esiste una versione \index{funzioni!rientranti} rientrante,
 \func{tmpnam\_r}, che non fa nulla quando si passa \val{NULL} come argomento.
 Una funzione simile, \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)}
 
 Di questa funzione esiste una versione \index{funzioni!rientranti} rientrante,
 \func{tmpnam\_r}, che non fa nulla quando si passa \val{NULL} come argomento.
 Una funzione simile, \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
-  non esistente al momento dell'invocazione.
+  Genera un nome univoco per un file temporaneo.

 
   \bodydesc{La funzione ritorna il puntatore alla stringa con il nome o
   \val{NULL} in caso di fallimento, \var{errno} viene impostata a
 
   \bodydesc{La funzione ritorna il puntatore alla stringa con il nome o
   \val{NULL} in caso di fallimento, \var{errno} viene impostata a


@@ -1416,16 +1421,16 @@ La funzione alloca con \code{malloc} la stringa in cui restituisce il nome,
 per cui è sempre \index{funzioni!rientranti} rientrante, occorre però
 ricordarsi di disallocare con \code{free} il puntatore che restituisce.
 L'argomento \param{pfx} specifica un prefisso di massimo 5 caratteri per il
 per cui è sempre \index{funzioni!rientranti} rientrante, occorre però
 ricordarsi di disallocare con \code{free} il puntatore che restituisce.
 L'argomento \param{pfx} specifica un prefisso di massimo 5 caratteri per il

-nome provvisorio. La funzione assegna come directory per il file temporaneo
-(verificando che esista e sia accessibili), la prima valida delle seguenti:
-\begin{itemize}
+nome provvisorio. La funzione assegna come directory per il file temporaneo,
+verificando che esista e sia accessibile, la prima valida fra le seguenti:
+\begin{itemize*}

 \item La variabile di ambiente \const{TMPDIR} (non ha effetto se non è
   definita o se il programma chiamante è \itindex{suid~bit} \acr{suid} o
   \itindex{sgid~bit} \acr{sgid}, vedi sez.~\ref{sec:file_special_perm}).
 \item il valore dell'argomento \param{dir} (se diverso da \val{NULL}).
 \item Il valore della costante \const{P\_tmpdir}.
 \item la directory \file{/tmp}.
 \item La variabile di ambiente \const{TMPDIR} (non ha effetto se non è
   definita o se il programma chiamante è \itindex{suid~bit} \acr{suid} o
   \itindex{sgid~bit} \acr{sgid}, vedi sez.~\ref{sec:file_special_perm}).
 \item il valore dell'argomento \param{dir} (se diverso da \val{NULL}).
 \item Il valore della costante \const{P\_tmpdir}.
 \item la directory \file{/tmp}.

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

 
 In ogni caso, anche se la generazione del nome è casuale, ed è molto difficile
 ottenere un nome duplicato, nulla assicura che un altro processo non possa
 
 In ogni caso, anche se la generazione del nome è casuale, ed è molto difficile
 ottenere un nome duplicato, nulla assicura che un altro processo non possa


@@ -1439,7 +1444,7 @@ esistente.
 Per evitare di dovere effettuare a mano tutti questi controlli, lo standard
 POSIX definisce la funzione \funcd{tmpfile}, che permette di ottenere in
 maniera sicura l'accesso ad un file temporaneo, il suo prototipo è:
 Per evitare di dovere effettuare a mano tutti questi controlli, lo standard
 POSIX definisce la funzione \funcd{tmpfile}, che permette di ottenere in
 maniera sicura l'accesso ad un file temporaneo, il suo prototipo è:

-\begin{prototype}{stdio.h}{FILE *tmpfile (void)}
+\begin{prototype}{stdio.h}{FILE *tmpfile(void)}

   Restituisce un file temporaneo aperto in lettura/scrittura.
   
   \bodydesc{La funzione ritorna il puntatore allo stream associato al file
   Restituisce un file temporaneo aperto in lettura/scrittura.
   
   \bodydesc{La funzione ritorna il puntatore allo stream associato al file


@@ -1468,8 +1473,7 @@ 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,
 il suo prototipo è:
 \begin{prototype}{stlib.h}{char *mktemp(char *template)}
 unico. La prima delle due è analoga a \func{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
-  \param{template}.
+  Genera un nome univoco per un file temporaneo.

   
   \bodydesc{La funzione ritorna il puntatore \param{template} in caso di
     successo e \val{NULL} in caso di errore, nel qual caso \var{errno}
   
   \bodydesc{La funzione ritorna il puntatore \param{template} in caso di
     successo e \val{NULL} in caso di errore, nel qual caso \var{errno}


@@ -1478,7 +1482,9 @@ il suo prototipo è:
     \item[\errcode{EINVAL}] \param{template} non termina con \code{XXXXXX}.
     \end{errlist}}
 \end{prototype}
     \item[\errcode{EINVAL}] \param{template} non termina con \code{XXXXXX}.
     \end{errlist}}
 \end{prototype}

-\noindent dato che \param{template} deve poter essere modificata dalla
+
+La funzionne genera un nome univoco sostituendo le \code{XXXXXX} finali di
+\param{template}; dato che \param{template} deve poter essere modificata dalla

 funzione non si può usare una stringa costante.  Tutte le avvertenze riguardo
 alle possibili \itindex{race~condition} \textit{race condition} date per
 \func{tmpnam} continuano a valere; inoltre in alcune vecchie implementazioni
 funzione non si può usare una stringa costante.  Tutte le avvertenze riguardo
 alle possibili \itindex{race~condition} \textit{race condition} date per
 \func{tmpnam} continuano a valere; inoltre in alcune vecchie implementazioni


@@ -1489,13 +1495,12 @@ Per tutti questi motivi la funzione è deprecata e non dovrebbe mai essere
 usata.
 
 La seconda funzione, \funcd{mkstemp} è sostanzialmente equivalente a
 usata.
 
 La seconda funzione, \funcd{mkstemp} è sostanzialmente equivalente a

-\func{tmpfile}, ma restituisce un file descriptor invece di uno stream; il suo
+\func{tmpfile}, ma restituisce un file descriptor invece di un nome; il suo

 prototipo è:
 \begin{prototype}{stlib.h}{int mkstemp(char *template)}
 prototipo è:
 \begin{prototype}{stlib.h}{int mkstemp(char *template)}

-  Genera un file temporaneo con un nome ottenuto sostituendo le \code{XXXXXX}
-  finali di \param{template}.
+  Genera un file temporaneo.

   
   

-  \bodydesc{La funzione ritorna il file descriptor in caso successo e
+  \bodydesc{La funzione ritorna il file descriptor in caso di successo e

     -1 in caso di errore, nel qual caso \var{errno} assumerà i valori:
     \begin{errlist}
     \item[\errcode{EINVAL}] \param{template} non termina con \code{XXXXXX}.
     -1 in caso di errore, nel qual caso \var{errno} assumerà i valori:
     \begin{errlist}
     \item[\errcode{EINVAL}] \param{template} non termina con \code{XXXXXX}.


@@ -1503,22 +1508,38 @@ prototipo è:
       contenuto di \param{template} è indefinito.
     \end{errlist}}
 \end{prototype}
       contenuto di \param{template} è indefinito.
     \end{errlist}}
 \end{prototype}

-\noindent come per \func{mktemp} anche in questo caso \param{template} non può
-essere una stringa costante. La funzione apre un file in lettura/scrittura con
-la funzione \func{open}, usando l'opzione \const{O\_EXCL} (si veda
+
+Come per \func{mktemp} anche in questo caso \param{template} non può essere
+una stringa costante. La funzione apre un file in lettura/scrittura con la
+funzione \func{open}, usando l'opzione \const{O\_EXCL} (si veda

 sez.~\ref{sec:file_open}), in questo modo al ritorno della funzione si ha la
 sez.~\ref{sec:file_open}), in questo modo al ritorno della funzione si ha la

-certezza di essere i soli utenti del file. I permessi sono impostati al valore
-\code{0600}\footnote{questo è vero a partire dalle \acr{glibc} 2.0.7, le
-  versioni precedenti delle \acr{glibc} e le vecchie \acr{libc5} e \acr{libc4}
-  usavano il valore \code{0666} che permetteva a chiunque di leggere i
-  contenuti del file.} (si veda sez.~\ref{sec:file_perm_overview}).
-
-In OpenBSD è stata introdotta un'altra funzione\footnote{introdotta anche in
-  Linux a partire dalle \acr{glibc} 2.1.91.} simile alle precedenti,
-\funcd{mkdtemp}, che crea una directory temporanea; il suo prototipo è:
+certezza di essere stati i creatori del file, i cui permessi (si veda
+sez.~\ref{sec:file_perm_overview}) sono impostati al valore \code{0600}
+(lettura e scrittura solo per il proprietario).\footnote{questo è vero a
+  partire dalle \acr{glibc} 2.0.7, le versioni precedenti delle \acr{glibc} e
+  le vecchie \acr{libc5} e \acr{libc4} usavano il valore \code{0666} che
+  permetteva a chiunque di leggere e scrivere i contenuti del file.}  Di
+questa funzione esiste una variante \funcd{mkostemp}, introdotta
+specificamente dalla \acr{glibc},\footnote{la funzione è stata introdotta
+  nella versione 2.7 delle librerie e richiede che sia definita la macro
+  \const{\_GNU\_SOURCE}.} il cui prototipo è:
+\begin{prototype}{stlib.h}{int mkostemp(char *template, int flags)}
+  Genera un file temporaneo.
+  
+  \bodydesc{La funzione ritorna il file descriptor in caso di successo e
+    -1 in caso di errore, con gli stessi errori di \func{mkstemp}.}
+\end{prototype}
+\noindent la cui sola differenza è la presenza dell'ulteriore argomento
+\var{flags} che consente di specificare i flag da passare ad \func{open}
+nell'apertura del file.
+
+
+In OpenBSD è stata introdotta un'altra funzione simile alle precedenti,
+\funcd{mkdtemp}, che crea invece una directory temporanea;\footnote{la
+  funzione è stata introdotta nelle \acr{glibc} a partire dalla versione
+  2.1.91 ed inserita nello standard POSIX.1-2008.}  il suo prototipo è:

 \begin{prototype}{stlib.h}{char *mkdtemp(char *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}.
+  Genera una directory temporanea.

   
   \bodydesc{La funzione ritorna il puntatore al nome della directory in caso
     successo e \val{NULL} in caso di errore, nel qual caso \var{errno}
   
   \bodydesc{La funzione ritorna il puntatore al nome della directory in caso
     successo e \val{NULL} in caso di errore, nel qual caso \var{errno}


@@ -1528,9 +1549,11 @@ In OpenBSD è stata introdotta un'altra funzione\footnote{introdotta anche in
     \end{errlist}
     più gli altri eventuali codici di errore di \func{mkdir}.}
 \end{prototype}
     \end{errlist}
     più gli altri eventuali codici di errore di \func{mkdir}.}
 \end{prototype}

-\noindent la directory è creata con permessi \code{0700} (al solito si veda
-cap.~\ref{cha:file_unix_interface} per i dettagli); dato che la creazione
-della directory è sempre esclusiva i precedenti problemi di
+
+La funzione genera una directory il cui nome è ottenuto sostituendo le
+\code{XXXXXX} finali di \param{template} con permessi \code{0700} (al solito
+si veda cap.~\ref{cha:file_unix_interface} per i dettagli); dato che la
+creazione della directory è sempre esclusiva i precedenti problemi di

 \itindex{race~condition} \textit{race condition} non si pongono.
 
 
 \itindex{race~condition} \textit{race condition} non si pongono.
 
 


@@ -1554,34 +1577,32 @@ sez.~\ref{sec:file_access_control}).
 \label{sec:file_stat}
 
 La lettura delle informazioni relative ai file è fatta attraverso la famiglia
 \label{sec:file_stat}
 
 La lettura delle informazioni relative ai file è fatta attraverso la famiglia

-delle funzioni \func{stat} (\funcd{stat}, \funcd{fstat} e \funcd{lstat});
-questa è la funzione che ad esempio usa il comando \cmd{ls} per poter ottenere
-e mostrare tutti i dati relativi ad un file. I prototipi di queste funzioni
-sono i seguenti:
+delle funzioni \func{stat} che sono quelle che usa il comando \cmd{ls} per
+poter ottenere e mostrare tutti i dati relativi ad un file; ne fanno parte le
+funzioni \funcd{stat}, \funcd{fstat} e \funcd{lstat}, i cui prototipi sono:

 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/stat.h} 
   \headdecl{unistd.h}
 
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/stat.h} 
   \headdecl{unistd.h}
 

-  \funcdecl{int stat(const char *file\_name, struct stat *buf)} Legge le
-  informazione del file specificato da \param{file\_name} e le inserisce in
-  \param{buf}.
-  
-  \funcdecl{int lstat(const char *file\_name, struct stat *buf)} Identica a
-  \func{stat} eccetto che se il \param{file\_name} è un link simbolico vengono
-  lette le informazioni relative ad esso e non al file a cui fa riferimento.
-  
-  \funcdecl{int fstat(int filedes, struct stat *buf)} Identica a \func{stat}
-  eccetto che si usa con un file aperto, specificato tramite il suo file
-  descriptor \param{filedes}.
-  
+  \funcdecl{int stat(const char *file\_name, struct stat *buf)} 
+  \funcdecl{int lstat(const char *file\_name, struct stat *buf)} 
+  \funcdecl{int fstat(int filedes, struct stat *buf)} 
+  Legge le informazioni di un file.
+

   \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 per un
     errore, nel qual caso \var{errno} assumerà uno dei valori: \errval{EBADF},
     \errval{ENOENT}, \errval{ENOTDIR}, \errval{ELOOP}, \errval{EFAULT},
     \errval{EACCES}, \errval{ENOMEM}, \errval{ENAMETOOLONG}.}
 \end{functions}
   \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 per un
     errore, nel qual caso \var{errno} assumerà uno dei valori: \errval{EBADF},
     \errval{ENOENT}, \errval{ENOTDIR}, \errval{ELOOP}, \errval{EFAULT},
     \errval{EACCES}, \errval{ENOMEM}, \errval{ENAMETOOLONG}.}
 \end{functions}

-\noindent il loro comportamento è identico, solo che operano rispettivamente
-su un file, su un link simbolico e su un file descriptor.
+
+La funzione \func{stat} legge le informazion del file il cui pathname è
+specificato dalla stringa puntata da \param{file\_name} e le inserisce nel
+buffer puntato dall'argomento \param{buf}; la funzione \func{lstat} è identica
+a \func{stat} eccetto che se \param{file\_name} è un link simbolico vengono
+lette le informazioni relative ad esso e non al file a cui fa
+riferimento. Infine \func{fstat} esegue la stessa operazione su un file già
+aperto, specificato tramite il suo file descriptor \param{filedes}.

 
 La struttura \struct{stat} usata da queste funzioni è definita nell'header
 \file{sys/stat.h} e in generale dipende dall'implementazione; la versione
 
 La struttura \struct{stat} usata da queste funzioni è definita nell'header
 \file{sys/stat.h} e in generale dipende dall'implementazione; la versione


@@ -1723,9 +1744,9 @@ Si tenga conto che la lunghezza del file riportata in \var{st\_size} non è
 detto che corrisponda all'occupazione dello spazio su disco per via della
 possibile esistenza dei cosiddetti \index{file!\textit{hole}} \textit{holes}
 (letteralmente \textsl{buchi}) che si formano tutte le volte che si va a
 detto che corrisponda all'occupazione dello spazio su disco per via della
 possibile esistenza dei cosiddetti \index{file!\textit{hole}} \textit{holes}
 (letteralmente \textsl{buchi}) che si formano tutte le volte che si va a

-scrivere su un \itindex{sparse~file} file dopo aver eseguito una \func{lseek}
-(tratteremo in dettaglio l'argomento in sez.~\ref{sec:file_lseek}) oltre la
-sua fine.
+scrivere su un \itindex{sparse~file} file dopo aver eseguito uno spostamento
+oltre la sua fine (tratteremo in dettaglio l'argomento in
+sez.~\ref{sec:file_lseek}).

 
 In questo caso si avranno risultati differenti a seconda del modo in cui si
 calcola la lunghezza del file, ad esempio il comando \cmd{du}, (che riporta il
 
 In questo caso si avranno risultati differenti a seconda del modo in cui si
 calcola la lunghezza del file, ad esempio il comando \cmd{du}, (che riporta il


@@ -1744,14 +1765,14 @@ Un file può sempre essere troncato a zero aprendolo con il flag
 dimensione si possono usare le due funzioni \funcd{truncate} e
 \funcd{ftruncate}, i cui prototipi sono:
 \begin{functions}
 dimensione si possono usare le due funzioni \funcd{truncate} e
 \funcd{ftruncate}, i cui prototipi sono:
 \begin{functions}

-  \headdecl{unistd.h} \funcdecl{int truncate(const char *file\_name, off\_t
-    length)} Fa si che la dimensione del file \param{file\_name} sia troncata
-  ad un valore massimo specificato da \param{length}.
-  
-  \funcdecl{int ftruncate(int fd, off\_t length))} Identica a \func{truncate}
-  eccetto che si usa con un file aperto, specificato tramite il suo file
-  descriptor \param{fd}.
-  
+  \headdecl{unistd.h} 
+
+  \funcdecl{int truncate(const char *file\_name, off\_t length)} 
+
+  \funcdecl{int ftruncate(int fd, off\_t length))} 
+
+  Troncano un file alla lunghezza \param{length}.
+

   \bodydesc{Le funzioni restituiscono zero in caso di successo e -1 per un
     errore, nel qual caso \var{errno} viene impostata opportunamente; per
     \func{ftruncate} si hanno i valori:
   \bodydesc{Le funzioni restituiscono zero in caso di successo e -1 per un
     errore, nel qual caso \var{errno} viene impostata opportunamente; per
     \func{ftruncate} si hanno i valori:


@@ -1771,20 +1792,28 @@ dimensione si possono usare le due funzioni \funcd{truncate} e
   \errval{EROFS}, \errval{EIO}, \errval{EFAULT}, \errval{ELOOP}.}
 \end{functions}
 
   \errval{EROFS}, \errval{EIO}, \errval{EFAULT}, \errval{ELOOP}.}
 \end{functions}
 

-Se il file è più lungo della lunghezza specificata i dati in eccesso saranno
-perduti; il comportamento in caso di lunghezza inferiore non è specificato e
-dipende dall'implementazione: il file può essere lasciato invariato o esteso
-fino alla lunghezza scelta; nel caso di Linux viene esteso con la creazione di
-un \index{file!\textit{hole}} \textsl{buco} nel \itindex{sparse~file} file e
-ad una lettura si otterranno degli zeri.
+Emtrambe le funzioni fan sì che la dimensione del file sia troncata ad un
+valore massimo specificato da \param{length}, e si distinguono solo per il
+fatto che il file viene indicato con il pathame \param{file\_name} per
+\func{truncate} e con il file descriptor \param{fd} per \funcd{ftruncate}; se
+il file è più lungo della lunghezza specificata i dati in eccesso saranno
+perduti.
+
+Il comportamento in caso di lunghezza inferiore non è specificato e dipende
+dall'implementazione: il file può essere lasciato invariato o esteso fino alla
+lunghezza scelta; nel caso di Linux viene esteso con la creazione di un
+\index{file!\textit{hole}} \textsl{buco} nel \itindex{sparse~file} file e ad
+una lettura si otterranno degli zeri; si tenga presente però che questo
+comportamento è supportato solo per filesystem nativi, ad esempio su un
+filesystem non nativo come il VFAT di windows questo non è possibile.

 
 \subsection{I tempi dei file}
 \label{sec:file_file_times}
 
 
 \subsection{I tempi dei file}
 \label{sec:file_file_times}
 

-Il sistema mantiene per ciascun file tre tempi. Questi sono registrati
+Il sistema mantiene per ciascun file tre tempi, questi sono registrati

 \itindex{inode} nell'\textit{inode} insieme agli altri attributi del file e
 possono essere letti tramite la funzione \func{stat}, che li restituisce
 \itindex{inode} nell'\textit{inode} insieme agli altri attributi del file e
 possono essere letti tramite la funzione \func{stat}, che li restituisce

-attraverso tre campi della struttura \struct{stat} di
+attraverso tre specifici campi della struttura \struct{stat} di

 fig.~\ref{fig:file_stat_struct}. Il significato di detti tempi e dei relativi
 campi è riportato nello schema in tab.~\ref{tab:file_file_times}, dove è anche
 riportato un esempio delle funzioni che effettuano cambiamenti su di essi. Il
 fig.~\ref{fig:file_stat_struct}. Il significato di detti tempi e dei relativi
 campi è riportato nello schema in tab.~\ref{tab:file_file_times}, dove è anche
 riportato un esempio delle funzioni che effettuano cambiamenti su di essi. Il


@@ -1813,14 +1842,14 @@ valore è espresso nel cosiddetto \itindex{calendar~time} \textit{calendar
 \end{table}
 
 Il primo punto da tenere presente è la differenza fra il cosiddetto tempo di
 \end{table}
 
 Il primo punto da tenere presente è la differenza fra il cosiddetto tempo di

-modifica (il \textit{modification time}, \var{st\_mtime}) e il tempo di
-cambiamento di stato (il \textit{change time}, \var{st\_ctime}). Il primo
-infatti fa riferimento ad una modifica del contenuto di un file, mentre il
-secondo ad una modifica \itindex{inode} dell'\textit{inode}; siccome esistono
-molte operazioni (come la funzione \func{link} e molte altre che vedremo in
-seguito) che modificano solo le informazioni contenute \itindex{inode}
+ultima modifica (il \textit{modification time}, \var{st\_mtime}) e il tempo di
+ultimo cambiamento di stato (il \textit{change time}, \var{st\_ctime}). Il
+primo infatti fa riferimento ad una modifica del contenuto di un file, mentre
+il secondo ad una modifica \itindex{inode} dell'\textit{inode}. Dato che
+esistono molte operazioni, come la funzione \func{link} e altre che vedremo in
+seguito, che modificano solo le informazioni contenute \itindex{inode}

 nell'\textit{inode} senza toccare il contenuto del file, diventa necessario
 nell'\textit{inode} senza toccare il contenuto del file, diventa necessario

-l'utilizzo di un altro tempo.
+l'utilizzo di questo secondo tempo.

 
 Il tempo di ultima modifica viene usato ad esempio da programmi come
 \cmd{make} per decidere quali file necessitano di essere ricompilati o
 
 Il tempo di ultima modifica viene usato ad esempio da programmi come
 \cmd{make} per decidere quali file necessitano di essere ricompilati o


@@ -1859,14 +1888,6 @@ kernel 2.6.30, è diventata il comportamento di default e non deve più essere
 specificata esplicitamente.\footnote{si può comunque riottenere il vecchio
   comportamento usando la opzione di montaggio \texttt{strictatime}.}
 
 specificata esplicitamente.\footnote{si può comunque riottenere il vecchio
   comportamento usando la opzione di montaggio \texttt{strictatime}.}
 

-L'effetto delle varie funzioni di manipolazione dei file sui relativi tempi è
-illustrato in tab.~\ref{tab:file_times_effects}, facendo riferimento al
-comportamento classico per quanto riguarda \var{st\_atime}. Si sono riportati
-gli effetti sia per il file a cui si fa riferimento, sia per la directory che
-lo contiene; questi ultimi possono essere capiti se si tiene conto di quanto
-già detto, e cioè che anche le directory sono file (che contengono una lista
-di nomi) che il sistema tratta in maniera del tutto analoga a tutti gli altri.
-

 \begin{table}[htb]
   \centering
   \footnotesize
 \begin{table}[htb]
   \centering
   \footnotesize


@@ -1947,12 +1968,22 @@ di nomi) che il sistema tratta in maniera del tutto analoga a tutti gli altri.
   \label{tab:file_times_effects}  
 \end{table}
 
   \label{tab:file_times_effects}  
 \end{table}
 

+
+L'effetto delle varie funzioni di manipolazione dei file sui relativi tempi è
+illustrato in tab.~\ref{tab:file_times_effects}, facendo riferimento al
+comportamento classico per quanto riguarda \var{st\_atime}. Si sono riportati
+gli effetti sia per il file a cui si fa riferimento, sia per la directory che
+lo contiene; questi ultimi possono essere capiti se si tiene conto di quanto
+già detto, e cioè che anche le directory sono anch'esse file che contengono
+una lista di nomi, che il sistema tratta in maniera del tutto analoga a tutti
+gli altri.
+

 Per questo motivo tutte le volte che compiremo un'operazione su un file che
 comporta una modifica del nome contenuto nella directory, andremo anche a
 scrivere sulla directory che lo contiene cambiandone il tempo di modifica. Un
 Per questo motivo tutte le volte che compiremo un'operazione su un file che
 comporta una modifica del nome contenuto nella directory, andremo anche a
 scrivere sulla directory che lo contiene cambiandone il tempo di modifica. Un

-esempio di questo può essere la cancellazione di un file, invece leggere o
-scrivere o cambiare i permessi di un file ha effetti solo sui tempi di
-quest'ultimo.
+esempio di questo tipo di operazione può essere la cancellazione di un file,
+invece leggere o scrivere o cambiare i permessi di un file ha effetti solo sui
+tempi di quest'ultimo.

 
 Si noti infine come \var{st\_ctime} non abbia nulla a che fare con il tempo di
 creazione del file, usato in molti altri sistemi operativi, ma che in Unix non
 
 Si noti infine come \var{st\_ctime} non abbia nulla a che fare con il tempo di
 creazione del file, usato in molti altri sistemi operativi, ma che in Unix non


@@ -1964,11 +1995,7 @@ I tempi di ultimo accesso e modifica possono essere modificati esplicitamente
 usando la funzione \funcd{utime}, il cui prototipo è:
 \begin{prototype}{utime.h}
   {int utime(const char *filename, struct utimbuf *times)} 
 usando la funzione \funcd{utime}, il cui prototipo è:
 \begin{prototype}{utime.h}
   {int utime(const char *filename, struct utimbuf *times)} 

-
-  Cambia i tempi di ultimo accesso e modifica \itindex{inode}
-  dell'\textit{inode} specificato da \param{filename} secondo i valori dei
-  campi \var{actime} e \var{modtime} di \param{times}. Se questa è \val{NULL}
-  allora viene usato il tempo corrente.
+  Modidica i tempi di ultimo accesso e modifica di un file.

 
   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
     errore, nel qual caso \var{errno} assumerà uno dei valori:
 
   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
     errore, nel qual caso \var{errno} assumerà uno dei valori:


@@ -1979,10 +2006,12 @@ usando la funzione \funcd{utime}, il cui prototipo è:
     ed inoltre \errval{EROFS} e \errval{ENOENT}.}
 \end{prototype}
 
     ed inoltre \errval{EROFS} e \errval{ENOENT}.}
 \end{prototype}
 

-La funzione prende come argomento \param{times} una struttura
-\struct{utimbuf}, la cui definizione è riportata in
-fig.~\ref{fig:struct_utimebuf}, con la quale si possono specificare i nuovi
-valori che si vogliono impostare per tempi.
+La funzione cambia i tempi di ultimo accesso e modifica del file specificato
+dall'argomento \param{filename}, e richiede come secondo argomento il
+puntatore ad una struttura \struct{utimbuf}, la cui definizione è riportata in
+fig.~\ref{fig:struct_utimebuf}, con i nuovi valori di detti tempi
+(rispettivamente  nei campi \var{actime} e \var{modtime}). Se si passa un
+puntatore nullo verrà impostato il tempo corrente.

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


@@ -1999,17 +2028,17 @@ L'effetto della funzione e i privilegi necessari per eseguirla dipendono da
 cosa è l'argomento \param{times}; se è \val{NULL} la funzione imposta il
 tempo corrente ed è sufficiente avere accesso in scrittura al file; se invece
 si è specificato un valore la funzione avrà successo solo se si è proprietari
 cosa è l'argomento \param{times}; se è \val{NULL} la funzione imposta il
 tempo corrente ed è sufficiente avere accesso in scrittura al file; se invece
 si è specificato un valore la funzione avrà successo solo se si è proprietari

-del file (o si hanno i privilegi di amministratore).
+del file o si hanno i privilegi di amministratore.

 
 Si tenga presente che non è comunque possibile specificare il tempo di
 
 Si tenga presente che non è comunque possibile specificare il tempo di

-cambiamento di stato del file, che viene comunque cambiato dal kernel tutte le
-volte che si modifica \itindex{inode} l'\textit{inode} (quindi anche alla
-chiamata di \func{utime}).  Questo serve anche come misura di sicurezza per
-evitare che si possa modificare un file nascondendo completamente le proprie
-tracce. In realtà la cosa resta possibile, se si è in grado di accedere al
-\index{file!di~dispositivo} file di dispositivo, scrivendo direttamente sul
+cambiamento di stato del file, che viene aggiornato direttamente dal kernel
+tutte le volte che si modifica \itindex{inode} l'\textit{inode} (quindi anche
+alla chiamata di \func{utime}).  Questo serve anche come misura di sicurezza
+per evitare che si possa modificare un file nascondendo completamente le
+proprie tracce. In realtà la cosa resta possibile se si è in grado di accedere
+al \index{file!di~dispositivo} file di dispositivo, scrivendo direttamente sul

 disco senza passare attraverso il filesystem, ma ovviamente in questo modo la
 disco senza passare attraverso il filesystem, ma ovviamente in questo modo la

-cosa è molto più complicata da realizzare.
+cosa è più complicata da realizzare.

 
 A partire dal kernel 2.6 la risoluzione dei tempi dei file, che nei campi di
 tab.~\ref{tab:file_file_times} è espressa in secondi, è stata portata ai
 
 A partire dal kernel 2.6 la risoluzione dei tempi dei file, che nei campi di
 tab.~\ref{tab:file_file_times} è espressa in secondi, è stata portata ai


@@ -2028,11 +2057,7 @@ precisione; il suo prototipo è:
 \begin{prototype}
   {sys/time.h}
   {int utimes(const char *filename, struct timeval times[2])} 
 \begin{prototype}
   {sys/time.h}
   {int utimes(const char *filename, struct timeval times[2])} 

-
-  Cambia i tempi di ultimo accesso e modifica \itindex{inode}
-  dell'\textit{inode} specificato da \param{filename} secondo i valori
-  specificati da \param{times}. Se questo è \val{NULL} allora viene usato il
-  tempo corrente.
+  Modidica i tempi di ultimo accesso e modifica di un file.

 
   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
     errore, nel qual caso \var{errno} assumerà uno dei valori:
 
   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
     errore, nel qual caso \var{errno} assumerà uno dei valori:


@@ -2044,11 +2069,12 @@ precisione; il suo prototipo è:
 \end{prototype}
 
 La funzione è del tutto analoga alla precedente \func{utime} ma usa come
 \end{prototype}
 
 La funzione è del tutto analoga alla precedente \func{utime} ma usa come

-argomento \param{times}, un vettore di due strutture \struct{timeval}, la cui
+secondo argomento un vettore di due strutture \struct{timeval}, la cui

 definizione è riportata in fig.~\ref{fig:sys_timeval_struct}, che consentono
 di indicare i tempi con una precisione del microsecondo. Il primo elemento
 di \param{times} indica il valore per il tempo di ultimo accesso, il secondo
 definizione è riportata in fig.~\ref{fig:sys_timeval_struct}, che consentono
 di indicare i tempi con una precisione del microsecondo. Il primo elemento
 di \param{times} indica il valore per il tempo di ultimo accesso, il secondo

-quello per il tempo di ultima modifica.
+quello per il tempo di ultima modifica. Se si indica come secondo argomento un
+puntatore nullo di nuovo verrà utilizzato il tempo corrente.

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


@@ -2089,10 +2115,9 @@ prototipi sono:
 Le due funzioni anno lo stesso comportamento di \texttt{utimes} e richiedono
 gli stessi privilegi per poter operare, la differenza è che con \func{futimes}
 si può indicare il file su cui operare facendo riferimento al relativo file
 Le due funzioni anno lo stesso comportamento di \texttt{utimes} e richiedono
 gli stessi privilegi per poter operare, la differenza è che con \func{futimes}
 si può indicare il file su cui operare facendo riferimento al relativo file

-descriptor (tratteremo in dettaglio l'argomento in
-sez.~\ref{cha:file_unix_interface}) mentre con \func{lutimes} nel caso in
-cui \param{filename} sia un link simbolico saranno modificati i suoi tempi
-invece di quelli del file a cui esso punta.
+descriptor mentre con \func{lutimes} nel caso in cui \param{filename} sia un
+link simbolico saranno modificati i suoi tempi invece di quelli del file a cui
+esso punta.

 
 Nonostante il kernel, come accennato, supporti risoluzioni dei tempi dei file
 fino al nanosecondo, le funzioni fin qui esaminate non consentono di impostare
 
 Nonostante il kernel, come accennato, supporti risoluzioni dei tempi dei file
 fino al nanosecondo, le funzioni fin qui esaminate non consentono di impostare


@@ -2156,13 +2181,13 @@ kernel 2.6.22, e supportate dalle \acr{glibc} a partire dalla versione
 sostanzialmente una estensione di \func{futimes} che consente di specificare i
 tempi con precisione maggiore, la seconda supporta invece, rispetto ad
 \func{utimes}, una sintassi più complessa che, come vedremo in
 sostanzialmente una estensione di \func{futimes} che consente di specificare i
 tempi con precisione maggiore, la seconda supporta invece, rispetto ad
 \func{utimes}, una sintassi più complessa che, come vedremo in

-sez.~\ref{sec:file_openat},\footnote{si rimanda pertanto la spiegazione del
-  significato degli argomenti aggiuntivi alla trattazione generica delle varie
-  funzioni che usano la stessa sintassi, effettuata in
-  sez.~\ref{sec:file_openat}.}  consente una indicazione sicura dei
+sez.~\ref{sec:file_openat} consente una indicazione sicura dei

 \textit{pathname relativi} specificando la directory da usare come riferimento
 in \param{dirfd} e la possibilità di usare \param{flags} per indicare alla
 \textit{pathname relativi} specificando la directory da usare come riferimento
 in \param{dirfd} e la possibilità di usare \param{flags} per indicare alla

-funzione di dereferenziare o meno i link simbolici.
+funzione di dereferenziare o meno i link simbolici; si rimanda pertanto la
+spiegazione del significato degli argomenti aggiuntivi alla trattazione
+generica delle varie funzioni che usano la stessa sintassi, effettuata in
+sez.~\ref{sec:file_openat}.

 
 
 \section{Il controllo di accesso ai file}
 
 
 \section{Il controllo di accesso ai file}


@@ -2683,16 +2708,16 @@ in particolare accade che:
 \end{enumerate}
 
 Per alcuni filesystem\footnote{i filesystem più comuni (\textsl{ext2},
 \end{enumerate}
 
 Per alcuni filesystem\footnote{i filesystem più comuni (\textsl{ext2},

-  \textsl{ext3}, \textsl{reiserfs}) supportano questa caratteristica, che è
-  mutuata da BSD.} è inoltre prevista un'ulteriore misura di sicurezza, volta
-a scongiurare l'abuso dei \itindex{suid~bit} bit \acr{suid} e \acr{sgid}; essa
-consiste nel cancellare automaticamente questi bit dai permessi di un file
-qualora un processo che non appartenga all'amministratore\footnote{per la
-  precisione un processo che non dispone della \itindex{capabilities} capacità
-  \const{CAP\_FSETID}, vedi sez.~\ref{sec:proc_capabilities}.} effettui una
-scrittura. In questo modo anche se un utente malizioso scopre un file
-\acr{suid} su cui può scrivere, un'eventuale modifica comporterà la perdita di
-questo privilegio.
+  \textsl{ext3}, \textsl{ext4}, \textsl{reiserfs}) supportano questa
+  caratteristica, che è mutuata da BSD.} è inoltre prevista un'ulteriore
+misura di sicurezza, volta a scongiurare l'abuso dei \itindex{suid~bit} bit
+\acr{suid} e \acr{sgid}; essa consiste nel cancellare automaticamente questi
+bit dai permessi di un file qualora un processo che non appartenga
+all'amministratore\footnote{per la precisione un processo che non dispone
+  della \itindex{capabilities} capacità \const{CAP\_FSETID}, vedi
+  sez.~\ref{sec:proc_capabilities}.} effettui una scrittura. In questo modo
+anche se un utente malizioso scopre un file \acr{suid} su cui può scrivere,
+un'eventuale modifica comporterà la perdita di questo privilegio.

 
 Le funzioni \func{chmod} e \func{fchmod} ci permettono di modificare i
 permessi di un file, resta però il problema di quali sono i permessi assegnati
 
 Le funzioni \func{chmod} e \func{fchmod} ci permettono di modificare i
 permessi di un file, resta però il problema di quali sono i permessi assegnati


@@ -2951,1936 +2976,1938 @@ dell'interfaccia classica dei sistemi unix-like, principalmente utilizzate a
 scopi di sicurezza, che sono state introdotte nelle versioni più recenti di
 Linux.
 
 scopi di sicurezza, che sono state introdotte nelle versioni più recenti di
 Linux.
 

+\subsection{Gli attributi estesi}
+\label{sec:file_xattr}

 
 

-\subsection{La gestione delle \textit{capabilities}}
-\label{sec:proc_capabilities}
-
-\itindbeg{capabilities} 
-
-Come accennato in sez.~\ref{sec:proc_access_id} l'architettura classica della
-gestione dei privilegi in un sistema unix-like ha il sostanziale problema di
-fornire all'amministratore dei poteri troppo ampi, questo comporta che anche
-quando si siano predisposte delle misure di protezione per in essere in grado
-di difendersi dagli effetti di una eventuale compromissione del
-sistema,\footnote{come montare un filesystem in sola lettura per impedirne
-  modifiche, o marcare un file come immutabile.} una volta che questa sia
-stata effettuata e si siano ottenuti i privilegi di amministratore, queste
-potranno essere comunque rimosse.\footnote{nei casi elencati nella precedente
-  nota si potrà sempre rimontare il sistema in lettura-scrittura, o togliere
-  la marcatura di immutabilità.}
-
-Il problema consiste nel fatto che nell'architettura tradizionale di un
-sistema unix-like i controlli di accesso sono basati su un solo livello di
-separazione: per i processi normali essi sono posti in atto, mentre per i
-processi con i privilegi di amministratore essi non vengono neppure eseguiti;
-per questo motivo non era previsto alcun modo per evitare che un processo con
-diritti di amministratore non potesse eseguire certe operazioni, o per cedere
-definitivamente alcuni privilegi da un certo momento in poi.
-
-Per ovviare a tutto ciò, a partire dai kernel della serie 2.2, è stato
-introdotto un meccanismo, detto \textit{capabilities}, che consentisse di
-suddividere i vari privilegi tradizionalmente associati all'amministratore in
-un insieme di \textsl{capacità} distinte.  L'idea era che queste capacità
-potessero essere abilitate e disabilitate in maniera indipendente per ciascun
-processo con privilegi di amministratore, permettendo così una granularità
-molto più fine nella distribuzione degli stessi che evitasse la originaria
-situazione di ``\textsl{tutto o nulla}''.
-
-Il meccanismo completo delle \textit{capabilities}\footnote{l'implementazione
-  si rifà ad una bozza di quello che doveva diventare lo standard POSIX.1e,
-  poi abbandonato.} prevede inoltre la possibilità di associare le stesse ai
-singoli file eseguibili, in modo da poter stabilire quali capacità possono
-essere utilizzate quando viene messo in esecuzione uno specifico programma; ma
-il supporto per questa funzionalità è stato introdotto soltanto a partire dal
-kernel 2.6.24; fino ad allora doveva essere il programma stesso ad eseguire
-una riduzione esplicita delle sue capacità, cosa che ha reso l'uso di questa
-funzionalità poco diffuso, vista la presenza di meccanismi alternativi come
-\index{SELinux} SELinux.
-
-Per gestire questo meccanismo ciascun processo porta con sé tre distinti
-insiemi di \textit{capabilities}, che vengono denominati rispettivamente
-\textit{effective}, \textit{permitted} ed \textit{inherited}. Questi insiemi
-vengono mantenuti in forma di tre diverse maschere binarie,\footnote{il kernel
-  li mantiene, come i vari identificatori di sez.~\ref{sec:proc_setuid},
-  all'interno della \struct{task\_struct} di ciascun processo (vedi
-  fig.~\ref{fig:proc_task_struct}), nei tre campi \texttt{cap\_effective},
-  \texttt{cap\_inheritable}, \texttt{cap\_permitted} del tipo
-  \texttt{kernel\_cap\_t}; questo è attualmente definito come intero a 32 bit,
-  il che comporta un massimo di 32 \textit{capabilities} distinte.} in cui
-ciascun bit corrisponde ad una capacità diversa.
-
-L'utilizzo di tre distinti insiemi serve a fornire una interfaccia flessibile
-per l'uso delle \textit{capabilities}, con scopi analoghi a quelli per cui
-sono mantenuti i diversi insiemi di identificatori di
-sez.~\ref{sec:proc_setuid}; il loro significato è il seguente:
-\begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}}
-\item[\textit{effective}] l'insieme delle \textit{capabilities}
-  ``\textsl{effettive}'', cioè di quelle che vengono effettivamente usate dal
-  kernel quando deve eseguire il controllo di accesso per le varie operazioni
-  compiute dal processo.
-\item[\textit{permitted}] l'insieme delle \textit{capabilities}
-  ``\textsl{permesse}'', cioè l'insieme di quelle capacità che un processo
-  \textsl{può} impostare come \textsl{effettive}. Se un processo cancella una
-  capacità da questo insieme non potrà più riassumerla (almeno che non esegua
-  un programma che è \acr{suid} di root).
-\item[\textit{inherited}] l'insieme delle \textit{capabilities}
-  ``\textsl{ereditabili}'', cioè quelle che vengono trasmesse ad un nuovo
-  programma eseguito attraverso una chiamata ad \func{exec} (con l'eccezione
-  del caso che questo sia \acr{suid} di root).
-\label{sec:capabilities_set}
-\end{basedescript}
-
-Oltre a questi tre insiemi, che sono relativi al singolo processo, il kernel
-mantiene un insieme generale valido per tutto il sistema, chiamato
-\itindex{capabilities~bounding~set} \textit{capabilities bounding set}. Ogni
-volta che un programma viene posto in esecuzione con \func{exec} il contenuto
-degli insiemi \textit{effective} e \textit{permitted} vengono mascherati con
-un \textsl{AND} binario del contenuto corrente del \textit{capabilities
-  bounding set}, così che il nuovo processo potrà disporre soltanto delle
-capacità in esso elencate.
-
-Il \textit{capabilities bounding set} è un parametro di sistema, accessibile
-attraverso il contenuto del file \procfile{/proc/sys/kernel/cap-bound}, che per
-questa sua caratteristica consente di impostare un limite generale alle
-capacità che possono essere accordate ai vari processi.  Questo valore può
-essere impostato ad un valore arbitrario esclusivamente dal primo processo
-eseguito nel sistema (di norma cioè da \texttt{/sbin/init}), ogni processo
-eseguito successivamente (cioè con \textsl{pid} diverso da 1) anche se
-eseguito con privilegi di amministratore potrà soltanto rimuovere uno dei bit
-già presenti dell'insieme: questo significa che una volta rimossa una
-\textit{capability} dal \textit{capabilities bounding set} essa non sarà più
-disponibile, neanche per l'amministratore, a meno di un riavvio.
+\itindbeg{Extended~Attributes}

 
 

-Quando un programma viene messo in esecuzione\footnote{cioè quando viene
-  eseguita la \func{execve} con cui lo si lancia; in corrispondenza di una
-  \func{fork} le \textit{capabilities} non vengono modificate.} esso eredita
-(nel senso che assume negli insiemi \textit{effective} e \textit{permitted})
-le \textit{capabilities} mantenute nell'insieme \textit{inherited}, a meno che
-non sia eseguito un programma \acr{suid} di root o la \func{exec} sia stata
-eseguita da un programma con \textsl{uid} reale zero; in tal caso il programma
-ottiene tutte le \textit{capabilities} presenti nel \textit{capabilities
-  bounding set}. In questo modo si può far si che ad un processo eseguito in
-un secondo tempo possano essere trasmesse solo un insieme limitato di
-capacità, impedendogli di recuperare quelle assenti nell'insieme
-\textit{inherited}. Si tenga presente invece che attraverso una \func{fork}
-vengono mantenute le stesse capacità del processo padre.
+Nelle sezioni precedenti abbiamo trattato in dettaglio le varie informazioni
+che il sistema mantiene negli \itindex{inode} \textit{inode}, e le varie
+funzioni che permettono di modificarle.  Si sarà notato come in realtà queste
+informazioni siano estremamente ridotte.  Questo è dovuto al fatto che Unix
+origina negli anni '70, quando le risorse di calcolo e di spazio disco erano
+minime. Con il venir meno di queste restrizioni è incominciata ad emergere
+l'esigenza di poter associare ai file delle ulteriori informazioni astratte
+(quelli che vengono chiamati i \textsl{meta-dati}) che però non potevano
+trovare spazio nei dati classici mantenuti negli \itindex{inode}
+\textit{inode}.

 
 

+Per risolvere questo problema alcuni sistemi unix-like (e fra questi anche
+Linux) hanno introdotto un meccanismo generico, detto \textit{Extended
+  Attributes} che consenta di associare delle informazioni ai singoli
+file.\footnote{l'uso più comune è quello della ACL, che tratteremo nella
+  prossima sezione.} Gli \textsl{attributi estesi} non sono altro che delle
+coppie nome/valore che sono associate permanentemente ad un oggetto sul
+filesystem, analoghi di quello che sono le variabili di ambiente (vedi
+sez.~\ref{sec:proc_environ}) per un processo.

 
 

-% TODO verificare per process capability bounding set, vedi:
-%  http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3b7391de67da515c91f48aa371de77cb6cc5c07e
+Altri sistemi (come Solaris, MacOS e Windows) hanno adottato un meccanismo
+diverso in cui ad un file sono associati diversi flussi di dati, su cui
+possono essere mantenute ulteriori informazioni, che possono essere accedute
+con le normali operazioni di lettura e scrittura. Questi non vanno confusi con
+gli \textit{Extended Attributes} (anche se su Solaris hanno lo stesso nome),
+che sono un meccanismo molto più semplice, che pur essendo limitato (potendo
+contenere solo una quantità limitata di informazione) hanno il grande
+vantaggio di essere molto più semplici da realizzare, più
+efficienti,\footnote{cosa molto importante, specie per le applicazioni che
+  richiedono una gran numero di accessi, come le ACL.} e di garantire
+l'atomicità di tutte le operazioni.

 
 

-% TODO capire cosa cambia con i patch vari, vedi
-% http://lwn.net/Articles/280279/  
-% http://lwn.net/Articles/256519/
-% http://lwn.net/Articles/211883/
+In Linux gli attributi estesi sono sempre associati al singolo \itindex{inode}
+\textit{inode} e l'accesso viene sempre eseguito in forma atomica, in lettura
+il valore corrente viene scritto su un buffer in memoria, mentre la scrittura
+prevede che ogni valore precedente sia sovrascritto.

 
 

+Si tenga presente che non tutti i filesystem supportano gli \textit{Extended
+  Attributes}; al momento della scrittura di queste dispense essi sono
+presenti solo sui vari \textsl{extN}, \textsl{ReiserFS}, \textsl{JFS},
+\textsl{XFS} e \textsl{Btrfs}.\footnote{l'elenco è aggiornato a Luglio 2011.}
+Inoltre a seconda della implementazione ci possono essere dei limiti sulla
+quantità di attributi che si possono utilizzare.\footnote{ad esempio nel caso
+  di \textsl{ext2} ed \textsl{ext3} è richiesto che essi siano contenuti
+  all'interno di un singolo blocco (pertanto con dimensioni massime pari a
+  1024, 2048 o 4096 byte a seconda delle dimensioni di quest'ultimo impostate
+  in fase di creazione del filesystem), mentre con \textsl{XFS} non ci sono
+  limiti ed i dati vengono memorizzati in maniera diversa (nell'\textit{inode}
+  stesso, in un blocco a parte, o in una struttura ad albero dedicata) per
+  mantenerne la scalabilità.} Infine lo spazio utilizzato per mantenere gli
+attributi estesi viene tenuto in conto per il calcolo delle quote di utente e
+gruppo proprietari del file.

 
 

-Un elenco delle delle \textit{capabilities} disponibili su Linux, con una
-breve descrizione ed il nome delle costanti che le identificano, è riportato
-in tab.~\ref{tab:proc_capabilities};\footnote{l'elenco presentato questa
-  tabella, ripreso dalla pagina di manuale (accessibile con \texttt{man
-    capabilities}) e dalle definizioni in \texttt{linux/capabilities.h}, è
-  aggiornato al kernel 2.6.26.} la tabella è divisa in due parti, la prima
-riporta le \textit{capabilities} previste anche nella bozza dello standard
-POSIX1.e, la seconda quelle specifiche di Linux.  Come si può notare dalla
-tabella alcune \textit{capabilities} attengono a singole funzionalità e sono
-molto specializzate, mentre altre hanno un campo di applicazione molto vasto,
-che è opportuno dettagliare maggiormente.
+Come meccanismo per mantenere informazioni aggiuntive associate al singolo
+file, gli \textit{Extended Attributes} possono avere usi anche molto diversi
+fra loro.  Per poterli distinguere allora sono stati suddivisi in
+\textsl{classi}, a cui poter applicare requisiti diversi per l'accesso e la
+gestione. Per questo motivo il nome di un attributo deve essere sempre
+specificato nella forma \texttt{namespace.attribute}, dove \texttt{namespace}
+fa riferimento alla classe a cui l'attributo appartiene, mentre
+\texttt{attribute} è il nome ad esso assegnato. In tale forma il nome di un
+attributo esteso deve essere univoco. Al momento\footnote{della scrittura di
+  questa sezione, kernel 2.6.23, ottobre 2007.} sono state definite le quattro
+classi di attributi riportate in tab.~\ref{tab:extended_attribute_class}.

 
 

-\begin{table}[!h!bt]
+\begin{table}[htb]

   \centering
   \footnotesize
   \begin{tabular}{|l|p{12cm}|}
     \hline
   \centering
   \footnotesize
   \begin{tabular}{|l|p{12cm}|}
     \hline

-    \textbf{Capacità}&\textbf{Descrizione}\\
+    \textbf{Nome} & \textbf{Descrizione} \\

     \hline
     \hline
     \hline
     \hline

-%
-% POSIX-draft defined capabilities.
-%
-    \const{CAP\_AUDIT\_WRITE}&La capacità di scrivere dati nel giornale di
-                              auditing del kernel (dal kernel 2.6.11).\\ 
-    \const{CAP\_AUDIT\_CONTROL}& La capacità di abilitare e disabilitare il
-                              controllo dell'auditing (dal kernel 2.6.11).\\ 
-    % TODO verificare questa roba dell'auditing
-    \const{CAP\_CHOWN}      & La capacità di cambiare proprietario e gruppo
-                              proprietario di un file (vedi
-                              sez.~\ref{sec:file_ownership_management}).\\
-    \const{CAP\_DAC\_OVERRIDE}& La capacità di evitare il controllo dei
-                              permessi di lettura, scrittura ed esecuzione dei
-                              file,\footnotemark (vedi
-                              sez.~\ref{sec:file_access_control}).\\
-    \const{CAP\_DAC\_READ\_SEARCH}& La capacità di evitare il controllo dei
-                              permessi di lettura ed esecuzione per
-                              le directory (vedi
-                              sez.~\ref{sec:file_access_control}).\\
-    \const{CAP\_FOWNER}     & La capacità di evitare il controllo della
-                              proprietà di un file per tutte
-                              le operazioni privilegiate non coperte dalle
-                              precedenti \const{CAP\_DAC\_OVERRIDE} e
-                              \const{CAP\_DAC\_READ\_SEARCH}.\\
-    \const{CAP\_FSETID}     & La capacità di evitare la cancellazione
-                              automatica dei bit \itindex{suid~bit} \acr{suid}
-                              e \itindex{sgid~bit} \acr{sgid} quando un file
-                              per i quali sono impostati viene modificato da
-                              un processo senza questa capacità e la capacità
-                              di impostare il bit \acr{sgid} su un file anche
-                              quando questo è relativo ad un gruppo cui non si
-                              appartiene (vedi
-                              sez.~\ref{sec:file_perm_management}).\\ 
-    \const{CAP\_SETFCAP}    & La capacità di impostare le
-                              \textit{capabilities} di un file (dal kernel
-                              2.6.24).\\  
-    \const{CAP\_KILL}       & La capacità di mandare segnali a qualunque
-                              processo (vedi sez.~\ref{sec:sig_kill_raise}).\\
-    \const{CAP\_SETGID}     & La capacità di manipolare i group ID dei
-                              processi, sia il principale che i supplementari,
-                              (vedi sez.~\ref{sec:proc_setgroups}) che quelli
-                              trasmessi tramite i socket \textit{unix domain}
-                              (vedi sez.~\ref{sec:unix_socket}).\\
-    \const{CAP\_SETUID}     & La capacità di manipolare gli user ID del
-                              processo (vedi sez.~\ref{sec:proc_setuid}) e di
-                              trasmettere un user ID arbitrario nel passaggio
-                              delle credenziali coi socket \textit{unix
-                                domain} (vedi sez.~\ref{sec:unix_socket}).\\ 
-%
-% Linux specific capabilities
-%
-\hline
-    \const{CAP\_IPC\_LOCK}  & La capacità di effettuare il \textit{memory
-                              locking} \itindex{memory~locking} con le
-                              funzioni \func{mlock}, \func{mlockall},
-                              \func{shmctl}, \func{mmap} (vedi
-                              sez.~\ref{sec:proc_mem_lock} e 
-                              sez.~\ref{sec:file_memory_map}). \\  
-    \const{CAP\_IPC\_OWNER} & La capacità di evitare il controllo dei permessi
-                              per le operazioni sugli oggetti di
-                              intercomunicazione fra processi (vedi
-                              sez.~\ref{sec:ipc_sysv}).\\  
-    \const{CAP\_LEASE}      & La capacità di creare dei \textit{file lease}
-                              \index{file!lease} (vedi
-                              sez.~\ref{sec:file_asyncronous_lease})
-                              pur non essendo proprietari del file (dal kernel
-                              2.4).\\ 
-    \const{CAP\_LINUX\_IMMUTABLE}& La capacità di impostare sui file gli
-                              attributi \textit{immutable} e
-                              \itindex{append~mode} \textit{append only} (se
-                              supportati).\\
-    \const{CAP\_MKNOD}      & La capacità di creare
-                              \index{file!di~dispositivo} file di dispositivo
-                              con \func{mknod} (vedi
-                              sez.~\ref{sec:file_mknod}) (dal kernel 2.4).\\ 
-    \const{CAP\_NET\_ADMIN} & La capacità di eseguire alcune operazioni
-                              privilegiate sulla rete.\\
-    \const{CAP\_NET\_BIND\_SERVICE}& La capacità di porsi in ascolto
-                              su porte riservate (vedi
-                              sez.~\ref{sec:TCP_func_bind}).\\ 
-    \const{CAP\_NET\_BROADCAST}& La capacità di consentire l'uso di socket in
-                              \itindex{broadcast} \textit{broadcast} e
-                              \itindex{multicast} \textit{multicast}.\\ 
-    \const{CAP\_NET\_RAW}   & La capacità di usare socket \texttt{RAW} e
-                              \texttt{PACKET} (vedi sez.~\ref{sec:sock_type}).\\
-    \const{CAP\_SETPCAP}    & La capacità di impostare o rimuovere una
-                              capacità.\\ 
-    % TODO cambiata nel 2.4.24 rc1 ? 
-    \const{CAP\_SYS\_ADMIN} & La capacità di eseguire una serie di compiti
-                              amministrativi. \\
-    \const{CAP\_SYS\_BOOT}  & La capacità di fare eseguire un riavvio del
-                              sistema.\\
-% TODO trattare reboot e kexec 
-    \const{CAP\_SYS\_CHROOT}& La capacità di eseguire la funzione
-                              \func{chroot} (vedi
-                              sez.~\ref{sec:file_chroot}).\\
-    \const{CAP\_MAC\_ADMIN} & La capacità amministrare il MAC di Smack (dal
-                              kernel 2.6.25).\\  
-    \const{CAP\_MAC\_OVERRIDE}& La capacità evitare il MAC di Smack (dal
-                              kernel 2.6.25).\\  
-    \const{CAP\_SYS\_MODULE}& La capacità di caricare e rimuovere moduli del
-                              kernel. \\ 
-    \const{CAP\_SYS\_NICE}  & La capacità di modificare le priorità dei
-                              processi. \\ 
-    \const{CAP\_SYS\_PACCT} & La capacità di usare le funzioni di
-                              \textit{accounting} dei processi (vedi
-                              sez.~\ref{sec:sys_bsd_accounting}).\\ 
-    \const{CAP\_SYS\_PTRACE}& La capacità  di tracciare qualunque processo con
-                              \func{ptrace} (vedi 
-                              sez.~\ref{sec:xxx_ptrace}).\\
-    \const{CAP\_SYS\_RAWIO} & La capacità di eseguire operazioni sulle porte
-                              di I/O con \func{ioperm} e \func{iopl} (vedi
-                              sez.~\ref{sec:file_io_port}).\\
-    \const{CAP\_SYS\_RESOURCE}& La capacità di superare le limitazioni sulle
-                              risorse.\\ 
-    \const{CAP\_SYS\_TIME}  & La capacità di modificare il tempo di sistema
-                              (vedi sez.~\ref{sec:sys_time}).\\ 
-    \const{CAP\_SYS\_TTY\_CONFIG}& La capacità di simulare un \textit{hangup}
-                              della console, con la funzione
-                              \func{vhangup}.\\
+    \texttt{security}&Gli \textit{extended security attributes}: vengono
+                      utilizzati dalle estensioni di sicurezza del kernel (i
+                      \itindex{Linux~Security~Modules} \textit{Linux 
+                        Security Modules}), per le realizzazione di meccanismi
+                      evoluti di controllo di accesso come \index{SELinux}
+                      SELinux o le \textit{capabilities} dei file di
+                      sez.~\ref{sec:proc_capabilities}.\\ 
+    \texttt{system} & Gli \textit{extended security attributes}: sono usati
+                      dal kernel per memorizzare dati di sistema associati ai
+                      file come le \itindex{Access~Control~List} ACL (vedi
+                      sez.~\ref{sec:file_ACL}) o le \itindex{capabilities}
+                      \textit{capabilities} (vedi
+                      sez.~\ref{sec:proc_capabilities}).\\
+    \texttt{trusted}& I \textit{trusted extended attributes}: vengono
+                      utilizzati per poter realizzare in user space 
+                      meccanismi che consentano di mantenere delle
+                      informazioni sui file che non devono essere accessibili
+                      ai processi ordinari.\\
+    \texttt{user}   & Gli \textit{extended user attributes}: utilizzati per
+                      mantenere informazioni aggiuntive sui file (come il
+                      \textit{mime-type}, la codifica dei caratteri o del
+                      file) accessibili dagli utenti.\\

     \hline
   \end{tabular}
     \hline
   \end{tabular}

-  \caption{Le costanti che identificano le \textit{capabilities} presenti nel
-    kernel.}
-\label{tab:proc_capabilities}
+  \caption{I nomi utilizzati valore di \texttt{namespace} per distinguere le
+    varie classi di \textit{Extended Attributes}.}
+  \label{tab:extended_attribute_class}

 \end{table}
 
 \end{table}
 

-\footnotetext{vale a dire i permessi caratteristici del modello classico del
-  controllo di accesso chiamato \itindex{Discrectionary~Access~Control~(DAC)}
-  \textit{Discrectionary Access Control} (da cui il nome DAC).}
-
-% TODO aggiungere CAP_SYSLOG, citata in http://lwn.net/Articles/429595/

 
 

-La prima di queste capacità ``\textsl{ampie}'' è \const{CAP\_FOWNER}, che
-rimuove le restrizioni poste ad un processo che non ha la proprietà di un file
-in un vasto campo di operazioni;\footnote{vale a dire la richiesta che
-  l'user-ID effettivo del processo (o meglio il \textit{filesystem user-ID},
-  vedi sez.~\ref{sec:proc_setuid}) coincida con quello del proprietario.}
-queste comprendono i cambiamenti dei permessi e dei tempi del file (vedi
-sez.~\ref{sec:file_perm_management} e sez.~\ref{sec:file_file_times}), le
-impostazioni degli attributi estesi e delle ACL (vedi
-sez.~\ref{sec:file_xattr} e \ref{sec:file_ACL}), poter ignorare lo
-\itindex{sticky~bit} \textit{sticky bit} nella cancellazione dei file (vedi
-sez.~\ref{sec:file_special_perm}), la possibilità di impostare il flag di
-\const{O\_NOATIME} con \func{open} e \func{fcntl} (vedi
-sez.~\ref{sec:file_open} e sez.~\ref{sec:file_fcntl}) senza restrizioni.
+Dato che uno degli usi degli \textit{Extended Attributes} è quello che li
+impiega per realizzare delle estensioni (come le \itindex{Access~Control~List}
+ACL, \index{SELinux} SELinux, ecc.) al tradizionale meccanismo dei controlli
+di accesso di Unix, l'accesso ai loro valori viene regolato in maniera diversa
+a seconda sia della loro classe sia di quali, fra le estensioni che li
+utilizzano, sono poste in uso. In particolare, per ciascuna delle classi
+riportate in tab.~\ref{tab:extended_attribute_class}, si hanno i seguenti
+casi:
+\begin{basedescript}{\desclabelwidth{1.7cm}\desclabelstyle{\nextlinelabel}}
+\item[\texttt{security}] L'accesso agli \textit{extended security attributes}
+  dipende dalle politiche di sicurezza stabilite da loro stessi tramite
+  l'utilizzo di un sistema di controllo basato sui
+  \itindex{Linux~Security~Modules} \textit{Linux Security Modules} (ad esempio
+  \index{SELinux} SELinux). Pertanto l'accesso in lettura o scrittura dipende
+  dalle politiche di sicurezza implementate all'interno dal modulo di
+  sicurezza che si sta utilizzando al momento (ciascuno avrà le sue). Se non è
+  stato caricato nessun modulo di sicurezza l'accesso in lettura sarà
+  consentito a tutti i processi, mentre quello in scrittura solo ai processi
+  con privilegi amministrativi dotati della \index{capabilities}
+  \textit{capability} \const{CAP\_SYS\_ADMIN}.

 
 

-Una seconda capacità che copre diverse operazioni, in questo caso riguardanti
-la rete, è \const{CAP\_NET\_ADMIN}, che consente di impostare le opzioni
-privilegiate dei socket (vedi sez.~\ref{sec:sock_generic_options}), abilitare
-il \itindex{multicast} \textit{multicasting}, eseguire la configurazione delle
-interfacce di rete (vedi sez.~\ref{sec:sock_ioctl_netdevice}) ed impostare la
-tabella di instradamento.
+\item[\texttt{system}] Anche l'accesso agli \textit{extended system
+    attributes} dipende dalle politiche di accesso che il kernel realizza
+  anche utilizzando gli stessi valori in essi contenuti. Ad esempio nel caso
+  delle \itindex{Access~Control~List} ACL l'accesso è consentito in lettura ai
+  processi che hanno la capacità di eseguire una ricerca sul file (cioè hanno
+  il permesso di lettura sulla directory che contiene il file) ed in scrittura
+  al proprietario del file o ai processi dotati della \textit{capability}
+  \index{capabilities} \const{CAP\_FOWNER}.\footnote{vale a dire una politica
+    di accesso analoga a quella impiegata per gli ordinari permessi dei file.}

 
 

-Una terza \textit{capability} con vasto campo di applicazione è
-\const{CAP\_SYS\_ADMIN}, che copre una serie di operazioni amministrative,
-come impostare le quote disco (vedi sez.\ref{sec:disk_quota}), attivare e
-disattivare la swap, montare, rimontare e smontare filesystem (vedi
-sez.~\ref{sec:sys_file_config}), effettuare operazioni di controllo sugli
-oggetti dell'IPC di SysV (vedi sez.~\ref{sec:ipc_sysv}), operare sugli
-attributi estesi di classe \texttt{security} o \texttt{trusted} (vedi
-sez.~\ref{sec:file_xattr}), specificare un user-ID arbitrario nella
-trasmissione delle credenziali dei socket (vedi sez.~\ref{sec:socket_xxx}),
-assegnare classi privilegiate per lo scheduling dell'I/O (vedi
-sez.~\ref{sec:io_priority}), superare il limite di sistema sul numero massimo
-di file aperti,\footnote{quello indicato da \procfile{/proc/sys/fs/file-max}.}
-effettuare operazioni privilegiate sulle chiavi mantenute dal kernel (vedi
-sez.~\ref{sec:io_priority}), usare la funzione \func{lookup\_dcookie} (vedi
-sez.~\ref{sec:xxx_profiling}), usare \const{CLONE\_NEWNS} con \func{unshare},
-(vedi sez.~\ref{sec:process_clone}).
+\item[\texttt{trusted}] L'accesso ai \textit{trusted extended attributes}, sia
+  per la lettura che per la scrittura, è consentito soltanto ai processi con
+  privilegi amministrativi dotati della \index{capabilities}
+  \textit{capability} \const{CAP\_SYS\_ADMIN}. In questo modo si possono
+  utilizzare questi attributi per realizzare in user space dei meccanismi di
+  controllo che accedono ad informazioni non disponibili ai processi ordinari.

 
 

-Originariamente \const{CAP\_SYS\_NICE} riguardava soltanto la capacità di
-aumentare le priorità di esecuzione dei processi, come la diminuzione del
-valore di \textit{nice} (vedi sez.~\ref{sec:proc_sched_stand}), l'uso delle
-priorità \textit{real-time} (vedi sez.~\ref{sec:proc_real_time}), o
-l'impostazione delle affinità di processore (vedi
-sez.~\ref{sec:proc_sched_multiprocess}); ma con l'introduzione di priorità
-anche riguardo le operazioni di accesso al disco, e, nel caso di sistemi NUMA,
-alla memoria, essa viene a coprire anche la possibilità di assegnare priorità
-arbitrarie nell'accesso a disco (vedi sez.~\ref{sec:io_priority}) e nelle
-politiche di allocazione delle pagine di memoria ai nodi di un sistema NUMA.
+\item[\texttt{user}] L'accesso agli \textit{extended user attributes} è
+  regolato dai normali permessi dei file: occorre avere il permesso di lettura
+  per leggerli e quello di scrittura per scriverli o modificarli. Dato l'uso
+  di questi attributi si è scelto di applicare al loro accesso gli stessi
+  criteri che si usano per l'accesso al contenuto dei file (o delle directory)
+  cui essi fanno riferimento. Questa scelta vale però soltanto per i file e le
+  directory ordinarie, se valesse in generale infatti si avrebbe un serio
+  problema di sicurezza dato che esistono diversi oggetti sul filesystem per i
+  quali è normale avere avere il permesso di scrittura consentito a tutti gli
+  utenti, come i link simbolici, o alcuni \index{file!di~dispositivo} file di
+  dispositivo come \texttt{/dev/null}. Se fosse possibile usare su di essi gli
+  \textit{extended user attributes} un utente qualunque potrebbe inserirvi
+  dati a piacere.\footnote{la cosa è stata notata su XFS, dove questo
+    comportamento permetteva, non essendovi limiti sullo spazio occupabile
+    dagli \textit{Extended Attributes}, di bloccare il sistema riempiendo il
+    disco.}

 
 

-Infine la \textit{capability} \const{CAP\_SYS\_RESOURCE} attiene alla
-possibilità di superare i limiti imposti sulle risorse di sistema, come usare
-lo spazio disco riservato all'amministratore sui filesystem che lo supportano,
-usare la funzione \func{ioctl} per controllare il \textit{journaling} sul
-filesystem \acr{ext3}, non subire le quote disco, aumentare i limiti sulle
-risorse (vedi sez.~\ref{sec:sys_resource_limit}) e sulle dimensioni dei
-messaggi delle code del SysV IPC (vedi sez.~\ref{sec:ipc_sysv_mq}).
+  La semantica del controllo di accesso indicata inoltre non avrebbe alcun
+  senso al di fuori di file e directory: i permessi di lettura e scrittura per
+  un \index{file!di~dispositivo} file di dispositivo attengono alle capacità
+  di accesso al dispositivo sottostante,\footnote{motivo per cui si può
+    formattare un disco anche se \texttt{/dev} è su un filesystem in sola
+    lettura.} mentre per i link simbolici questi vengono semplicemente
+  ignorati: in nessuno dei due casi hanno a che fare con il contenuto del
+  file, e nella discussione relativa all'uso degli \textit{extended user
+    attributes} nessuno è mai stato capace di indicare una qualche forma
+  sensata di utilizzo degli stessi per link simbolici o
+  \index{file!di~dispositivo} file di dispositivo, e neanche per le fifo o i
+  socket.  Per questo motivo essi sono stati completamente disabilitati per
+  tutto ciò che non sia un file regolare o una directory.\footnote{si può
+    verificare la semantica adottata consultando il file \texttt{fs/xattr.c}
+    dei sorgenti del kernel.} Inoltre per le directory è stata introdotta una
+  ulteriore restrizione, dovuta di nuovo alla presenza ordinaria di permessi
+  di scrittura completi su directory come \texttt{/tmp}. Per questo motivo,
+  per evitare eventuali abusi, se una directory ha lo \itindex{sticky~bit}
+  \textit{sticky bit} attivo sarà consentito scrivere i suoi \textit{extended
+    user attributes} soltanto se si è proprietari della stessa, o si hanno i
+  privilegi amministrativi della capability \index{capabilities}
+  \const{CAP\_FOWNER}.
+\end{basedescript}

 
 

+Le funzioni per la gestione degli attributi estesi, come altre funzioni di
+gestione avanzate specifiche di Linux, non fanno parte delle \acr{glibc}, e
+sono fornite da una apposita libreria, \texttt{libattr}, che deve essere
+installata a parte;\footnote{la versione corrente della libreria è
+  \texttt{libattr1}.}  pertanto se un programma le utilizza si dovrà indicare
+esplicitamente l'uso della suddetta libreria invocando il compilatore con
+l'opzione \texttt{-lattr}.  

 
 

-Per la gestione delle \textit{capabilities} il kernel mette a disposizione due
-funzioni che permettono rispettivamente di leggere ed impostare i valori dei
-tre insiemi illustrati in precedenza. Queste due funzioni sono \funcd{capget}
-e \funcd{capset} e costituiscono l'interfaccia di gestione basso livello; i
-loro rispettivi prototipi sono:
+Per poter leggere gli attributi estesi sono disponibili tre diverse funzioni,
+\funcd{getxattr}, \funcd{lgetxattr} e \funcd{fgetxattr}, che consentono
+rispettivamente di richiedere gli attributi relativi a un file, a un link
+simbolico e ad un file descriptor; i rispettivi prototipi sono:

 \begin{functions}
 \begin{functions}

-  \headdecl{sys/capability.h}
+  \headdecl{sys/types.h} 
+  \headdecl{attr/xattr.h} 
+  
+  \funcdecl{ssize\_t getxattr(const char *path, const char *name, void
+    *value, size\_t size)} 

 
 

-  \funcdecl{int capget(cap\_user\_header\_t hdrp, cap\_user\_data\_t datap)}
-  Legge le \textit{capabilities}.
+  \funcdecl{ssize\_t lgetxattr(const char *path, const char *name, void
+    *value, size\_t size)} 

 
 

-  \funcdecl{int capset(cap\_user\_header\_t hdrp, const cap\_user\_data\_t
-    datap)} 
-  Imposta le \textit{capabilities}.
+  \funcdecl{ssize\_t fgetxattr(int filedes, const char *name, void *value,
+    size\_t size)}

 
 

+  Le funzioni leggono il valore di un attributo esteso.

   
   

-  \bodydesc{Entrambe le funzioni ritornano 0 in caso di successo e -1 in caso
-    di errore, nel qual caso \var{errno} può assumere i valori:
-    \begin{errlist}
-    \item[\errcode{ESRCH}] si è fatto riferimento ad un processo inesistente.
-    \item[\errcode{EPERM}] si è tentato di aggiungere una capacità
-      nell'insieme delle \textit{capabilities} permesse, o di impostare una
-      capacità non presente nell'insieme di quelle permesse negli insieme
-      delle effettive o ereditate, o si è cercato di impostare una
-      \textit{capability} di un altro processo senza avare
-      \const{CAP\_SETPCAP}. 
+  \bodydesc{Le funzioni restituiscono un intero positivo che indica la
+    dimensione dell'attributo richiesto in caso di successo, e $-1$ in caso di
+    errore, nel qual caso \var{errno} assumerà i valori:
+  \begin{errlist}
+  \item[\errcode{ENOATTR}] l'attributo richiesto non esiste.
+  \item[\errcode{ERANGE}] la dimensione \param{size} del buffer \param{value}
+    non è sufficiente per contenere il risultato.
+  \item[\errcode{ENOTSUP}] gli attributi estesi non sono supportati dal
+    filesystem o sono disabilitati.

   \end{errlist}
   \end{errlist}

-  ed inoltre \errval{EFAULT} ed \errval{EINVAL}.
-}
-
+  e tutti gli errori di \func{stat}, come \errcode{EPERM} se non si hanno i
+  permessi di accesso all'attributo. }

 \end{functions}
 
 \end{functions}
 

-Queste due funzioni prendono come argomenti due tipi di dati dedicati,
-definiti come puntatori a due strutture specifiche di Linux, illustrate in
-fig.~\ref{fig:cap_kernel_struct}. Per poterle utilizzare occorre anche
-cancellare la macro \macro{\_POSIX\_SOURCE}.\footnote{per farlo occorre
-  utilizzare la direttiva di preprocessore \direct{undef}; si dovrà cioè
-  inserire una istruzione \texttt{\#undef \_POSIX\_SOURCE} prima di includere
-  \texttt{sys/capability.h}.} Si tenga presente che le strutture di
-fig.~\ref{fig:cap_kernel_struct}, come i prototipi delle due funzioni
-\func{capget} e \func{capset}, sono soggette ad essere modificate con il
-cambiamento del kernel (in particolare i tipi di dati delle strutture) ed
-anche se finora l'interfaccia è risultata stabile, non c'è nessuna
-assicurazione che questa venga mantenuta.\footnote{anzi, visto lo scarso
-  utilizzo di questa funzionalità ci sono state varie discussioni fra gli
-  sviluppatori del kernel relative all'eliminarla o al modificarla
-  radicalmente.} Pertanto se si vogliono scrivere programmi portabili che
-possano essere eseguiti su qualunque versione del kernel è opportuno
-utilizzare le interfacce di alto livello.
-
-\begin{figure}[!htb]
-  \footnotesize
-  \centering
-  \begin{minipage}[c]{15cm}
-    \includestruct{listati/cap_user_header_t.h}
-  \end{minipage} 
-  \normalsize 
-  \caption{Definizione delle strutture a cui fanno riferimento i puntatori
-    \structd{cap\_user\_header\_t} e \structd{cap\_user\_data\_t} usati per
-    l'interfaccia di gestione di basso livello delle \textit{capabilities}.}
-  \label{fig:cap_kernel_struct}
-\end{figure}
-
-La struttura a cui deve puntare l'argomento \param{hdrp} serve ad indicare,
-tramite il campo \var{pid}, il processo del quale si vogliono leggere o
-modificare le \textit{capabilities}. Il campo \var{version} deve essere
-impostato al valore della versione delle usata dal kernel (quello indicato
-dalla costante \const{\_LINUX\_CAPABILITY\_VERSION} di
-fig.~\ref{fig:cap_kernel_struct}) altrimenti le funzioni ritorneranno con un
-errore di \errcode{EINVAL}, restituendo nel campo stesso il valore corretto
-della versione in uso.  La struttura a cui deve puntare l'argomento
-\param{datap} invece conterrà i valori letti o da impostare per i tre insiemi
-delle capacità del processo.
+Le funzioni \func{getxattr} e \func{lgetxattr} prendono come primo argomento
+un pathname che indica il file di cui si vuole richiedere un attributo, la
+sola differenza è che la seconda, se il pathname indica un link simbolico,
+restituisce gli attributi di quest'ultimo e non quelli del file a cui esso fa
+riferimento. La funzione \func{fgetxattr} prende invece come primo argomento
+un numero di file descriptor, e richiede gli attributi del file ad esso
+associato.

 
 

-Dato che le precedenti funzioni, oltre ad essere specifiche di Linux, non
-garantiscono la stabilità nell'interfaccia, è sempre opportuno effettuare la
-gestione delle \textit{capabilities} utilizzando le funzioni di libreria a
-questo dedicate. Queste funzioni, che seguono quanto previsto nelle bozze
-dello standard POSIX.1e, non fanno parte delle \acr{glibc} e sono fornite in
-una libreria a parte,\footnote{la libreria è \texttt{libcap2}, nel caso di
-  Debian può essere installata con il pacchetto omonimo.} pertanto se un
-programma le utilizza si dovrà indicare esplicitamente l'uso della suddetta
-libreria attraverso l'opzione \texttt{-lcap} del compilatore.
+Tutte e tre le funzioni richiedono di specificare nell'argomento \param{name}
+il nome dell'attributo di cui si vuole ottenere il valore. Il nome deve essere
+indicato comprensivo di prefisso del \textit{namespace} cui appartiene (uno
+dei valori di tab.~\ref{tab:extended_attribute_class}) nella forma
+\texttt{namespace.attributename}, come stringa terminata da un carattere NUL.
+Il suo valore verrà restituito nel buffer puntato dall'argomento \param{value}
+per una dimensione massima di \param{size} byte;\footnote{gli attributi estesi
+  possono essere costituiti arbitrariamente da dati testuali o binari.}  se
+quest'ultima non è sufficiente si avrà un errore di \errcode{ERANGE}.

 
 

-Le funzioni dell'interfaccia delle bozze di POSIX.1e prevedono l'uso di uno
-tipo di dato opaco, \type{cap\_t}, come puntatore ai dati mantenuti nel
-cosiddetto \textit{capability state},\footnote{si tratta in sostanza di un
-  puntatore ad una struttura interna utilizzata dalle librerie, i cui campi
-  non devono mai essere acceduti direttamente.} in sono memorizzati tutti i
-dati delle \textit{capabilities}. In questo modo è possibile mascherare i
-dettagli della gestione di basso livello, che potranno essere modificati senza
-dover cambiare le funzioni dell'interfaccia, che faranno riferimento soltanto
-ad oggetti di questo tipo.  L'interfaccia pertanto non soltanto fornisce le
-funzioni per modificare e leggere le \textit{capabilities}, ma anche quelle
-per gestire i dati attraverso \type{cap\_t}.
+Per evitare di dover indovinare la dimensione di un attributo per tentativi si
+può eseguire una interrogazione utilizzando un valore nullo per \param{size};
+in questo caso non verrà letto nessun dato, ma verrà restituito come valore di
+ritorno della funzione chiamata la dimensione totale dell'attributo esteso
+richiesto, che si potrà usare come stima per allocare un buffer di dimensioni
+sufficienti.\footnote{si parla di stima perché anche se le funzioni
+  restituiscono la dimensione esatta dell'attributo al momento in cui sono
+  eseguite, questa potrebbe essere modificata in qualunque momento da un
+  successivo accesso eseguito da un altro processo.}

 
 

-La prima funzione dell'interfaccia è quella che permette di inizializzare un
-\textit{capability state}, allocando al contempo la memoria necessaria per i
-relativi dati. La funzione è \funcd{cap\_init} ed il suo prototipo è:
+Un secondo gruppo di funzioni è quello che consente di impostare il valore di
+un attributo esteso, queste sono \funcd{setxattr}, \funcd{lsetxattr} e
+\funcd{fsetxattr}, e consentono di operare rispettivamente su un file, su un
+link simbolico o specificando un file descriptor; i loro prototipi sono:

 \begin{functions}
 \begin{functions}

-  \headdecl{sys/capability.h}
-
-  \funcdecl{cap\_t cap\_init(void)} 
-  Crea ed inizializza un \textit{capability state}.
+  \headdecl{sys/types.h} 
+  \headdecl{attr/xattr.h} 

   
   

-  \bodydesc{La funzione ritorna un valore non nullo in caso di successo e
-    \macro{NULL} in caso di errore, nel qual caso \var{errno} assumerà il
-    valore \errval{ENOMEM}.
-  }
-\end{functions}
+  \funcdecl{int setxattr(const char *path, const char *name, const void
+    *value, size\_t size, int flags)}

 
 

-La funzione restituisce il puntatore \type{cap\_t} ad uno stato inizializzato
-con tutte le \textit{capabilities} azzerate. In caso di errore (cioè quando
-non c'è memoria sufficiente ad allocare i dati) viene restituito \macro{NULL}
-ed \var{errno} viene impostata a \errval{ENOMEM}.  La memoria necessaria a
-mantenere i dati viene automaticamente allocata da \func{cap\_init}, ma dovrà
-essere disallocata esplicitamente quando non è più necessaria utilizzando, per
-questo l'interfaccia fornisce una apposita funzione, \funcd{cap\_free}, il cui
-prototipo è:
-\begin{functions}
-  \headdecl{sys/capability.h}
+  \funcdecl{int lsetxattr(const char *path, const char *name, const void
+    *value, size\_t size, int flags)}

 
 

-  \funcdecl{int cap\_free(void *obj\_d)} 
-  Disalloca la memoria allocata per i dati delle \textit{capabilities}.
+  \funcdecl{int fsetxattr(int filedes, const char *name, const void *value,
+    size\_t size, int flags)}
+
+  Impostano il valore di un attributo esteso.

   
   

-  \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
-    errore, nel qual caso \var{errno} assumerà il valore \errval{EINVAL}.
-  }
+  \bodydesc{Le funzioni restituiscono 0 in caso di successo, e $-1$ in caso di
+    errore, nel qual caso \var{errno} assumerà i valori:
+  \begin{errlist}
+  \item[\errcode{ENOATTR}] si è usato il flag \const{XATTR\_REPLACE} e
+    l'attributo richiesto non esiste.
+  \item[\errcode{EEXIST}] si è usato il flag \const{XATTR\_CREATE} ma
+    l'attributo esiste già.
+  \item[\errcode{ENOTSUP}] gli attributi estesi non sono supportati dal
+    filesystem o sono disabilitati.
+  \end{errlist}
+  Oltre a questi potranno essere restituiti tutti gli errori di \func{stat},
+  ed in particolare \errcode{EPERM} se non si hanno i permessi di accesso
+  all'attributo.  
+}

 \end{functions}
 
 \end{functions}
 

-La funzione permette di liberare la memoria allocata dalle altre funzioni
-della libreria sia per un \textit{capability state}, nel qual caso l'argomento
-dovrà essere un dato di tipo \type{cap\_t}, che per una descrizione testuale
-dello stesso,\footnote{cioè quanto ottenuto tramite la funzione
-  \func{cap\_to\_text}.} nel qual caso l'argomento dovrà essere un dato di
-tipo \texttt{char *}. Per questo l'argomento \param{obj\_d} è dichiarato come
-\texttt{void *} e deve sempre corrispondere ad un puntatore ottenuto tramite
-le altre funzioni della libreria, altrimenti la funzione fallirà con un errore
-di \errval{EINVAL}.
+Le tre funzioni prendono come primo argomento un valore adeguato al loro
+scopo, usato in maniera del tutto identica a quanto visto in precedenza per le
+analoghe che leggono gli attributi estesi. Il secondo argomento \param{name}
+deve indicare, anche in questo caso con gli stessi criteri appena visti per le
+analoghe \func{getxattr}, \func{lgetxattr} e \func{fgetxattr}, il nome
+(completo di suffisso) dell'attributo su cui si vuole operare. 

 
 

-Infine si può creare una copia di un \textit{capability state} ottenuto in
-precedenza tramite la funzione \funcd{cap\_dup}, il cui prototipo è:
-\begin{functions}
-  \headdecl{sys/capability.h}
+Il valore che verrà assegnato all'attributo dovrà essere preparato nel buffer
+puntato da \param{value}, e la sua dimensione totale (in byte) sarà indicata
+dall'argomento \param{size}. Infine l'argomento \param{flag} consente di
+controllare le modalità di sovrascrittura dell'attributo esteso, esso può
+prendere due valori: con \const{XATTR\_REPLACE} si richiede che l'attributo
+esista, nel qual caso verrà sovrascritto, altrimenti si avrà errore, mentre
+con \const{XATTR\_CREATE} si richiede che l'attributo non esista, nel qual
+caso verrà creato, altrimenti si avrà errore ed il valore attuale non sarà
+modificato.  Utilizzando per \param{flag} un valore nullo l'attributo verrà
+modificato se è già presente, o creato se non c'è.

 
 

-  \funcdecl{cap\_t cap\_dup(cap\_t cap\_p)} 
-  Duplica un \textit{capability state} restituendone una copia.
+Le funzioni finora illustrate permettono di leggere o scrivere gli attributi
+estesi, ma sarebbe altrettanto utile poter vedere quali sono gli attributi
+presenti; a questo provvedono le funzioni \funcd{listxattr},
+\funcd{llistxattr} e \funcd{flistxattr} i cui prototipi sono:
+\begin{functions}
+  \headdecl{sys/types.h} 
+  \headdecl{attr/xattr.h} 

   
   

-  \bodydesc{La funzione ritorna un valore non nullo in caso di successo e
-    \macro{NULL} in caso di errore, nel qual caso \var{errno} potrà assumere i
-    valori \errval{ENOMEM} o \errval{EINVAL}.  
-  }
-\end{functions}
+  \funcdecl{ssize\_t listxattr(const char *path, char *list, size\_t size)}

 
 

-La funzione crea una copia del \textit{capability state} posto all'indirizzo
-\param{cap\_p} che si è passato come argomento, restituendo il puntatore alla
-copia, che conterrà gli stessi valori delle \textit{capabilities} presenti
-nell'originale. La memoria necessaria viene allocata automaticamente dalla
-funzione. Una volta effettuata la copia i due \textit{capability state}
-potranno essere modificati in maniera completamente
-indipendente.\footnote{alla fine delle operazioni si ricordi però di
-  disallocare anche la copia, oltre all'originale. }
+  \funcdecl{ssize\_t llistxattr(const char *path, char *list, size\_t size)}

 
 

-Una seconda classe di funzioni di servizio previste dall'interfaccia sono
-quelle per la gestione dei dati contenuti all'interno di un \textit{capability
-  state}; la prima di queste è \funcd{cap\_clear}, il cui prototipo è:
-\begin{functions}
-  \headdecl{sys/capability.h}
+  \funcdecl{ssize\_t flistxattr(int filedes, char *list, size\_t size)}

 
 

-  \funcdecl{int cap\_clear(cap\_t cap\_p)} 
-  Inizializza un \textit{capability state} cancellando tutte le
-  \textit{capabilities}.
+  Leggono la lista degli attributi estesi di un file.

   
   

-  \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
-    errore, nel qual caso \var{errno} assumerà il valore \errval{EINVAL}.
-  }
-\end{functions}
-
-La funzione si limita ad azzerare tutte le \textit{capabilities} presenti nel
-\textit{capability state} all'indirizzo \param{cap\_p} passato come argomento,
-restituendo uno stato \textsl{vuoto}, analogo a quello che si ottiene nella
-creazione con \func{cap\_init}.
+  \bodydesc{Le funzioni restituiscono un intero positivo che indica la
+    dimensione della lista in caso di successo, e $-1$ in caso di errore, nel
+    qual caso \var{errno} assumerà i valori:
+  \begin{errlist}
+  \item[\errcode{ERANGE}] la dimensione \param{size} del buffer \param{value}
+    non è sufficiente per contenere il risultato.
+  \item[\errcode{ENOTSUP}] gli attributi estesi non sono supportati dal
+    filesystem o sono disabilitati.
+  \end{errlist}
+  Oltre a questi potranno essere restituiti tutti gli errori di \func{stat},
+  ed in particolare \errcode{EPERM} se non si hanno i permessi di accesso
+  all'attributo.  
+}
+\end{functions}

 
 

-Per la gestione dei valori delle \textit{capabilities} presenti in un
-\textit{capability state} l'interfaccia prevede due funzioni,
-\funcd{cap\_get\_flag} e \funcd{cap\_set\_flag}, che permettono
-rispettivamente di leggere o impostare il valore di un flag delle
-\textit{capabilities}; i rispettivi prototipi sono:
+Come per le precedenti le tre funzioni leggono gli attributi rispettivamente
+di un file, un link simbolico o specificando un file descriptor, da
+specificare con il loro primo argomento. Gli altri due argomenti, identici per
+tutte e tre, indicano rispettivamente il puntatore \param{list} al buffer dove
+deve essere letta la lista e la dimensione \param{size} di quest'ultimo.
+
+La lista viene fornita come sequenza non ordinata dei nomi dei singoli
+attributi estesi (sempre comprensivi del prefisso della loro classe) ciascuno
+dei quali è terminato da un carattere nullo. I nomi sono inseriti nel buffer
+uno di seguito all'altro. Il valore di ritorno della funzione indica la
+dimensione totale della lista in byte.
+
+Come per le funzioni di lettura dei singoli attributi se le dimensioni del
+buffer non sono sufficienti si avrà un errore, ma è possibile ottenere dal
+valore di ritorno della funzione una stima della dimensione totale della lista
+usando per \param{size} un valore nullo. 
+
+Infine per rimuovere semplicemente un attributo esteso, si ha a disposizione
+un ultimo gruppo di funzioni: \funcd{removexattr}, \funcd{lremovexattr} e
+\funcd{fremovexattr}; i rispettivi prototipi sono:

 \begin{functions}
 \begin{functions}

-  \headdecl{sys/capability.h}
+  \headdecl{sys/types.h} 
+  \headdecl{attr/xattr.h} 
+  
+  \funcdecl{int removexattr(const char *path, const char *name)}

 
 

-  \funcdecl{int cap\_get\_flag(cap\_t cap\_p, cap\_value\_t cap, cap\_flag\_t
-    flag, cap\_flag\_value\_t *value\_p)}
-  Legge il valore di una \textit{capability}.
+  \funcdecl{int lremovexattr(const char *path, const char *name)}

 
 

-  \funcdecl{int cap\_set\_flag(cap\_t cap\_p, cap\_flag\_t flag, int ncap,
-    cap\_value\_t *caps, cap\_flag\_value\_t value)} 
-  Imposta il valore di una \textit{capability}.
+  \funcdecl{int fremovexattr(int filedes, const char *name)}
+
+
+  Rimuovono un attributo esteso di un file.

   
   

-  \bodydesc{Le funzioni ritornano 0 in caso di successo e $-1$ in caso di
-    errore, nel qual caso \var{errno} assumerà il valore \errval{EINVAL}.
+  \bodydesc{Le funzioni restituiscono 0 in caso di successo, e $-1$ in caso di
+    errore, nel qual caso \var{errno} assumerà i valori:
+  \begin{errlist}
+  \item[\errcode{ENOATTR}] l'attributo richiesto non esiste.
+  \item[\errcode{ENOTSUP}] gli attributi estesi non sono supportati dal
+    filesystem o sono disabilitati.
+  \end{errlist}
+  ed inoltre tutti gli errori di \func{stat}.  

 }
 \end{functions}
 
 }
 \end{functions}
 

-In entrambe le funzioni l'argomento \param{cap\_p} indica il puntatore al
-\textit{capability state} su cui operare, mentre l'argomento \param{flag}
-indica su quale dei tre insiemi illustrati a
-pag.~\pageref{sec:capabilities_set} si intende operare. Questi devono essere
-specificati con una variabile di tipo \type{cap\_flag\_t} che può assumere
-esclusivamente\footnote{si tratta in effetti di un tipo enumerato, come si può
-  verificare dalla sua definizione che si trova in
-  \texttt{/usr/include/sys/capability.h}.} uno dei valori illustrati in
-tab.~\ref{tab:cap_set_identifier}.
+Le tre funzioni rimuovono l'attributo esteso indicato dall'argomento
+\param{name} rispettivamente di un file, un link simbolico o specificando un
+file descriptor, da specificare con il loro primo argomento.  Anche in questo
+caso l'argomento \param{name} deve essere specificato con le modalità già
+illustrate in precedenza per le altre funzioni relative agli attributi estesi.

 
 

-\begin{table}[htb]
-  \centering
-  \footnotesize
-  \begin{tabular}[c]{|l|l|}
-    \hline
-    \textbf{Valore} & \textbf{Significato} \\
-    \hline
-    \hline
-    \const{CAP\_EFFECTIVE}  & Capacità dell'insieme \textsl{effettivo}.\\
-    \const{CAP\_PERMITTED}  & Capacità dell'insieme \textsl{permesso}.\\ 
-    \const{CAP\_INHERITABLE}& Capacità dell'insieme \textsl{ereditabile}.\\
-    \hline
-  \end{tabular}
-  \caption{Valori possibili per il tipo di dato \type{cap\_flag\_t} che
-    identifica gli insiemi delle \textit{capabilities}.}
-  \label{tab:cap_set_identifier}
-\end{table}
+\itindend{Extended~Attributes}

 
 

-La capacità che si intende controllare o impostare invece deve essere
-specificata attraverso una variabile di tipo \type{cap\_value\_t}, che può
-prendere come valore uno qualunque di quelli riportati in
-tab.~\ref{tab:proc_capabilities}, in questo caso però non è possibile
-combinare diversi valori in una maschera binaria, una variabile di tipo
-\type{cap\_value\_t} deve indicare una sola capacità.\footnote{nel file di
-  header citato nella nota precedente il tipo \type{cap\_value\_t} è definito
-  come \ctyp{int}, ma i valori validi sono soltanto quelli di
-  tab.~\ref{tab:proc_capabilities}.}  

 
 

-Infine lo stato di una capacità è descritto ad una variabile di tipo
-\type{cap\_flag\_value\_t}, che a sua volta può assumere soltanto
-uno\footnote{anche questo è un tipo enumerato.} dei valori di
-tab.~\ref{tab:cap_value_type}.
+\subsection{Le \textit{Access  Control List}}
+\label{sec:file_ACL}
+
+% la documentazione di sistema è nei pacchetti libacl1-dev e acl 
+% vedi anche http://www.suse.de/~agruen/acl/linux-acls/online/
+
+\itindbeg{Access~Control~List}
+
+Il modello classico dei permessi di Unix, per quanto funzionale ed efficiente,
+è comunque piuttosto limitato e per quanto possa aver coperto per lunghi anni
+le esigenze più comuni con un meccanismo semplice e potente, non è in grado di
+rispondere in maniera adeguata a situazioni che richiedono una gestione
+complessa dei permessi di accesso.\footnote{già un requisito come quello di
+  dare accesso in scrittura ad alcune persone ed in sola lettura ad altre non
+  si può soddisfare in maniera semplice.}
+
+Per questo motivo erano state progressivamente introdotte nelle varie versioni
+di Unix dei meccanismi di gestione dei permessi dei file più flessibili, nella
+forma delle cosiddette \textit{Access Control List} (indicate usualmente con
+la sigla ACL).  Nello sforzo di standardizzare queste funzionalità era stato
+creato un gruppo di lavoro il cui scopo era estendere lo standard POSIX 1003
+attraverso due nuovi insiemi di specifiche, la POSIX 1003.1e per l'interfaccia
+di programmazione e la POSIX 1003.2c per i comandi di shell.
+
+Gli obiettivi erano però forse troppo ambizioni, e nel gennaio del 1998 i
+finanziamenti vennero ritirati senza che si fosse arrivati alla definizione di
+uno standard, dato però che una parte della documentazione prodotta era di
+alta qualità venne deciso di rilasciare al pubblico la diciassettesima bozza
+del documento, quella che va sotto il nome di \textit{POSIX 1003.1e Draft 17},
+che è divenuta la base sulla quale si definiscono le cosiddette \textit{Posix
+  ACL}.
+
+A differenza di altri sistemi (ad esempio FreeBSD) nel caso di Linux si è
+scelto di realizzare le ACL attraverso l'uso degli
+\itindex{Extended~Attributes} \textit{Extended Attributes} (appena trattati in
+sez.~\ref{sec:file_xattr}), e fornire tutte le relative funzioni di gestione
+tramite una libreria, \texttt{libacl} che nasconde i dettagli implementativi
+delle ACL e presenta ai programmi una interfaccia che fa riferimento allo
+standard POSIX 1003.1e.
+
+Anche in questo caso le funzioni di questa libreria non fanno parte delle
+\acr{glibc} e devono essere installate a parte;\footnote{la versione corrente
+  della libreria è \texttt{libacl1}, e nel caso si usi Debian la si può
+  installare con il pacchetto omonimo e con il collegato \texttt{libacl1-dev}
+  per i file di sviluppo.}  pertanto se un programma le utilizza si dovrà
+indicare esplicitamente l'uso della libreria \texttt{libacl} invocando il
+compilatore con l'opzione \texttt{-lacl}. Si tenga presente inoltre che per
+poterle utilizzare le ACL devono essere attivate esplicitamente montando il
+filesystem\footnote{che deve supportarle, ma questo è ormai vero per
+  praticamente tutti i filesystem più comuni, con l'eccezione di NFS per il
+  quale esiste però un supporto sperimentale.} su cui le si vogliono
+utilizzare con l'opzione \texttt{acl} attiva. Dato che si tratta di una
+estensione è infatti opportuno utilizzarle soltanto laddove siano necessarie.
+
+Una ACL è composta da un insieme di voci, e ciascuna voce è a sua volta
+costituita da un \textsl{tipo}, da un eventuale
+\textsl{qualificatore},\footnote{deve essere presente soltanto per le voci di
+  tipo \const{ACL\_USER} e \const{ACL\_GROUP}.} e da un insieme di permessi.
+Ad ogni oggetto sul filesystem si può associare una ACL che ne governa i
+permessi di accesso, detta \textit{access ACL}.  Inoltre per le directory si
+può impostare una ACL aggiuntiva, detta \textit{default ACL}, che serve ad
+indicare quale dovrà essere la ACL assegnata di default nella creazione di un
+file all'interno della directory stessa. Come avviene per i permessi le ACL
+possono essere impostate solo del proprietario del file, o da un processo con
+la capability \index{capabilities} \const{CAP\_FOWNER}.

 
 \begin{table}[htb]
   \centering
   \footnotesize
 
 \begin{table}[htb]
   \centering
   \footnotesize

-  \begin{tabular}[c]{|l|l|}
+  \begin{tabular}{|l|p{8cm}|}

     \hline
     \hline

-    \textbf{Valore} & \textbf{Significato} \\
+    \textbf{Tipo} & \textbf{Descrizione} \\

     \hline
     \hline
     \hline
     \hline

-    \const{CAP\_CLEAR}& La capacità non è impostata.\\ 
-    \const{CAP\_SET}  & La capacità è impostata.\\
+    \const{ACL\_USER\_OBJ} & voce che contiene i diritti di accesso del
+                             proprietario del file.\\
+    \const{ACL\_USER}      & voce che contiene i diritti di accesso per
+                             l'utente indicato dal rispettivo
+                             qualificatore.\\  
+    \const{ACL\_GROUP\_OBJ}& voce che contiene i diritti di accesso del
+                             gruppo proprietario del file.\\
+    \const{ACL\_GROUP}     & voce che contiene i diritti di accesso per
+                             il gruppo indicato dal rispettivo
+                             qualificatore.\\
+    \const{ACL\_MASK}      & voce che contiene la maschera dei massimi
+                             permessi di accesso che possono essere garantiti
+                             da voci del tipo \const{ACL\_USER},
+                             \const{ACL\_GROUP} e \const{ACL\_GROUP\_OBJ}.\\
+    \const{ACL\_OTHER}     & voce che contiene i diritti di accesso di chi
+                             non corrisponde a nessuna altra voce dell'ACL.\\

     \hline
   \end{tabular}
     \hline
   \end{tabular}

-  \caption{Valori possibili per il tipo di dato \type{cap\_flag\_value\_t} che
-    indica lo stato di una capacità.}
-  \label{tab:cap_value_type}
+  \caption{Le costanti che identificano i tipi delle voci di una ACL.}
+  \label{tab:acl_tag_types}

 \end{table}
 
 \end{table}
 

-La funzione \func{cap\_get\_flag} legge lo stato della capacità indicata
-dall'argomento \param{cap} all'interno dell'insieme indicato dall'argomento
-\param{flag} e ne restituisce il valore nella variabile posta all'indirizzo
-puntato dall'argomento \param{value\_p}; è possibile cioè leggere soltanto uno
-stato di una capacità alla volta.
-
-La funzione \func{cap\_set\_flag} può invece impostare in una sola chiamata
-più \textit{capabilities}, anche se solo all'interno dello stesso insieme. Per
-questo motivo essa prende un vettore di valori di tipo \type{cap\_value\_t}
-nell'argomento \param{caps}, la cui dimensione viene specificata dall'argomento
-\param{ncap}. Il tipo di impostazione da eseguire (cancellazione o
-impostazione) viene indicato dall'argomento \param{value}.
-
-Per la visualizzazione dello stato delle \textit{capabilities} l'interfaccia
-prevede una funzione apposita, \funcd{cap\_to\_text}, il cui prototipo è:
-\begin{functions}
-  \headdecl{sys/capability.h}
+L'elenco dei vari tipi di voci presenti in una ACL, con una breve descrizione
+del relativo significato, è riportato in tab.~\ref{tab:acl_tag_types}. Tre di
+questi tipi, \const{ACL\_USER\_OBJ}, \const{ACL\_GROUP\_OBJ} e
+\const{ACL\_OTHER}, corrispondono direttamente ai tre permessi ordinari dei
+file (proprietario, gruppo proprietario e tutti gli altri) e per questo una
+ACL valida deve sempre contenere una ed una sola voce per ciascuno di questi
+tipi.

 
 

-  \funcdecl{char * cap\_to\_text(cap\_t caps, ssize\_t * length\_p)}
+Una ACL può poi contenere un numero arbitrario di voci di tipo
+\const{ACL\_USER} e \const{ACL\_GROUP}, ciascuna delle quali indicherà i
+permessi assegnati all'utente e al gruppo indicato dal relativo qualificatore;
+ovviamente ciascuna di queste voci dovrà fare riferimento ad un utente o ad un
+gruppo diverso, e non corrispondenti a quelli proprietari del file. Inoltre se
+in una ACL esiste una voce di uno di questi due tipi è obbligatoria anche la
+presenza di una ed una sola voce di tipo \const{ACL\_MASK}, che negli altri
+casi è opzionale.

 
 

-  Genera una visualizzazione testuale delle \textit{capabilities}.
-  
-  \bodydesc{La funzione ritorna un puntatore alla stringa con la descrizione
-    delle \textit{capabilities} in caso di successo e \val{NULL} in caso di
-    errore, nel qual caso \var{errno} può assumere i valori \errval{EINVAL} o
-    \errval{ENOMEM}.
-  }
-\end{functions}
+Quest'ultimo tipo di voce contiene la maschera dei permessi che possono essere
+assegnati tramite voci di tipo \const{ACL\_USER}, \const{ACL\_GROUP} e
+\const{ACL\_GROUP\_OBJ}; se in una di queste voci si fosse specificato un
+permesso non presente in \const{ACL\_MASK} questo verrebbe ignorato. L'uso di
+una ACL di tipo \const{ACL\_MASK} è di particolare utilità quando essa
+associata ad una \textit{default ACL} su una directory, in quanto i permessi
+così specificati verranno ereditati da tutti i file creati nella stessa
+directory. Si ottiene così una sorta di \itindex{umask} \textit{umask}
+associata ad un oggetto sul filesystem piuttosto che a un processo.

 
 

-La funzione ritorna l'indirizzo di una stringa contente la descrizione
-testuale del contenuto del \textit{capabilities state} \param{caps} passato
-come argomento, e, qualora l'argomento \param{length\_p} sia diverso da
-\val{NULL}, restituisce nella variabile intera da questo puntata la lunghezza
-della stringa. La stringa restituita viene allocata automaticamente dalla
-funzione e pertanto dovrà essere liberata con \func{cap\_free}.
+Dato che le ACL vengono a costituire una estensione dei permessi ordinari, uno
+dei problemi che si erano posti nella loro standardizzazione era appunto
+quello della corrispondenza fra questi e le ACL. Come accennato i permessi
+ordinari vengono mappati le tre voci di tipo \const{ACL\_USER\_OBJ},
+\const{ACL\_GROUP\_OBJ} e \const{ACL\_OTHER} che devono essere presenti in
+qualunque ACL; un cambiamento ad una di queste voci viene automaticamente
+riflesso sui permessi ordinari dei file\footnote{per permessi ordinari si
+  intende quelli mantenuti nell'\textit{inode}, che devono restare dato che un
+  filesystem può essere montato senza abilitare le ACL.} e viceversa. In
+realtà la mappatura è diretta solo per le voci \const{ACL\_USER\_OBJ} e
+\const{ACL\_OTHER}, nel caso di \const{ACL\_GROUP\_OBJ} questo vale soltanto
+se non è presente una voce di tipo \const{ACL\_MASK}, se invece questa è
+presente verranno tolti dai permessi di \const{ACL\_GROUP\_OBJ} tutti quelli
+non presenti in \const{ACL\_MASK}.\footnote{questo diverso comportamento a
+  seconda delle condizioni è stato introdotto dalla standardizzazione
+  \textit{POSIX 1003.1e Draft 17} per mantenere il comportamento invariato sui
+  sistemi dotati di ACL per tutte quelle applicazioni che sono conformi
+  soltanto all'ordinario standard \textit{POSIX 1003.1}.}

 
 

-Fin quei abbiamo trattato solo le funzioni di servizio relative alla
-manipolazione dei \textit{capabilities state}; l'interfaccia di gestione
-prevede però anche le funzioni per la gestione delle \textit{capabilities}
-stesse. La prima di queste è \funcd{cap\_get\_proc} che consente la lettura
-delle \textit{capabilities} del processo corrente, il suo prototipo è:
+Un secondo aspetto dell'incidenza delle ACL sul comportamento del sistema è
+quello relativo alla creazione di nuovi file,\footnote{o oggetti sul
+  filesystem, il comportamento discusso vale per le funzioni \func{open} e
+  \func{creat} (vedi sez.~\ref{sec:file_open}), \func{mkdir} (vedi
+  sez.~\ref{sec:file_dir_creat_rem}), \func{mknod} e \func{mkfifo} (vedi
+  sez.~\ref{sec:file_mknod}).} che come accennato può essere modificato dalla
+presenza di una \textit{default ACL} sulla directory che contiene quel file.
+Se questa non c'è valgono le regole usuali illustrate in
+sez.~\ref{sec:file_perm_management}, per cui essi sono determinati dalla
+\itindex{umask} \textit{umask} del processo, e la sola differenza è che i
+permessi ordinari da esse risultanti vengono automaticamente rimappati anche
+su una ACL di accesso assegnata automaticamente al nuovo file, che contiene
+soltanto le tre corrispondenti voci di tipo \const{ACL\_USER\_OBJ},
+\const{ACL\_GROUP\_OBJ} e \const{ACL\_OTHER}.
+
+Se invece è presente una ACL di default sulla directory che contiene il nuovo
+file questa diventerà automaticamente la sua ACL di accesso, a meno di non
+aver indicato, nelle funzioni di creazione che lo consentono, uno specifico
+valore per i permessi ordinari;\footnote{tutte le funzioni citate in
+  precedenza supportano un argomento \var{mode} che indichi un insieme di
+  permessi iniziale.} in tal caso saranno eliminati dalle voci corrispondenti
+nella ACL tutti quelli non presenti in tale indicazione.
+
+Dato che questa è la ragione che ha portato alla loro creazione, la principale
+modifica introdotta con la presenza della ACL è quella alle regole del
+controllo di accesso ai file illustrate in sez.~\ref{sec:file_perm_overview}.
+Come nel caso ordinario per il controllo vengono sempre utilizzati gli
+identificatori del gruppo \textit{effective} del processo, ma in presenza di
+ACL i passi attraverso i quali viene stabilito se esso ha diritto di accesso
+sono i seguenti:
+\begin{enumerate*}
+\item Se l'user-ID del processo è nullo l'accesso è sempre garantito senza
+  nessun controllo.
+\item Se l'user-ID del processo corrisponde al proprietario del file allora:
+  \begin{itemize*}
+  \item se la voce \const{ACL\_USER\_OBJ} contiene il permesso richiesto,
+    l'accesso è consentito;
+  \item altrimenti l'accesso è negato.
+  \end{itemize*}
+\item Se l'user-ID del processo corrisponde ad un qualunque qualificatore
+  presente in una voce \const{ACL\_USER} allora:
+  \begin{itemize*}
+  \item se la voce \const{ACL\_USER} corrispondente e la voce
+    \const{ACL\_MASK} contengono entrambe il permesso richiesto, l'accesso è
+    consentito;
+  \item altrimenti l'accesso è negato.
+  \end{itemize*}
+\item Se è il group-ID del processo o uno dei group-ID supplementari
+  corrisponde al gruppo proprietario del file allora: 
+  \begin{itemize*}
+  \item se la voce \const{ACL\_GROUP\_OBJ} e una eventuale voce
+    \const{ACL\_MASK} (se non vi sono voci di tipo \const{ACL\_GROUP} questa
+    può non essere presente) contengono entrambe il permesso richiesto,
+    l'accesso è consentito;
+  \item altrimenti l'accesso è negato.
+  \end{itemize*}
+\item Se è il group-ID del processo o uno dei group-ID supplementari
+  corrisponde ad un qualunque qualificatore presente in una voce
+  \const{ACL\_GROUP} allora:
+  \begin{itemize*}
+  \item se la voce \const{ACL\_GROUP} corrispondente e la voce
+    \const{ACL\_MASK} contengono entrambe il permesso richiesto, l'accesso è
+    consentito;
+  \item altrimenti l'accesso è negato.
+  \end{itemize*}
+\item Se la voce \const{ACL\_USER\_OBJ} contiene il permesso richiesto,
+  l'accesso è consentito, altrimenti l'accesso è negato.
+\end{enumerate*}
+
+I passi di controllo vengono eseguiti esattamente in questa sequenza, e la
+decisione viene presa non appena viene trovata una corrispondenza con gli
+identificatori del processo. Questo significa che i permessi presenti in una
+voce di tipo \const{ACL\_USER} hanno la precedenza sui permessi ordinari
+associati al gruppo proprietario del file (vale a dire su
+\const{ACL\_GROUP\_OBJ}).
+
+Per la gestione delle ACL lo standard \textit{POSIX 1003.1e Draft 17} ha
+previsto delle apposite funzioni ed tutta una serie di tipi di dati
+dedicati;\footnote{fino a definire un tipo di dato e delle costanti apposite
+  per identificare i permessi standard di lettura, scrittura ed esecuzione.}
+tutte le operazioni devono essere effettuate attraverso tramite questi tipi di
+dati, che incapsulano tutte le informazioni contenute nelle ACL. La prima di
+queste funzioni che prendiamo in esame è \funcd{acl\_init}, il cui prototipo
+è:

 \begin{functions}
 \begin{functions}

-  \headdecl{sys/capability.h}
+  \headdecl{sys/types.h} 
+  \headdecl{sys/acl.h}
+  
+  \funcdecl{acl\_t acl\_init(int count)}

 
 

-  \funcdecl{cap\_t cap\_get\_proc(void)}
-  Legge le \textit{capabilities} del processo corrente.
+  Inizializza un'area di lavoro per una ACL di \param{count} voci.

   
   

-  \bodydesc{La funzione ritorna un valore diverso da \val{NULL} in caso di
-    successo e \val{NULL} in caso di errore, nel qual caso \var{errno} può
-    assumere i valori \errval{EINVAL}, \errval{EPERM} o \errval{ENOMEM}.  }
+  \bodydesc{La funzione restituisce un puntatore all'area di lavoro in caso di
+    successo e \const{NULL} in caso di errore, nel qual caso \var{errno}
+    assumerà uno dei valori:
+  \begin{errlist}
+  \item[\errcode{EINVAL}] il valore di \param{count} è negativo.
+  \item[\errcode{ENOMEM}] non c'è sufficiente memoria disponibile.
+  \end{errlist}
+}

 \end{functions}
 
 \end{functions}
 

-La funzione legge il valore delle \textit{capabilities} associate al processo
-da cui viene invocata, restituendo il risultato tramite il puntatore ad un
-\textit{capabilities state} contenente tutti i dati che provvede ad allocare
-autonomamente e che di nuovo occorrerà liberare con \func{cap\_free} quando
-non sarà più utilizzato.
+La funzione alloca ed inizializza un'area di memoria che verrà usata per
+mantenere i dati di una ACL contenente fino ad un massimo di \param{count}
+voci. La funzione ritorna un valore di tipo \type{acl\_t}, da usare in tutte
+le altre funzioni che operano sulla ACL. La funzione si limita alla
+allocazione iniziale e non inserisce nessun valore nella ACL che resta vuota.
+Si tenga presente che pur essendo \type{acl\_t} un tipo opaco che identifica
+``\textsl{l'oggetto}'' ACL, il valore restituito dalla funzione non è altro
+che un puntatore all'area di memoria allocata per i dati richiesti; pertanto
+in caso di fallimento verrà restituito un puntatore nullo e si dovrà
+confrontare il valore di ritorno della funzione con ``\code{(acl\_t) NULL}''.

 
 

-Se invece si vogliono leggere le \textit{capabilities} di un processo
-specifico occorre usare la funzione \funcd{capgetp}, il cui
-prototipo\footnote{su alcune pagine di manuale la funzione è descritta con un
-  prototipo sbagliato, che prevede un valore di ritorno di tipo \type{cap\_t},
-  ma il valore di ritorno è intero, come si può verificare anche dalla
-  dichiarazione della stessa in \texttt{sys/capability.h}.} è:
+Una volta che si siano completate le operazioni sui dati di una ACL la memoria
+allocata dovrà essere liberata esplicitamente attraverso una chiamata alla
+funzione \funcd{acl\_free}, il cui prototipo è:

 \begin{functions}
 \begin{functions}

-  \headdecl{sys/capability.h}
+  \headdecl{sys/types.h} 
+  \headdecl{sys/acl.h}
+  
+  \funcdecl{int acl\_free(void * obj\_p)}

 
 

-  \funcdecl{int capgetp(pid\_t pid, cap\_t cap\_d)}
-  Legge le \textit{capabilities} del processo indicato da \param{pid}.
+  Disalloca la memoria riservata per i dati di una ACL.

   
   

-  \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
-    errore, nel qual caso \var{errno} può assumere i valori \errval{EINVAL},
-    \errval{EPERM} o \errval{ENOMEM}.  
-  }
+  \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ se
+    \param{obj\_p} non è un puntatore valido, nel qual caso \var{errno}
+    assumerà il valore \errcode{EINVAL} 
+}

 \end{functions}
 \end{functions}

-%TODO controllare e correggere i codici di errore!!!

 
 

-La funzione legge il valore delle \textit{capabilities} del processo indicato
-con l'argomento \param{pid}, e restituisce il risultato nel
-\textit{capabilities state} posto all'indirizzo indicato con l'argomento
-\param{cap\_d}; a differenza della precedente in questo caso il
-\textit{capability state} deve essere stato creato in precedenza. Qualora il
-processo indicato non esista si avrà un errore di \errval{ESRCH}. Gli stessi
-valori possono essere letti direttamente nel filesystem \textit{proc}, nei
-file \texttt{/proc/<pid>/status}; ad esempio per \texttt{init} si otterrà
-qualcosa del tipo:
-\begin{Verbatim}
-...
-CapInh: 0000000000000000
-CapPrm: 00000000fffffeff
-CapEff: 00000000fffffeff  
-...
-\end{Verbatim}
+Si noti come la funzione richieda come argomento un puntatore di tipo
+``\ctyp{void *}'', essa infatti può essere usata non solo per liberare la
+memoria allocata per i dati di una ACL, ma anche per quella usata per creare
+le stringhe di descrizione testuale delle ACL o per ottenere i valori dei
+qualificatori di una voce; pertanto a seconda dei casi occorrerà eseguire un
+\textit{cast} a ``\ctyp{void *}'' del tipo di dato di cui si vuole eseguire la
+disallocazione.  Si tenga presente poi che oltre a \func{acl\_init} esistono
+molte altre funzioni che possono allocare memoria per i dati delle ACL, è
+pertanto opportuno tenere traccia di tutte queste funzioni perché alla fine
+delle operazioni tutta la memoria allocata dovrà essere liberata con
+\func{acl\_free}.

 
 

-Infine per impostare le \textit{capabilities} del processo corrente (non
-esiste una funzione che permetta di cambiare le \textit{capabilities} di un
-altro processo) si deve usare la funzione \funcd{cap\_set\_proc}, il cui
-prototipo è:
+Una volta che si abbiano a disposizione i dati di una ACL tramite il
+riferimento ad oggetto di tipo \type{acl\_t} questi potranno essere copiati
+con la funzione \funcd{acl\_dup}, il cui prototipo è:

 \begin{functions}
 \begin{functions}

-  \headdecl{sys/capability.h}
+  \headdecl{sys/types.h} 
+  \headdecl{sys/acl.h}
+  
+  \funcdecl{acl\_t acl\_dup(acl\_t acl)}

 
 

-  \funcdecl{int cap\_set\_proc(cap\_t cap\_p)}
-  Imposta le \textit{capabilities} del processo corrente.
+  Crea una copia della ACL \param{acl}.

   
   

-  \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
-    errore, nel qual caso \var{errno} può assumere i valori \errval{EINVAL},
-    \errval{EPERM} o \errval{ENOMEM}.  
-  }
+  \bodydesc{La funzione restituisce un oggetto di tipo \type{acl\_t} in caso
+    di successo e \code{(acl\_t)NULL} in caso di errore, nel qual caso
+    \var{errno} assumerà uno dei valori:
+  \begin{errlist}
+  \item[\errcode{EINVAL}] l'argomento \param{acl} non è un puntatore valido
+    per una ACL.
+  \item[\errcode{ENOMEM}] non c'è sufficiente memoria disponibile per eseguire
+    la copia.
+  \end{errlist}
+}

 \end{functions}
 
 \end{functions}
 

-La funzione modifica le \textit{capabilities} del processo corrente secondo
-quanto specificato con l'argomento \param{cap\_p}, posto che questo sia
-possibile nei termini spiegati in precedenza (non sarà ad esempio possibile
-impostare capacità non presenti nell'insieme di quelle permesse). In caso di
-successo i nuovi valori saranno effettivi al ritorno della funzione, in caso
-di fallimento invece lo stato delle capacità resterà invariato. Si tenga
-presente che \textsl{tutte} le capacità specificate tramite \param{cap\_p}
-devono essere permesse; se anche una sola non lo è la funzione fallirà, e per
-quanto appena detto, lo stato delle \textit{capabilities} non verrà modificato
-(neanche per le parti eventualmente permesse).
-
-Come esempio di utilizzo di queste funzioni nei sorgenti allegati alla guida
-si è distribuito il programma \texttt{getcap.c}, che consente di leggere le
-\textit{capabilities} del processo corrente\footnote{vale a dire di sé stesso,
-  quando lo si lancia, il che può sembrare inutile, ma serve a mostrarci quali
-  sono le \textit{capabilities} standard che ottiene un processo lanciato
-  dalla riga di comando.} o tramite l'opzione \texttt{-p}, quelle di un
-processo qualunque il cui pid viene passato come parametro dell'opzione.
+La funzione crea una copia dei dati della ACL indicata tramite l'argomento
+\param{acl}, allocando autonomamente tutto spazio necessario alla copia e
+restituendo un secondo oggetto di tipo \type{acl\_t} come riferimento a
+quest'ultima.  Valgono per questo le stesse considerazioni fatte per il valore
+di ritorno di \func{acl\_init}, ed in particolare il fatto che occorrerà
+prevedere una ulteriore chiamata esplicita a \func{acl\_free} per liberare la
+memoria occupata dalla copia.

 
 

-\begin{figure}[htb]
-  \footnotesize \centering
-  \begin{minipage}[c]{15cm}
-    \includecodesample{listati/getcap.c}
-  \end{minipage} 
-  \normalsize
-  \caption{Corpo principale del programma \texttt{getcap.c}.}
-  \label{fig:proc_getcap}
-\end{figure}
-
-La sezione principale del programma è riportata in fig.~\ref{fig:proc_getcap},
-e si basa su una condizione sulla variabile \var{pid} che se si è usato
-l'opzione \texttt{-p} è impostata (nella sezione di gestione delle opzioni,
-che si è tralasciata) al valore del \textsl{pid} del processo di cui si vuole
-leggere le \textit{capabilities} e nulla altrimenti. Nel primo caso
-(\texttt{\small 1--6}) si utilizza direttamente (\texttt{\small 2})
-\func{cap\_get\_proc} per ottenere lo stato delle capacità del processo, nel
-secondo (\texttt{\small 7--14}) prima si inizializza (\texttt{\small 8}) uno
-stato vuoto e poi (\texttt{\small 9}) si legge il valore delle capacità del
-processo indicato.
-
-Il passo successivo è utilizzare (\texttt{\small 16}) \func{cap\_to\_text} per
-tradurre in una stringa lo stato, e poi (\texttt{\small 17}) stamparlo; infine
-(\texttt{\small 19--20}) si libera la memoria allocata dalle precedenti
-funzioni con \func{cap\_free} per poi ritornare dal ciclo principale della
-funzione.
-
-\itindend{capabilities}
-
-% TODO vedi http://lwn.net/Articles/198557/ e 
-% http://www.madore.org/~david/linux/newcaps/
-% TODO documentare prctl ...
-
-\subsection{Gli attributi estesi}
-\label{sec:file_xattr}
+Se si deve creare una ACL manualmente l'uso di \func{acl\_init} è scomodo,
+dato che la funzione restituisce una ACL vuota, una alternativa allora è usare
+\funcd{acl\_from\_mode} che consente di creare una ACL a partire da un valore
+di permessi ordinari, il prototipo della funzione è:
+\begin{functions}
+  \headdecl{sys/types.h} 
+  \headdecl{sys/acl.h}
+  
+  \funcdecl{acl\_t acl\_from\_mode(mode\_t mode)}

 
 

-\itindbeg{Extended~Attributes}
+  Crea una ACL inizializzata con i permessi di \param{mode}.
+  
+  \bodydesc{La funzione restituisce un oggetto di tipo \type{acl\_t} in caso
+    di successo e \code{(acl\_t)NULL} in caso di errore, nel qual caso
+    \var{errno} assumerà il valore \errval{ENOMEM}.

 
 

-Nelle sezioni precedenti abbiamo trattato in dettaglio le varie informazioni
-che il sistema mantiene negli \itindex{inode} \textit{inode}, e le varie
-funzioni che permettono di modificarle.  Si sarà notato come in realtà queste
-informazioni siano estremamente ridotte.  Questo è dovuto al fatto che Unix
-origina negli anni '70, quando le risorse di calcolo e di spazio disco erano
-minime. Con il venir meno di queste restrizioni è incominciata ad emergere
-l'esigenza di poter associare ai file delle ulteriori informazioni astratte
-(quelli che vengono chiamati i \textsl{meta-dati}) che però non potevano
-trovare spazio nei dati classici mantenuti negli \itindex{inode}
-\textit{inode}.
+}
+\end{functions}

 
 

-Per risolvere questo problema alcuni sistemi unix-like (e fra questi anche
-Linux) hanno introdotto un meccanismo generico che consenta di associare delle
-informazioni ai singoli file,\footnote{l'uso più comune è quello della ACL,
-  che tratteremo nella prossima sezione, ma si possono inserire anche altre
-  informazioni.}  detto \textit{Extended Attributes}. Gli \textsl{attributi
-  estesi} non sono altro che delle coppie nome/valore che sono associate
-permanentemente ad un oggetto sul filesystem, analoghi di quello che sono le
-variabili di ambiente (vedi sez.~\ref{sec:proc_environ}) per un processo.
+La funzione restituisce una ACL inizializzata con le tre voci obbligatorie
+\const{ACL\_USER\_OBJ}, \const{ACL\_GROUP\_OBJ} e \const{ACL\_OTHER} già
+impostate secondo la corrispondenza ai valori dei permessi ordinari indicati
+dalla maschera passata nell'argomento \param{mode}. Questa funzione è una
+estensione usata dalle ACL di Linux e non è portabile, ma consente di
+semplificare l'inizializzazione in maniera molto comoda. 

 
 

-Altri sistemi (come Solaris, MacOS e Windows) hanno adottato un meccanismo
-diverso in cui ad un file sono associati diversi flussi di dati, su cui
-possono essere mantenute ulteriori informazioni, che possono essere accedute
-con le normali operazioni di lettura e scrittura. Questi non vanno confusi con
-gli \textit{Extended Attributes} (anche se su Solaris hanno lo stesso nome),
-che sono un meccanismo molto più semplice, che pur essendo limitato (potendo
-contenere solo una quantità limitata di informazione) hanno il grande
-vantaggio di essere molto più semplici da realizzare, più
-efficienti,\footnote{cosa molto importante, specie per le applicazioni che
-  richiedono una gran numero di accessi, come le ACL.} e di garantire
-l'atomicità di tutte le operazioni.
+Altre due funzioni che consentono di creare una ACL già inizializzata sono
+\funcd{acl\_get\_fd} e \funcd{acl\_get\_file}, che però sono per lo più
+utilizzate per leggere la ACL corrente di un file; i rispettivi prototipi
+sono:
+\begin{functions}
+  \headdecl{sys/types.h} 
+  \headdecl{sys/acl.h}
+  
+  \funcdecl{acl\_t acl\_get\_file(const char *path\_p, acl\_type\_t type)}
+  \funcdecl{acl\_t acl\_get\_fd(int fd)}

 
 

-In Linux gli attributi estesi sono sempre associati al singolo \itindex{inode}
-\textit{inode} e l'accesso viene sempre eseguito in forma atomica, in lettura
-il valore corrente viene scritto su un buffer in memoria, mentre la scrittura
-prevede che ogni valore precedente sia sovrascritto.
+  Ottiene i dati delle ACL di un file.
+  
+  \bodydesc{La funzione restituisce un oggetto di tipo \type{acl\_t} in caso
+    di successo e \code{(acl\_t)NULL} in caso di errore, nel qual caso
+    \var{errno} assumerà uno dei valori:
+  \begin{errlist}
+  \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
+  \item[\errcode{ENOTSUP}] il filesystem cui fa riferimento il file non
+    supporta le ACL.
+  \end{errlist}
+  ed inoltre \errval{EBADF} per \func{acl\_get\_fd}, ed \errval{EINVAL} per
+  valori scorretti di \param{type} e tutti i possibili errori per l'accesso ad
+  un file per \func{acl\_get\_file}.

 
 

-Si tenga presente che non tutti i filesystem supportano gli \textit{Extended
-  Attributes}, in particolare al momento della scrittura di queste dispense
-essi sono presenti solo su \textsl{ext2}, \textsl{ext3} e \textsl{XFS}.
-Inoltre a seconda della implementazione ci possono essere dei limiti sulla
-quantità di attributi che si possono utilizzare.\footnote{ad esempio nel caso
-  di \textsl{ext2} ed \textsl{ext3} è richiesto che essi siano contenuti
-  all'interno di un singolo blocco (pertanto con dimensioni massime pari a
-  1024, 2048 o 4096 byte a seconda delle dimensioni di quest'ultimo impostate
-  in fase di creazione del filesystem), mentre con \textsl{XFS} non ci sono
-  limiti ed i dati vengono memorizzati in maniera diversa (nell'\textit{inode}
-  stesso, in un blocco a parte, o in una struttura ad albero dedicata) per
-  mantenerne la scalabilità.} Infine lo spazio utilizzato per mantenere gli
-attributi estesi viene tenuto in conto per il calcolo delle quote di utente e
-gruppo proprietari del file.
+}
+\end{functions}

 
 

-Come meccanismo per mantenere informazioni aggiuntive associate al singolo
-file, gli \textit{Extended Attributes} possono avere usi anche molto diversi
-fra loro.  Per poterli distinguere allora sono stati suddivisi in
-\textsl{classi}, a cui poter applicare requisiti diversi per l'accesso e la
-gestione. Per questo motivo il nome di un attributo deve essere sempre
-specificato nella forma \texttt{namespace.attribute}, dove \texttt{namespace}
-fa riferimento alla classe a cui l'attributo appartiene, mentre
-\texttt{attribute} è il nome ad esso assegnato. In tale forma il nome di un
-attributo esteso deve essere univoco. Al momento\footnote{della scrittura di
-  questa sezione, kernel 2.6.23, ottobre 2007.} sono state definite le quattro
-classi di attributi riportate in tab.~\ref{tab:extended_attribute_class}.
+Le due funzioni ritornano, con un oggetto di tipo \type{acl\_t}, il valore
+della ACL correntemente associata ad un file, che può essere identificato
+tramite un file descriptor usando \func{acl\_get\_fd} o con un pathname usando
+\func{acl\_get\_file}. Nel caso di quest'ultima funzione, che può richiedere
+anche la ACL relativa ad una directory, il secondo argomento \param{type}
+consente di specificare se si vuole ottenere la ACL di default o quella di
+accesso. Questo argomento deve essere di tipo \type{acl\_type\_t} e può
+assumere solo i due valori riportati in tab.~\ref{tab:acl_type}.

 
 \begin{table}[htb]
   \centering
   \footnotesize
 
 \begin{table}[htb]
   \centering
   \footnotesize

-  \begin{tabular}{|l|p{10cm}|}
+  \begin{tabular}{|l|l|}

     \hline
     \hline

-    \textbf{Nome} & \textbf{Descrizione} \\
+    \textbf{Tipo} & \textbf{Descrizione} \\

     \hline
     \hline
     \hline
     \hline

-    \texttt{security}&Gli \textit{extended security attributes}: vengono
-                      utilizzati dalle estensioni di sicurezza del kernel (i
-                      \itindex{Linux~Security~Modules} \textit{Linux 
-                        Security Modules}), per le realizzazione di meccanismi
-                      evoluti di controllo di accesso come \index{SELinux}
-                      SELinux o le \textit{capabilities} dei file di
-                      sez.~\ref{sec:proc_capabilities}.\\ 
-    \texttt{system} & Gli \textit{extended security attributes}: sono usati
-                      dal kernel per memorizzare dati di sistema associati ai
-                      file come le \itindex{Access~Control~List} ACL (vedi
-                      sez.~\ref{sec:file_ACL}) o le \itindex{capabilities}
-                      \textit{capabilities} (vedi
-                      sez.~\ref{sec:proc_capabilities}).\\
-    \texttt{trusted}& I \textit{trusted extended attributes}: vengono
-                      utilizzati per poter realizzare in user space 
-                      meccanismi che consentano di mantenere delle
-                      informazioni sui file che non devono essere accessibili
-                      ai processi ordinari.\\
-    \texttt{user}   & Gli \textit{extended user attributes}: utilizzati per
-                      mantenere informazioni aggiuntive sui file (come il
-                      \textit{mime-type}, la codifica dei caratteri o del
-                      file) accessibili dagli utenti.\\
+    \const{ACL\_TYPE\_ACCESS} & indica una ACL di accesso.\\
+    \const{ACL\_TYPE\_DEFAULT}& indica una ACL di default.\\  

     \hline
   \end{tabular}
     \hline
   \end{tabular}

-  \caption{I nomi utilizzati valore di \texttt{namespace} per distinguere le
-    varie classi di \textit{Extended Attributes}.}
-  \label{tab:extended_attribute_class}
+  \caption{Le costanti che identificano il tipo di ACL.}
+  \label{tab:acl_type}

 \end{table}
 
 \end{table}
 

+Si tenga presente che nel caso di \func{acl\_get\_file} occorrerà che il
+processo chiamante abbia privilegi di accesso sufficienti a poter leggere gli
+attributi estesi dei file (come illustrati in sez.~\ref{sec:file_xattr});
+inoltre una ACL di tipo \const{ACL\_TYPE\_DEFAULT} potrà essere richiesta
+soltanto per una directory, e verrà restituita solo se presente, altrimenti
+verrà restituita una ACL vuota.

 
 

-Dato che uno degli usi degli \textit{Extended Attributes} è quello che li
-impiega per realizzare delle estensioni (come le \itindex{Access~Control~List}
-ACL, \index{SELinux} SELinux, ecc.) al tradizionale meccanismo dei controlli
-di accesso di Unix, l'accesso ai loro valori viene regolato in maniera diversa
-a seconda sia della loro classe sia di quali, fra le estensioni che li
-utilizzano, sono poste in uso. In particolare, per ciascuna delle classi
-riportate in tab.~\ref{tab:extended_attribute_class}, si hanno i seguenti
-casi:
-\begin{basedescript}{\desclabelwidth{1.7cm}\desclabelstyle{\nextlinelabel}}
-\item[\texttt{security}] L'accesso agli \textit{extended security attributes}
-  dipende dalle politiche di sicurezza stabilite da loro stessi tramite
-  l'utilizzo di un sistema di controllo basato sui
-  \itindex{Linux~Security~Modules} \textit{Linux Security Modules} (ad esempio
-  \index{SELinux} SELinux). Pertanto l'accesso in lettura o scrittura dipende
-  dalle politiche di sicurezza implementate all'interno dal modulo di
-  sicurezza che si sta utilizzando al momento (ciascuno avrà le sue). Se non è
-  stato caricato nessun modulo di sicurezza l'accesso in lettura sarà
-  consentito a tutti i processi, mentre quello in scrittura solo ai processi
-  con privilegi amministrativi dotati della \index{capabilities}
-  \textit{capability} \const{CAP\_SYS\_ADMIN}.
+Infine si potrà creare una ACL direttamente dalla sua rappresentazione
+testuale con la funzione  \funcd{acl\_from\_text}, il cui prototipo è:
+\begin{functions}
+  \headdecl{sys/types.h} 
+  \headdecl{sys/acl.h}
+  
+  \funcdecl{acl\_t acl\_from\_text(const char *buf\_p)}

 
 

-\item[\texttt{system}] Anche l'accesso agli \textit{extended system
-    attributes} dipende dalle politiche di accesso che il kernel realizza
-  anche utilizzando gli stessi valori in essi contenuti. Ad esempio nel caso
-  delle \itindex{Access~Control~List} ACL l'accesso è consentito in lettura ai
-  processi che hanno la capacità di eseguire una ricerca sul file (cioè hanno
-  il permesso di lettura sulla directory che contiene il file) ed in scrittura
-  al proprietario del file o ai processi dotati della \textit{capability}
-  \index{capabilities} \const{CAP\_FOWNER}.\footnote{vale a dire una politica
-    di accesso analoga a quella impiegata per gli ordinari permessi dei file.}
+  Crea una ACL a partire dalla sua rappresentazione testuale.
+  
+  \bodydesc{La funzione restituisce un oggetto di tipo \type{acl\_t} in caso
+    di successo e \code{(acl\_t)NULL} in caso di errore, nel qual caso
+    \var{errno} assumerà uno dei valori:
+  \begin{errlist}
+  \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
+  \item[\errcode{EINVAL}] la rappresentazione testuale all'indirizzo
+    \param{buf\_p} non è valida.
+  \end{errlist}

 
 

-\item[\texttt{trusted}] L'accesso ai \textit{trusted extended attributes}, sia
-  per la lettura che per la scrittura, è consentito soltanto ai processi con
-  privilegi amministrativi dotati della \index{capabilities}
-  \textit{capability} \const{CAP\_SYS\_ADMIN}. In questo modo si possono
-  utilizzare questi attributi per realizzare in user space dei meccanismi di
-  controllo che accedono ad informazioni non disponibili ai processi ordinari.
+}
+\end{functions}

 
 

-\item[\texttt{user}] L'accesso agli \textit{extended user attributes} è
-  regolato dai normali permessi dei file: occorre avere il permesso di lettura
-  per leggerli e quello di scrittura per scriverli o modificarli. Dato l'uso
-  di questi attributi si è scelto di applicare al loro accesso gli stessi
-  criteri che si usano per l'accesso al contenuto dei file (o delle directory)
-  cui essi fanno riferimento. Questa scelta vale però soltanto per i file e le
-  directory ordinarie, se valesse in generale infatti si avrebbe un serio
-  problema di sicurezza dato che esistono diversi oggetti sul filesystem per i
-  quali è normale avere avere il permesso di scrittura consentito a tutti gli
-  utenti, come i link simbolici, o alcuni \index{file!di~dispositivo} file di
-  dispositivo come \texttt{/dev/null}. Se fosse possibile usare su di essi gli
-  \textit{extended user attributes} un utente qualunque potrebbe inserirvi
-  dati a piacere.\footnote{la cosa è stata notata su XFS, dove questo
-    comportamento permetteva, non essendovi limiti sullo spazio occupabile
-    dagli \textit{Extended Attributes}, di bloccare il sistema riempiendo il
-    disco.}
+La funzione prende come argomento il puntatore ad un buffer dove si è inserita
+la rappresentazione testuale della ACL che si vuole creare, la memoria
+necessaria viene automaticamente allocata ed in caso di successo viene
+restituito come valore di ritorno un oggetto di tipo \type{acl\_t} con il
+contenuto della stessa, che come per le precedenti funzioni, dovrà essere
+disallocato esplicitamente al termine del suo utilizzo.

 
 

-  La semantica del controllo di accesso indicata inoltre non avrebbe alcun
-  senso al di fuori di file e directory: i permessi di lettura e scrittura per
-  un \index{file!di~dispositivo} file di dispositivo attengono alle capacità
-  di accesso al dispositivo sottostante,\footnote{motivo per cui si può
-    formattare un disco anche se \texttt{/dev} è su un filesystem in sola
-    lettura.} mentre per i link simbolici questi vengono semplicemente
-  ignorati: in nessuno dei due casi hanno a che fare con il contenuto del
-  file, e nella discussione relativa all'uso degli \textit{extended user
-    attributes} nessuno è mai stato capace di indicare una qualche forma
-  sensata di utilizzo degli stessi per link simbolici o
-  \index{file!di~dispositivo} file di dispositivo, e neanche per le fifo o i
-  socket.  Per questo motivo essi sono stati completamente disabilitati per
-  tutto ciò che non sia un file regolare o una directory.\footnote{si può
-    verificare la semantica adottata consultando il file \texttt{fs/xattr.c}
-    dei sorgenti del kernel.} Inoltre per le directory è stata introdotta una
-  ulteriore restrizione, dovuta di nuovo alla presenza ordinaria di permessi
-  di scrittura completi su directory come \texttt{/tmp}. Per questo motivo,
-  per evitare eventuali abusi, se una directory ha lo \itindex{sticky~bit}
-  \textit{sticky bit} attivo sarà consentito scrivere i suoi \textit{extended
-    user attributes} soltanto se si è proprietari della stessa, o si hanno i
-  privilegi amministrativi della capability \index{capabilities}
-  \const{CAP\_FOWNER}.
-\end{basedescript}
+La rappresentazione testuale di una ACL è quella usata anche dai comandi
+ordinari per la gestione delle ACL (\texttt{getfacl} e \texttt{setfacl}), che
+prevede due diverse forme, estesa e breve, entrambe supportate da
+\func{acl\_from\_text}. La forma estesa prevede che sia specificata una voce
+per riga, nella forma:
+\begin{Verbatim}
+  tipo:qualificatore:permessi
+\end{Verbatim}
+dove il tipo può essere uno fra \texttt{user}, \texttt{group}, \texttt{other}
+e \texttt{mask}. Il qualificatore è presente solo per \texttt{user} e
+\texttt{group} e indica l'utente o il gruppo a cui la voce si riferisce; i
+permessi sono espressi con una tripletta di lettere analoga a quella usata per
+i permessi dei file.\footnote{vale a dire \texttt{r} per il permesso di
+  lettura, \texttt{w} per il permesso di scrittura, \texttt{x} per il permesso
+  di esecuzione (scritti in quest'ordine) e \texttt{-} per l'assenza del
+  permesso.}

 
 

-Le funzioni per la gestione degli attributi estesi, come altre funzioni di
-gestione avanzate specifiche di Linux, non fanno parte delle \acr{glibc}, e
-sono fornite da una apposita libreria, \texttt{libattr}, che deve essere
-installata a parte;\footnote{la versione corrente della libreria è
-  \texttt{libattr1}.}  pertanto se un programma le utilizza si dovrà indicare
-esplicitamente l'uso della suddetta libreria invocando il compilatore con
-l'opzione \texttt{-lattr}.  
+Va precisato che i due tipi \texttt{user} e \texttt{group} sono usati
+rispettivamente per indicare delle voci relative ad utenti e
+gruppi,\footnote{cioè per voci di tipo \const{ACL\_USER\_OBJ} e
+  \const{ACL\_USER} per \texttt{user} e \const{ACL\_GROUP\_OBJ} e
+  \const{ACL\_GROUP} per \texttt{group}.} applicate sia a quelli proprietari
+del file che a quelli generici; quelle dei proprietari si riconoscono per
+l'assenza di un qualificatore, ed in genere si scrivono per prima delle altre.
+Il significato delle voci di tipo \texttt{mask} e \texttt{mark} è evidente. In
+questa forma si possono anche inserire dei commenti precedendoli con il
+carattere ``\texttt{\#}''.

 
 

-Per poter leggere gli attributi estesi sono disponibili tre diverse funzioni,
-\funcd{getxattr}, \funcd{lgetxattr} e \funcd{fgetxattr}, che consentono
-rispettivamente di richiedere gli attributi relativi a un file, a un link
-simbolico e ad un file descriptor; i rispettivi prototipi sono:
+La forma breve prevede invece la scrittura delle singole voci su una riga,
+separate da virgole; come specificatori del tipo di voce si possono usare le
+iniziali dei valori usati nella forma estesa (cioè ``\texttt{u}'',
+``\texttt{g}'', ``\texttt{o}'' e ``\texttt{m}''), mentre le altri parte della
+voce sono le stesse. In questo caso non sono consentiti permessi.
+
+Per la conversione inversa, che consente di ottenere la rappresentazione
+testuale di una ACL, sono invece disponibili due funzioni, la prima delle due,
+di uso più immediato, è \funcd{acl\_to\_text}, il cui prototipo è:

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

-  \headdecl{attr/xattr.h} 
+  \headdecl{sys/acl.h}

   
   

-  \funcdecl{ssize\_t getxattr(const char *path, const char *name, void
-    *value, size\_t size)} 
-
-  \funcdecl{ssize\_t lgetxattr(const char *path, const char *name, void
-    *value, size\_t size)} 
-
-  \funcdecl{ssize\_t fgetxattr(int filedes, const char *name, void *value,
-    size\_t size)}
+  \funcdecl{char * acl\_to\_text(acl\_t acl, ssize\_t *len\_p)}

 
 

-  Le funzioni leggono il valore di un attributo esteso.
+  Produce la rappresentazione testuale di una ACL.

   
   

-  \bodydesc{Le funzioni restituiscono un intero positivo che indica la
-    dimensione dell'attributo richiesto in caso di successo, e $-1$ in caso di
-    errore, nel qual caso \var{errno} assumerà i valori:
+  \bodydesc{La funzione restituisce il puntatore ad una stringa con la
+    rappresentazione testuale della ACL in caso di successo e
+    \code(acl\_t){NULL} in caso di errore, nel qual caso \var{errno} assumerà
+    uno dei valori:

   \begin{errlist}
   \begin{errlist}

-  \item[\errcode{ENOATTR}] l'attributo richiesto non esiste.
-  \item[\errcode{ERANGE}] la dimensione \param{size} del buffer \param{value}
-    non è sufficiente per contenere il risultato.
-  \item[\errcode{ENOTSUP}] gli attributi estesi non sono supportati dal
-    filesystem o sono disabilitati.
+  \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
+  \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida.

   \end{errlist}
   \end{errlist}

-  e tutti gli errori di \func{stat}, come \errcode{EPERM} se non si hanno i
-  permessi di accesso all'attributo. }
-\end{functions}
-
-Le funzioni \func{getxattr} e \func{lgetxattr} prendono come primo argomento
-un pathname che indica il file di cui si vuole richiedere un attributo, la
-sola differenza è che la seconda, se il pathname indica un link simbolico,
-restituisce gli attributi di quest'ultimo e non quelli del file a cui esso fa
-riferimento. La funzione \func{fgetxattr} prende invece come primo argomento
-un numero di file descriptor, e richiede gli attributi del file ad esso
-associato.

 
 

-Tutte e tre le funzioni richiedono di specificare nell'argomento \param{name}
-il nome dell'attributo di cui si vuole ottenere il valore. Il nome deve essere
-indicato comprensivo di prefisso del \textit{namespace} cui appartiene (uno
-dei valori di tab.~\ref{tab:extended_attribute_class}) nella forma
-\texttt{namespace.attributename}, come stringa terminata da un carattere NUL.
-Il suo valore verrà restituito nel buffer puntato dall'argomento \param{value}
-per una dimensione massima di \param{size} byte;\footnote{gli attributi estesi
-  possono essere costituiti arbitrariamente da dati testuali o binari.}  se
-quest'ultima non è sufficiente si avrà un errore di \errcode{ERANGE}.
+}
+\end{functions}

 
 

-Per evitare di dover indovinare la dimensione di un attributo per tentativi si
-può eseguire una interrogazione utilizzando un valore nullo per \param{size};
-in questo caso non verrà letto nessun dato, ma verrà restituito come valore di
-ritorno della funzione chiamata la dimensione totale dell'attributo esteso
-richiesto, che si potrà usare come stima per allocare un buffer di dimensioni
-sufficienti.\footnote{si parla di stima perché anche se le funzioni
-  restituiscono la dimensione esatta dell'attributo al momento in cui sono
-  eseguite, questa potrebbe essere modificata in qualunque momento da un
-  successivo accesso eseguito da un altro processo.}
+La funzione restituisce il puntatore ad una stringa terminata da NUL
+contenente la rappresentazione in forma estesa della ACL passata come
+argomento, ed alloca automaticamente la memoria necessaria. Questa dovrà poi
+essere liberata, quando non più necessaria, con \func{acl\_free}. Se
+nell'argomento \param{len\_p} si passa un valore puntatore ad una variabile
+intera in questa verrà restituita la dimensione della stringa con la
+rappresentazione testuale (non comprendente il carattere nullo finale). 

 
 

-Un secondo gruppo di funzioni è quello che consente di impostare il valore di
-un attributo esteso, queste sono \funcd{setxattr}, \funcd{lsetxattr} e
-\funcd{fsetxattr}, e consentono di operare rispettivamente su un file, su un
-link simbolico o specificando un file descriptor; i loro prototipi sono:
+La seconda funzione, \funcd{acl\_to\_any\_text}, permette di controllare con
+dovizia di dettagli la generazione della stringa contenente la
+rappresentazione testuale della ACL, il suo prototipo è:

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

-  \headdecl{attr/xattr.h} 
+  \headdecl{sys/acl.h}

   
   

-  \funcdecl{int setxattr(const char *path, const char *name, const void
-    *value, size\_t size, int flags)}
-
-  \funcdecl{int lsetxattr(const char *path, const char *name, const void
-    *value, size\_t size, int flags)}
+  \funcdecl{char * acl\_to\_any\_text(acl\_t acl, const char *prefix, char
+    separator, int options)}

 
 

-  \funcdecl{int fsetxattr(int filedes, const char *name, const void *value,
-    size\_t size, int flags)}
+  Produce la rappresentazione testuale di una ACL.

 
 

-  Impostano il valore di un attributo esteso.
-  
-  \bodydesc{Le funzioni restituiscono 0 in caso di successo, e $-1$ in caso di
-    errore, nel qual caso \var{errno} assumerà i valori:
+  \bodydesc{La funzione restituisce il puntatore ad una stringa con la
+    rappresentazione testuale della ACL in caso di successo e \code{NULL} in
+    caso di errore, nel qual caso \var{errno} assumerà uno dei valori:

   \begin{errlist}
   \begin{errlist}

-  \item[\errcode{ENOATTR}] si è usato il flag \const{XATTR\_REPLACE} e
-    l'attributo richiesto non esiste.
-  \item[\errcode{EEXIST}] si è usato il flag \const{XATTR\_CREATE} ma
-    l'attributo esiste già.
-  \item[\errcode{ENOTSUP}] gli attributi estesi non sono supportati dal
-    filesystem o sono disabilitati.
+  \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
+  \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida.

   \end{errlist}
   \end{errlist}

-  Oltre a questi potranno essere restituiti tutti gli errori di \func{stat},
-  ed in particolare \errcode{EPERM} se non si hanno i permessi di accesso
-  all'attributo.  
+

 }
 \end{functions}
 
 }
 \end{functions}
 

-Le tre funzioni prendono come primo argomento un valore adeguato al loro
-scopo, usato in maniera del tutto identica a quanto visto in precedenza per le
-analoghe che leggono gli attributi estesi. Il secondo argomento \param{name}
-deve indicare, anche in questo caso con gli stessi criteri appena visti per le
-analoghe \func{getxattr}, \func{lgetxattr} e \func{fgetxattr}, il nome
-(completo di suffisso) dell'attributo su cui si vuole operare. 
+La funzione converte in formato testo la ACL indicata dall'argomento
+\param{acl}, usando il carattere \param{separator} come separatore delle
+singole voci; se l'argomento \param{prefix} non è nullo la stringa da esso
+indicata viene utilizzata come prefisso per le singole voci. 

 
 

-Il valore che verrà assegnato all'attributo dovrà essere preparato nel buffer
-puntato da \param{value}, e la sua dimensione totale (in byte) sarà indicata
-dall'argomento \param{size}. Infine l'argomento \param{flag} consente di
-controllare le modalità di sovrascrittura dell'attributo esteso, esso può
-prendere due valori: con \const{XATTR\_REPLACE} si richiede che l'attributo
-esista, nel qual caso verrà sovrascritto, altrimenti si avrà errore, mentre
-con \const{XATTR\_CREATE} si richiede che l'attributo non esista, nel qual
-caso verrà creato, altrimenti si avrà errore ed il valore attuale non sarà
-modificato.  Utilizzando per \param{flag} un valore nullo l'attributo verrà
-modificato se è già presente, o creato se non c'è.
+L'ultimo argomento, \param{options}, consente di controllare la modalità con
+cui viene generata la rappresentazione testuale. Un valore nullo fa si che
+vengano usati gli identificatori standard \texttt{user}, \texttt{group},
+\texttt{other} e \texttt{mask} con i nomi di utenti e gruppi risolti rispetto
+ai loro valori numerici. Altrimenti si può specificare un valore in forma di
+maschera binaria, da ottenere con un OR aritmetico dei valori riportati in
+tab.~\ref{tab:acl_to_text_options}.

 
 

-Le funzioni finora illustrate permettono di leggere o scrivere gli attributi
-estesi, ma sarebbe altrettanto utile poter vedere quali sono gli attributi
-presenti; a questo provvedono le funzioni \funcd{listxattr},
-\funcd{llistxattr} e \funcd{flistxattr} i cui prototipi sono:
+\begin{table}[htb]
+  \centering
+  \footnotesize
+  \begin{tabular}{|l|p{8cm}|}
+    \hline
+    \textbf{Tipo} & \textbf{Descrizione} \\
+    \hline
+    \hline
+    \const{TEXT\_ABBREVIATE}     & stampa le voci in forma abbreviata.\\
+    \const{TEXT\_NUMERIC\_IDS}   & non effettua la risoluzione numerica di
+                                   user-ID e group-ID.\\
+    \const{TEXT\_SOME\_EFFECTIVE}& per ciascuna voce che contiene permessi che
+                                   vengono eliminati dalla \const{ACL\_MASK}
+                                   viene generato un commento con i permessi 
+                                   effettivamente risultanti; il commento è
+                                   separato con un tabulatore.\\
+    \const{TEXT\_ALL\_EFFECTIVE} & viene generato un commento con i permessi
+                                   effettivi per ciascuna voce che contiene
+                                   permessi citati nella \const{ACL\_MASK},
+                                   anche quando questi non vengono modificati
+                                   da essa; il commento è separato con un
+                                   tabulatore.\\
+    \const{TEXT\_SMART\_INDENT}  & da usare in combinazione con le precedenti
+                                   \const{TEXT\_SOME\_EFFECTIVE} e
+                                   \const{TEXT\_ALL\_EFFECTIVE} aumenta
+                                   automaticamente il numero di spaziatori
+                                   prima degli eventuali commenti in modo da
+                                   mantenerli allineati.\\
+    \hline
+  \end{tabular}
+  \caption{Possibili valori per l'argomento \param{options} di
+    \func{acl\_to\_any\_text}.} 
+  \label{tab:acl_to_text_options}
+\end{table}
+
+Come per \func{acl\_to\_text} anche in questo caso il buffer contenente la
+rappresentazione testuale dell'ACL, di cui la funzione restituisce
+l'indirizzo, viene allocato automaticamente, e dovrà essere esplicitamente
+disallocato con una chiamata ad \func{acl\_free}. Si tenga presente infine che
+questa funzione è una estensione specifica di Linux, e non è presente nella
+bozza dello standard POSIX.1e.
+
+Per quanto utile per la visualizzazione o l'impostazione da comando delle ACL,
+la forma testuale non è la più efficiente per poter memorizzare i dati
+relativi ad una ACL, ad esempio quando si vuole eseguirne una copia a scopo di
+archiviazione. Per questo è stata prevista la possibilità di utilizzare una
+rappresentazione delle ACL in una apposita forma binaria contigua e
+persistente. È così possibile copiare il valore di una ACL in un buffer e da
+questa rappresentazione tornare indietro e generare una ACL. 
+
+Lo standard POSIX.1e prevede a tale scopo tre funzioni, la prima e più
+semplice è \funcd{acl\_size}, che consente di ottenere la dimensione che avrà
+la citata rappresentazione binaria, in modo da poter allocare per essa un
+buffer di dimensione sufficiente, il suo prototipo è:

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

-  \headdecl{attr/xattr.h} 
+  \headdecl{sys/acl.h}

   
   

-  \funcdecl{ssize\_t listxattr(const char *path, char *list, size\_t size)}
+  \funcdecl{ssize\_t acl\_size(acl\_t acl)}

 
 

-  \funcdecl{ssize\_t llistxattr(const char *path, char *list, size\_t size)}
-
-  \funcdecl{ssize\_t flistxattr(int filedes, char *list, size\_t size)}
+  Determina la dimensione della rappresentazione binaria di una ACL.

 
 

-  Leggono la lista degli attributi estesi di un file.
-  
-  \bodydesc{Le funzioni restituiscono un intero positivo che indica la
-    dimensione della lista in caso di successo, e $-1$ in caso di errore, nel
-    qual caso \var{errno} assumerà i valori:
+  \bodydesc{La funzione restituisce in caso di successo la dimensione in byte
+    della rappresentazione binaria della ACL indicata da \param{acl} e $-1$ in
+    caso di errore, nel qual caso \var{errno} assumerà uno dei valori:

   \begin{errlist}
   \begin{errlist}

-  \item[\errcode{ERANGE}] la dimensione \param{size} del buffer \param{value}
-    non è sufficiente per contenere il risultato.
-  \item[\errcode{ENOTSUP}] gli attributi estesi non sono supportati dal
-    filesystem o sono disabilitati.
+  \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida.

   \end{errlist}
   \end{errlist}

-  Oltre a questi potranno essere restituiti tutti gli errori di \func{stat},
-  ed in particolare \errcode{EPERM} se non si hanno i permessi di accesso
-  all'attributo.  
+

 }
 \end{functions}
 
 }
 \end{functions}
 

-Come per le precedenti le tre funzioni leggono gli attributi rispettivamente
-di un file, un link simbolico o specificando un file descriptor, da
-specificare con il loro primo argomento. Gli altri due argomenti, identici per
-tutte e tre, indicano rispettivamente il puntatore \param{list} al buffer dove
-deve essere letta la lista e la dimensione \param{size} di quest'ultimo.
+Prima di effettuare la lettura della rappresentazione binaria è sempre
+necessario allocare un buffer di dimensione sufficiente a contenerla, pertanto
+prima si dovrà far ricorso a \funcd{acl\_size} per ottenere tale dimensione e
+poi allocare il buffer con una delle funzioni di
+sez.~\ref{sec:proc_mem_alloc}. Una volta terminato l'uso della
+rappresentazione binaria, il buffer dovrà essere esplicitamente disallocato.

 
 

-La lista viene fornita come sequenza non ordinata dei nomi dei singoli
-attributi estesi (sempre comprensivi del prefisso della loro classe) ciascuno
-dei quali è terminato da un carattere nullo. I nomi sono inseriti nel buffer
-uno di seguito all'altro. Il valore di ritorno della funzione indica la
-dimensione totale della lista in byte.
+La funzione che consente di leggere la rappresentazione binaria di una ACL è
+\funcd{acl\_copy\_ext}, il cui prototipo è:
+\begin{functions}
+  \headdecl{sys/types.h} 
+  \headdecl{sys/acl.h}
+  
+  \funcdecl{ssize\_t acl\_copy\_ext(void *buf\_p, acl\_t acl, ssize\_t size)}

 
 

-Come per le funzioni di lettura dei singoli attributi se le dimensioni del
-buffer non sono sufficienti si avrà un errore, ma è possibile ottenere dal
-valore di ritorno della funzione una stima della dimensione totale della lista
-usando per \param{size} un valore nullo. 
+  Ottiene la rappresentazione binaria di una ACL.

 
 

-Infine per rimuovere semplicemente un attributo esteso, si ha a disposizione
-un ultimo gruppo di funzioni: \funcd{removexattr}, \funcd{lremovexattr} e
-\funcd{fremovexattr}; i rispettivi prototipi sono:
+  \bodydesc{La funzione restituisce in caso di successo la dimensione in byte
+    della rappresentazione binaria della ACL indicata da \param{acl} e $-1$ in
+    caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
+  \begin{errlist}
+  \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida o
+    \param{size} è negativo o nullo.
+  \item[\errcode{ERANGE}] il valore di \param{size} è più piccolo della
+    dimensione della rappresentazione della ACL.
+  \end{errlist}
+
+}
+\end{functions}
+
+La funzione salverà la rappresentazione binaria della ACL indicata da
+\param{acl} sul buffer posto all'indirizzo \param{buf\_p} e lungo \param{size}
+byte, restituendo la dimensione della stessa come valore di ritorno. Qualora
+la dimensione della rappresentazione ecceda il valore di \param{size} la
+funzione fallirà con un errore di \errcode{ERANGE}. La funzione non ha nessun
+effetto sulla ACL indicata da \param{acl}.
+
+Viceversa se si vuole ripristinare una ACL a partire dalla rappresentazione
+binaria della stessa disponibile in un buffer si potrà usare la funzione 
+\funcd{acl\_copy\_int}, il cui prototipo è:

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

-  \headdecl{attr/xattr.h} 
+  \headdecl{sys/acl.h}

   
   

-  \funcdecl{int removexattr(const char *path, const char *name)}
+  \funcdecl{ssize\_t acl\_copy\_int(const void *buf\_p)}

 
 

-  \funcdecl{int lremovexattr(const char *path, const char *name)}
+  Ripristina la rappresentazione binaria di una ACL.

 
 

-  \funcdecl{int fremovexattr(int filedes, const char *name)}
+  \bodydesc{La funzione restituisce un oggetto di tipo \type{acl\_t} in caso
+    di successo e \code{(acl\_t)NULL} in caso di errore, nel qual caso
+    \var{errno} assumerà uno dei valori:
+  \begin{errlist}
+  \item[\errcode{EINVAL}] il buffer all'indirizzo \param{buf\_p} non contiene
+    una rappresentazione corretta di una ACL.
+  \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare un oggetto
+    \type{acl\_t} per la ACL richiesta.
+  \end{errlist}

 
 

+}
+\end{functions}

 
 

-  Rimuovono un attributo esteso di un file.
+La funzione in caso di successo alloca autonomamente un oggetto di tipo
+\type{acl\_t} che viene restituito come valore di ritorno con il contenuto
+della ACL rappresentata dai dati contenuti nel buffer puntato da
+\param{buf\_p}. Si ricordi che come per le precedenti funzioni l'oggetto
+\type{acl\_t} dovrà essere disallocato esplicitamente al termine del suo
+utilizzo.
+
+Una volta che si disponga della ACL desiderata, questa potrà essere impostata
+su un file o una directory. Per impostare una ACL sono disponibili due
+funzioni; la prima è \funcd{acl\_set\_file}, che opera sia su file che su
+directory, ed il cui prototipo è:
+\begin{functions}
+  \headdecl{sys/types.h} 
+  \headdecl{sys/acl.h}

   
   

-  \bodydesc{Le funzioni restituiscono 0 in caso di successo, e $-1$ in caso di
-    errore, nel qual caso \var{errno} assumerà i valori:
+  \funcdecl{int acl\_set\_file(const char *path, acl\_type\_t type, acl\_t
+    acl)}
+
+  Imposta una ACL su un file o una directory.
+
+  \bodydesc{La funzione restituisce $0$ in caso di successo e $-1$ in caso di
+    errore, nel qual caso \var{errno} assumerà uno dei valori:

   \begin{errlist}
   \begin{errlist}

-  \item[\errcode{ENOATTR}] l'attributo richiesto non esiste.
-  \item[\errcode{ENOTSUP}] gli attributi estesi non sono supportati dal
-    filesystem o sono disabilitati.
+  \item[\errcode{EACCES}] o un generico errore di accesso a \param{path} o il
+    valore di \param{type} specifica una ACL il cui tipo non può essere
+    assegnato a \param{path}.
+  \item[\errcode{EINVAL}] o \param{acl} non è una ACL valida, o \param{type}
+    ha in valore non corretto.
+  \item[\errcode{ENOSPC}] non c'è spazio disco sufficiente per contenere i
+    dati aggiuntivi della ACL.
+  \item[\errcode{ENOTSUP}] si è cercato di impostare una ACL su un file
+    contenuto in un filesystem che non supporta le ACL.

   \end{errlist}
   \end{errlist}

-  ed inoltre tutti gli errori di \func{stat}.  
+  ed inoltre \errval{ENOENT}, \errval{ENOTDIR}, \errval{ENAMETOOLONG},
+  \errval{EROFS}, \errval{EPERM}.

 }
 \end{functions}
 
 }
 \end{functions}
 

-Le tre funzioni rimuovono l'attributo esteso indicato dall'argomento
-\param{name} rispettivamente di un file, un link simbolico o specificando un
-file descriptor, da specificare con il loro primo argomento.  Anche in questo
-caso l'argomento \param{name} deve essere specificato con le modalità già
-illustrate in precedenza per le altre funzioni relative agli attributi estesi.
+La funzione consente di assegnare la ACL contenuta in \param{acl} al file o
+alla directory indicate dal pathname \param{path}, mentre con \param{type} si
+indica il tipo di ACL utilizzando le costanti di tab.~\ref{tab:acl_type}, ma
+si tenga presente che le ACL di default possono essere solo impostate
+qualora \param{path} indichi una directory. Inoltre perché la funzione abbia
+successo la ACL dovrà essere valida, e contenere tutti le voci necessarie,
+unica eccezione è quella in cui si specifica una ACL vuota per cancellare la
+ACL di default associata a \func{path}.\footnote{questo però è una estensione
+  della implementazione delle ACL di Linux, la bozza di standard POSIX.1e
+  prevedeva l'uso della apposita funzione \funcd{acl\_delete\_def\_file}, che
+  prende come unico argomento il pathname della directory di cui si vuole
+  cancellare l'ACL di default, per i dettagli si ricorra alla pagina di
+  manuale.}  La seconda funzione che consente di impostare una ACL è
+\funcd{acl\_set\_fd}, ed il suo prototipo è:
+\begin{functions}
+  \headdecl{sys/types.h} 
+  \headdecl{sys/acl.h}
+  
+  \funcdecl{int acl\_set\_fd(int fd, acl\_t acl)}

 
 

-\itindend{Extended~Attributes}
+  Imposta una ACL su un file descriptor.

 
 

+  \bodydesc{La funzione restituisce $0$ in caso di successo e $-1$ in caso di
+    errore, nel qual caso \var{errno} assumerà uno dei valori:
+  \begin{errlist}
+  \item[\errcode{EBADF}].
+  \item[\errcode{EINVAL}] o \param{acl} non è una ACL valida, o \param{type}
+    ha in valore non corretto.
+  \item[\errcode{ENOSPC}] non c'è spazio disco sufficiente per contenere i
+    dati aggiuntivi della ACL.
+  \item[\errcode{ENOTSUP}] si è cercato di impostare una ACL su un file
+    contenuto in un filesystem che non supporta le ACL.
+  \end{errlist}
+  ed inoltre \errval{EBADF}, \errval{EROFS}, \errval{EPERM}.
+}
+\end{functions}

 
 

-\subsection{Le \textit{Access  Control List}}
-\label{sec:file_ACL}
+La funzione è del tutto è analoga a \funcd{acl\_set\_file} ma opera
+esclusivamente sui file identificati tramite un file descriptor. Non dovendo
+avere a che fare con directory (e con la conseguente possibilità di avere una
+ACL di default) la funzione non necessita che si specifichi il tipo di ACL,
+che sarà sempre di accesso, e prende come unico argomento, a parte il file
+descriptor, la ACL da impostare.

 
 

-% la documentazione di sistema è nei pacchetti libacl1-dev e acl 
-% vedi anche http://www.suse.de/~agruen/acl/linux-acls/online/
+Le funzioni viste finora operano a livello di una intera ACL, eseguendo in una
+sola volta tutte le operazioni relative a tutte le voci in essa contenuta. In
+generale è possibile modificare un singolo valore all'interno di una singola
+voce direttamente con le funzioni previste dallo standard POSIX.1e.  Queste
+funzioni però sono alquanto macchinose da utilizzare per cui è molto più
+semplice operare direttamente sulla rappresentazione testuale. Questo è il
+motivo per non tratteremo nei dettagli dette funzioni, fornendone solo una
+descrizione sommaria; chi fosse interessato potrà ricorrere alle pagina di
+manuale.

 
 

-\itindbeg{Access~Control~List}
+Se si vuole operare direttamente sui contenuti di un oggetto di tipo
+\type{acl\_t} infatti occorre fare riferimento alle singole voci tramite gli
+opportuni puntatori di tipo \type{acl\_entry\_t}, che possono essere ottenuti
+dalla funzione \funcd{acl\_get\_entry} (per una voce esistente) o dalla
+funzione \funcd{acl\_create\_entry} per una voce da aggiungere. Nel caso della
+prima funzione si potrà poi ripetere la lettura per ottenere i puntatori alle
+singole voci successive alla prima.

 
 

-Il modello classico dei permessi di Unix, per quanto funzionale ed efficiente,
-è comunque piuttosto limitato e per quanto possa aver coperto per lunghi anni
-le esigenze più comuni con un meccanismo semplice e potente, non è in grado di
-rispondere in maniera adeguata a situazioni che richiedono una gestione
-complessa dei permessi di accesso.\footnote{già un requisito come quello di
-  dare accesso in scrittura ad alcune persone ed in sola lettura ad altre non
-  si può soddisfare in maniera semplice.}
+Una volta ottenuti detti puntatori si potrà operare sui contenuti delle singole
+voci; con le funzioni \funcd{acl\_get\_tag\_type}, \funcd{acl\_get\_qualifier},
+\funcd{acl\_get\_permset} si potranno leggere rispettivamente tipo,
+qualificatore e permessi mentre con le corrispondente funzioni
+\funcd{acl\_set\_tag\_type}, \funcd{acl\_set\_qualifier},
+\funcd{acl\_set\_permset} si possono impostare i valori; in entrambi i casi
+vengono utilizzati tipi di dato ad hoc.\footnote{descritti nelle singole
+  pagine di manuale.} Si possono poi copiare i valori di una voce da una ACL
+ad un altra con \funcd{acl\_copy\_entry} o eliminare una voce da una ACL con
+\funcd{acl\_delete\_entry}.

 
 

-Per questo motivo erano state progressivamente introdotte nelle varie versioni
-di Unix dei meccanismi di gestione dei permessi dei file più flessibili, nella
-forma delle cosiddette \textit{Access Control List} (indicate usualmente con
-la sigla ACL).  Nello sforzo di standardizzare queste funzionalità era stato
-creato un gruppo di lavoro il cui scopo era estendere lo standard POSIX 1003
-attraverso due nuovi insiemi di specifiche, la POSIX 1003.1e per l'interfaccia
-di programmazione e la POSIX 1003.2c per i comandi di shell.
+\itindend{Access~Control~List}

 
 

-Gli obiettivi erano però forse troppo ambizioni, e nel gennaio del 1998 i
-finanziamenti vennero ritirati senza che si fosse arrivati alla definizione di
-uno standard, dato però che una parte della documentazione prodotta era di
-alta qualità venne deciso di rilasciare al pubblico la diciassettesima bozza
-del documento, quella che va sotto il nome di \textit{POSIX 1003.1e Draft 17},
-che è divenuta la base sulla quale si definiscono le cosiddette \textit{Posix
-  ACL}.

 
 

-A differenza di altri sistemi (ad esempio FreeBSD) nel caso di Linux si è
-scelto di realizzare le ACL attraverso l'uso degli
-\itindex{Extended~Attributes} \textit{Extended Attributes} (appena trattati in
-sez.~\ref{sec:file_xattr}), e fornire tutte le relative funzioni di gestione
-tramite una libreria, \texttt{libacl} che nasconde i dettagli implementativi
-delle ACL e presenta ai programmi una interfaccia che fa riferimento allo
-standard POSIX 1003.1e.

 
 

-Anche in questo caso le funzioni di questa libreria non fanno parte delle
-\acr{glibc} e devono essere installate a parte;\footnote{la versione corrente
-  della libreria è \texttt{libacl1}, e nel caso si usi Debian la si può
-  installare con il pacchetto omonimo e con il collegato \texttt{libacl1-dev}
-  per i file di sviluppo.}  pertanto se un programma le utilizza si dovrà
-indicare esplicitamente l'uso della libreria \texttt{libacl} invocando il
-compilatore con l'opzione \texttt{-lacl}. Si tenga presente inoltre che per
-poterle utilizzare le ACL devono essere attivate esplicitamente montando il
-filesystem\footnote{che deve supportarle, ma questo è ormai vero per
-  praticamente tutti i filesystem più comuni, con l'eccezione di NFS per il
-  quale esiste però un supporto sperimentale.} su cui le si vogliono
-utilizzare con l'opzione \texttt{acl} attiva. Dato che si tratta di una
-estensione è infatti opportuno utilizzarle soltanto laddove siano necessarie.

 
 

-Una ACL è composta da un insieme di voci, e ciascuna voce è a sua volta
-costituita da un \textsl{tipo}, da un eventuale
-\textsl{qualificatore},\footnote{deve essere presente soltanto per le voci di
-  tipo \const{ACL\_USER} e \const{ACL\_GROUP}.} e da un insieme di permessi.
-Ad ogni oggetto sul filesystem si può associare una ACL che ne governa i
-permessi di accesso, detta \textit{access ACL}.  Inoltre per le directory si
-può impostare una ACL aggiuntiva, detta \textit{default ACL}, che serve ad
-indicare quale dovrà essere la ACL assegnata di default nella creazione di un
-file all'interno della directory stessa. Come avviene per i permessi le ACL
-possono essere impostate solo del proprietario del file, o da un processo con
-la capability \index{capabilities} \const{CAP\_FOWNER}.
-
-\begin{table}[htb]
-  \centering
-  \footnotesize
-  \begin{tabular}{|l|p{8cm}|}
-    \hline
-    \textbf{Tipo} & \textbf{Descrizione} \\
-    \hline
-    \hline
-    \const{ACL\_USER\_OBJ} & voce che contiene i diritti di accesso del
-                             proprietario del file.\\
-    \const{ACL\_USER}      & voce che contiene i diritti di accesso per
-                             l'utente indicato dal rispettivo
-                             qualificatore.\\  
-    \const{ACL\_GROUP\_OBJ}& voce che contiene i diritti di accesso del
-                             gruppo proprietario del file.\\
-    \const{ACL\_GROUP}     & voce che contiene i diritti di accesso per
-                             il gruppo indicato dal rispettivo
-                             qualificatore.\\
-    \const{ACL\_MASK}      & voce che contiene la maschera dei massimi
-                             permessi di accesso che possono essere garantiti
-                             da voci del tipo \const{ACL\_USER},
-                             \const{ACL\_GROUP} e \const{ACL\_GROUP\_OBJ}.\\
-    \const{ACL\_OTHER}     & voce che contiene i diritti di accesso di chi
-                             non corrisponde a nessuna altra voce dell'ACL.\\
-    \hline
-  \end{tabular}
-  \caption{Le costanti che identificano i tipi delle voci di una ACL.}
-  \label{tab:acl_tag_types}
-\end{table}
+\subsection{La gestione delle \textit{capabilities}}
+\label{sec:proc_capabilities}

 
 

-L'elenco dei vari tipi di voci presenti in una ACL, con una breve descrizione
-del relativo significato, è riportato in tab.~\ref{tab:acl_tag_types}. Tre di
-questi tipi, \const{ACL\_USER\_OBJ}, \const{ACL\_GROUP\_OBJ} e
-\const{ACL\_OTHER}, corrispondono direttamente ai tre permessi ordinari dei
-file (proprietario, gruppo proprietario e tutti gli altri) e per questo una
-ACL valida deve sempre contenere una ed una sola voce per ciascuno di questi
-tipi.
+\itindbeg{capabilities} 

 
 

-Una ACL può poi contenere un numero arbitrario di voci di tipo
-\const{ACL\_USER} e \const{ACL\_GROUP}, ciascuna delle quali indicherà i
-permessi assegnati all'utente e al gruppo indicato dal relativo qualificatore;
-ovviamente ciascuna di queste voci dovrà fare riferimento ad un utente o ad un
-gruppo diverso, e non corrispondenti a quelli proprietari del file. Inoltre se
-in una ACL esiste una voce di uno di questi due tipi è obbligatoria anche la
-presenza di una ed una sola voce di tipo \const{ACL\_MASK}, che negli altri
-casi è opzionale.
+Come accennato in sez.~\ref{sec:proc_access_id} l'architettura classica della
+gestione dei privilegi in un sistema unix-like ha il sostanziale problema di
+fornire all'amministratore dei poteri troppo ampi, questo comporta che anche
+quando si siano predisposte delle misure di protezione per in essere in grado
+di difendersi dagli effetti di una eventuale compromissione del
+sistema,\footnote{come montare un filesystem in sola lettura per impedirne
+  modifiche, o marcare un file come immutabile.} una volta che questa sia
+stata effettuata e si siano ottenuti i privilegi di amministratore, queste
+potranno essere comunque rimosse.\footnote{nei casi elencati nella precedente
+  nota si potrà sempre rimontare il sistema in lettura-scrittura, o togliere
+  la marcatura di immutabilità.}

 
 

-Quest'ultimo tipo di voce contiene la maschera dei permessi che possono essere
-assegnati tramite voci di tipo \const{ACL\_USER}, \const{ACL\_GROUP} e
-\const{ACL\_GROUP\_OBJ}; se in una di queste voci si fosse specificato un
-permesso non presente in \const{ACL\_MASK} questo verrebbe ignorato. L'uso di
-una ACL di tipo \const{ACL\_MASK} è di particolare utilità quando essa
-associata ad una \textit{default ACL} su una directory, in quanto i permessi
-così specificati verranno ereditati da tutti i file creati nella stessa
-directory. Si ottiene così una sorta di \itindex{umask} \textit{umask}
-associata ad un oggetto sul filesystem piuttosto che a un processo.
+Il problema consiste nel fatto che nell'architettura tradizionale di un
+sistema unix-like i controlli di accesso sono basati su un solo livello di
+separazione: per i processi normali essi sono posti in atto, mentre per i
+processi con i privilegi di amministratore essi non vengono neppure eseguiti;
+per questo motivo non era previsto alcun modo per evitare che un processo con
+diritti di amministratore non potesse eseguire certe operazioni, o per cedere
+definitivamente alcuni privilegi da un certo momento in poi.

 
 

-Dato che le ACL vengono a costituire una estensione dei permessi ordinari, uno
-dei problemi che si erano posti nella loro standardizzazione era appunto
-quello della corrispondenza fra questi e le ACL. Come accennato i permessi
-ordinari vengono mappati le tre voci di tipo \const{ACL\_USER\_OBJ},
-\const{ACL\_GROUP\_OBJ} e \const{ACL\_OTHER} che devono essere presenti in
-qualunque ACL; un cambiamento ad una di queste voci viene automaticamente
-riflesso sui permessi ordinari dei file\footnote{per permessi ordinari si
-  intende quelli mantenuti nell'\textit{inode}, che devono restare dato che un
-  filesystem può essere montato senza abilitare le ACL.} e viceversa. In
-realtà la mappatura è diretta solo per le voci \const{ACL\_USER\_OBJ} e
-\const{ACL\_OTHER}, nel caso di \const{ACL\_GROUP\_OBJ} questo vale soltanto
-se non è presente una voce di tipo \const{ACL\_MASK}, se invece questa è
-presente verranno tolti dai permessi di \const{ACL\_GROUP\_OBJ} tutti quelli
-non presenti in \const{ACL\_MASK}.\footnote{questo diverso comportamento a
-  seconda delle condizioni è stato introdotto dalla standardizzazione
-  \textit{POSIX 1003.1e Draft 17} per mantenere il comportamento invariato sui
-  sistemi dotati di ACL per tutte quelle applicazioni che sono conformi
-  soltanto all'ordinario standard \textit{POSIX 1003.1}.}
+Per ovviare a tutto ciò, a partire dai kernel della serie 2.2, è stato
+introdotto un meccanismo, detto \textit{capabilities}, che consentisse di
+suddividere i vari privilegi tradizionalmente associati all'amministratore in
+un insieme di \textsl{capacità} distinte.  L'idea era che queste capacità
+potessero essere abilitate e disabilitate in maniera indipendente per ciascun
+processo con privilegi di amministratore, permettendo così una granularità
+molto più fine nella distribuzione degli stessi che evitasse la originaria
+situazione di ``\textsl{tutto o nulla}''.

 
 

-Un secondo aspetto dell'incidenza delle ACL sul comportamento del sistema è
-quello relativo alla creazione di nuovi file,\footnote{o oggetti sul
-  filesystem, il comportamento discusso vale per le funzioni \func{open} e
-  \func{creat} (vedi sez.~\ref{sec:file_open}), \func{mkdir} (vedi
-  sez.~\ref{sec:file_dir_creat_rem}), \func{mknod} e \func{mkfifo} (vedi
-  sez.~\ref{sec:file_mknod}).} che come accennato può essere modificato dalla
-presenza di una \textit{default ACL} sulla directory che contiene quel file.
-Se questa non c'è valgono le regole usuali illustrate in
-sez.~\ref{sec:file_perm_management}, per cui essi sono determinati dalla
-\itindex{umask} \textit{umask} del processo, e la sola differenza è che i
-permessi ordinari da esse risultanti vengono automaticamente rimappati anche
-su una ACL di accesso assegnata automaticamente al nuovo file, che contiene
-soltanto le tre corrispondenti voci di tipo \const{ACL\_USER\_OBJ},
-\const{ACL\_GROUP\_OBJ} e \const{ACL\_OTHER}.
+Il meccanismo completo delle \textit{capabilities}\footnote{l'implementazione
+  si rifà ad una bozza di quello che doveva diventare lo standard POSIX.1e,
+  poi abbandonato.} prevede inoltre la possibilità di associare le stesse ai
+singoli file eseguibili, in modo da poter stabilire quali capacità possono
+essere utilizzate quando viene messo in esecuzione uno specifico programma; ma
+il supporto per questa funzionalità è stato introdotto soltanto a partire dal
+kernel 2.6.24; fino ad allora doveva essere il programma stesso ad eseguire
+una riduzione esplicita delle sue capacità, cosa che ha reso l'uso di questa
+funzionalità poco diffuso, vista la presenza di meccanismi alternativi come
+\index{SELinux} SELinux.

 
 

-Se invece è presente una ACL di default sulla directory che contiene il nuovo
-file questa diventerà automaticamente la sua ACL di accesso, a meno di non
-aver indicato, nelle funzioni di creazione che lo consentono, uno specifico
-valore per i permessi ordinari;\footnote{tutte le funzioni citate in
-  precedenza supportano un argomento \var{mode} che indichi un insieme di
-  permessi iniziale.} in tal caso saranno eliminati dalle voci corrispondenti
-nella ACL tutti quelli non presenti in tale indicazione.
+Per gestire questo meccanismo ciascun processo porta con sé tre distinti
+insiemi di \textit{capabilities}, che vengono denominati rispettivamente
+\textit{effective}, \textit{permitted} ed \textit{inherited}. Questi insiemi
+vengono mantenuti in forma di tre diverse maschere binarie,\footnote{il kernel
+  li mantiene, come i vari identificatori di sez.~\ref{sec:proc_setuid},
+  all'interno della \struct{task\_struct} di ciascun processo (vedi
+  fig.~\ref{fig:proc_task_struct}), nei tre campi \texttt{cap\_effective},
+  \texttt{cap\_inheritable}, \texttt{cap\_permitted} del tipo
+  \texttt{kernel\_cap\_t}; questo è attualmente definito come intero a 32 bit,
+  il che comporta un massimo di 32 \textit{capabilities} distinte.} in cui
+ciascun bit corrisponde ad una capacità diversa.

 
 

-Dato che questa è la ragione che ha portato alla loro creazione, la principale
-modifica introdotta con la presenza della ACL è quella alle regole del
-controllo di accesso ai file illustrate in sez.~\ref{sec:file_perm_overview}.
-Come nel caso ordinario per il controllo vengono sempre utilizzati gli
-identificatori del gruppo \textit{effective} del processo, ma in presenza di
-ACL i passi attraverso i quali viene stabilito se esso ha diritto di accesso
-sono i seguenti:
-\begin{enumerate*}
-\item Se l'user-ID del processo è nullo l'accesso è sempre garantito senza
-  nessun controllo.
-\item Se l'user-ID del processo corrisponde al proprietario del file allora:
-  \begin{itemize*}
-  \item se la voce \const{ACL\_USER\_OBJ} contiene il permesso richiesto,
-    l'accesso è consentito;
-  \item altrimenti l'accesso è negato.
-  \end{itemize*}
-\item Se l'user-ID del processo corrisponde ad un qualunque qualificatore
-  presente in una voce \const{ACL\_USER} allora:
-  \begin{itemize*}
-  \item se la voce \const{ACL\_USER} corrispondente e la voce
-    \const{ACL\_MASK} contengono entrambe il permesso richiesto, l'accesso è
-    consentito;
-  \item altrimenti l'accesso è negato.
-  \end{itemize*}
-\item Se è il group-ID del processo o uno dei group-ID supplementari
-  corrisponde al gruppo proprietario del file allora: 
-  \begin{itemize*}
-  \item se la voce \const{ACL\_GROUP\_OBJ} e una eventuale voce
-    \const{ACL\_MASK} (se non vi sono voci di tipo \const{ACL\_GROUP} questa
-    può non essere presente) contengono entrambe il permesso richiesto,
-    l'accesso è consentito;
-  \item altrimenti l'accesso è negato.
-  \end{itemize*}
-\item Se è il group-ID del processo o uno dei group-ID supplementari
-  corrisponde ad un qualunque qualificatore presente in una voce
-  \const{ACL\_GROUP} allora:
-  \begin{itemize*}
-  \item se la voce \const{ACL\_GROUP} corrispondente e la voce
-    \const{ACL\_MASK} contengono entrambe il permesso richiesto, l'accesso è
-    consentito;
-  \item altrimenti l'accesso è negato.
-  \end{itemize*}
-\item Se la voce \const{ACL\_USER\_OBJ} contiene il permesso richiesto,
-  l'accesso è consentito, altrimenti l'accesso è negato.
-\end{enumerate*}
+L'utilizzo di tre distinti insiemi serve a fornire una interfaccia flessibile
+per l'uso delle \textit{capabilities}, con scopi analoghi a quelli per cui
+sono mantenuti i diversi insiemi di identificatori di
+sez.~\ref{sec:proc_setuid}; il loro significato è il seguente:
+\begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}}
+\item[\textit{effective}] l'insieme delle \textit{capabilities}
+  ``\textsl{effettive}'', cioè di quelle che vengono effettivamente usate dal
+  kernel quando deve eseguire il controllo di accesso per le varie operazioni
+  compiute dal processo.
+\item[\textit{permitted}] l'insieme delle \textit{capabilities}
+  ``\textsl{permesse}'', cioè l'insieme di quelle capacità che un processo
+  \textsl{può} impostare come \textsl{effettive}. Se un processo cancella una
+  capacità da questo insieme non potrà più riassumerla (almeno che non esegua
+  un programma che è \acr{suid} di root).
+\item[\textit{inherited}] l'insieme delle \textit{capabilities}
+  ``\textsl{ereditabili}'', cioè quelle che vengono trasmesse ad un nuovo
+  programma eseguito attraverso una chiamata ad \func{exec} (con l'eccezione
+  del caso che questo sia \acr{suid} di root).
+\label{sec:capabilities_set}
+\end{basedescript}

 
 

-I passi di controllo vengono eseguiti esattamente in questa sequenza, e la
-decisione viene presa non appena viene trovata una corrispondenza con gli
-identificatori del processo. Questo significa che i permessi presenti in una
-voce di tipo \const{ACL\_USER} hanno la precedenza sui permessi ordinari
-associati al gruppo proprietario del file (vale a dire su
-\const{ACL\_GROUP\_OBJ}).
+Oltre a questi tre insiemi, che sono relativi al singolo processo, il kernel
+mantiene un insieme generale valido per tutto il sistema, chiamato
+\itindex{capabilities~bounding~set} \textit{capabilities bounding set}. Ogni
+volta che un programma viene posto in esecuzione con \func{exec} il contenuto
+degli insiemi \textit{effective} e \textit{permitted} vengono mascherati con
+un \textsl{AND} binario del contenuto corrente del \textit{capabilities
+  bounding set}, così che il nuovo processo potrà disporre soltanto delle
+capacità in esso elencate.

 
 

-Per la gestione delle ACL lo standard \textit{POSIX 1003.1e Draft 17} ha
-previsto delle apposite funzioni ed tutta una serie di tipi di dati
-dedicati;\footnote{fino a definire un tipo di dato e delle costanti apposite
-  per identificare i permessi standard di lettura, scrittura ed esecuzione.}
-tutte le operazioni devono essere effettuate attraverso tramite questi tipi di
-dati, che incapsulano tutte le informazioni contenute nelle ACL. La prima di
-queste funzioni che prendiamo in esame è \funcd{acl\_init}, il cui prototipo
-è:
-\begin{functions}
-  \headdecl{sys/types.h} 
-  \headdecl{sys/acl.h}
-  
-  \funcdecl{acl\_t acl\_init(int count)}
+Il \textit{capabilities bounding set} è un parametro di sistema, accessibile
+attraverso il contenuto del file \procfile{/proc/sys/kernel/cap-bound}, che per
+questa sua caratteristica consente di impostare un limite generale alle
+capacità che possono essere accordate ai vari processi.  Questo valore può
+essere impostato ad un valore arbitrario esclusivamente dal primo processo
+eseguito nel sistema (di norma cioè da \texttt{/sbin/init}), ogni processo
+eseguito successivamente (cioè con \textsl{pid} diverso da 1) anche se
+eseguito con privilegi di amministratore potrà soltanto rimuovere uno dei bit
+già presenti dell'insieme: questo significa che una volta rimossa una
+\textit{capability} dal \textit{capabilities bounding set} essa non sarà più
+disponibile, neanche per l'amministratore, a meno di un riavvio.

 
 

-  Inizializza un'area di lavoro per una ACL di \param{count} voci.
-  
-  \bodydesc{La funzione restituisce un puntatore all'area di lavoro in caso di
-    successo e \const{NULL} in caso di errore, nel qual caso \var{errno}
-    assumerà uno dei valori:
-  \begin{errlist}
-  \item[\errcode{EINVAL}] il valore di \param{count} è negativo.
-  \item[\errcode{ENOMEM}] non c'è sufficiente memoria disponibile.
-  \end{errlist}
-}
-\end{functions}
+Quando un programma viene messo in esecuzione\footnote{cioè quando viene
+  eseguita la \func{execve} con cui lo si lancia; in corrispondenza di una
+  \func{fork} le \textit{capabilities} non vengono modificate.} esso eredita
+(nel senso che assume negli insiemi \textit{effective} e \textit{permitted})
+le \textit{capabilities} mantenute nell'insieme \textit{inherited}, a meno che
+non sia eseguito un programma \acr{suid} di root o la \func{exec} sia stata
+eseguita da un programma con \textsl{uid} reale zero; in tal caso il programma
+ottiene tutte le \textit{capabilities} presenti nel \textit{capabilities
+  bounding set}. In questo modo si può far si che ad un processo eseguito in
+un secondo tempo possano essere trasmesse solo un insieme limitato di
+capacità, impedendogli di recuperare quelle assenti nell'insieme
+\textit{inherited}. Si tenga presente invece che attraverso una \func{fork}
+vengono mantenute le stesse capacità del processo padre.

 
 

-La funzione alloca ed inizializza un'area di memoria che verrà usata per
-mantenere i dati di una ACL contenente fino ad un massimo di \param{count}
-voci. La funzione ritorna un valore di tipo \type{acl\_t}, da usare in tutte
-le altre funzioni che operano sulla ACL. La funzione si limita alla
-allocazione iniziale e non inserisce nessun valore nella ACL che resta vuota.
-Si tenga presente che pur essendo \type{acl\_t} un tipo opaco che identifica
-``\textsl{l'oggetto}'' ACL, il valore restituito dalla funzione non è altro
-che un puntatore all'area di memoria allocata per i dati richiesti; pertanto
-in caso di fallimento verrà restituito un puntatore nullo e si dovrà
-confrontare il valore di ritorno della funzione con ``\code{(acl\_t) NULL}''.

 
 

-Una volta che si siano completate le operazioni sui dati di una ACL la memoria
-allocata dovrà essere liberata esplicitamente attraverso una chiamata alla
-funzione \funcd{acl\_free}, il cui prototipo è:
-\begin{functions}
-  \headdecl{sys/types.h} 
-  \headdecl{sys/acl.h}
-  
-  \funcdecl{int acl\_free(void * obj\_p)}
+% TODO verificare per process capability bounding set, vedi:
+%  http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3b7391de67da515c91f48aa371de77cb6cc5c07e

 
 

-  Disalloca la memoria riservata per i dati di una ACL.
-  
-  \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ se
-    \param{obj\_p} non è un puntatore valido, nel qual caso \var{errno}
-    assumerà il valore \errcode{EINVAL} 
-}
-\end{functions}
+% TODO capire cosa cambia con i patch vari, vedi
+% http://lwn.net/Articles/280279/  
+% http://lwn.net/Articles/256519/
+% http://lwn.net/Articles/211883/

 
 

-Si noti come la funzione richieda come argomento un puntatore di tipo
-``\ctyp{void *}'', essa infatti può essere usata non solo per liberare la
-memoria allocata per i dati di una ACL, ma anche per quella usata per creare
-le stringhe di descrizione testuale delle ACL o per ottenere i valori dei
-qualificatori di una voce; pertanto a seconda dei casi occorrerà eseguire un
-\textit{cast} a ``\ctyp{void *}'' del tipo di dato di cui si vuole eseguire la
-disallocazione.  Si tenga presente poi che oltre a \func{acl\_init} esistono
-molte altre funzioni che possono allocare memoria per i dati delle ACL, è
-pertanto opportuno tenere traccia di tutte queste funzioni perché alla fine
-delle operazioni tutta la memoria allocata dovrà essere liberata con
-\func{acl\_free}.

 
 

-Una volta che si abbiano a disposizione i dati di una ACL tramite il
-riferimento ad oggetto di tipo \type{acl\_t} questi potranno essere copiati
-con la funzione \funcd{acl\_dup}, il cui prototipo è:
-\begin{functions}
-  \headdecl{sys/types.h} 
-  \headdecl{sys/acl.h}
-  
-  \funcdecl{acl\_t acl\_dup(acl\_t acl)}
+Un elenco delle delle \textit{capabilities} disponibili su Linux, con una
+breve descrizione ed il nome delle costanti che le identificano, è riportato
+in tab.~\ref{tab:proc_capabilities};\footnote{l'elenco presentato questa
+  tabella, ripreso dalla pagina di manuale (accessibile con \texttt{man
+    capabilities}) e dalle definizioni in \texttt{linux/capabilities.h}, è
+  aggiornato al kernel 2.6.26.} la tabella è divisa in due parti, la prima
+riporta le \textit{capabilities} previste anche nella bozza dello standard
+POSIX1.e, la seconda quelle specifiche di Linux.  Come si può notare dalla
+tabella alcune \textit{capabilities} attengono a singole funzionalità e sono
+molto specializzate, mentre altre hanno un campo di applicazione molto vasto,
+che è opportuno dettagliare maggiormente.

 
 

-  Crea una copia della ACL \param{acl}.
-  
-  \bodydesc{La funzione restituisce un oggetto di tipo \type{acl\_t} in caso
-    di successo e \code{(acl\_t)NULL} in caso di errore, nel qual caso
-    \var{errno} assumerà uno dei valori:
-  \begin{errlist}
-  \item[\errcode{EINVAL}] l'argomento \param{acl} non è un puntatore valido
-    per una ACL.
-  \item[\errcode{ENOMEM}] non c'è sufficiente memoria disponibile per eseguire
-    la copia.
-  \end{errlist}
-}
-\end{functions}
+\begin{table}[!h!bt]
+  \centering
+  \footnotesize
+  \begin{tabular}{|l|p{12cm}|}
+    \hline
+    \textbf{Capacità}&\textbf{Descrizione}\\
+    \hline
+    \hline
+%
+% POSIX-draft defined capabilities.
+%
+    \const{CAP\_AUDIT\_WRITE}&La capacità di scrivere dati nel giornale di
+                              auditing del kernel (dal kernel 2.6.11).\\ 
+    \const{CAP\_AUDIT\_CONTROL}& La capacità di abilitare e disabilitare il
+                              controllo dell'auditing (dal kernel 2.6.11).\\ 
+    % TODO verificare questa roba dell'auditing
+    \const{CAP\_CHOWN}      & La capacità di cambiare proprietario e gruppo
+                              proprietario di un file (vedi
+                              sez.~\ref{sec:file_ownership_management}).\\
+    \const{CAP\_DAC\_OVERRIDE}& La capacità di evitare il controllo dei
+                              permessi di lettura, scrittura ed esecuzione dei
+                              file,\footnotemark (vedi
+                              sez.~\ref{sec:file_access_control}).\\
+    \const{CAP\_DAC\_READ\_SEARCH}& La capacità di evitare il controllo dei
+                              permessi di lettura ed esecuzione per
+                              le directory (vedi
+                              sez.~\ref{sec:file_access_control}).\\
+    \const{CAP\_FOWNER}     & La capacità di evitare il controllo della
+                              proprietà di un file per tutte
+                              le operazioni privilegiate non coperte dalle
+                              precedenti \const{CAP\_DAC\_OVERRIDE} e
+                              \const{CAP\_DAC\_READ\_SEARCH}.\\
+    \const{CAP\_FSETID}     & La capacità di evitare la cancellazione
+                              automatica dei bit \itindex{suid~bit} \acr{suid}
+                              e \itindex{sgid~bit} \acr{sgid} quando un file
+                              per i quali sono impostati viene modificato da
+                              un processo senza questa capacità e la capacità
+                              di impostare il bit \acr{sgid} su un file anche
+                              quando questo è relativo ad un gruppo cui non si
+                              appartiene (vedi
+                              sez.~\ref{sec:file_perm_management}).\\ 
+    \const{CAP\_SETFCAP}    & La capacità di impostare le
+                              \textit{capabilities} di un file (dal kernel
+                              2.6.24).\\  
+    \const{CAP\_KILL}       & La capacità di mandare segnali a qualunque
+                              processo (vedi sez.~\ref{sec:sig_kill_raise}).\\
+    \const{CAP\_SETGID}     & La capacità di manipolare i group ID dei
+                              processi, sia il principale che i supplementari,
+                              (vedi sez.~\ref{sec:proc_setgroups}) che quelli
+                              trasmessi tramite i socket \textit{unix domain}
+                              (vedi sez.~\ref{sec:unix_socket}).\\
+    \const{CAP\_SETUID}     & La capacità di manipolare gli user ID del
+                              processo (vedi sez.~\ref{sec:proc_setuid}) e di
+                              trasmettere un user ID arbitrario nel passaggio
+                              delle credenziali coi socket \textit{unix
+                                domain} (vedi sez.~\ref{sec:unix_socket}).\\ 
+%
+% Linux specific capabilities
+%
+\hline
+    \const{CAP\_IPC\_LOCK}  & La capacità di effettuare il \textit{memory
+                              locking} \itindex{memory~locking} con le
+                              funzioni \func{mlock}, \func{mlockall},
+                              \func{shmctl}, \func{mmap} (vedi
+                              sez.~\ref{sec:proc_mem_lock} e 
+                              sez.~\ref{sec:file_memory_map}). \\  
+    \const{CAP\_IPC\_OWNER} & La capacità di evitare il controllo dei permessi
+                              per le operazioni sugli oggetti di
+                              intercomunicazione fra processi (vedi
+                              sez.~\ref{sec:ipc_sysv}).\\  
+    \const{CAP\_LEASE}      & La capacità di creare dei \textit{file lease}
+                              \index{file!lease} (vedi
+                              sez.~\ref{sec:file_asyncronous_lease})
+                              pur non essendo proprietari del file (dal kernel
+                              2.4).\\ 
+    \const{CAP\_LINUX\_IMMUTABLE}& La capacità di impostare sui file gli
+                              attributi \textit{immutable} e
+                              \itindex{append~mode} \textit{append only} (se
+                              supportati).\\
+    \const{CAP\_MKNOD}      & La capacità di creare
+                              \index{file!di~dispositivo} file di dispositivo
+                              con \func{mknod} (vedi
+                              sez.~\ref{sec:file_mknod}) (dal kernel 2.4).\\ 
+    \const{CAP\_NET\_ADMIN} & La capacità di eseguire alcune operazioni
+                              privilegiate sulla rete.\\
+    \const{CAP\_NET\_BIND\_SERVICE}& La capacità di porsi in ascolto
+                              su porte riservate (vedi
+                              sez.~\ref{sec:TCP_func_bind}).\\ 
+    \const{CAP\_NET\_BROADCAST}& La capacità di consentire l'uso di socket in
+                              \itindex{broadcast} \textit{broadcast} e
+                              \itindex{multicast} \textit{multicast}.\\ 
+    \const{CAP\_NET\_RAW}   & La capacità di usare socket \texttt{RAW} e
+                              \texttt{PACKET} (vedi sez.~\ref{sec:sock_type}).\\
+    \const{CAP\_SETPCAP}    & La capacità di impostare o rimuovere una
+                              capacità.\\ 
+    % TODO cambiata nel 2.4.24 rc1 ? 
+    \const{CAP\_SYS\_ADMIN} & La capacità di eseguire una serie di compiti
+                              amministrativi. \\
+    \const{CAP\_SYS\_BOOT}  & La capacità di fare eseguire un riavvio del
+                              sistema.\\
+% TODO trattare reboot e kexec 
+    \const{CAP\_SYS\_CHROOT}& La capacità di eseguire la funzione
+                              \func{chroot} (vedi
+                              sez.~\ref{sec:file_chroot}).\\
+    \const{CAP\_MAC\_ADMIN} & La capacità amministrare il MAC di Smack (dal
+                              kernel 2.6.25).\\  
+    \const{CAP\_MAC\_OVERRIDE}& La capacità evitare il MAC di Smack (dal
+                              kernel 2.6.25).\\  
+    \const{CAP\_SYS\_MODULE}& La capacità di caricare e rimuovere moduli del
+                              kernel. \\ 
+    \const{CAP\_SYS\_NICE}  & La capacità di modificare le priorità dei
+                              processi. \\ 
+    \const{CAP\_SYS\_PACCT} & La capacità di usare le funzioni di
+                              \textit{accounting} dei processi (vedi
+                              sez.~\ref{sec:sys_bsd_accounting}).\\ 
+    \const{CAP\_SYS\_PTRACE}& La capacità  di tracciare qualunque processo con
+                              \func{ptrace} (vedi 
+                              sez.~\ref{sec:xxx_ptrace}).\\
+    \const{CAP\_SYS\_RAWIO} & La capacità di eseguire operazioni sulle porte
+                              di I/O con \func{ioperm} e \func{iopl} (vedi
+                              sez.~\ref{sec:file_io_port}).\\
+    \const{CAP\_SYS\_RESOURCE}& La capacità di superare le limitazioni sulle
+                              risorse.\\ 
+    \const{CAP\_SYS\_TIME}  & La capacità di modificare il tempo di sistema
+                              (vedi sez.~\ref{sec:sys_time}).\\ 
+    \const{CAP\_SYS\_TTY\_CONFIG}& La capacità di simulare un \textit{hangup}
+                              della console, con la funzione
+                              \func{vhangup}.\\
+    \hline
+  \end{tabular}
+  \caption{Le costanti che identificano le \textit{capabilities} presenti nel
+    kernel.}
+\label{tab:proc_capabilities}
+\end{table}
+
+\footnotetext{vale a dire i permessi caratteristici del modello classico del
+  controllo di accesso chiamato \itindex{Discrectionary~Access~Control~(DAC)}
+  \textit{Discrectionary Access Control} (da cui il nome DAC).}
+
+% TODO aggiungere CAP_SYSLOG, citata in http://lwn.net/Articles/429595/
+
+La prima di queste capacità ``\textsl{ampie}'' è \const{CAP\_FOWNER}, che
+rimuove le restrizioni poste ad un processo che non ha la proprietà di un file
+in un vasto campo di operazioni;\footnote{vale a dire la richiesta che
+  l'user-ID effettivo del processo (o meglio il \textit{filesystem user-ID},
+  vedi sez.~\ref{sec:proc_setuid}) coincida con quello del proprietario.}
+queste comprendono i cambiamenti dei permessi e dei tempi del file (vedi
+sez.~\ref{sec:file_perm_management} e sez.~\ref{sec:file_file_times}), le
+impostazioni degli attributi estesi e delle ACL (vedi
+sez.~\ref{sec:file_xattr} e \ref{sec:file_ACL}), poter ignorare lo
+\itindex{sticky~bit} \textit{sticky bit} nella cancellazione dei file (vedi
+sez.~\ref{sec:file_special_perm}), la possibilità di impostare il flag di
+\const{O\_NOATIME} con \func{open} e \func{fcntl} (vedi
+sez.~\ref{sec:file_open} e sez.~\ref{sec:file_fcntl}) senza restrizioni.
+
+Una seconda capacità che copre diverse operazioni, in questo caso riguardanti
+la rete, è \const{CAP\_NET\_ADMIN}, che consente di impostare le opzioni
+privilegiate dei socket (vedi sez.~\ref{sec:sock_generic_options}), abilitare
+il \itindex{multicast} \textit{multicasting}, eseguire la configurazione delle
+interfacce di rete (vedi sez.~\ref{sec:sock_ioctl_netdevice}) ed impostare la
+tabella di instradamento.
+
+Una terza \textit{capability} con vasto campo di applicazione è
+\const{CAP\_SYS\_ADMIN}, che copre una serie di operazioni amministrative,
+come impostare le quote disco (vedi sez.\ref{sec:disk_quota}), attivare e
+disattivare la swap, montare, rimontare e smontare filesystem (vedi
+sez.~\ref{sec:sys_file_config}), effettuare operazioni di controllo sugli
+oggetti dell'IPC di SysV (vedi sez.~\ref{sec:ipc_sysv}), operare sugli
+attributi estesi di classe \texttt{security} o \texttt{trusted} (vedi
+sez.~\ref{sec:file_xattr}), specificare un user-ID arbitrario nella
+trasmissione delle credenziali dei socket (vedi sez.~\ref{sec:socket_xxx}),
+assegnare classi privilegiate per lo scheduling dell'I/O (vedi
+sez.~\ref{sec:io_priority}), superare il limite di sistema sul numero massimo
+di file aperti,\footnote{quello indicato da \procfile{/proc/sys/fs/file-max}.}
+effettuare operazioni privilegiate sulle chiavi mantenute dal kernel (vedi
+sez.~\ref{sec:io_priority}), usare la funzione \func{lookup\_dcookie} (vedi
+sez.~\ref{sec:xxx_profiling}), usare \const{CLONE\_NEWNS} con \func{unshare},
+(vedi sez.~\ref{sec:process_clone}).

 
 

-La funzione crea una copia dei dati della ACL indicata tramite l'argomento
-\param{acl}, allocando autonomamente tutto spazio necessario alla copia e
-restituendo un secondo oggetto di tipo \type{acl\_t} come riferimento a
-quest'ultima.  Valgono per questo le stesse considerazioni fatte per il valore
-di ritorno di \func{acl\_init}, ed in particolare il fatto che occorrerà
-prevedere una ulteriore chiamata esplicita a \func{acl\_free} per liberare la
-memoria occupata dalla copia.
+Originariamente \const{CAP\_SYS\_NICE} riguardava soltanto la capacità di
+aumentare le priorità di esecuzione dei processi, come la diminuzione del
+valore di \textit{nice} (vedi sez.~\ref{sec:proc_sched_stand}), l'uso delle
+priorità \textit{real-time} (vedi sez.~\ref{sec:proc_real_time}), o
+l'impostazione delle affinità di processore (vedi
+sez.~\ref{sec:proc_sched_multiprocess}); ma con l'introduzione di priorità
+anche riguardo le operazioni di accesso al disco, e, nel caso di sistemi NUMA,
+alla memoria, essa viene a coprire anche la possibilità di assegnare priorità
+arbitrarie nell'accesso a disco (vedi sez.~\ref{sec:io_priority}) e nelle
+politiche di allocazione delle pagine di memoria ai nodi di un sistema NUMA.

 
 

-Se si deve creare una ACL manualmente l'uso di \func{acl\_init} è scomodo,
-dato che la funzione restituisce una ACL vuota, una alternativa allora è usare
-\funcd{acl\_from\_mode} che consente di creare una ACL a partire da un valore
-di permessi ordinari, il prototipo della funzione è:
-\begin{functions}
-  \headdecl{sys/types.h} 
-  \headdecl{sys/acl.h}
-  
-  \funcdecl{acl\_t acl\_from\_mode(mode\_t mode)}
+Infine la \textit{capability} \const{CAP\_SYS\_RESOURCE} attiene alla
+possibilità di superare i limiti imposti sulle risorse di sistema, come usare
+lo spazio disco riservato all'amministratore sui filesystem che lo supportano,
+usare la funzione \func{ioctl} per controllare il \textit{journaling} sul
+filesystem \acr{ext3}, non subire le quote disco, aumentare i limiti sulle
+risorse (vedi sez.~\ref{sec:sys_resource_limit}) e sulle dimensioni dei
+messaggi delle code del SysV IPC (vedi sez.~\ref{sec:ipc_sysv_mq}).

 
 

-  Crea una ACL inizializzata con i permessi di \param{mode}.
-  
-  \bodydesc{La funzione restituisce un oggetto di tipo \type{acl\_t} in caso
-    di successo e \code{(acl\_t)NULL} in caso di errore, nel qual caso
-    \var{errno} assumerà il valore \errval{ENOMEM}.

 
 

-}
-\end{functions}
+Per la gestione delle \textit{capabilities} il kernel mette a disposizione due
+funzioni che permettono rispettivamente di leggere ed impostare i valori dei
+tre insiemi illustrati in precedenza. Queste due funzioni sono \funcd{capget}
+e \funcd{capset} e costituiscono l'interfaccia di gestione basso livello; i
+loro rispettivi prototipi sono:
+\begin{functions}
+  \headdecl{sys/capability.h}

 
 

-La funzione restituisce una ACL inizializzata con le tre voci obbligatorie
-\const{ACL\_USER\_OBJ}, \const{ACL\_GROUP\_OBJ} e \const{ACL\_OTHER} già
-impostate secondo la corrispondenza ai valori dei permessi ordinari indicati
-dalla maschera passata nell'argomento \param{mode}. Questa funzione è una
-estensione usata dalle ACL di Linux e non è portabile, ma consente di
-semplificare l'inizializzazione in maniera molto comoda. 
+  \funcdecl{int capget(cap\_user\_header\_t hdrp, cap\_user\_data\_t datap)}
+  Legge le \textit{capabilities}.

 
 

-Altre due funzioni che consentono di creare una ACL già inizializzata sono
-\funcd{acl\_get\_fd} e \funcd{acl\_get\_file}, che però sono per lo più
-utilizzate per leggere la ACL corrente di un file; i rispettivi prototipi
-sono:
-\begin{functions}
-  \headdecl{sys/types.h} 
-  \headdecl{sys/acl.h}
-  
-  \funcdecl{acl\_t acl\_get\_file(const char *path\_p, acl\_type\_t type)}
-  \funcdecl{acl\_t acl\_get\_fd(int fd)}
+  \funcdecl{int capset(cap\_user\_header\_t hdrp, const cap\_user\_data\_t
+    datap)} 
+  Imposta le \textit{capabilities}.

 
 

-  Ottiene i dati delle ACL di un file.

   
   

-  \bodydesc{La funzione restituisce un oggetto di tipo \type{acl\_t} in caso
-    di successo e \code{(acl\_t)NULL} in caso di errore, nel qual caso
-    \var{errno} assumerà uno dei valori:
-  \begin{errlist}
-  \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
-  \item[\errcode{ENOTSUP}] il filesystem cui fa riferimento il file non
-    supporta le ACL.
+  \bodydesc{Entrambe le funzioni ritornano 0 in caso di successo e -1 in caso
+    di errore, nel qual caso \var{errno} può assumere i valori:
+    \begin{errlist}
+    \item[\errcode{ESRCH}] si è fatto riferimento ad un processo inesistente.
+    \item[\errcode{EPERM}] si è tentato di aggiungere una capacità
+      nell'insieme delle \textit{capabilities} permesse, o di impostare una
+      capacità non presente nell'insieme di quelle permesse negli insieme
+      delle effettive o ereditate, o si è cercato di impostare una
+      \textit{capability} di un altro processo senza avare
+      \const{CAP\_SETPCAP}. 

   \end{errlist}
   \end{errlist}

-  ed inoltre \errval{EBADF} per \func{acl\_get\_fd}, ed \errval{EINVAL} per
-  valori scorretti di \param{type} e tutti i possibili errori per l'accesso ad
-  un file per \func{acl\_get\_file}.
-
+  ed inoltre \errval{EFAULT} ed \errval{EINVAL}.

 }
 }

+

 \end{functions}
 
 \end{functions}
 

-Le due funzioni ritornano, con un oggetto di tipo \type{acl\_t}, il valore
-della ACL correntemente associata ad un file, che può essere identificato
-tramite un file descriptor usando \func{acl\_get\_fd} o con un pathname usando
-\func{acl\_get\_file}. Nel caso di quest'ultima funzione, che può richiedere
-anche la ACL relativa ad una directory, il secondo argomento \param{type}
-consente di specificare se si vuole ottenere la ACL di default o quella di
-accesso. Questo argomento deve essere di tipo \type{acl\_type\_t} e può
-assumere solo i due valori riportati in tab.~\ref{tab:acl_type}.
+Queste due funzioni prendono come argomenti due tipi di dati dedicati,
+definiti come puntatori a due strutture specifiche di Linux, illustrate in
+fig.~\ref{fig:cap_kernel_struct}. Per poterle utilizzare occorre anche
+cancellare la macro \macro{\_POSIX\_SOURCE}.\footnote{per farlo occorre
+  utilizzare la direttiva di preprocessore \direct{undef}; si dovrà cioè
+  inserire una istruzione \texttt{\#undef \_POSIX\_SOURCE} prima di includere
+  \texttt{sys/capability.h}.} Si tenga presente che le strutture di
+fig.~\ref{fig:cap_kernel_struct}, come i prototipi delle due funzioni
+\func{capget} e \func{capset}, sono soggette ad essere modificate con il
+cambiamento del kernel (in particolare i tipi di dati delle strutture) ed
+anche se finora l'interfaccia è risultata stabile, non c'è nessuna
+assicurazione che questa venga mantenuta.\footnote{anzi, visto lo scarso
+  utilizzo di questa funzionalità ci sono state varie discussioni fra gli
+  sviluppatori del kernel relative all'eliminarla o al modificarla
+  radicalmente.} Pertanto se si vogliono scrivere programmi portabili che
+possano essere eseguiti su qualunque versione del kernel è opportuno
+utilizzare le interfacce di alto livello.

 
 

-\begin{table}[htb]
-  \centering
+\begin{figure}[!htb]

   \footnotesize
   \footnotesize

-  \begin{tabular}{|l|l|}
-    \hline
-    \textbf{Tipo} & \textbf{Descrizione} \\
-    \hline
-    \hline
-    \const{ACL\_TYPE\_ACCESS} & indica una ACL di accesso.\\
-    \const{ACL\_TYPE\_DEFAULT}& indica una ACL di default.\\  
-    \hline
-  \end{tabular}
-  \caption{Le costanti che identificano il tipo di ACL.}
-  \label{tab:acl_type}
-\end{table}
+  \centering
+  \begin{minipage}[c]{15cm}
+    \includestruct{listati/cap_user_header_t.h}
+  \end{minipage} 
+  \normalsize 
+  \caption{Definizione delle strutture a cui fanno riferimento i puntatori
+    \structd{cap\_user\_header\_t} e \structd{cap\_user\_data\_t} usati per
+    l'interfaccia di gestione di basso livello delle \textit{capabilities}.}
+  \label{fig:cap_kernel_struct}
+\end{figure}

 
 

-Si tenga presente che nel caso di \func{acl\_get\_file} occorrerà che il
-processo chiamante abbia privilegi di accesso sufficienti a poter leggere gli
-attributi estesi dei file (come illustrati in sez.~\ref{sec:file_xattr});
-inoltre una ACL di tipo \const{ACL\_TYPE\_DEFAULT} potrà essere richiesta
-soltanto per una directory, e verrà restituita solo se presente, altrimenti
-verrà restituita una ACL vuota.
+La struttura a cui deve puntare l'argomento \param{hdrp} serve ad indicare,
+tramite il campo \var{pid}, il processo del quale si vogliono leggere o
+modificare le \textit{capabilities}. Il campo \var{version} deve essere
+impostato al valore della versione delle usata dal kernel (quello indicato
+dalla costante \const{\_LINUX\_CAPABILITY\_VERSION} di
+fig.~\ref{fig:cap_kernel_struct}) altrimenti le funzioni ritorneranno con un
+errore di \errcode{EINVAL}, restituendo nel campo stesso il valore corretto
+della versione in uso.  La struttura a cui deve puntare l'argomento
+\param{datap} invece conterrà i valori letti o da impostare per i tre insiemi
+delle capacità del processo.

 
 

-Infine si potrà creare una ACL direttamente dalla sua rappresentazione
-testuale con la funzione  \funcd{acl\_from\_text}, il cui prototipo è:
+Dato che le precedenti funzioni, oltre ad essere specifiche di Linux, non
+garantiscono la stabilità nell'interfaccia, è sempre opportuno effettuare la
+gestione delle \textit{capabilities} utilizzando le funzioni di libreria a
+questo dedicate. Queste funzioni, che seguono quanto previsto nelle bozze
+dello standard POSIX.1e, non fanno parte delle \acr{glibc} e sono fornite in
+una libreria a parte,\footnote{la libreria è \texttt{libcap2}, nel caso di
+  Debian può essere installata con il pacchetto omonimo.} pertanto se un
+programma le utilizza si dovrà indicare esplicitamente l'uso della suddetta
+libreria attraverso l'opzione \texttt{-lcap} del compilatore.
+
+Le funzioni dell'interfaccia delle bozze di POSIX.1e prevedono l'uso di uno
+tipo di dato opaco, \type{cap\_t}, come puntatore ai dati mantenuti nel
+cosiddetto \textit{capability state},\footnote{si tratta in sostanza di un
+  puntatore ad una struttura interna utilizzata dalle librerie, i cui campi
+  non devono mai essere acceduti direttamente.} in sono memorizzati tutti i
+dati delle \textit{capabilities}. In questo modo è possibile mascherare i
+dettagli della gestione di basso livello, che potranno essere modificati senza
+dover cambiare le funzioni dell'interfaccia, che faranno riferimento soltanto
+ad oggetti di questo tipo.  L'interfaccia pertanto non soltanto fornisce le
+funzioni per modificare e leggere le \textit{capabilities}, ma anche quelle
+per gestire i dati attraverso \type{cap\_t}.
+
+La prima funzione dell'interfaccia è quella che permette di inizializzare un
+\textit{capability state}, allocando al contempo la memoria necessaria per i
+relativi dati. La funzione è \funcd{cap\_init} ed il suo prototipo è:

 \begin{functions}
 \begin{functions}

-  \headdecl{sys/types.h} 
-  \headdecl{sys/acl.h}
-  
-  \funcdecl{acl\_t acl\_from\_text(const char *buf\_p)}
+  \headdecl{sys/capability.h}

 
 

-  Crea una ACL a partire dalla sua rappresentazione testuale.
+  \funcdecl{cap\_t cap\_init(void)} 
+  Crea ed inizializza un \textit{capability state}.

   
   

-  \bodydesc{La funzione restituisce un oggetto di tipo \type{acl\_t} in caso
-    di successo e \code{(acl\_t)NULL} in caso di errore, nel qual caso
-    \var{errno} assumerà uno dei valori:
-  \begin{errlist}
-  \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
-  \item[\errcode{EINVAL}] la rappresentazione testuale all'indirizzo
-    \param{buf\_p} non è valida.
-  \end{errlist}
-
-}
+  \bodydesc{La funzione ritorna un valore non nullo in caso di successo e
+    \macro{NULL} in caso di errore, nel qual caso \var{errno} assumerà il
+    valore \errval{ENOMEM}.
+  }

 \end{functions}
 
 \end{functions}
 

-La funzione prende come argomento il puntatore ad un buffer dove si è inserita
-la rappresentazione testuale della ACL che si vuole creare, la memoria
-necessaria viene automaticamente allocata ed in caso di successo viene
-restituito come valore di ritorno un oggetto di tipo \type{acl\_t} con il
-contenuto della stessa, che come per le precedenti funzioni, dovrà essere
-disallocato esplicitamente al termine del suo utilizzo.
-
-La rappresentazione testuale di una ACL è quella usata anche dai comandi
-ordinari per la gestione delle ACL (\texttt{getfacl} e \texttt{setfacl}), che
-prevede due diverse forme, estesa e breve, entrambe supportate da
-\func{acl\_from\_text}. La forma estesa prevede che sia specificata una voce
-per riga, nella forma:
-\begin{Verbatim}
-  tipo:qualificatore:permessi
-\end{Verbatim}
-dove il tipo può essere uno fra \texttt{user}, \texttt{group}, \texttt{other}
-e \texttt{mask}. Il qualificatore è presente solo per \texttt{user} e
-\texttt{group} e indica l'utente o il gruppo a cui la voce si riferisce; i
-permessi sono espressi con una tripletta di lettere analoga a quella usata per
-i permessi dei file.\footnote{vale a dire \texttt{r} per il permesso di
-  lettura, \texttt{w} per il permesso di scrittura, \texttt{x} per il permesso
-  di esecuzione (scritti in quest'ordine) e \texttt{-} per l'assenza del
-  permesso.}
+La funzione restituisce il puntatore \type{cap\_t} ad uno stato inizializzato
+con tutte le \textit{capabilities} azzerate. In caso di errore (cioè quando
+non c'è memoria sufficiente ad allocare i dati) viene restituito \macro{NULL}
+ed \var{errno} viene impostata a \errval{ENOMEM}.  La memoria necessaria a
+mantenere i dati viene automaticamente allocata da \func{cap\_init}, ma dovrà
+essere disallocata esplicitamente quando non è più necessaria utilizzando, per
+questo l'interfaccia fornisce una apposita funzione, \funcd{cap\_free}, il cui
+prototipo è:
+\begin{functions}
+  \headdecl{sys/capability.h}

 
 

-Va precisato che i due tipi \texttt{user} e \texttt{group} sono usati
-rispettivamente per indicare delle voci relative ad utenti e
-gruppi,\footnote{cioè per voci di tipo \const{ACL\_USER\_OBJ} e
-  \const{ACL\_USER} per \texttt{user} e \const{ACL\_GROUP\_OBJ} e
-  \const{ACL\_GROUP} per \texttt{group}.} applicate sia a quelli proprietari
-del file che a quelli generici; quelle dei proprietari si riconoscono per
-l'assenza di un qualificatore, ed in genere si scrivono per prima delle altre.
-Il significato delle voci di tipo \texttt{mask} e \texttt{mark} è evidente. In
-questa forma si possono anche inserire dei commenti precedendoli con il
-carattere ``\texttt{\#}''.
+  \funcdecl{int cap\_free(void *obj\_d)} 
+  Disalloca la memoria allocata per i dati delle \textit{capabilities}.
+  
+  \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
+    errore, nel qual caso \var{errno} assumerà il valore \errval{EINVAL}.
+  }
+\end{functions}

 
 

-La forma breve prevede invece la scrittura delle singole voci su una riga,
-separate da virgole; come specificatori del tipo di voce si possono usare le
-iniziali dei valori usati nella forma estesa (cioè ``\texttt{u}'',
-``\texttt{g}'', ``\texttt{o}'' e ``\texttt{m}''), mentre le altri parte della
-voce sono le stesse. In questo caso non sono consentiti permessi.
+La funzione permette di liberare la memoria allocata dalle altre funzioni
+della libreria sia per un \textit{capability state}, nel qual caso l'argomento
+dovrà essere un dato di tipo \type{cap\_t}, che per una descrizione testuale
+dello stesso,\footnote{cioè quanto ottenuto tramite la funzione
+  \func{cap\_to\_text}.} nel qual caso l'argomento dovrà essere un dato di
+tipo \texttt{char *}. Per questo l'argomento \param{obj\_d} è dichiarato come
+\texttt{void *} e deve sempre corrispondere ad un puntatore ottenuto tramite
+le altre funzioni della libreria, altrimenti la funzione fallirà con un errore
+di \errval{EINVAL}.

 
 

-Per la conversione inversa, che consente di ottenere la rappresentazione
-testuale di una ACL, sono invece disponibili due funzioni, la prima delle due,
-di uso più immediato, è \funcd{acl\_to\_text}, il cui prototipo è:
+Infine si può creare una copia di un \textit{capability state} ottenuto in
+precedenza tramite la funzione \funcd{cap\_dup}, il cui prototipo è:

 \begin{functions}
 \begin{functions}

-  \headdecl{sys/types.h} 
-  \headdecl{sys/acl.h}
-  
-  \funcdecl{char * acl\_to\_text(acl\_t acl, ssize\_t *len\_p)}
+  \headdecl{sys/capability.h}

 
 

-  Produce la rappresentazione testuale di una ACL.
+  \funcdecl{cap\_t cap\_dup(cap\_t cap\_p)} 
+  Duplica un \textit{capability state} restituendone una copia.

   
   

-  \bodydesc{La funzione restituisce il puntatore ad una stringa con la
-    rappresentazione testuale della ACL in caso di successo e
-    \code(acl\_t){NULL} in caso di errore, nel qual caso \var{errno} assumerà
-    uno dei valori:
-  \begin{errlist}
-  \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
-  \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida.
-  \end{errlist}
-
-}
+  \bodydesc{La funzione ritorna un valore non nullo in caso di successo e
+    \macro{NULL} in caso di errore, nel qual caso \var{errno} potrà assumere i
+    valori \errval{ENOMEM} o \errval{EINVAL}.  
+  }

 \end{functions}
 
 \end{functions}
 

-La funzione restituisce il puntatore ad una stringa terminata da NUL
-contenente la rappresentazione in forma estesa della ACL passata come
-argomento, ed alloca automaticamente la memoria necessaria. Questa dovrà poi
-essere liberata, quando non più necessaria, con \func{acl\_free}. Se
-nell'argomento \param{len\_p} si passa un valore puntatore ad una variabile
-intera in questa verrà restituita la dimensione della stringa con la
-rappresentazione testuale (non comprendente il carattere nullo finale). 
+La funzione crea una copia del \textit{capability state} posto all'indirizzo
+\param{cap\_p} che si è passato come argomento, restituendo il puntatore alla
+copia, che conterrà gli stessi valori delle \textit{capabilities} presenti
+nell'originale. La memoria necessaria viene allocata automaticamente dalla
+funzione. Una volta effettuata la copia i due \textit{capability state}
+potranno essere modificati in maniera completamente
+indipendente.\footnote{alla fine delle operazioni si ricordi però di
+  disallocare anche la copia, oltre all'originale. }

 
 

-La seconda funzione, \funcd{acl\_to\_any\_text}, permette di controllare con
-dovizia di dettagli la generazione della stringa contenente la
-rappresentazione testuale della ACL, il suo prototipo è:
+Una seconda classe di funzioni di servizio previste dall'interfaccia sono
+quelle per la gestione dei dati contenuti all'interno di un \textit{capability
+  state}; la prima di queste è \funcd{cap\_clear}, il cui prototipo è:

 \begin{functions}
 \begin{functions}

-  \headdecl{sys/types.h} 
-  \headdecl{sys/acl.h}
+  \headdecl{sys/capability.h}
+
+  \funcdecl{int cap\_clear(cap\_t cap\_p)} 
+  Inizializza un \textit{capability state} cancellando tutte le
+  \textit{capabilities}.

   
   

-  \funcdecl{char * acl\_to\_any\_text(acl\_t acl, const char *prefix, char
-    separator, int options)}
+  \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
+    errore, nel qual caso \var{errno} assumerà il valore \errval{EINVAL}.
+  }
+\end{functions}

 
 

-  Produce la rappresentazione testuale di una ACL.
+La funzione si limita ad azzerare tutte le \textit{capabilities} presenti nel
+\textit{capability state} all'indirizzo \param{cap\_p} passato come argomento,
+restituendo uno stato \textsl{vuoto}, analogo a quello che si ottiene nella
+creazione con \func{cap\_init}.

 
 

-  \bodydesc{La funzione restituisce il puntatore ad una stringa con la
-    rappresentazione testuale della ACL in caso di successo e \code{NULL} in
-    caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
-  \begin{errlist}
-  \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
-  \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida.
-  \end{errlist}
+Per la gestione dei valori delle \textit{capabilities} presenti in un
+\textit{capability state} l'interfaccia prevede due funzioni,
+\funcd{cap\_get\_flag} e \funcd{cap\_set\_flag}, che permettono
+rispettivamente di leggere o impostare il valore di un flag delle
+\textit{capabilities}; i rispettivi prototipi sono:
+\begin{functions}
+  \headdecl{sys/capability.h}

 
 

+  \funcdecl{int cap\_get\_flag(cap\_t cap\_p, cap\_value\_t cap, cap\_flag\_t
+    flag, cap\_flag\_value\_t *value\_p)}
+  Legge il valore di una \textit{capability}.
+
+  \funcdecl{int cap\_set\_flag(cap\_t cap\_p, cap\_flag\_t flag, int ncap,
+    cap\_value\_t *caps, cap\_flag\_value\_t value)} 
+  Imposta il valore di una \textit{capability}.
+  
+  \bodydesc{Le funzioni ritornano 0 in caso di successo e $-1$ in caso di
+    errore, nel qual caso \var{errno} assumerà il valore \errval{EINVAL}.

 }
 \end{functions}
 
 }
 \end{functions}
 

-La funzione converte in formato testo la ACL indicata dall'argomento
-\param{acl}, usando il carattere \param{separator} come separatore delle
-singole voci; se l'argomento \param{prefix} non è nullo la stringa da esso
-indicata viene utilizzata come prefisso per le singole voci. 
-
-L'ultimo argomento, \param{options}, consente di controllare la modalità con
-cui viene generata la rappresentazione testuale. Un valore nullo fa si che
-vengano usati gli identificatori standard \texttt{user}, \texttt{group},
-\texttt{other} e \texttt{mask} con i nomi di utenti e gruppi risolti rispetto
-ai loro valori numerici. Altrimenti si può specificare un valore in forma di
-maschera binaria, da ottenere con un OR aritmetico dei valori riportati in
-tab.~\ref{tab:acl_to_text_options}.
+In entrambe le funzioni l'argomento \param{cap\_p} indica il puntatore al
+\textit{capability state} su cui operare, mentre l'argomento \param{flag}
+indica su quale dei tre insiemi illustrati a
+pag.~\pageref{sec:capabilities_set} si intende operare. Questi devono essere
+specificati con una variabile di tipo \type{cap\_flag\_t} che può assumere
+esclusivamente\footnote{si tratta in effetti di un tipo enumerato, come si può
+  verificare dalla sua definizione che si trova in
+  \texttt{/usr/include/sys/capability.h}.} uno dei valori illustrati in
+tab.~\ref{tab:cap_set_identifier}.

 
 \begin{table}[htb]
   \centering
   \footnotesize
 
 \begin{table}[htb]
   \centering
   \footnotesize

-  \begin{tabular}{|l|p{8cm}|}
+  \begin{tabular}[c]{|l|l|}

     \hline
     \hline

-    \textbf{Tipo} & \textbf{Descrizione} \\
+    \textbf{Valore} & \textbf{Significato} \\

     \hline
     \hline
     \hline
     \hline

-    \const{TEXT\_ABBREVIATE}     & stampa le voci in forma abbreviata.\\
-    \const{TEXT\_NUMERIC\_IDS}   & non effettua la risoluzione numerica di
-                                   user-ID e group-ID.\\
-    \const{TEXT\_SOME\_EFFECTIVE}& per ciascuna voce che contiene permessi che
-                                   vengono eliminati dalla \const{ACL\_MASK}
-                                   viene generato un commento con i permessi 
-                                   effettivamente risultanti; il commento è
-                                   separato con un tabulatore.\\
-    \const{TEXT\_ALL\_EFFECTIVE} & viene generato un commento con i permessi
-                                   effettivi per ciascuna voce che contiene
-                                   permessi citati nella \const{ACL\_MASK},
-                                   anche quando questi non vengono modificati
-                                   da essa; il commento è separato con un
-                                   tabulatore.\\
-    \const{TEXT\_SMART\_INDENT}  & da usare in combinazione con le precedenti
-                                   \const{TEXT\_SOME\_EFFECTIVE} e
-                                   \const{TEXT\_ALL\_EFFECTIVE} aumenta
-                                   automaticamente il numero di spaziatori
-                                   prima degli eventuali commenti in modo da
-                                   mantenerli allineati.\\
+    \const{CAP\_EFFECTIVE}  & Capacità dell'insieme \textsl{effettivo}.\\
+    \const{CAP\_PERMITTED}  & Capacità dell'insieme \textsl{permesso}.\\ 
+    \const{CAP\_INHERITABLE}& Capacità dell'insieme \textsl{ereditabile}.\\

     \hline
   \end{tabular}
     \hline
   \end{tabular}

-  \caption{Possibili valori per l'argomento \param{options} di
-    \func{acl\_to\_any\_text}.} 
-  \label{tab:acl_to_text_options}
+  \caption{Valori possibili per il tipo di dato \type{cap\_flag\_t} che
+    identifica gli insiemi delle \textit{capabilities}.}
+  \label{tab:cap_set_identifier}

 \end{table}
 
 \end{table}
 

-Come per \func{acl\_to\_text} anche in questo caso il buffer contenente la
-rappresentazione testuale dell'ACL, di cui la funzione restituisce
-l'indirizzo, viene allocato automaticamente, e dovrà essere esplicitamente
-disallocato con una chiamata ad \func{acl\_free}. Si tenga presente infine che
-questa funzione è una estensione specifica di Linux, e non è presente nella
-bozza dello standard POSIX.1e.
-
-Per quanto utile per la visualizzazione o l'impostazione da comando delle ACL,
-la forma testuale non è la più efficiente per poter memorizzare i dati
-relativi ad una ACL, ad esempio quando si vuole eseguirne una copia a scopo di
-archiviazione. Per questo è stata prevista la possibilità di utilizzare una
-rappresentazione delle ACL in una apposita forma binaria contigua e
-persistente. È così possibile copiare il valore di una ACL in un buffer e da
-questa rappresentazione tornare indietro e generare una ACL. 
-
-Lo standard POSIX.1e prevede a tale scopo tre funzioni, la prima e più
-semplice è \funcd{acl\_size}, che consente di ottenere la dimensione che avrà
-la citata rappresentazione binaria, in modo da poter allocare per essa un
-buffer di dimensione sufficiente, il suo prototipo è:
-\begin{functions}
-  \headdecl{sys/types.h} 
-  \headdecl{sys/acl.h}
-  
-  \funcdecl{ssize\_t acl\_size(acl\_t acl)}
-
-  Determina la dimensione della rappresentazione binaria di una ACL.
-
-  \bodydesc{La funzione restituisce in caso di successo la dimensione in byte
-    della rappresentazione binaria della ACL indicata da \param{acl} e $-1$ in
-    caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
-  \begin{errlist}
-  \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida.
-  \end{errlist}
-
-}
-\end{functions}
-
-Prima di effettuare la lettura della rappresentazione binaria è sempre
-necessario allocare un buffer di dimensione sufficiente a contenerla, pertanto
-prima si dovrà far ricorso a \funcd{acl\_size} per ottenere tale dimensione e
-poi allocare il buffer con una delle funzioni di
-sez.~\ref{sec:proc_mem_alloc}. Una volta terminato l'uso della
-rappresentazione binaria, il buffer dovrà essere esplicitamente disallocato.
-
-La funzione che consente di leggere la rappresentazione binaria di una ACL è
-\funcd{acl\_copy\_ext}, il cui prototipo è:
-\begin{functions}
-  \headdecl{sys/types.h} 
-  \headdecl{sys/acl.h}
-  
-  \funcdecl{ssize\_t acl\_copy\_ext(void *buf\_p, acl\_t acl, ssize\_t size)}
+La capacità che si intende controllare o impostare invece deve essere
+specificata attraverso una variabile di tipo \type{cap\_value\_t}, che può
+prendere come valore uno qualunque di quelli riportati in
+tab.~\ref{tab:proc_capabilities}, in questo caso però non è possibile
+combinare diversi valori in una maschera binaria, una variabile di tipo
+\type{cap\_value\_t} deve indicare una sola capacità.\footnote{nel file di
+  header citato nella nota precedente il tipo \type{cap\_value\_t} è definito
+  come \ctyp{int}, ma i valori validi sono soltanto quelli di
+  tab.~\ref{tab:proc_capabilities}.}  

 
 

-  Ottiene la rappresentazione binaria di una ACL.
+Infine lo stato di una capacità è descritto ad una variabile di tipo
+\type{cap\_flag\_value\_t}, che a sua volta può assumere soltanto
+uno\footnote{anche questo è un tipo enumerato.} dei valori di
+tab.~\ref{tab:cap_value_type}.

 
 

-  \bodydesc{La funzione restituisce in caso di successo la dimensione in byte
-    della rappresentazione binaria della ACL indicata da \param{acl} e $-1$ in
-    caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
-  \begin{errlist}
-  \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida o
-    \param{size} è negativo o nullo.
-  \item[\errcode{ERANGE}] il valore di \param{size} è più piccolo della
-    dimensione della rappresentazione della ACL.
-  \end{errlist}
+\begin{table}[htb]
+  \centering
+  \footnotesize
+  \begin{tabular}[c]{|l|l|}
+    \hline
+    \textbf{Valore} & \textbf{Significato} \\
+    \hline
+    \hline
+    \const{CAP\_CLEAR}& La capacità non è impostata.\\ 
+    \const{CAP\_SET}  & La capacità è impostata.\\
+    \hline
+  \end{tabular}
+  \caption{Valori possibili per il tipo di dato \type{cap\_flag\_value\_t} che
+    indica lo stato di una capacità.}
+  \label{tab:cap_value_type}
+\end{table}

 
 

-}
-\end{functions}
+La funzione \func{cap\_get\_flag} legge lo stato della capacità indicata
+dall'argomento \param{cap} all'interno dell'insieme indicato dall'argomento
+\param{flag} e ne restituisce il valore nella variabile posta all'indirizzo
+puntato dall'argomento \param{value\_p}; è possibile cioè leggere soltanto uno
+stato di una capacità alla volta.

 
 

-La funzione salverà la rappresentazione binaria della ACL indicata da
-\param{acl} sul buffer posto all'indirizzo \param{buf\_p} e lungo \param{size}
-byte, restituendo la dimensione della stessa come valore di ritorno. Qualora
-la dimensione della rappresentazione ecceda il valore di \param{size} la
-funzione fallirà con un errore di \errcode{ERANGE}. La funzione non ha nessun
-effetto sulla ACL indicata da \param{acl}.
+La funzione \func{cap\_set\_flag} può invece impostare in una sola chiamata
+più \textit{capabilities}, anche se solo all'interno dello stesso insieme. Per
+questo motivo essa prende un vettore di valori di tipo \type{cap\_value\_t}
+nell'argomento \param{caps}, la cui dimensione viene specificata dall'argomento
+\param{ncap}. Il tipo di impostazione da eseguire (cancellazione o
+impostazione) viene indicato dall'argomento \param{value}.

 
 

-Viceversa se si vuole ripristinare una ACL a partire dalla rappresentazione
-binaria della stessa disponibile in un buffer si potrà usare la funzione 
-\funcd{acl\_copy\_int}, il cui prototipo è:
+Per la visualizzazione dello stato delle \textit{capabilities} l'interfaccia
+prevede una funzione apposita, \funcd{cap\_to\_text}, il cui prototipo è:

 \begin{functions}
 \begin{functions}

-  \headdecl{sys/types.h} 
-  \headdecl{sys/acl.h}
-  
-  \funcdecl{ssize\_t acl\_copy\_int(const void *buf\_p)}
-
-  Ripristina la rappresentazione binaria di una ACL.
+  \headdecl{sys/capability.h}

 
 

-  \bodydesc{La funzione restituisce un oggetto di tipo \type{acl\_t} in caso
-    di successo e \code{(acl\_t)NULL} in caso di errore, nel qual caso
-    \var{errno} assumerà uno dei valori:
-  \begin{errlist}
-  \item[\errcode{EINVAL}] il buffer all'indirizzo \param{buf\_p} non contiene
-    una rappresentazione corretta di una ACL.
-  \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare un oggetto
-    \type{acl\_t} per la ACL richiesta.
-  \end{errlist}
+  \funcdecl{char * cap\_to\_text(cap\_t caps, ssize\_t * length\_p)}

 
 

-}
+  Genera una visualizzazione testuale delle \textit{capabilities}.
+  
+  \bodydesc{La funzione ritorna un puntatore alla stringa con la descrizione
+    delle \textit{capabilities} in caso di successo e \val{NULL} in caso di
+    errore, nel qual caso \var{errno} può assumere i valori \errval{EINVAL} o
+    \errval{ENOMEM}.
+  }

 \end{functions}
 
 \end{functions}
 

-La funzione in caso di successo alloca autonomamente un oggetto di tipo
-\type{acl\_t} che viene restituito come valore di ritorno con il contenuto
-della ACL rappresentata dai dati contenuti nel buffer puntato da
-\param{buf\_p}. Si ricordi che come per le precedenti funzioni l'oggetto
-\type{acl\_t} dovrà essere disallocato esplicitamente al termine del suo
-utilizzo.
+La funzione ritorna l'indirizzo di una stringa contente la descrizione
+testuale del contenuto del \textit{capabilities state} \param{caps} passato
+come argomento, e, qualora l'argomento \param{length\_p} sia diverso da
+\val{NULL}, restituisce nella variabile intera da questo puntata la lunghezza
+della stringa. La stringa restituita viene allocata automaticamente dalla
+funzione e pertanto dovrà essere liberata con \func{cap\_free}.

 
 

-Una volta che si disponga della ACL desiderata, questa potrà essere impostata
-su un file o una directory. Per impostare una ACL sono disponibili due
-funzioni; la prima è \funcd{acl\_set\_file}, che opera sia su file che su
-directory, ed il cui prototipo è:
+Fin quei abbiamo trattato solo le funzioni di servizio relative alla
+manipolazione dei \textit{capabilities state}; l'interfaccia di gestione
+prevede però anche le funzioni per la gestione delle \textit{capabilities}
+stesse. La prima di queste è \funcd{cap\_get\_proc} che consente la lettura
+delle \textit{capabilities} del processo corrente, il suo prototipo è:

 \begin{functions}
 \begin{functions}

-  \headdecl{sys/types.h} 
-  \headdecl{sys/acl.h}
-  
-  \funcdecl{int acl\_set\_file(const char *path, acl\_type\_t type, acl\_t
-    acl)}
-
-  Imposta una ACL su un file o una directory.
+  \headdecl{sys/capability.h}

 
 

-  \bodydesc{La funzione restituisce $0$ in caso di successo e $-1$ in caso di
-    errore, nel qual caso \var{errno} assumerà uno dei valori:
-  \begin{errlist}
-  \item[\errcode{EACCES}] o un generico errore di accesso a \param{path} o il
-    valore di \param{type} specifica una ACL il cui tipo non può essere
-    assegnato a \param{path}.
-  \item[\errcode{EINVAL}] o \param{acl} non è una ACL valida, o \param{type}
-    ha in valore non corretto.
-  \item[\errcode{ENOSPC}] non c'è spazio disco sufficiente per contenere i
-    dati aggiuntivi della ACL.
-  \item[\errcode{ENOTSUP}] si è cercato di impostare una ACL su un file
-    contenuto in un filesystem che non supporta le ACL.
-  \end{errlist}
-  ed inoltre \errval{ENOENT}, \errval{ENOTDIR}, \errval{ENAMETOOLONG},
-  \errval{EROFS}, \errval{EPERM}.
-}
+  \funcdecl{cap\_t cap\_get\_proc(void)}
+  Legge le \textit{capabilities} del processo corrente.
+  
+  \bodydesc{La funzione ritorna un valore diverso da \val{NULL} in caso di
+    successo e \val{NULL} in caso di errore, nel qual caso \var{errno} può
+    assumere i valori \errval{EINVAL}, \errval{EPERM} o \errval{ENOMEM}.  }

 \end{functions}
 
 \end{functions}
 

-La funzione consente di assegnare la ACL contenuta in \param{acl} al file o
-alla directory indicate dal pathname \param{path}, mentre con \param{type} si
-indica il tipo di ACL utilizzando le costanti di tab.~\ref{tab:acl_type}, ma
-si tenga presente che le ACL di default possono essere solo impostate
-qualora \param{path} indichi una directory. Inoltre perché la funzione abbia
-successo la ACL dovrà essere valida, e contenere tutti le voci necessarie,
-unica eccezione è quella in cui si specifica una ACL vuota per cancellare la
-ACL di default associata a \func{path}.\footnote{questo però è una estensione
-  della implementazione delle ACL di Linux, la bozza di standard POSIX.1e
-  prevedeva l'uso della apposita funzione \funcd{acl\_delete\_def\_file}, che
-  prende come unico argomento il pathname della directory di cui si vuole
-  cancellare l'ACL di default, per i dettagli si ricorra alla pagina di
-  manuale.}  La seconda funzione che consente di impostare una ACL è
-\funcd{acl\_set\_fd}, ed il suo prototipo è:
+La funzione legge il valore delle \textit{capabilities} associate al processo
+da cui viene invocata, restituendo il risultato tramite il puntatore ad un
+\textit{capabilities state} contenente tutti i dati che provvede ad allocare
+autonomamente e che di nuovo occorrerà liberare con \func{cap\_free} quando
+non sarà più utilizzato.
+
+Se invece si vogliono leggere le \textit{capabilities} di un processo
+specifico occorre usare la funzione \funcd{capgetp}, il cui
+prototipo\footnote{su alcune pagine di manuale la funzione è descritta con un
+  prototipo sbagliato, che prevede un valore di ritorno di tipo \type{cap\_t},
+  ma il valore di ritorno è intero, come si può verificare anche dalla
+  dichiarazione della stessa in \texttt{sys/capability.h}.} è:

 \begin{functions}
 \begin{functions}

-  \headdecl{sys/types.h} 
-  \headdecl{sys/acl.h}
+  \headdecl{sys/capability.h}
+
+  \funcdecl{int capgetp(pid\_t pid, cap\_t cap\_d)}
+  Legge le \textit{capabilities} del processo indicato da \param{pid}.

   
   

-  \funcdecl{int acl\_set\_fd(int fd, acl\_t acl)}
+  \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
+    errore, nel qual caso \var{errno} può assumere i valori \errval{EINVAL},
+    \errval{EPERM} o \errval{ENOMEM}.  
+  }
+\end{functions}
+%TODO controllare e correggere i codici di errore!!!

 
 

-  Imposta una ACL su un file descriptor.
+La funzione legge il valore delle \textit{capabilities} del processo indicato
+con l'argomento \param{pid}, e restituisce il risultato nel
+\textit{capabilities state} posto all'indirizzo indicato con l'argomento
+\param{cap\_d}; a differenza della precedente in questo caso il
+\textit{capability state} deve essere stato creato in precedenza. Qualora il
+processo indicato non esista si avrà un errore di \errval{ESRCH}. Gli stessi
+valori possono essere letti direttamente nel filesystem \textit{proc}, nei
+file \texttt{/proc/<pid>/status}; ad esempio per \texttt{init} si otterrà
+qualcosa del tipo:
+\begin{Verbatim}
+...
+CapInh: 0000000000000000
+CapPrm: 00000000fffffeff
+CapEff: 00000000fffffeff  
+...
+\end{Verbatim}

 
 

-  \bodydesc{La funzione restituisce $0$ in caso di successo e $-1$ in caso di
-    errore, nel qual caso \var{errno} assumerà uno dei valori:
-  \begin{errlist}
-  \item[\errcode{EBADF}].
-  \item[\errcode{EINVAL}] o \param{acl} non è una ACL valida, o \param{type}
-    ha in valore non corretto.
-  \item[\errcode{ENOSPC}] non c'è spazio disco sufficiente per contenere i
-    dati aggiuntivi della ACL.
-  \item[\errcode{ENOTSUP}] si è cercato di impostare una ACL su un file
-    contenuto in un filesystem che non supporta le ACL.
-  \end{errlist}
-  ed inoltre \errval{EBADF}, \errval{EROFS}, \errval{EPERM}.
-}
+Infine per impostare le \textit{capabilities} del processo corrente (non
+esiste una funzione che permetta di cambiare le \textit{capabilities} di un
+altro processo) si deve usare la funzione \funcd{cap\_set\_proc}, il cui
+prototipo è:
+\begin{functions}
+  \headdecl{sys/capability.h}
+
+  \funcdecl{int cap\_set\_proc(cap\_t cap\_p)}
+  Imposta le \textit{capabilities} del processo corrente.
+  
+  \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
+    errore, nel qual caso \var{errno} può assumere i valori \errval{EINVAL},
+    \errval{EPERM} o \errval{ENOMEM}.  
+  }

 \end{functions}
 
 \end{functions}
 

-La funzione è del tutto è analoga a \funcd{acl\_set\_file} ma opera
-esclusivamente sui file identificati tramite un file descriptor. Non dovendo
-avere a che fare con directory (e con la conseguente possibilità di avere una
-ACL di default) la funzione non necessita che si specifichi il tipo di ACL,
-che sarà sempre di accesso, e prende come unico argomento, a parte il file
-descriptor, la ACL da impostare.
+La funzione modifica le \textit{capabilities} del processo corrente secondo
+quanto specificato con l'argomento \param{cap\_p}, posto che questo sia
+possibile nei termini spiegati in precedenza (non sarà ad esempio possibile
+impostare capacità non presenti nell'insieme di quelle permesse). In caso di
+successo i nuovi valori saranno effettivi al ritorno della funzione, in caso
+di fallimento invece lo stato delle capacità resterà invariato. Si tenga
+presente che \textsl{tutte} le capacità specificate tramite \param{cap\_p}
+devono essere permesse; se anche una sola non lo è la funzione fallirà, e per
+quanto appena detto, lo stato delle \textit{capabilities} non verrà modificato
+(neanche per le parti eventualmente permesse).

 
 

-Le funzioni viste finora operano a livello di una intera ACL, eseguendo in una
-sola volta tutte le operazioni relative a tutte le voci in essa contenuta. In
-generale è possibile modificare un singolo valore all'interno di una singola
-voce direttamente con le funzioni previste dallo standard POSIX.1e.  Queste
-funzioni però sono alquanto macchinose da utilizzare per cui è molto più
-semplice operare direttamente sulla rappresentazione testuale. Questo è il
-motivo per non tratteremo nei dettagli dette funzioni, fornendone solo una
-descrizione sommaria; chi fosse interessato potrà ricorrere alle pagina di
-manuale.
+Come esempio di utilizzo di queste funzioni nei sorgenti allegati alla guida
+si è distribuito il programma \texttt{getcap.c}, che consente di leggere le
+\textit{capabilities} del processo corrente\footnote{vale a dire di sé stesso,
+  quando lo si lancia, il che può sembrare inutile, ma serve a mostrarci quali
+  sono le \textit{capabilities} standard che ottiene un processo lanciato
+  dalla riga di comando.} o tramite l'opzione \texttt{-p}, quelle di un
+processo qualunque il cui pid viene passato come parametro dell'opzione.

 
 

-Se si vuole operare direttamente sui contenuti di un oggetto di tipo
-\type{acl\_t} infatti occorre fare riferimento alle singole voci tramite gli
-opportuni puntatori di tipo \type{acl\_entry\_t}, che possono essere ottenuti
-dalla funzione \funcd{acl\_get\_entry} (per una voce esistente) o dalla
-funzione \funcd{acl\_create\_entry} per una voce da aggiungere. Nel caso della
-prima funzione si potrà poi ripetere la lettura per ottenere i puntatori alle
-singole voci successive alla prima.
+\begin{figure}[htb]
+  \footnotesize \centering
+  \begin{minipage}[c]{15cm}
+    \includecodesample{listati/getcap.c}
+  \end{minipage} 
+  \normalsize
+  \caption{Corpo principale del programma \texttt{getcap.c}.}
+  \label{fig:proc_getcap}
+\end{figure}

 
 

-Una volta ottenuti detti puntatori si potrà operare sui contenuti delle singole
-voci; con le funzioni \funcd{acl\_get\_tag\_type}, \funcd{acl\_get\_qualifier},
-\funcd{acl\_get\_permset} si potranno leggere rispettivamente tipo,
-qualificatore e permessi mentre con le corrispondente funzioni
-\funcd{acl\_set\_tag\_type}, \funcd{acl\_set\_qualifier},
-\funcd{acl\_set\_permset} si possono impostare i valori; in entrambi i casi
-vengono utilizzati tipi di dato ad hoc.\footnote{descritti nelle singole
-  pagine di manuale.} Si possono poi copiare i valori di una voce da una ACL
-ad un altra con \funcd{acl\_copy\_entry} o eliminare una voce da una ACL con
-\funcd{acl\_delete\_entry}.
+La sezione principale del programma è riportata in fig.~\ref{fig:proc_getcap},
+e si basa su una condizione sulla variabile \var{pid} che se si è usato
+l'opzione \texttt{-p} è impostata (nella sezione di gestione delle opzioni,
+che si è tralasciata) al valore del \textsl{pid} del processo di cui si vuole
+leggere le \textit{capabilities} e nulla altrimenti. Nel primo caso
+(\texttt{\small 1--6}) si utilizza direttamente (\texttt{\small 2})
+\func{cap\_get\_proc} per ottenere lo stato delle capacità del processo, nel
+secondo (\texttt{\small 7--14}) prima si inizializza (\texttt{\small 8}) uno
+stato vuoto e poi (\texttt{\small 9}) si legge il valore delle capacità del
+processo indicato.

 
 

-\itindend{Access~Control~List}
+Il passo successivo è utilizzare (\texttt{\small 16}) \func{cap\_to\_text} per
+tradurre in una stringa lo stato, e poi (\texttt{\small 17}) stamparlo; infine
+(\texttt{\small 19--20}) si libera la memoria allocata dalle precedenti
+funzioni con \func{cap\_free} per poi ritornare dal ciclo principale della
+funzione.
+
+\itindend{capabilities}

 
 

+% TODO vedi http://lwn.net/Articles/198557/ e 
+% http://www.madore.org/~david/linux/newcaps/
+% TODO documentare prctl ...

 
 
 \subsection{La funzione \func{chroot}}
 
 
 \subsection{La funzione \func{chroot}}