+Un esempio tipico per l'uso di questa funzione è quello di un processo che sta
+eseguendo un programma coi privilegi di un altro utente (ad esempio attraverso
+l'uso del \textit{suid bit}) che vuole controllare se l'utente originale ha i
+permessi per accedere ad un certo file, ma eseguire questo controllo prima di
+aprire il file espone al rischio di una \textit{race condition} che apre ad un
+possibile \textit{symlink attack} fra il controllo e l'apertura del file. In
+questo caso è sempre opportuno usare invece la funzione \func{faccessat} che
+tratteremo insieme alle altre \textit{at-functions} in
+sez.~\ref{sec:file_openat}.
+
+Del tutto analoghe a \func{access} sono le due funzioni \funcm{euidaccess} e
+\funcm{eaccess} che ripetono lo stesso controllo usando però gli
+identificatori del gruppo effettivo, verificando quindi le effettive capacità
+di accesso ad un file. Le funzioni hanno entrambe lo stesso
+prototipo\footnote{in realtà \funcm{eaccess} è solo un sinonimo di
+ \funcm{euidaccess} fornita per compatibilità con l'uso di questo nome in
+ altri sistemi.} che è del tutto identico a quello di \func{access}. Prendono
+anche gli stessi valori e restituiscono gli stessi risultati e gli stessi
+codici di errore.
+
+Per cambiare i permessi di un file il sistema mette ad disposizione due
+funzioni \funcd{chmod} e \funcd{fchmod}, che operano rispettivamente su un
+filename e su un file descriptor, i loro prototipi sono:
+
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{sys/stat.h}
+\fdecl{int chmod(const char *path, mode\_t mode)}
+\fdesc{Cambia i permessi del file indicato da \param{path} al valore indicato
+ da \param{mode}.}
+\fdecl{int fchmod(int fd, mode\_t mode)}
+\fdesc{Analoga alla precedente, ma usa il file descriptor \param{fd} per
+ indicare il file.}
+
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EPERM}] l'\ids{UID} effettivo non corrisponde a quello del
+ proprietario del file o non si hanno i privilegi di amministratore.
+ \item[\errcode{EROFS}] il file è su un filesystem in sola lettura.
+ \end{errlist}
+ ed inoltre per entrambe \errval{EIO}, per \func{chmod} \errval{EACCES},
+ \errval{EFAULT}, \errval{ELOOP}, \errval{ENAMETOOLONG}, \errval{ENOENT},
+ \errval{ENOMEM}, \errval{ENOTDIR}, per \func{fchmod} \errval{EBADF} nel loro
+ significato generico.}
+\end{funcproto}
+
+
+Entrambe le funzioni utilizzano come secondo argomento \param{mode}, una
+variabile dell'apposito tipo primitivo \type{mode\_t} (vedi
+tab.~\ref{tab:intro_primitive_types}) utilizzato per specificare i permessi
+sui file.
+
+\begin{table}[!htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|c|c|l|}
+ \hline
+ \textbf{\param{mode}} & \textbf{Valore} & \textbf{Significato} \\
+ \hline
+ \hline
+ \const{S\_ISUID} & 04000 & Set user ID bit.\\
+ \const{S\_ISGID} & 02000 & Set group ID bit.\\
+ \const{S\_ISVTX} & 01000 & Sticky bit.\\
+ \hline
+ \const{S\_IRWXU} & 00700 & L'utente ha tutti i permessi.\\
+ \const{S\_IRUSR} & 00400 & L'utente ha il permesso di lettura.\\
+ \const{S\_IWUSR} & 00200 & L'utente ha il permesso di scrittura.\\
+ \const{S\_IXUSR} & 00100 & L'utente ha il permesso di esecuzione.\\
+ \hline
+ \const{S\_IRWXG} & 00070 & Il gruppo ha tutti i permessi.\\
+ \const{S\_IRGRP} & 00040 & Il gruppo ha il permesso di lettura.\\
+ \const{S\_IWGRP} & 00020 & Il gruppo ha il permesso di scrittura.\\
+ \const{S\_IXGRP} & 00010 & Il gruppo ha il permesso di esecuzione.\\
+ \hline
+ \const{S\_IRWXO} & 00007 & Gli altri hanno tutti i permessi.\\
+ \const{S\_IROTH} & 00004 & Gli altri hanno il permesso di lettura.\\
+ \const{S\_IWOTH} & 00002 & Gli altri hanno il permesso di scrittura.\\
+ \const{S\_IXOTH} & 00001 & Gli altri hanno il permesso di esecuzione.\\
+ \hline
+ \end{tabular}
+ \caption{Valori delle costanti usate per indicare i vari bit di
+ \param{mode} utilizzato per impostare i permessi dei file.}
+ \label{tab:file_permission_const}
+\end{table}
+
+Le costanti con cui specificare i singoli bit di \param{mode} sono riportate
+in tab.~\ref{tab:file_permission_const}, e corrispondono agli stessi valori
+usati per \var{st\_mode} in tab.~\ref{tab:file_mode_flags}. Il valore
+di \param{mode} può essere ottenuto combinando fra loro con un OR binario le
+costanti simboliche relative ai vari bit, o specificato direttamente, come per
+l'omonimo comando di shell, con un valore numerico (la shell lo vuole in
+ottale, dato che i bit dei permessi sono divisibili in gruppi di tre), che si
+può calcolare direttamente usando lo schema di utilizzo dei bit illustrato in
+fig.~\ref{fig:file_perm_bit}.
+
+Ad esempio i permessi standard assegnati ai nuovi file (lettura e scrittura
+per il proprietario, sola lettura per il gruppo e gli altri) sono
+corrispondenti al valore ottale $0644$, un programma invece avrebbe anche il
+bit di esecuzione attivo, con un valore di $0755$, se si volesse attivare il
+bit \acr{suid} il valore da fornire sarebbe $4755$.
+
+Il cambiamento dei permessi di un file eseguito attraverso queste funzioni ha
+comunque alcune limitazioni, previste per motivi di sicurezza. L'uso delle
+funzioni infatti è possibile solo se l'\ids{UID} effettivo del processo
+corrisponde a quello del proprietario del file o dell'amministratore,
+altrimenti esse falliranno con un errore di \errcode{EPERM}.
+
+Ma oltre a questa regola generale, di immediata comprensione, esistono delle
+limitazioni ulteriori. Per questo motivo, anche se si è proprietari del file,
+non tutti i valori possibili di \param{mode} sono permessi o hanno effetto;
+in particolare accade che:
+\begin{enumerate*}
+\item siccome solo l'amministratore può impostare lo \textit{sticky bit}, se
+ l'\ids{UID} effettivo del processo non è zero esso viene automaticamente
+ cancellato, senza notifica di errore, qualora sia stato indicato
+ in \param{mode}.
+\item per quanto detto in sez.~\ref{sec:file_ownership_management} riguardo la
+ creazione dei nuovi file, si può avere il caso in cui il file creato da un
+ processo è assegnato ad un gruppo per il quale il processo non ha privilegi.
+ Per evitare che si possa assegnare il bit \acr{sgid} ad un file appartenente
+ ad un gruppo per cui non si hanno diritti, questo viene automaticamente
+ cancellato da \param{mode}, senza notifica di errore, qualora il gruppo del
+ file non corrisponda a quelli associati al processo; la cosa non avviene
+ quando l'\ids{UID} effettivo del processo è zero.
+\end{enumerate*}
+
+Per alcuni filesystem\footnote{i filesystem più comuni (\textsl{ext2},
+ \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 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 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
+quando il file viene creato. Le funzioni dell'interfaccia nativa di Unix, come
+vedremo in sez.~\ref{sec:file_open_close}, permettono di indicare
+esplicitamente i permessi di creazione di un file, ma questo non è possibile
+per le funzioni dell'interfaccia standard ANSI C che non prevede l'esistenza
+di utenti e gruppi, ed inoltre il problema si pone anche per l'interfaccia
+nativa quando i permessi non vengono indicati esplicitamente.
+
+\itindbeg{umask}
+
+Per le funzioni dell'interfaccia standard ANSI C l'unico riferimento possibile
+è quello della modalità di apertura del nuovo file (lettura/scrittura o sola
+lettura), che però può fornire un valore che è lo stesso per tutti e tre i
+permessi di sez.~\ref{sec:file_perm_overview} (cioè $666$ nel primo caso e
+$222$ nel secondo). Per questo motivo il sistema associa ad ogni
+processo\footnote{è infatti contenuta nel campo \var{umask} della struttura
+ \kstruct{fs\_struct}, vedi fig.~\ref{fig:proc_task_struct}.} una maschera
+di bit, la cosiddetta \textit{umask}, che viene utilizzata per impedire che
+alcuni permessi possano essere assegnati ai nuovi file in sede di creazione. I
+bit indicati nella maschera vengono infatti cancellati dai permessi quando un
+nuovo file viene creato.\footnote{l'operazione viene fatta sempre: anche
+ qualora si indichi esplicitamente un valore dei permessi nelle funzioni di
+ creazione che lo consentono, i permessi contenuti nella \textit{umask}
+ verranno tolti.}
+
+La funzione di sistema che permette di impostare il valore di questa maschera
+di controllo è \funcd{umask}, ed il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{stat.h}
+\fdecl{mode\_t umask(mode\_t mask)}
+\fdesc{Imposta la maschera dei permessi.}
+}
+
+{La funzione ritorna ritorna il precedente valore della maschera, non sono
+ previste condizioni di errore.}
+\end{funcproto}
+
+La funzione imposta la maschera dei permessi dei bit al valore specificato
+da \param{mask}, di cui vengono presi solo i 9 bit meno significativi. In
+genere si usa questa maschera per impostare un valore predefinito che escluda
+preventivamente alcuni permessi, il caso più comune è eliminare il permesso di
+scrittura per il gruppo e gli altri, corrispondente ad un valore
+per \param{mask} pari a $022$. In questo modo è possibile cancellare
+automaticamente i permessi non voluti. Di norma questo valore viene impostato
+una volta per tutte al login (a $022$ se non indicato altrimenti), e gli
+utenti non hanno motivi per modificarlo.
+
+\itindend{umask}
+
+
+\subsection{La gestione della titolarità dei file}
+\label{sec:file_ownership_management}
+
+Vedremo in sez.~\ref{sec:file_open_close} con quali funzioni si possono creare
+nuovi file, in tale occasione vedremo che è possibile specificare in sede di
+creazione quali permessi applicare ad un file, però non si può indicare a
+quale utente e gruppo esso deve appartenere. Lo stesso problema si presenta
+per la creazione di nuove directory (procedimento descritto in
+sez.~\ref{sec:file_dir_creat_rem}).
+
+Lo standard POSIX prescrive che l'\ids{UID} del nuovo file corrisponda
+all'\ids{UID} effettivo del processo che lo crea; per il \ids{GID} invece
+prevede due diverse possibilità:
+\begin{itemize*}
+\item che il \ids{GID} del file corrisponda al \ids{GID} effettivo del
+ processo.
+\item che il \ids{GID} del file corrisponda al \ids{GID} della directory in
+ cui esso è creato.
+\end{itemize*}
+
+In genere BSD usa sempre la seconda possibilità, che viene per questo chiamata
+semantica BSD. Linux invece segue normalmente quella che viene chiamata
+semantica SVr4: di norma un nuovo file viene creato, seguendo la prima
+opzione, con il \ids{GID} del processo, se però la directory in cui viene
+creato ha il bit \acr{sgid} impostato allora viene usata la seconda
+opzione. L'adozione di questa semantica però può essere controllata,
+all'interno di alcuni filesystem,\footnote{con il kernel 2.6.25 questi erano
+ \acr{ext2}, \acr{ext3}, \acr{ext4}, e XFS.} con l'uso dell'opzione di
+montaggio \texttt{grpid}, che se attivata fa passare all'uso della semantica
+BSD.
+
+Usare la semantica BSD ha il vantaggio che il \ids{GID} viene sempre
+automaticamente propagato, restando coerente a quello della directory di
+partenza, in tutte le sotto-directory. La semantica SVr4 offre la possibilità
+di scegliere, ma per ottenere lo stesso risultato di coerenza che si ha con
+quella di BSD necessita che quando si creano nuove directory venga propagato
+il bit \acr{sgid}. Questo è il comportamento predefinito del comando
+\cmd{mkdir}, ed è in questo modo ad esempio che le varie distribuzioni
+assicurano che le sotto-directory create nella home di un utente restino
+sempre con il \ids{GID} del gruppo primario dello stesso.
+
+La presenza del bit \acr{sgid} è inoltre molto comoda quando si hanno
+directory contenenti file condivisi da un gruppo di utenti in cui possono
+scrivere tutti i membri dello stesso, dato che assicura che i file che gli
+utenti vi creano appartengano allo gruppo stesso. Questo non risolve però
+completamente i problemi di accesso da parte di altri utenti dello stesso
+gruppo, in quanto di default i permessi assegnati al gruppo non sono
+sufficienti per un accesso in scrittura; in questo caso si deve aver cura di
+usare prima della creazione dei file un valore per \textit{umask} lasci il
+permesso di scrittura.\footnote{in tal caso si può assegnare agli utenti del
+ gruppo una \textit{umask} di $002$, anche se la soluzione migliore in questo
+ caso è usare una ACL di default (vedi sez.~\ref{sec:file_ACL}).}
+
+Come avviene nel caso dei permessi esistono anche delle appropriate funzioni
+di sistema, \funcd{chown} \funcd{fchown} e \funcd{lchown}, che permettono di
+cambiare sia l'utente che il gruppo a cui un file appartiene; i rispettivi
+prototipi sono:
+
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{sys/stat.h}
+\fdecl{int chown(const char *path, uid\_t owner, gid\_t group)}
+\fdecl{int fchown(int fd, uid\_t owner, gid\_t group)}
+\fdecl{int lchown(const char *path, uid\_t owner, gid\_t group)}
+\fdesc{Cambiano proprietario e gruppo proprietario di un file.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EPERM}] l'\ids{UID} effettivo non corrisponde a quello del
+ proprietario del file o non è zero, o utente e gruppo non sono validi.
+ \end{errlist}
+ ed inoltre per tutte \errval{EROFS} e \errval{EIO}, per \func{chown}
+ \errval{EACCES}, \errval{EFAULT}, \errval{ELOOP}, \errval{ENAMETOOLONG},
+ \errval{ENOENT}, \errval{ENOMEM}, \errval{ENOTDIR}, per \func{fchown}
+ \errval{EBADF} nel loro significato generico.}
+\end{funcproto}
+
+Le funzioni cambiano utente e gruppo di appartenenza di un file ai valori
+specificati dalle variabili \param{owner} e \param{group}. Con Linux solo
+l'amministratore\footnote{o in generale un processo con la capacità
+ \const{CAP\_CHOWN}, vedi sez.~\ref{sec:proc_capabilities}.} può cambiare il
+proprietario di un file; in questo viene seguita la semantica usata da BSD che
+non consente agli utenti di assegnare i loro file ad altri utenti evitando
+eventuali aggiramenti delle quote. L'amministratore può cambiare sempre il
+gruppo di un file, il proprietario può cambiare il gruppo solo dei file che
+gli appartengono e solo se il nuovo gruppo è il suo gruppo primario o uno dei
+gruppi di cui fa parte.
+
+La funzione \func{chown} segue i collegamenti simbolici, per operare
+direttamente su un collegamento simbolico si deve usare la funzione
+\func{lchown}.\footnote{fino alla versione 2.1.81 in Linux \func{chown} non
+ seguiva i collegamenti simbolici, da allora questo comportamento è stato
+ assegnato alla funzione \func{lchown}, introdotta per l'occasione, ed è
+ stata creata una nuova \textit{system call} per \func{chown} che seguisse i
+ collegamenti simbolici.} La funzione \func{fchown} opera su un file aperto,
+essa è mutuata da BSD, ma non è nello standard POSIX. Un'altra estensione
+rispetto allo standard POSIX è che specificando -1 come valore
+per \param{owner} e \param{group} i valori restano immutati.
+
+Quando queste funzioni sono chiamate con successo da un processo senza i
+privilegi di amministratore entrambi i bit \acr{suid} e \acr{sgid} vengono
+cancellati. Questo non avviene per il bit \acr{sgid} nel caso in cui esso sia
+usato (in assenza del corrispondente permesso di esecuzione) per indicare che
+per il file è attivo il \textit{mandatory locking} (vedi
+sez.~\ref{sec:file_mand_locking}).
+
+
+\subsection{Un quadro d'insieme sui permessi}
+\label{sec:file_riepilogo}
+
+Avendo affrontato in maniera separata il comportamento delle varie funzioni
+che operano sui permessi dei file ed avendo trattato in sezioni diverse il
+significato dei singoli bit dei permessi, vale la pena di fare un riepilogo in
+cui si riassumano le caratteristiche di ciascuno di essi, in modo da poter
+fornire un quadro d'insieme.
+
+\begin{table}[!htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|c|c|c|c|c|c|c|c|c|c|c|c|l|}
+ \hline
+ \multicolumn{3}{|c|}{special}&
+ \multicolumn{3}{|c|}{user}&
+ \multicolumn{3}{|c|}{group}&
+ \multicolumn{3}{|c|}{other}&
+ \multirow{2}{*}{\textbf{Significato per i file}} \\
+ \cline{1-12}
+ \texttt{s}&\texttt{s}&\texttt{t}&
+ \texttt{r}&\texttt{w}&\texttt{x}&
+ \texttt{r}&\texttt{w}&\texttt{x}&
+ \texttt{r}&\texttt{w}&\texttt{x}& \\
+ \hline
+ \hline
+ 1&-&-&-&-&1&-&-&-&-&-&-&Eseguito conferisce l'\ids{UID} effettivo dell'utente.\\
+ -&1&-&-&-&1&-&-&-&-&-&-&Eseguito conferisce il \ids{GID} effettivo del gruppo.\\
+ -&1&-&-&-&0&-&-&-&-&-&-&Il \textit{mandatory locking} è abilitato.\\
+ -&-&1&-&-&-&-&-&-&-&-&-&Non utilizzato.\\
+ -&-&-&1&-&-&-&-&-&-&-&-&Permesso di lettura per l'utente.\\
+ -&-&-&-&1&-&-&-&-&-&-&-&Permesso di scrittura per l'utente.\\
+ -&-&-&-&-&1&-&-&-&-&-&-&Permesso di esecuzione per l'utente.\\
+ -&-&-&-&-&-&1&-&-&-&-&-&Permesso di lettura per il gruppo.\\
+ -&-&-&-&-&-&-&1&-&-&-&-&Permesso di scrittura per il gruppo.\\
+ -&-&-&-&-&-&-&-&1&-&-&-&Permesso di esecuzione per il gruppo.\\
+ -&-&-&-&-&-&-&-&-&1&-&-&Permesso di lettura per tutti gli altri.\\
+ -&-&-&-&-&-&-&-&-&-&1&-&Permesso di scrittura per tutti gli altri.\\
+ -&-&-&-&-&-&-&-&-&-&-&1&Permesso di esecuzione per tutti gli altri.\\
+ \hline
+ \hline
+ \multicolumn{3}{|c|}{special}&
+ \multicolumn{3}{|c|}{user}&
+ \multicolumn{3}{|c|}{group}&
+ \multicolumn{3}{|c|}{other}&
+ \multirow{2}{*}{\textbf{Significato per le directory}} \\
+ \cline{1-12}
+ \texttt{s}&\texttt{s}&\texttt{t}&
+ \texttt{r}&\texttt{w}&\texttt{x}&
+ \texttt{r}&\texttt{w}&\texttt{x}&
+ \texttt{r}&\texttt{w}&\texttt{x}& \\
+ \hline
+ \hline
+ 1&-&-&-&-&-&-&-&-&-&-&-&Non utilizzato.\\
+ -&1&-&-&-&-&-&-&-&-&-&-&Propaga il gruppo ai nuovi file creati.\\
+ -&-&1&-&-&-&-&-&-&-&-&-&Solo il proprietario di un file può rimuoverlo.\\
+ -&-&-&1&-&-&-&-&-&-&-&-&Permesso di visualizzazione per l'utente.\\
+ -&-&-&-&1&-&-&-&-&-&-&-&Permesso di aggiornamento per l'utente.\\
+ -&-&-&-&-&1&-&-&-&-&-&-&Permesso di attraversamento per l'utente.\\
+ -&-&-&-&-&-&1&-&-&-&-&-&Permesso di visualizzazione per il gruppo.\\
+ -&-&-&-&-&-&-&1&-&-&-&-&Permesso di aggiornamento per il gruppo.\\
+ -&-&-&-&-&-&-&-&1&-&-&-&Permesso di attraversamento per il gruppo.\\
+ -&-&-&-&-&-&-&-&-&1&-&-&Permesso di visualizzazione per tutti gli altri.\\
+ -&-&-&-&-&-&-&-&-&-&1&-&Permesso di aggiornamento per tutti gli altri.\\
+ -&-&-&-&-&-&-&-&-&-&-&1&Permesso di attraversamento per tutti gli altri.\\
+ \hline
+ \end{tabular}
+ \caption{Tabella riassuntiva del significato dei bit dei permessi per un
+ file e directory.}
+ \label{tab:file_fileperm_bits}
+\end{table}
+
+Nella parte superiore di tab.~\ref{tab:file_fileperm_bits} si è riassunto il
+significato dei vari bit dei permessi per un file ordinario; per quanto
+riguarda l'applicazione dei permessi per proprietario, gruppo ed altri si
+ricordi quanto illustrato in sez.~\ref{sec:file_perm_overview}. Per
+compattezza, nella tabella si sono specificati i bit di \textit{suid},
+\textit{sgid} e \textit{sticky} con la notazione illustrata anche in
+fig.~\ref{fig:file_perm_bit}. Nella parte inferiore si sono invece riassunti
+i significati dei vari bit dei permessi per una directory; anche in questo
+caso si è riapplicato ai bit di \textit{suid}, \textit{sgid} e \textit{sticky}
+la notazione illustrata in fig.~\ref{fig:file_perm_bit}.
+
+Si ricordi infine che i permessi non hanno alcun significato per i
+collegamenti simbolici, mentre per i file di dispositivo hanno senso soltanto
+i permessi di lettura e scrittura, che si riflettono sulla possibilità di
+compiere dette operazioni sul dispositivo stesso.
+
+Nella tabella si è indicato con il carattere ``-'' il fatto che il valore del
+bit in questione non è influente rispetto a quanto indicato nella riga della
+tabella; la descrizione del significato fa riferimento soltanto alla
+combinazione di bit per i quali è stato riportato esplicitamente un valore.
+Si rammenti infine che il valore dei bit dei permessi non ha alcun effetto
+qualora il processo possieda i privilegi di amministratore.
+
+
+\section{Caratteristiche e funzionalità avanzate}
+\label{sec:file_dir_advances}
+
+Tratteremo qui alcune caratteristiche e funzionalità avanzate della gestione
+di file e directory, affrontando anche una serie di estensioni
+dell'interfaccia classica dei sistemi unix-like, principalmente utilizzate a
+scopi di sicurezza, che sono state introdotte nelle versioni più recenti di
+Linux.
+
+\subsection{Gli attributi estesi}
+\label{sec:file_xattr}
+
+\itindbeg{Extended~Attributes}
+
+Nelle sezioni precedenti abbiamo trattato in dettaglio le varie informazioni
+che il sistema mantiene negli \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
+abbiamo chiamato genericamente \textsl{metadati}) che però non potevano
+trovare spazio nei dati classici mantenuti negli \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 consente di associare delle informazioni ulteriori ai
+singoli file.\footnote{essi ad esempio vengono usati per le ACL, che
+ tratteremo in sez.~\ref{sec:file_ACL} e le \textit{file capabilities}, che
+ vedremo in sez.~\ref{sec:proc_capabilities}.} 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.
+
+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.
+
+In Linux gli attributi estesi sono sempre associati al singolo \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.
+
+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}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}{|l|p{8cm}|}
+ \hline
+ \textbf{Nome} & \textbf{Descrizione} \\
+ \hline
+ \hline
+ \texttt{security}&Gli \textit{extended security attributes}: vengono
+ utilizzati dalle estensioni di sicurezza del kernel (i
+ \textit{Linux Security Modules}), per le realizzazione
+ di meccanismi evoluti di controllo di accesso come
+ \textit{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 ACL (vedi sez.~\ref{sec:file_ACL}) o le
+ \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}
+ \caption{I nomi utilizzati valore di \texttt{namespace} per distinguere le
+ varie classi di \textit{Extended Attributes}.}
+ \label{tab:extended_attribute_class}
+\end{table}
+
+
+Dato che uno degli usi degli \textit{Extended Attributes} è di impiegarli per
+realizzare delle estensioni (come le ACL, \textit{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 che
+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 \textit{Linux Security
+ Modules} (ad esempio \textit{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 capacità
+ \const{CAP\_SYS\_ADMIN}.
+
+\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 ACL (vedi sez.~\ref{sec:file_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 capacità
+ \const{CAP\_FOWNER}.\footnote{vale a dire una politica di accesso analoga a
+ quella impiegata per gli ordinari permessi dei file.}
+
+\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 capacità \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.
+
+\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 collegamenti simbolici, o alcuni 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 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 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
+ collegamenti 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
+ collegamenti simbolici o file di dispositivo, e neanche per le \textit{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 \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 capacità \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 della \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 poter leggere gli attributi estesi sono disponibili tre diverse funzioni
+di sistema, \funcd{getxattr}, \funcd{lgetxattr} e \funcd{fgetxattr}, che
+consentono rispettivamente di richiedere gli attributi relativi a un file, a
+un collegamento simbolico e ad un file descriptor; i rispettivi prototipi
+sono:
+
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{attr/xattr.h}
+\fdecl{ssize\_t getxattr(const char *path, const char *name, void *value,
+ size\_t size)}
+\fdecl{ssize\_t lgetxattr(const char *path, const char *name, void *value,
+ size\_t size)}
+\fdecl{ssize\_t fgetxattr(int filedes, const char *name, void *value,
+ size\_t size)}
+\fdesc{Leggono il valore di un attributo esteso.}
+}
+
+{Le funzioni ritornano un intero positivo che indica la dimensione
+ dell'attributo richiesto in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei 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.
+ \item[\errcode{ERANGE}] la dimensione \param{size} del buffer \param{value}
+ non è sufficiente per contenere il risultato.
+ \end{errlist}
+ ed inoltre tutti gli errori delle analoghe della famiglia \func{stat} con lo
+ stesso significato, ed in particolare \errcode{EPERM} se non si hanno i
+ permessi di accesso all'attributo.}
+\end{funcproto}
+
+Le funzioni \func{getxattr} e \func{lgetxattr} prendono come primo argomento
+un \textit{pathname} che indica il file di cui si vuole richiedere un
+attributo, la sola differenza è che la seconda, se il \textit{pathname} indica
+un collegamento 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}.
+
+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.}
+
+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
+collegamento simbolico o specificando un file descriptor; i loro prototipi sono:
+
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{attr/xattr.h}
+\fdecl{int setxattr(const char *path, const char *name, const void *value,
+ size\_t size, int flags)}
+\fdecl{int lsetxattr(const char *path, const char *name, const void *value,
+ size\_t size, int flags)}
+\fdecl{int fsetxattr(int filedes, const char *name, const void *value, size\_t
+ size, int flags)}
+\fdesc{Impostano il valore di un attributo esteso.}
+}
+
+{Le funzioni ritornano un $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EEXIST}] si è usato il flag \const{XATTR\_CREATE} ma
+ l'attributo esiste già.
+ \item[\errcode{ENOATTR}] si è usato il flag \const{XATTR\_REPLACE} e
+ 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 delle analoghe della famiglia \func{stat} con lo
+ stesso significato ed in particolare \errcode{EPERM} se non si hanno i
+ permessi di accesso all'attributo.}
+\end{funcproto}
+
+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.
+
+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 \constd{XATTR\_REPLACE} si richiede che l'attributo
+esista, nel qual caso verrà sovrascritto, altrimenti si avrà errore, mentre
+con \constd{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'è.
+
+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 di sistema \funcd{listxattr},
+\funcd{llistxattr} e \funcd{flistxattr} i cui prototipi sono:
+
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{attr/xattr.h}
+\fdecl{ssize\_t listxattr(const char *path, char *list, size\_t size)}
+\fdecl{ssize\_t llistxattr(const char *path, char *list, size\_t size)}
+\fdecl{ssize\_t flistxattr(int filedes, char *list, size\_t size)}
+\fdesc{Leggono la lista degli attributi estesi di un file.}
+}
+
+{Le funzioni ritornano un intero positivo che indica la dimensione della lista
+ in caso di successo e $-1$ per un errore, nel qual caso \var{errno} assumerà
+ uno dei valori:
+ \begin{errlist}
+ \item[\errcode{ENOTSUP}] gli attributi estesi non sono supportati dal
+ filesystem o sono disabilitati.
+ \item[\errcode{ERANGE}] la dimensione \param{size} del buffer \param{value}
+ non è sufficiente per contenere il risultato.
+ \end{errlist}
+ ed inoltre tutti gli errori delle analoghe della famiglia \func{stat} con lo
+ stesso significato ed in particolare \errcode{EPERM} se non si hanno i
+ permessi di accesso all'attributo.}
+\end{funcproto}
+
+Come per le precedenti le tre funzioni leggono gli attributi rispettivamente
+di un file, un collegamento 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 di sistema: \funcd{removexattr},
+\funcd{lremovexattr} e \funcd{fremovexattr}; i rispettivi prototipi sono:
+
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{attr/xattr.h}
+\fdecl{int removexattr(const char *path, const char *name)}
+\fdecl{int lremovexattr(const char *path, const char *name)}
+\fdecl{int fremovexattr(int filedes, const char *name)}
+\fdesc{Rimuovono un attributo esteso di un file.}
+}
+
+{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei 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 delle analoghe della famiglia \func{stat} con lo
+ stesso significato ed in particolare \errcode{EPERM} se non si hanno i
+ permessi di accesso all'attributo.}
+\end{funcproto}
+
+Le tre funzioni rimuovono un attributo esteso operando rispettivamente su di
+un file, su un collegamento simbolico o un file descriptor, che vengono
+specificati dal valore passato con il loro primo argomento. L'attributo da
+rimuovere deve essere anche in questo caso indicato con
+l'argomento \param{name} secondo le stesse modalità già illustrate in
+precedenza per le altre funzioni relative alla gestione degli attributi
+estesi.
+
+\itindend{Extended~Attributes}
+
+
+\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~(ACL)}
+
+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 del gruppo di lavoro erano però forse troppo ambizioni, e nel
+gennaio del 1998 i finanziamenti vennero ritirati senza che si fosse arrivati
+alla definizione dello standard richiesto. 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, come ad esempio FreeBSD, nel caso di Linux si è
+scelto di realizzare le ACL attraverso l'uso degli \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 della
+\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 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 capacità \const{CAP\_FOWNER}.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}{|l|p{8cm}|}
+ \hline
+ \textbf{Tipo} & \textbf{Descrizione} \\
+ \hline
+ \hline
+ \constd{ACL\_USER\_OBJ}& Voce che contiene i diritti di accesso del
+ proprietario del file.\\
+ \constd{ACL\_USER} & Voce che contiene i diritti di accesso per
+ l'utente indicato dal rispettivo
+ qualificatore.\\
+ \constd{ACL\_GROUP\_OBJ}&Voce che contiene i diritti di accesso del
+ gruppo proprietario del file.\\
+ \constd{ACL\_GROUP} & Voce che contiene i diritti di accesso per
+ il gruppo indicato dal rispettivo
+ qualificatore.\\
+ \constd{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}.\\
+ \constd{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}
+
+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.
+
+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.
+
+Una voce di tipo \const{ACL\_MASK} serve a mantenere 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 \textit{umask} associata
+ad un oggetto sul filesystem piuttosto che a un processo.
+
+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 nelle 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 e viceversa.\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.}
+
+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}, che è quanto avviene
+normalmente se non sono presenti ACL aggiuntive rispetto ai permessi
+ordinari. Se invece questa è presente verranno tolti dai permessi di
+\const{ACL\_GROUP\_OBJ} (cioè dai permessi per il gruppo proprietario del
+file) 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}.}
+
+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_close}), \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 andrà a contenerli.
+Se questa non c'è valgono le regole usuali illustrate in
+sez.~\ref{sec:file_perm_management}, per cui essi sono determinati dalla
+\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, essa diventerà automaticamente anche la ACL di accesso di quest'ultimo,
+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 che deriverebbero dalla ACL di default, tutti i permessi non
+presenti in tale indicazione.
+
+Dato che questa è la ragione che ha portato alla loro creazione, la principale
+modifica introdotta nel sistema con la presenza della ACL è quella alle regole
+del controllo di accesso ai file che si sono 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 caso di presenza di una ACL sul file, i passi attraverso i
+quali viene stabilito se il processo ha il diritto di accesso sono i seguenti:
+\begin{enumerate}
+\item Se l'\ids{UID} del processo è nullo (se cioè si è l'amministratore)
+ l'accesso è sempre garantito senza nessun controllo.\footnote{più
+ precisamente se si devono avere le capacità \const{CAP\_DAC\_OVERRIDE} per
+ i file e \const{CAP\_DAC\_READ\_SEARCH} per le directory, vedi
+ sez.~\ref{sec:proc_capabilities}.}
+\item Se l'\ids{UID} 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'\ids{UID} 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 \ids{GID} del processo o uno dei \ids{GID} 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 \ids{GID} del processo o uno dei \ids{GID} 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{funcproto}{
+\fhead{sys/types.h}
+\fhead{sys/acl.h}
+\fdecl{acl\_t acl\_init(int count)}
+\fdesc{Inizializza un'area di lavoro per una ACL.}
+}
+
+{La funzione ritorna un oggetto di tipo \type{acl\_t} in caso di successo e
+ \val{NULL} per un 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{funcproto}
+
+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 \typed{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 \typed{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 di tipo
+``\code{(acl\_t) NULL}'' e si dovrà, in questa come in tutte le funzioni
+seguenti che restituiscono un oggetto di tipo \type{acl\_t}, confrontare il
+valore di ritorno della funzione con \val{NULL}.\footnote{a voler essere
+ estremamente pignoli si dovrebbe usare ``\code{(acl\_t) NULL}'', ma è
+ sufficiente fare un confronto direttamente con \val{NULL} essendo cura del
+ compilatore fare le conversioni necessarie.}
+
+Una volta che si siano completate le operazioni sui dati di una ACL la memoria
+allocata per un oggetto \type{acl\_t} dovrà essere liberata esplicitamente
+attraverso una chiamata alla funzione \funcd{acl\_free}, il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{sys/acl.h}
+\fdecl{int acl\_free(void *obj\_p)}
+\fdesc{Disalloca la memoria riservata per una ACL.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} può assumere solo il valore:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] \param{obj\_p} non è valido.
+ \end{errlist}
+}
+\end{funcproto}
+
+Si noti come la funzione usi 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 della una voce di una ACL. L'uso del tipo generico ``\ctyp{void
+ *}'' consente di evitare di eseguire un \textit{cast} al tipo di dato di cui
+si vuole effettuare la disallocazione.
+
+Si tenga presente poi che oltre a \func{acl\_init} ci sono molte altre
+funzioni che possono allocare memoria per i dati delle ACL, è pertanto
+opportuno tenere traccia di tutte le chiamate a 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{funcproto}{
+\fhead{sys/types.h}
+\fhead{sys/acl.h}
+\fdecl{acl\_t acl\_dup(acl\_t acl)}
+\fdesc{Crea una copia di una ACL.}
+}
+
+{La funzione ritorna un oggetto di tipo \type{acl\_t} in caso di successo in
+ caso di successo e \val{NULL} per un errore, nel qual caso \var{errno}
+ assumerà 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{funcproto}
+
+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.
+
+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{funcproto}{
+\fhead{sys/types.h}
+\fhead{sys/acl.h}
+\fdecl{acl\_t acl\_from\_mode(mode\_t mode)}
+\fdesc{Crea una ACL inizializzata con i permessi ordinari.}
+}
+
+{La funzione ritorna un oggetto di tipo \type{acl\_t} in caso di successo e
+ \val{NULL} per un errore, nel qual caso \var{errno} può assumere solo
+ il valore \errval{ENOMEM}.}
+\end{funcproto}
+
+
+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.
+
+Altre due funzioni che consentono di creare una ACL già inizializzata sono
+\funcd{acl\_get\_fd} e \funcd{acl\_get\_file}, che consentono di leggere la
+ACL di un file; i rispettivi prototipi sono:
+
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{sys/acl.h}
+\fdecl{acl\_t acl\_get\_file(const char *path\_p, acl\_type\_t type)}
+\fdecl{acl\_t acl\_get\_fd(int fd)}
+\fdesc{Leggono i dati delle ACL di un file.}
+}
+
+{Le funzioni ritornano un oggetto di tipo \type{acl\_t} in caso di successo e
+ \val{NULL} per un errore, nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EACCESS}] non c'è accesso per una componente di
+ \param{path\_p} o si è richiesta una ACL di default per un file (solo per
+ \func{acl\_get\_file}).
+ \item[\errcode{EINVAL}] \param{type} non ha un valore valido (solo per
+ \func{acl\_get\_file}).
+ \item[\errcode{ENOTSUP}] il filesystem cui fa riferimento il file non
+ supporta le ACL.
+ \end{errlist}
+ ed inoltre \errval{ENOMEM} per entrambe, \errval{EBADF} per
+ \func{acl\_get\_fd}, e \errval{ENAMETOOLONG}, \errval{ENOENT},
+ \errval{ENOTDIR}, per \func{acl\_get\_file} nel loro significato generico. }
+\end{funcproto}
+
+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
+\textit{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
+\typed{acl\_type\_t} e può assumere solo i due valori riportati in
+tab.~\ref{tab:acl_type}.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}{|l|l|}
+ \hline
+ \textbf{Tipo} & \textbf{Descrizione} \\
+ \hline
+ \hline
+ \constd{ACL\_TYPE\_ACCESS} & Indica una ACL di accesso.\\
+ \constd{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}
+
+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.
+
+Infine si potrà creare una ACL direttamente dalla sua rappresentazione
+testuale con la funzione \funcd{acl\_from\_text}, il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{sys/acl.h}
+\fdecl{acl\_t acl\_from\_text(const char *buf\_p)}
+\fdesc{Crea una ACL a partire dalla sua rappresentazione testuale.}
+}
+
+{La funzione ritorna un oggetto di tipo \type{acl\_t} in caso di successo e
+ \val{NULL} per un errore, nel qual caso \var{errno} assumerà uno
+ dei valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] la rappresentazione testuale all'indirizzo
+ \param{buf\_p} non è valida.
+ \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
+ \end{errlist}
+}
+\end{funcproto}
+
+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{Example}
+tipo:qualificatore:permessi
+\end{Example}
+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.}
+
+Un possibile esempio di rappresentazione della ACL di un file ordinario a cui,
+oltre ai permessi ordinari, si è aggiunto un altro utente con un accesso in
+lettura, è il seguente:
+\begin{Example}
+user::rw-
+group::r--
+other::r--
+user:piccardi:r--
+\end{Example}
+
+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{\#}''.
+
+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}, ed il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{sys/acl.h}
+\fdecl{char *acl\_to\_text(acl\_t acl, ssize\_t *len\_p)}
+\fdesc{Produce la rappresentazione testuale di una ACL.}
+}
+
+{La funzione ritorna il puntatore ad una stringa con la rappresentazione
+ testuale della ACL in caso di successo e \var{NULL} per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida.
+ \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
+ \end{errlist}
+}
+\end{funcproto}
+
+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 (come \textit{value result argument}) la
+dimensione della stringa con la rappresentazione testuale, non comprendente il
+carattere nullo finale.
+
+La seconda funzione, che permette di controllare con una gran dovizia di
+particolari la generazione della stringa contenente la rappresentazione
+testuale della ACL, è \funcd{acl\_to\_any\_text}, ed il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{sys/acl.h}
+\fdecl{char *acl\_to\_any\_text(acl\_t acl, const char *prefix, char
+ separator, int options)}
+\fdesc{Produce la rappresentazione testuale di una ACL.}
+}
+
+{La funzione ritorna il puntatore ad una stringa con la rappresentazione
+ testuale della ACL in caso di successo e \val{NULL} per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida.
+ \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
+ \end{errlist}
+}
+\end{funcproto}
+
+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}.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}{|l|p{8cm}|}
+ \hline
+ \textbf{Tipo} & \textbf{Descrizione} \\
+ \hline
+ \hline
+ \constd{TEXT\_ABBREVIATE} & Stampa le voci in forma abbreviata.\\
+ \constd{TEXT\_NUMERIC\_IDS} & non effettua la risoluzione numerica di
+ \ids{UID} e \ids{GID}.\\
+ \constd{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.\\
+ \constd{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.\\
+ \constd{TEXT\_SMART\_INDENT} & Da usare in combinazione con le precedenti
+ opzioni \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 riga di 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{funcproto}{
+\fhead{sys/types.h}
+\fhead{sys/acl.h}
+\fdecl{ssize\_t acl\_size(acl\_t acl)}
+\fdesc{Determina la dimensione della rappresentazione binaria di una ACL.}
+}
+
+{La funzione ritorna la dimensione in byte della rappresentazione binaria
+ della ACL in caso di successo e $-1$ per un errore, nel qual caso
+ \var{errno} può assumere solo il valore:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida.
+ \end{errlist}
+}
+\end{funcproto}
+
+Ottenuta con \func{acl\_size} la dimensione per il buffer di una ACL lo si
+potrà allocare direttamente con \func{malloc}. La rappresentazione binaria di
+una ACL si potrà invece ottenere con la funzione \funcd{acl\_copy\_ext}, il
+cui prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{sys/acl.h}
+\fdecl{ssize\_t acl\_copy\_ext(void *buf\_p, acl\_t acl, ssize\_t size)}
+\fdesc{Ottiene la rappresentazione binaria di una ACL.}
+}
+
+{La funzione ritorna la dimensione in byte della rappresentazione binaria
+ della ACL in caso di successo e $-1$ per un 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{funcproto}
+
+La funzione scriverà la rappresentazione binaria della ACL indicata da
+\param{acl} sul buffer di dimensione \param{size}
+all'indirizzo \param{buf\_p}, 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 da una rappresentazione
+binaria si potrà usare la funzione \funcd{acl\_copy\_int}, il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{sys/acl.h}
+\fdecl{acl\_t acl\_copy\_int(const void *buf\_p)}
+\fdesc{Ripristina la rappresentazione binaria di una ACL.}
+}
+
+{La funzione ritorna un oggetto di tipo \type{acl\_t} in caso di successo e
+ \val{NULL} per un 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{funcproto}
+
+La funzione alloca autonomamente un oggetto di tipo \type{acl\_t}, restituito
+come valore di ritorno, con il contenuto della ACL rappresentata dai dati del
+buffer puntato da \param{buf\_p}. Al solito 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{funcproto}{
+\fhead{sys/types.h}
+\fhead{sys/acl.h}
+\fdecl{int acl\_set\_file(const char *path, acl\_type\_t type, acl\_t acl)}
+\fdesc{Imposta una ACL su un file o una directory.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un 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 un 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{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOTDIR},
+ \errval{EPERM}, \errval{EROFS} nel loro significato generico.}
+\end{funcproto}
+
+La funzione consente di assegnare la ACL contenuta in \param{acl} al file o
+alla directory indicate dal \textit{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
+\param{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
+ \textit{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{funcproto}{
+\fhead{sys/types.h}
+\fhead{sys/acl.h}
+\fdecl{int acl\_set\_fd(int fd, acl\_t acl)}
+\fdesc{Imposta una ACL su un file descriptor.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] o \param{acl} non è una ACL valida, o ha più voci di
+ quante se ne possono assegnare al file indicato da \param{fd}.
+ \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{EPERM}, \errval{EROFS} nel loro
+ significato generico.
+}
+\end{funcproto}
+
+La funzione è del tutto è analoga a \func{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.
+
+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 pagine di
+manuale.
+
+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 \typed{acl\_entry\_t}, che possono essere ottenuti
+dalla funzione \funcm{acl\_get\_entry} (per una voce esistente) o dalla
+funzione \funcm{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.
+
+Una volta ottenuti detti puntatori si potrà operare sui contenuti delle singole
+voci; con le funzioni \funcm{acl\_get\_tag\_type}, \funcm{acl\_get\_qualifier},
+\funcm{acl\_get\_permset} si potranno leggere rispettivamente tipo,
+qualificatore e permessi mentre con le corrispondente funzioni
+\funcm{acl\_set\_tag\_type}, \funcm{acl\_set\_qualifier},
+\funcm{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 \funcm{acl\_copy\_entry} o eliminare una voce da una ACL con
+\funcm{acl\_delete\_entry} e verificarne la validità prima di usarla con
+\funcm{acl\_valid} o \funcm{acl\_check}.
+
+\itindend{Access~Control~List~(ACL)}
+
+Come esempio di utilizzo di queste funzioni nei sorgenti allegati alla guida
+si è distribuito il programma \texttt{mygetfacl.c}, che consente di leggere le
+ACL di un file, passato come argomento.
+
+\begin{figure}[!htbp]
+ \footnotesize \centering
+ \begin{minipage}[c]{\codesamplewidth}
+ \includecodesample{listati/mygetfacl.c}
+ \end{minipage}
+ \normalsize
+ \caption{Corpo principale del programma \texttt{mygetfacl.c}.}
+ \label{fig:proc_mygetfacl}
+\end{figure}
+
+La sezione principale del programma, da cui si è rimossa la sezione sulla
+gestione delle opzioni, è riportata in fig.~\ref{fig:proc_mygetfacl}. Il
+programma richiede un unico argomento (\texttt{\small 16-20}) che indica il
+file di cui si vuole leggere la ACL. Se questo è presente si usa
+(\texttt{\small 22}) la funzione \func{get\_acl\_file} per leggerne la ACL, e
+si controlla (\texttt{\small 23-26}) se l'operazione ha successo, uscendo con
+un messaggio di errore in caso contrario.
+
+Ottenuta la ACL la si converte in formato testuale (\texttt{\small 27}) con la
+funzione \func{acl\_to\_text}, controllando di nuovo se l'operazione ha
+successo (\texttt{\small 28-31}) ed uscendo in caso contrario. Si provvede
+infine a stampare la rappresentazione testuale (\texttt{\small 32}) e dopo
+aver liberato (\texttt{\small 33-34}) le risorse allocate automaticamente, si
+conclude l'esecuzione.
+
+
+\subsection{La gestione delle quote disco}
+\label{sec:disk_quota}
+
+Quella delle quote disco è una funzionalità introdotta inizialmente da BSD e
+presente in Linux fino dai kernel dalla serie 2.0, che consente di porre dei
+tetti massimi al consumo delle risorse di un filesystem (spazio disco e
+\textit{inode}) da parte di utenti e gruppi.
+
+Dato che la funzionalità ha senso solo per i filesystem su cui si mantengono i
+dati degli utenti\footnote{in genere la si attiva sul filesystem che contiene
+ le \textit{home} degli utenti, dato che non avrebbe senso per i file di
+ sistema che in genere appartengono all'amministratore.} essa deve essere
+attivata esplicitamente. Questo si fa, per tutti i filesystem che le
+supportano, tramite due distinte opzioni di montaggio, \texttt{usrquota} e
+\texttt{grpquota} che abilitano le quote rispettivamente per gli utenti e per
+i gruppi. Così è possibile usare le limitazioni sulle quote o sugli utenti o
+sui gruppi o su entrambi.
+
+Il meccanismo prevede che per ciascun filesystem che supporta le quote disco
+(i vari \textit{extN}, \textit{btrfs}, \textit{XFS}, \textit{JFS},
+\textit{ReiserFS}) il kernel provveda sia a mantenere aggiornati i dati
+relativi al consumo delle risorse da parte degli utenti e dei gruppi, che a
+far rispettare i limiti imposti dal sistema, con la generazione di un errore
+di \errcode{EDQUOT} per tutte le operazioni sui file che porterebbero ad un
+superamento degli stessi. Si tenga presente che questi due compiti sono
+separati, il primo si attiva al montaggio del filesystem con il supporto per
+le quote, il secondo deve essere abilitato esplicitamente.
+
+Per il mantenimento dei dati di consumo delle risorse vengono usati due file
+riservati nella directory radice del filesystem su cui si sono attivate le
+quote, uno per le quote utente e l'altro per le quote gruppo.\footnote{la cosa
+ vale per tutti i filesystem tranne \textit{XFS} che mantiene i dati
+ internamente.} Con la versione 2 del supporto delle quote, che da anni è
+l'unica rimasta in uso, questi file sono \texttt{aquota.user} e
+\texttt{aquota.group}, in precedenza erano \texttt{quota.user} e
+\texttt{quota.group}.
+
+Dato che questi file vengono aggiornati soltanto se il filesystem è stato
+montato attivando il supporto delle quote, se si abilita il supporto in un
+secondo tempo e nel frattempo sono state eseguite delle operazioni sul
+filesystem quando il supporto era disabilitato, i dati contenuti possono non
+corrispondere esattamente allo stato corrente del consumo delle risorse. Per
+questo motivo prima di montare in scrittura un filesystem su cui sono
+abilitate le quote viene richiesto di utilizzare il comando \cmd{quotacheck}
+per verificare e aggiornare i dati.
+
+Le restrizioni sul consumo delle risorse previste dal sistema delle quote
+prevedono sempre la presenza di due diversi limiti, il primo viene detto
+\textit{soft limit} e può essere superato per brevi periodi di tempo senza che
+causare errori per lo sforamento delle quote, il secondo viene detto
+\textit{hard limit} e non può mai essere superato.
+
+Il periodo di tempo per cui è possibile eccedere rispetto alle restrizioni
+indicate dal \textit{soft limit} è detto ``\textsl{periodo di grazia}''
+(\textit{grace period}), che si attiva non appena si supera la quota da esso
+indicata. Se si continua a restare al di sopra del \textit{soft limit} una
+volta scaduto il \textit{grace period} questo verrà trattato allo stesso modo
+dell'\textit{hard limit} e si avrà l'emissione immediata di un errore.
+
+Si tenga presente infine che entrambi i tipi di limiti (\textit{soft limit} e
+\textit{hard limit}) possono essere disposti separatamente su entrambe le
+risorse di un filesystem, essi cioè possono essere presenti in maniera
+indipendente sia sullo spazio disco, con un massimo per il numero di blocchi,
+che sui file, con un massimo per il numero di \textit{inode}.
+
+La funzione di sistema che consente di controllare tutti i vari aspetti della
+gestione delle quote è \funcd{quotactl}, ed il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{sys/quota.h}
+\fdecl{int quotactl(int cmd, const char *dev, int id, caddr\_t addr)}
+\fdesc{Esegue una operazione di controllo sulle quote disco.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EACCES}] si è richiesto \const{Q\_QUOTAON}, ma il file delle
+ quote indicato da \param{addr} non esiste o non è un file ordinario.
+ \item[\errcode{EBUSY}] si è richiesto \const{Q\_QUOTAON}, ma le quote sono
+ già attive.
+ \item[\errcode{EFAULT}] \param{addr} non è un puntatore valido.
+ \item[\errcode{EINVAL}] o \param{cmd} non è un comando valido,
+ o il dispositivo \param{dev} non esiste.
+ \item[\errcode{EIO}] errore di lettura/scrittura sul file delle quote.
+ \item[\errcode{EMFILE}] non si può aprire il file delle quote avendo
+ superato il limite sul numero di file aperti nel sistema.
+ \item[\errcode{ENODEV}] \param{dev} non corrisponde ad un \textit{mount
+ point} attivo.
+ \item[\errcode{ENOPKG}] il kernel è stato compilato senza supporto per le
+ quote.
+ \item[\errcode{ENOTBLK}] \param{dev} non è un dispositivo a blocchi.
+ \item[\errcode{EPERM}] non si hanno i permessi per l'operazione richiesta.
+ \item[\errcode{ESRCH}] è stato richiesto uno fra \const{Q\_GETQUOTA},
+ \const{Q\_SETQUOTA}, \const{Q\_SETUSE}, \const{Q\_SETQLIM} per un
+ filesystem senza quote attivate.
+ \end{errlist}
+}
+\end{funcproto}
+
+% TODO rivedere gli errori
+
+La funzione richiede che il filesystem sul quale si vuole operare, che deve
+essere specificato con il nome del relativo file di dispositivo
+nell'argomento \param{dev}, sia montato con il supporto delle quote
+abilitato. Per le operazioni che lo richiedono inoltre si dovrà indicare con
+l'argomento \param{id} l'utente o il gruppo (specificati rispettivamente per
+\ids{UID} e \ids{GID}) su cui si vuole operare, o altri dati relativi
+all'operazione. Alcune operazioni più complesse usano infine
+l'argomento \param{addr} per indicare un indirizzo ad un area di memoria il
+cui utilizzo dipende dall'operazione stessa.
+
+La funzione prevede la possibilità di eseguire una serie operazioni sulle
+quote molto diverse fra loro, la scelta viene effettuata tramite il primo
+argomento, \param{cmd}, che però oltre all'operazione indica anche a quale
+tipo di quota (utente o gruppo) l'operazione deve applicarsi. Per questo il
+valore di questo argomento viene costruito con l'ausilio della di una apposita
+macro \macro{QCMD}:
+
+{\centering
+\vspace{3pt}
+\begin{funcbox}{
+\fhead{sys/quota.h}
+\fdecl{int \macrod{QCMD}(subcmd,type)}
+\fdesc{Imposta il comando \param{subcmd} per il tipo di quote (utente o
+ gruppo) \param{type}.}
+}
+\end{funcbox}
+}
+
+La macro consente di specificare, oltre al tipo di operazione, da indicare con
+l'argomento \param{subcmd} se questa deve applicarsi alle quote utente o alle
+quote gruppo. Questo viene indicato dall'argomento \param{type} che deve
+essere sempre definito ed assegnato ad uno fra i due valori \const{USRQUOTA} o
+\const{GRPQUOTA}.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}{|l|p{10cm}|}
+ \hline
+ \textbf{Comando} & \textbf{Descrizione} \\
+ \hline
+ \hline
+ \constd{Q\_QUOTAON} & Attiva l'applicazione delle quote disco per il
+ filesystem indicato da \param{dev}, si deve passare
+ in \param{addr} il \textit{pathname} al file che
+ mantiene le quote, che deve esistere, e \param{id}
+ deve indicare la versione del formato con uno dei
+ valori di tab.~\ref{tab:quotactl_id_format};
+ l'operazione richiede i privilegi di
+ amministratore.\\
+ \constd{Q\_QUOTAOFF}& Disattiva l'applicazione delle quote disco per il
+ filesystem indicato da \param{dev}, \param{id}
+ e \param{addr} vengono ignorati; l'operazione
+ richiede i privilegi di amministratore.\\
+ \constd{Q\_GETQUOTA}& Legge i limiti ed i valori correnti delle quote nel
+ filesystem indicato da \param{dev} per l'utente o
+ il gruppo specificato da \param{id}; si devono avere
+ i privilegi di amministratore per leggere i dati
+ relativi ad altri utenti o a gruppi di cui non si fa
+ parte, il risultato viene restituito in una struttura
+ \struct{dqblk} all'indirizzo indicato
+ da \param{addr}.\\
+ \constd{Q\_SETQUOTA}& Imposta i limiti per le quote nel filesystem
+ indicato da \param{dev} per l'utente o il gruppo
+ specificato da \param{id} secondo i valori ottenuti
+ dalla struttura \struct{dqblk} puntata
+ da \param{addr}; l'operazione richiede i privilegi
+ di amministratore.\\
+ \constd{Q\_GETINFO} & Legge le informazioni (in sostanza i \textit{grace
+ time}) delle quote del filesystem indicato
+ da \param{dev} sulla struttura \struct{dqinfo}
+ puntata da \param{addr}, \param{id} viene ignorato.\\
+ \constd{Q\_SETINFO} & Imposta le informazioni delle quote del filesystem
+ indicato da \param{dev} come ottenuti dalla
+ struttura \struct{dqinfo} puntata
+ da \param{addr}, \param{id} viene ignorato;
+ l'operazione richiede i privilegi di amministratore.\\
+ \constd{Q\_GETFMT} & Richiede il valore identificativo (quello di
+ tab.~\ref{tab:quotactl_id_format}) per il formato
+ delle quote attualmente in uso sul filesystem
+ indicato da \param{dev}, che sarà memorizzato
+ sul buffer di 4 byte puntato da \param{addr}.\\
+ \constd{Q\_SYNC} & Aggiorna la copia su disco dei dati delle quote del
+ filesystem indicato da \param{dev}; in questo
+ caso \param{dev} può anche essere \val{NULL} nel
+ qual caso verranno aggiornati i dati per tutti i
+ filesystem con quote attive, \param{id}
+ e \param{addr} vengono comunque ignorati.\\
+ \constd{Q\_GETSTATS}& Ottiene statistiche ed altre informazioni generali
+ relative al sistema delle quote per il filesystem
+ indicato da \param{dev}, richiede che si
+ passi come argomento \param{addr} l'indirizzo di una
+ struttura \struct{dqstats}, mentre i valori
+ di \param{id} e \param{dev} vengono ignorati;
+ l'operazione è obsoleta e non supportata nei kernel
+ più recenti, che espongono la stessa informazione
+ nei file sotto \procfile{/proc/self/fs/quota/}.\\
+% \const{} & .\\
+ \hline
+ \end{tabular}
+ \caption{Possibili valori per l'argomento \param{subcmd} di
+ \macro{QCMD}.}
+ \label{tab:quotactl_commands}
+\end{table}
+
+I possibili valori per l'argomento \param{subcmd} di \macro{QCMD} sono
+riportati in tab.~\ref{tab:quotactl_commands}, che illustra brevemente il
+significato delle operazioni associate a ciascuno di essi. In generale le
+operazioni di attivazione, disattivazione e di modifica dei limiti delle quote
+sono riservate e richiedono i privilegi di amministratore.\footnote{per essere
+ precisi tutte le operazioni indicate come privilegiate in
+ tab.~\ref{tab:quotactl_commands} richiedono la capacità
+ \const{CAP\_SYS\_ADMIN}.} Inoltre gli utenti possono soltanto richiedere i
+dati relativi alle proprie quote, solo l'amministratore può ottenere i dati di
+tutti.
+
+
+Alcune delle operazioni di tab.~\ref{tab:quotactl_commands} sono alquanto
+complesse e richiedono un approfondimento maggiore. Le due più rilevanti sono
+probabilmente \const{Q\_GETQUOTA} e \const{Q\_SETQUOTA}, che consentono la
+gestione dei limiti delle quote. Entrambe fanno riferimento ad una specifica
+struttura \struct{dqblk}, la cui definizione è riportata in
+fig.~\ref{fig:dqblk_struct},\footnote{la definizione mostrata è quella usata
+ fino dal kernel 2.4.22, non prenderemo in considerazione le versioni
+ obsolete.} nella quale vengono inseriti i dati relativi alle quote di un
+singolo utente o gruppo.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{0.9\textwidth}
+ \includestruct{listati/dqblk.h}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{dqblk} per i dati delle quote disco.}
+ \label{fig:dqblk_struct}
+\end{figure}
+
+La struttura \struct{dqblk} viene usata sia con \const{Q\_GETQUOTA} per
+ottenere i valori correnti dei limiti e dell'occupazione delle risorse, che
+con \const{Q\_SETQUOTA} per effettuare modifiche ai limiti. Come si può notare
+ci sono alcuni campi (in sostanza \val{dqb\_curspace}, \val{dqb\_curinodes},
+\val{dqb\_btime}, \val{dqb\_itime}) che hanno senso solo in lettura, in quanto
+riportano uno stato non modificabile da \func{quotactl} come l'uso corrente di
+spazio disco ed \textit{inode}, o il tempo che resta nel caso si sia superato
+un \textit{soft limit}.
+
+Inoltre in caso di modifica di un limite si può voler operare solo su una
+delle risorse (blocchi o \textit{inode}),\footnote{non è possibile modificare
+ soltanto uno dei limiti (\textit{hard} o \textit{soft}) occorre sempre
+ rispecificarli entrambi.} per questo la struttura prevede un campo apposito,
+\val{dqb\_valid}, il cui scopo è quello di indicare quali sono gli altri campi
+che devono essere considerati validi. Questo campo è una maschera binaria che
+deve essere espressa nei termini di OR aritmetico delle apposite costanti di
+tab.~\ref{tab:quotactl_qif_const}, dove si è riportato il significato di
+ciascuna di esse ed i campi a cui fanno riferimento.
+
+\begin{table}[!htb]
+ \centering
+ \footnotesize
+ \begin{tabular}{|l|p{10cm}|}
+ \hline
+ \textbf{Costante} & \textbf{Descrizione} \\
+ \hline
+ \hline
+ \constd{QIF\_BLIMITS}& Limiti sui blocchi di spazio disco
+ (\val{dqb\_bhardlimit} e \val{dqb\_bsoftlimit}).\\
+ \constd{QIF\_SPACE} & Uso corrente dello spazio disco
+ (\val{dqb\_curspace}).\\
+ \constd{QIF\_ILIMITS}& Limiti sugli \textit{inode}
+ (\val{dqb\_ihardlimit} e \val{dqb\_isoftlimit}).\\
+ \constd{QIF\_INODES} & Uso corrente degli \textit{inode}
+ (\val{dqb\_curinodes}).\\
+ \constd{QIF\_BTIME} & Tempo di sforamento del \textit{soft limit} sul
+ numero di blocchi (\val{dqb\_btime}).\\
+ \constd{QIF\_ITIME} & Tempo di sforamento del \textit{soft limit} sul
+ numero di \textit{inode} (\val{dqb\_itime}).\\
+ \constd{QIF\_LIMITS} & L'insieme di \const{QIF\_BLIMITS} e
+ \const{QIF\_ILIMITS}.\\
+ \constd{QIF\_USAGE} & L'insieme di \const{QIF\_SPACE} e
+ \const{QIF\_INODES}.\\
+ \constd{QIF\_TIMES} & L'insieme di \const{QIF\_BTIME} e
+ \const{QIF\_ITIME}.\\
+ \constd{QIF\_ALL} & Tutti i precedenti.\\
+ \hline
+ \end{tabular}
+ \caption{Costanti per il campo \val{dqb\_valid} di \struct{dqblk}.}
+ \label{tab:quotactl_qif_const}
+\end{table}
+
+In lettura con \const{Q\_SETQUOTA} eventuali valori presenti in \struct{dqblk}
+vengono comunque ignorati, al momento la funzione sovrascrive tutti i campi
+che restituisce e li marca come validi in \val{dqb\_valid}. Si possono invece
+usare \const{QIF\_BLIMITS} o \const{QIF\_ILIMITS} per richiedere di impostare
+solo la rispettiva tipologia di limiti con \const{Q\_SETQUOTA}. Si tenga
+presente che il sistema delle quote richiede che l'occupazione di spazio disco
+sia indicata in termini di blocchi e non di byte, dato che la dimensione dei
+blocchi dipende da come si è creato il filesystem potrà essere necessario
+effettuare qualche conversione per avere un valore in byte.\footnote{in genere
+ viene usato un default di 1024 byte per blocco, ma quando si hanno file di
+ dimensioni medie maggiori può convenire usare valori più alti per ottenere
+ prestazioni migliori in conseguenza di un minore frazionamento dei dati e di
+ indici più corti.}
+
+Come accennato realizzazione delle quote disco ha visto diverse revisioni, con
+modifiche sia del formato delle stesse che dei nomi dei file utilizzate. Per
+questo alcune operazioni di gestione (in particolare \const{Q\_QUOTAON} e
+\const{Q\_GETFMT}) e possono fare riferimento a queste versioni, che vengono
+identificate tramite le costanti di tab.~\ref{tab:quotactl_id_format}.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}{|l|p{10cm}|}
+ \hline
+ \textbf{Identificatore} & \textbf{Descrizione} \\
+ \hline
+ \hline
+ \constd{QFMT\_VFS\_OLD}& Il vecchio (ed obsoleto) formato delle quote.\\
+ \constd{QFMT\_VFS\_V0} & La versione 0 usata dal VFS di Linux, supporta
+ \ids{UID} e \ids{GID} a 32 bit e limiti fino a
+ $2^{42}$ byte e $2^{32}$ file.\\
+ \constd{QFMT\_VFS\_V1} & La versione 1 usata dal VFS di Linux, supporta
+ \ids{UID} e \ids{GID} a 32 bit e limiti fino a
+ $2^{64}$ byte e $2^{64}$ file.\\
+ \hline
+ \end{tabular}
+ \caption{Valori di identificazione del formato delle quote.}
+ \label{tab:quotactl_id_format}
+\end{table}
+
+Altre due operazioni che necessitano di ulteriori spiegazioni sono
+\const{Q\_GETINFO} e \const{Q\_SETINFO}, che consentono di ottenere i dati
+relativi alle impostazioni delle altre proprietà delle quote, che al momento
+sono solo la durata del \textit{grace time} per i due tipi di limiti. Queste
+sono due proprietà generali identiche per tutti gli utenti (e i gruppi), per
+cui viene usata una operazione distinta dalle precedenti. Anche in questo caso
+le due operazioni richiedono l'uso di una apposita struttura \struct{dqinfo},
+la cui definizione è riportata in fig.~\ref{fig:dqinfo_struct}.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{0.8\textwidth}
+ \includestruct{listati/dqinfo.h}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{dqinfo} per i dati delle quote disco.}
+ \label{fig:dqinfo_struct}
+\end{figure}
+
+Come per \struct{dqblk} anche in questo caso viene usato un campo della
+struttura, \val{dqi\_valid} come maschera binaria per dichiarare quale degli
+altri campi sono validi; le costanti usate per comporre questo valore sono
+riportate in tab.~\ref{tab:quotactl_iif_const} dove si è riportato il
+significato di ciascuna di esse ed i campi a cui fanno riferimento.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}{|l|l|}
+ \hline
+ \textbf{Costante} & \textbf{Descrizione} \\
+ \hline
+ \hline
+ \constd{IIF\_BGRACE}& Il \textit{grace period} per i blocchi
+ (\val{dqi\_bgrace}).\\
+ \constd{IIF\_IGRACE}& Il \textit{grace period} per gli \textit{inode}
+ (\val{dqi\_igrace}).\\
+ \constd{IIF\_FLAGS} & I flag delle quote (\val{dqi\_flags}) (inusato ?).\\
+ \constd{IIF\_ALL} & Tutti i precedenti.\\
+ \hline
+ \end{tabular}
+ \caption{Costanti per il campo \val{dqi\_valid} di \struct{dqinfo}.}
+ \label{tab:quotactl_iif_const}
+\end{table}
+
+Come in precedenza con \const{Q\_GETINFO} tutti i valori vengono letti
+sovrascrivendo il contenuto di \struct{dqinfo} e marcati come validi in
+\val{dqi\_valid}. In scrittura con \const{Q\_SETINFO} si può scegliere quali
+impostare, si tenga presente che i tempi dei campi \val{dqi\_bgrace} e
+\val{dqi\_igrace} devono essere specificati in secondi.
+
+Come esempi dell'uso di \func{quotactl} utilizzeremo estratti del codice di un
+modulo Python usato per fornire una interfaccia diretta a \func{quotactl}
+senza dover passare dalla scansione dei risultati di un comando. Il modulo si
+trova fra i pacchetti Debian messi a disposizione da Truelite Srl,
+all'indirizzo \url{http://labs.truelite.it/projects/packages}.\footnote{in
+ particolare il codice C del modulo è nel file \texttt{quotamodule.c}
+ visionabile a partire dall'indirizzo indicato nella sezione
+ \textit{Repository}.}
+
+\begin{figure}[!htbp]
+ \footnotesize \centering
+ \begin{minipage}[c]{\codesamplewidth}
+ \includecodesample{listati/get_quota.c}
+ \end{minipage}
+ \caption{Esempio di codice per ottenere i dati delle quote.}
+ \label{fig:get_quota}
+\end{figure}
+
+Il primo esempio, riportato in fig.~\ref{fig:get_quota}, riporta il codice
+della funzione che consente di leggere le quote. La funzione fa uso
+dell'interfaccia dal C verso Python, che definisce i vari simboli \texttt{Py*}
+(tipi di dato e funzioni). Non staremo ad approfondire i dettagli di questa
+interfaccia, per la quale esistono numerose trattazioni dettagliate, ci
+interessa solo esaminare l'uso di \func{quotactl}.
+
+In questo caso la funzione prende come argomenti (\texttt{\small 1}) l'intero
+\texttt{who} che indica se si vuole operare sulle quote utente o gruppo,
+l'identificatore \texttt{id} dell'utente o del gruppo scelto, ed il nome del
+file di dispositivo del filesystem su cui si sono attivate le
+quote.\footnote{questi vengono passati come argomenti dalle funzioni mappate
+ come interfaccia pubblica del modulo (una per gruppi ed una per gli utenti)
+ che si incaricano di decodificare i dati passati da una chiamata nel codice
+ Python.} Questi argomenti vengono passati direttamente alla chiamata a
+\func{quotactl} (\texttt{\small 5}), a parte \texttt{who} che viene abbinato
+con \macro{QCMD} al comando \const{Q\_GETQUOTA} per ottenere i dati.
+
+La funzione viene eseguita all'interno di un condizionale (\texttt{\small
+ 5-16}) che in caso di successo provvede a costruire (\texttt{\small 6-12})
+opportunamente una risposta restituendo tramite la opportuna funzione di
+interfaccia un oggetto Python contenente i dati della struttura \struct{dqblk}
+relativi a uso corrente e limiti sia per i blocchi che per gli
+\textit{inode}. In caso di errore (\texttt{\small 13-15}) si usa un'altra
+funzione dell'interfaccia per passare il valore di \var{errno} come eccezione.
+
+\begin{figure}[!htbp]
+ \footnotesize \centering
+ \begin{minipage}[c]{\codesamplewidth}
+ \includecodesample{listati/set_block_quota.c}
+ \end{minipage}
+ \caption{Esempio di codice per impostare i limiti sullo spazio disco.}
+ \label{fig:set_block_quota}
+\end{figure}
+
+Per impostare i limiti sullo spazio disco si potrà usare una seconda funzione,
+riportata in fig.~\ref{fig:set_block_quota}, che prende gli stessi argomenti
+della precedente, con lo stesso significato, a cui si aggiungono i valori per
+il \textit{soft limit} e l'\textit{hard limit}. In questo caso occorrerà,
+prima di chiamare \func{quotactl}, inizializzare opportunamente
+(\texttt{\small 5-7}) i campi della struttura \struct{dqblk} che si vogliono
+utilizzare (quelli relativi ai limiti sui blocchi) e specificare gli stessi
+con \const{QIF\_BLIMITS} in \var{dq.dqb\_valid}.
+
+Fatto questo la chiamata a \func{quotactl}, stavolta con il comando
+\const{Q\_SETQUOTA}, viene eseguita come in precedenza all'interno di un
+condizionale (\texttt{\small 9-14}). In questo caso non essendovi da
+restituire nessun dato in caso di successo si usa (\texttt{\small 10}) una
+apposita funzione di uscita, mentre si restituisce come prima una eccezione
+con il valore di \var{errno} in caso di errore (\texttt{\small 12-13}).
+
+
+\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 (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 misure potranno essere comunque
+rimosse (nei casi elencati nella precedente nota si potrà sempre rimontare il
+sistema in lettura-scrittura, o togliere l'attributo 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 risolvere questo problema sono possibili varie soluzioni ed ad esempio dai
+kernel 2.5 è stata introdotta la struttura dei
+\itindex{Linux~Security~Modules} \textit{Linux Security Modules} che han
+permesso di aggiungere varie forme di \itindex{Mandatory~Access~Control~(DAC)}
+\textit{Mandatory Access Control} (MAC), in cui si potessero parcellizzare e
+controllare nei minimi dettagli tutti i privilegi e le modalità in cui questi
+possono essere usati dai programmi e trasferiti agli utenti, con la creazione
+di varie estensioni (come \textit{SELinux}, \textit{Smack}, \textit{Tomoyo},
+\textit{AppArmor}) che consentono di superare l'architettura tradizionale dei
+permessi basati sul modello classico del controllo di accesso chiamato
+\itindex{Discrectionary~Access~Control~(DAC)} \textit{Discrectionary Access
+ Control} (DAC).
+
+Ma già in precedenza, a partire dai kernel della serie 2.2, era 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 situazione
+originaria di ``\textsl{tutto o nulla}''.
+
+\itindbeg{file~capabilities}
+
+Il meccanismo completo delle \textit{capabilities} (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à, chiamata \textit{file capabilities}, è 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 per ottenere limitazioni delle capacità
+dell'amministratore a livello di sistema operativo, come \textit{SELinux}.
+
+Con questo supporto e con le ulteriori modifiche introdotte con il kernel
+2.6.25 il meccanismo delle \textit{capabilities} è stato totalmente
+rivoluzionato, rendendolo più aderente alle intenzioni originali dello
+standard POSIX, rimuovendo il significato che fino ad allora aveva avuto la
+capacità \const{CAP\_SETPCAP} e cambiando le modalità di funzionamento del
+cosiddetto \textit{capabilities bounding set}. Ulteriori modifiche sono state
+apportate con il kernel 2.6.26 per consentire la rimozione non ripristinabile
+dei privilegi di amministratore. Questo fa sì che il significato ed il
+comportamento del kernel finisca per dipendere dalla versione dello stesso e
+dal fatto che le nuove \textit{file capabilities} siano abilitate o meno. Per
+capire meglio la situazione e cosa è cambiato conviene allora spiegare con
+maggiori dettagli come funziona il meccanismo delle \textit{capabilities}.
+
+Il primo passo per frazionare i privilegi garantiti all'amministratore,
+supportato fin dalla introduzione iniziale del kernel 2.2, è stato quello in
+cui a ciascun processo sono stati associati tre distinti insiemi di
+\textit{capabilities}, denominati rispettivamente \textit{permitted},
+\textit{inheritable} ed \textit{effective}. 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
+ \texttt{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 era, fino al kernel 2.6.25 definito come
+ intero a 32 bit per un massimo di 32 \textit{capabilities} distinte,
+ attualmente è stato aggiornato ad un vettore in grado di mantenerne fino a
+ 64.} 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, che è rimasto sostanzialmente
+lo stesso anche dopo le modifiche seguite alla introduzione delle
+\textit{file capabilities} è il seguente:
+\begin{basedescript}{\desclabelwidth{2.1cm}\desclabelstyle{\nextlinelabel}}
+\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} o come
+ \textsl{ereditabili}. Se un processo cancella una capacità da questo insieme
+ non potrà più riassumerla.\footnote{questo nei casi ordinari, sono
+ previste però una serie di eccezioni, dipendenti anche dal tipo di
+ supporto, che vedremo meglio in seguito dato il notevole intreccio nella
+ casistica.}
+\item[\textit{inheritable}] l'insieme delle \textit{capabilities}
+ ``\textsl{ereditabili}'', cioè di quelle che verranno trasmesse come insieme
+ delle \textsl{permesse} ad un nuovo programma eseguito attraverso una
+ chiamata ad \func{exec}.
+\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.
+\label{sec:capabilities_set}
+\end{basedescript}
+
+Con l'introduzione delle \textit{file capabilities} sono stati introdotti
+altri tre insiemi associabili a ciascun file.\footnote{la realizzazione viene
+ eseguita con l'uso di uno specifico attributo esteso,
+ \texttt{security.capability}, la cui modifica è riservata, (come illustrato
+ in sez.~\ref{sec:file_xattr}) ai processi dotato della capacità
+ \const{CAP\_SYS\_ADMIN}.} Le \textit{file capabilities} hanno effetto
+soltanto quando il file che le porta viene eseguito come programma con una
+\func{exec}, e forniscono un meccanismo che consente l'esecuzione dello stesso
+con maggiori privilegi; in sostanza sono una sorta di estensione del
+\acr{suid} bit limitato ai privilegi di amministratore. Anche questi tre
+insiemi sono identificati con gli stessi nomi di quello dei processi, ma il
+loro significato è diverso:
+\begin{basedescript}{\desclabelwidth{2.1cm}\desclabelstyle{\nextlinelabel}}
+\item[\textit{permitted}] (chiamato originariamente \textit{forced}) l'insieme
+ delle capacità che con l'esecuzione del programma verranno aggiunte alle
+ capacità \textsl{permesse} del processo.
+\item[\textit{inheritable}] (chiamato originariamente \textit{allowed})
+ l'insieme delle capacità che con l'esecuzione del programma possono essere
+ ereditate dal processo originario (che cioè non vengono tolte
+ dall'\textit{inheritable set} del processo originale all'esecuzione di
+ \func{exec}).
+\item[\textit{effective}] in questo caso non si tratta di un insieme ma di un
+ unico valore logico; se attivo all'esecuzione del programma tutte le
+ capacità che risulterebbero \textsl{permesse} verranno pure attivate,
+ inserendole automaticamente nelle \textsl{effettive}, se disattivato nessuna
+ capacità verrà attivata (cioè l'\textit{effective set} resterà vuoto).
+\end{basedescript}
+
+\itindbeg{capabilities~bounding~set}
+
+Infine come accennato, esiste un ulteriore insieme, chiamato
+\textit{capabilities bounding set}, il cui scopo è quello di costituire un
+limite alle capacità che possono essere attivate per un programma. Il suo
+funzionamento però è stato notevolmente modificato con l'introduzione delle
+\textit{file capabilities} e si deve pertanto prendere in considerazione una
+casistica assai complessa.
+
+Per i kernel fino al 2.6.25, o se non si attiva il supporto per le
+\textit{file capabilities}, il \textit{capabilities bounding set} è un
+parametro generale di sistema, il cui valore viene riportato nel file
+\sysctlfiled{kernel/cap-bound}. Il suo valore iniziale è definito in sede di
+compilazione del kernel, e da sempre ha previsto come default la presenza di
+tutte le \textit{capabilities} eccetto \const{CAP\_SETPCAP}. In questa
+situazione solo il primo processo eseguito nel sistema (quello con
+\textsl{pid} 1, di norma \texttt{/sbin/init}) ha la possibilità di
+modificarlo; ogni processo eseguito successivamente, se dotato dei privilegi
+di amministratore, è in grado soltanto di rimuovere una delle
+\textit{capabilities} già presenti dell'insieme.\footnote{per essere precisi
+ occorre la capacità \const{CAP\_SYS\_MODULE}.}
+
+In questo caso l'effetto complessivo del \textit{capabilities bounding set} è
+che solo le capacità in esso presenti possono essere trasmesse ad un altro
+programma attraverso una \func{exec}. Questo in sostanza significa che se un
+qualunque programma elimina da esso una capacità, considerato che
+\texttt{init} (almeno nelle versioni ordinarie) non supporta la reimpostazione
+del \textit{bounding set}, questa non sarà più disponibile per nessun processo
+a meno di un riavvio, eliminando così in forma definitiva quella capacità per
+tutti, compreso l'amministratore.\footnote{la qual cosa, visto il default
+ usato per il \textit{capabilities bounding set}, significa anche che
+ \const{CAP\_SETPCAP} non è stata praticamente mai usata nella sua forma
+ originale.}
+
+Con il kernel 2.6.25 e le \textit{file capabilities} il \textit{bounding set}
+è diventato una proprietà di ciascun processo, che viene propagata invariata
+sia attraverso una \func{fork} che una \func{exec}. In questo caso il file
+\sysctlfile{kernel/cap-bound} non esiste e \texttt{init} non ha nessun
+ruolo speciale, inoltre in questo caso all'avvio il valore iniziale prevede la
+presenza di tutte le capacità (compresa \const{CAP\_SETPCAP}).
+
+Con questo nuovo meccanismo il \textit{bounding set} continua a ricoprire un
+ruolo analogo al precedente nel passaggio attraverso una \func{exec}, come
+limite alle capacità che possono essere aggiunte al processo in quanto
+presenti nel \textit{permitted set} del programma messo in esecuzione, in
+sostanza il nuovo programma eseguito potrà ricevere una capacità presente nel
+suo \textit{permitted set} (quello del file) solo se questa è anche nel
+\textit{bounding set} (del processo). In questo modo si possono rimuovere
+definitivamente certe capacità da un processo, anche qualora questo dovesse
+eseguire un programma privilegiato che prevede di riassegnarle.
+
+Si tenga presente però che in questo caso il \textit{bounding set} blocca
+esclusivamente le capacità indicate nel \textit{permitted set} del programma
+che verrebbero attivate in caso di esecuzione, e non quelle eventualmente già
+presenti nell'\textit{inheritable set} del processo (ad esempio perché
+presenti prima di averle rimosse dal \textit{bounding set}). In questo caso
+eseguendo un programma che abbia anche lui dette capacità nel suo
+\textit{inheritable set} queste verrebbero assegnate.
+
+In questa seconda versione inoltre il \textit{bounding set} costituisce anche
+un limite per le capacità che possono essere aggiunte all'\textit{inheritable
+ set} del processo stesso con \func{capset}, sempre nel senso che queste
+devono essere presenti nel \textit{bounding set} oltre che nel
+\textit{permitted set} del processo. Questo limite vale anche per processi con
+i privilegi di amministratore,\footnote{si tratta sempre di avere la
+ \textit{capability} \const{CAP\_SETPCAP}.} per i quali invece non vale la
+condizione che le \textit{capabilities} da aggiungere nell'\textit{inheritable
+ set} debbano essere presenti nel proprio \textit{permitted set}.\footnote{lo
+ scopo anche in questo caso è ottenere una rimozione definitiva della
+ possibilità di passare una capacità rimossa dal \textit{bounding set}.}
+
+Come si può notare per fare ricorso alle \textit{capabilities} occorre
+comunque farsi carico di una notevole complessità di gestione, aggravata dalla
+presenza di una radicale modifica del loro funzionamento con l'introduzione
+delle \textit{file capabilities}. Considerato che il meccanismo originale era
+incompleto e decisamente problematico nel caso di programmi che non ne
+sapessero tener conto,\footnote{c'è stato un grosso problema di sicurezza con
+ \texttt{sendmail}, riuscendo a rimuovere \const{CAP\_SETGID}
+ dall'\textit{inheritable set} di un processo si ottenne di far fallire
+ \func{setuid} in maniera inaspettata per il programma (che aspettandosi
+ sempre il successo della funzione non ne controllava lo stato di uscita) con
+ la conseguenza di effettuare come amministratore operazioni che altrimenti
+ sarebbero state eseguite, senza poter apportare danni, da utente normale.}
+ci soffermeremo solo sulla implementazione completa presente a partire dal
+kernel 2.6.25, tralasciando ulteriori dettagli riguardo la versione
+precedente.
+
+Riassumendo le regole finora illustrate tutte le \textit{capabilities} vengono
+ereditate senza modifiche attraverso una \func{fork} mentre, indicati con
+\texttt{orig\_*} i valori degli insiemi del processo chiamante, con
+\texttt{file\_*} quelli del file eseguito e con \texttt{bound\_set} il
+\textit{capabilities bounding set}, dopo l'invocazione di \func{exec} il
+processo otterrà dei nuovi insiemi di capacità \texttt{new\_*} secondo la
+formula espressa dal seguente pseudo-codice C:
+
+\includecodesnip{listati/cap-results.c}
+
+% \begin{figure}[!htbp]
+% \footnotesize \centering
+% \begin{minipage}[c]{12cm}
+% \includecodesnip{listati/cap-results.c}
+% \end{minipage}
+% \caption{Espressione della modifica delle \textit{capabilities} attraverso
+% una \func{exec}.}
+% \label{fig:cap_across_exec}
+% \end{figure}
+
+\noindent e si noti come in particolare il \textit{capabilities bounding set}
+non venga comunque modificato e resti lo stesso sia attraverso una \func{fork}
+che attraverso una \func{exec}.
+
+
+\itindend{capabilities~bounding~set}
+
+A queste regole se ne aggiungono delle altre che servono a riprodurre il
+comportamento tradizionale di un sistema unix-like in tutta una serie di
+circostanze. La prima di queste è relativa a quello che avviene quando si
+esegue un file senza \textit{capabilities}; se infatti si considerasse questo
+equivalente al non averne assegnata alcuna, non essendo presenti capacità né
+nel \textit{permitted set} né nell'\textit{inheritable set} del file,
+nell'esecuzione di un qualunque programma l'amministratore perderebbe tutti i
+privilegi originali dal processo.
+
+Per questo motivo se un programma senza \textit{capabilities} assegnate viene
+eseguito da un processo con \ids{UID} reale 0, esso verrà trattato come
+se tanto il \textit{permitted set} che l'\textit{inheritable set} fossero con
+tutte le \textit{capabilities} abilitate, con l'\textit{effective set} attivo,
+col risultato di fornire comunque al processo tutte le capacità presenti nel
+proprio \textit{bounding set}. Lo stesso avviene quando l'eseguibile ha attivo
+il \acr{suid} bit ed appartiene all'amministratore, in entrambi i casi si
+riesce così a riottenere il comportamento classico di un sistema unix-like.
+
+Una seconda circostanza è quella relativa a cosa succede alle
+\textit{capabilities} di un processo nelle possibili transizioni da \ids{UID}
+nullo a \ids{UID} non nullo o viceversa (corrispondenti rispettivamente a
+cedere o riottenere i i privilegi di amministratore) che si possono effettuare
+con le varie funzioni viste in sez.~\ref{sec:proc_setuid}. In questo caso la
+casistica è di nuovo alquanto complessa, considerata anche la presenza dei
+diversi gruppi di identificatori illustrati in tab.~\ref{tab:proc_uid_gid}, si
+avrà allora che:
+\begin{enumerate*}
+\item se si passa da \ids{UID} effettivo nullo a non nullo
+ l'\textit{effective set} del processo viene totalmente azzerato, se
+ viceversa si passa da \ids{UID} effettivo non nullo a nullo il
+ \textit{permitted set} viene copiato nell'\textit{effective set};
+\item se si passa da \textit{file system} \ids{UID} nullo a non nullo verranno
+ cancellate dall'\textit{effective set} del processo tutte le capacità
+ attinenti i file, e cioè \const{CAP\_LINUX\_IMMUTABLE}, \const{CAP\_MKNOD},
+ \const{CAP\_DAC\_OVERRIDE}, \const{CAP\_DAC\_READ\_SEARCH},
+ \const{CAP\_MAC\_OVERRIDE}, \const{CAP\_CHOWN}, \const{CAP\_FSETID} e
+ \const{CAP\_FOWNER} (le prime due a partire dal kernel 2.2.30), nella
+ transizione inversa verranno invece inserite nell'\textit{effective set}
+ quelle capacità della precedente lista che sono presenti nel suo
+ \textit{permitted set}.
+\item se come risultato di una transizione riguardante gli identificativi dei
+ gruppi \textit{real}, \textit{saved} ed \textit{effective} in cui si passa
+ da una situazione in cui uno di questi era nullo ad una in cui sono tutti
+ non nulli,\footnote{in sostanza questo è il caso di quando si chiama
+ \func{setuid} per rimuovere definitivamente i privilegi di amministratore
+ da un processo.} verranno azzerati completamente sia il \textit{permitted
+ set} che l'\textit{effective set}.
+\end{enumerate*}
+\label{sec:capability-uid-transition}
+
+La combinazione di tutte queste regole consente di riprodurre il comportamento
+ordinario di un sistema di tipo Unix tradizionale, ma può risultare
+problematica qualora si voglia passare ad una configurazione di sistema
+totalmente basata sull'applicazione delle \textit{capabilities}; in tal caso
+infatti basta ad esempio eseguire un programma con \acr{suid} bit di proprietà
+dell'amministratore per far riottenere ad un processo tutte le capacità
+presenti nel suo \textit{bounding set}, anche se si era avuta la cura di
+cancellarle dal \textit{permitted set}.
+
+\itindbeg{securebits}
+
+Per questo motivo a partire dal kernel 2.6.26, se le \textit{file
+ capabilities} sono abilitate, ad ogni processo viene stata associata una
+ulteriore maschera binaria, chiamata \textit{securebits flags}, su cui sono
+mantenuti una serie di flag (vedi tab.~\ref{tab:securebits_values}) il cui
+valore consente di modificare queste regole speciali che si applicano ai
+processi con \ids{UID} nullo. La maschera viene sempre mantenuta
+attraverso una \func{fork}, mentre attraverso una \func{exec} viene sempre
+cancellato il flag \const{SECURE\_KEEP\_CAPS}.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}{|l|p{10cm}|}
+ \hline
+ \textbf{Flag} & \textbf{Descrizione} \\
+ \hline
+ \hline
+ \constd{SECURE\_KEEP\_CAPS}&Il processo non subisce la cancellazione delle
+ sue \textit{capabilities} quando tutti i suoi
+ \ids{UID} passano ad un valore non
+ nullo (regola di compatibilità per il cambio
+ di \ids{UID} n.~3 del precedente
+ elenco), sostituisce il precedente uso
+ dell'operazione \const{PR\_SET\_KEEPCAPS} di
+ \func{prctl}.\\
+ \constd{SECURE\_NO\_SETUID\_FIXUP}&Il processo non subisce le modifiche
+ delle sue \textit{capabilities} nel passaggio
+ da nullo a non nullo degli \ids{UID}
+ dei gruppi \textit{effective} e
+ \textit{file system} (regole di compatibilità
+ per il cambio di \ids{UID} nn.~1 e 2 del
+ precedente elenco).\\
+ \constd{SECURE\_NOROOT} & Il processo non assume nessuna capacità
+ aggiuntiva quando esegue un programma, anche
+ se ha \ids{UID} nullo o il programma ha
+ il \acr{suid} bit attivo ed appartiene
+ all'amministratore (regola di compatibilità
+ per l'esecuzione di programmi senza
+ \textit{capabilities}).\\
+ \hline
+ \end{tabular}
+ \caption{Costanti identificative dei flag che compongono la maschera dei
+ \textit{securebits}.}
+ \label{tab:securebits_values}
+\end{table}
+
+A ciascuno dei flag di tab.~\ref{tab:securebits_values} è inoltre abbinato un
+corrispondente flag di blocco, identificato da una costante omonima con
+l'estensione \texttt{\_LOCKED}, la cui attivazione è irreversibile ed ha
+l'effetto di rendere permanente l'impostazione corrente del corrispondente
+flag ordinario; in sostanza con \constd{SECURE\_KEEP\_CAPS\_LOCKED} si rende
+non più modificabile \const{SECURE\_KEEP\_CAPS}, ed analogamente avviene con
+\constd{SECURE\_NO\_SETUID\_FIXUP\_LOCKED} per
+\const{SECURE\_NO\_SETUID\_FIXUP} e con \constd{SECURE\_NOROOT\_LOCKED} per
+\const{SECURE\_NOROOT}.
+
+Per l'impostazione di questi flag sono state predisposte due specifiche
+operazioni di \func{prctl} (vedi sez.~\ref{sec:process_prctl}),
+\const{PR\_GET\_SECUREBITS}, che consente di ottenerne il valore, e
+\const{PR\_SET\_SECUREBITS}, che consente di modificarne il valore; per
+quest'ultima sono comunque necessari i privilegi di amministratore ed in
+particolare la capacità \const{CAP\_SETPCAP}. Prima dell'introduzione dei
+\textit{securebits} era comunque possibile ottenere lo stesso effetto di
+\const{SECURE\_KEEP\_CAPS} attraverso l'uso di un'altra operazione di
+\func{prctl}, \const{PR\_SET\_KEEPCAPS}.
+
+\itindend{securebits}
+
+Oltre alla gestione dei \textit{securebits} la nuova versione delle
+\textit{file capabilities} prevede l'uso di \func{prctl} anche per la gestione
+del \textit{capabilities bounding set}, attraverso altre due operazioni
+dedicate, \const{PR\_CAPBSET\_READ} per controllarne il valore e
+\const{PR\_CAPBSET\_DROP} per modificarlo; quest'ultima di nuovo è una
+operazione privilegiata che richiede la capacità \const{CAP\_SETPCAP} e che,
+come indica chiaramente il nome, permette solo la rimozione di una
+\textit{capability} dall'insieme; per i dettagli sull'uso di tutte queste
+operazioni si rimanda alla rilettura di sez.~\ref{sec:process_prctl}.
+
+\itindend{file~capabilities}
+
+
+% NOTE per dati relativi al process capability bounding set, vedi:
+% http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3b7391de67da515c91f48aa371de77cb6cc5c07e
+
+% NOTE riferimenti ai vari cambiamenti vedi:
+% http://lwn.net/Articles/280279/
+% http://lwn.net/Articles/256519/
+% http://lwn.net/Articles/211883/
+
+
+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{include/linux/capabilities.h}, è aggiornato al kernel 3.2.} 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.
+
+\begin{table}[!h!btp]
+ \centering
+ \footnotesize
+ \begin{tabular}{|l|p{10cm}|}
+ \hline
+ \textbf{Capacità}&\textbf{Descrizione}\\
+ \hline
+ \hline
+%
+% POSIX-draft defined capabilities.
+%
+ \constd{CAP\_AUDIT\_CONTROL}& Abilitare e disabilitare il
+ controllo dell'auditing (dal kernel 2.6.11).\\
+ \constd{CAP\_AUDIT\_WRITE}&Scrivere dati nel giornale di
+ auditing del kernel (dal kernel 2.6.11).\\
+ % TODO verificare questa roba dell'auditing
+ \constd{CAP\_BLOCK\_SUSPEND}&Utilizzare funzionalità che possono bloccare
+ la sospensione del sistema (dal kernel 3.5).\\
+ \constd{CAP\_CHOWN} & Cambiare proprietario e gruppo
+ proprietario di un file (vedi
+ sez.~\ref{sec:file_ownership_management}).\\
+ \constd{CAP\_DAC\_OVERRIDE}& Evitare il controllo dei
+ permessi di lettura, scrittura ed esecuzione dei
+ file, (vedi sez.~\ref{sec:file_access_control}).\\
+ \constd{CAP\_DAC\_READ\_SEARCH}& Evitare il controllo dei
+ permessi di lettura ed esecuzione per
+ le directory (vedi
+ sez.~\ref{sec:file_access_control}).\\
+ \const{CAP\_FOWNER} & 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}.\\
+ \constd{CAP\_FSETID} & Evitare la cancellazione automatica dei bit
+ \acr{suid} e \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}).\\
+ \constd{CAP\_KILL} & Mandare segnali a qualunque
+ processo (vedi sez.~\ref{sec:sig_kill_raise}).\\
+ \constd{CAP\_SETFCAP} & Impostare le \textit{capabilities} di un file
+ (dal kernel 2.6.24).\\
+ \constd{CAP\_SETGID} & 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}).\\
+ \constd{CAP\_SETUID} & 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
+ \constd{CAP\_IPC\_LOCK} & Effettuare il \textit{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}). \\
+% TODO verificare l'interazione con SHM_HUGETLB
+ \constd{CAP\_IPC\_OWNER}& Evitare il controllo dei permessi
+ per le operazioni sugli oggetti di
+ intercomunicazione fra processi (vedi
+ sez.~\ref{sec:ipc_sysv}).\\
+ \constd{CAP\_LEASE} & Creare dei \textit{file lease} (vedi
+ sez.~\ref{sec:file_asyncronous_lease})
+ pur non essendo proprietari del file (dal kernel
+ 2.4).\\
+ \constd{CAP\_LINUX\_IMMUTABLE}& Impostare sui file gli attributi
+ \textit{immutable} e \textit{append-only} (vedi
+ sez.~\ref{sec:file_perm_overview}) se
+ supportati.\\
+ \constd{CAP\_MAC\_ADMIN}& Amministrare il \textit{Mandatory
+ Access Control} di \textit{Smack} (dal kernel
+ 2.6.25).\\
+ \constd{CAP\_MAC\_OVERRIDE}& Evitare il \textit{Mandatory
+ Access Control} di \textit{Smack} (dal kernel
+ 2.6.25).\\
+ \constd{CAP\_MKNOD} & Creare file di dispositivo con \func{mknod} (vedi
+ sez.~\ref{sec:file_mknod}) (dal kernel 2.4).\\
+ \const{CAP\_NET\_ADMIN} & Eseguire alcune operazioni
+ privilegiate sulla rete.\\
+ \constd{CAP\_NET\_BIND\_SERVICE}& Porsi in ascolto su porte riservate (vedi
+ sez.~\ref{sec:TCP_func_bind}).\\
+ \constd{CAP\_NET\_BROADCAST}& Consentire l'uso di socket in
+ \textit{broadcast} e \textit{multicast}.\\
+ \constd{CAP\_NET\_RAW} & Usare socket \texttt{RAW} e \texttt{PACKET}
+ (vedi sez.~\ref{sec:sock_type}).\\
+ \const{CAP\_SETPCAP} & Effettuare modifiche privilegiate alle
+ \textit{capabilities}.\\
+ \const{CAP\_SYS\_ADMIN} & Eseguire una serie di compiti amministrativi.\\
+ \constd{CAP\_SYS\_BOOT} & Eseguire un riavvio del sistema (vedi
+ sez.~\ref{sec:sys_reboot}).\\
+ \constd{CAP\_SYS\_CHROOT}& Eseguire la funzione \func{chroot} (vedi
+ sez.~\ref{sec:file_chroot}).\\
+ \constd{CAP\_SYS\_MODULE}& Caricare e rimuovere moduli del kernel.\\
+ \const{CAP\_SYS\_NICE} & Modificare le varie priorità dei processi (vedi
+ sez.~\ref{sec:proc_priority}).\\
+ \constd{CAP\_SYS\_PACCT}& Usare le funzioni di \textit{accounting} dei
+ processi (vedi
+ sez.~\ref{sec:sys_bsd_accounting}).\\
+ \constd{CAP\_SYS\_PTRACE}& La capacità di tracciare qualunque processo con
+ \func{ptrace} (vedi
+ sez.~\ref{sec:process_ptrace}).\\
+ \constd{CAP\_SYS\_RAWIO}& Operare sulle porte di I/O con \func{ioperm} e
+ \func{iopl} (vedi
+ sez.~\ref{sec:process_io_port}).\\
+ \const{CAP\_SYS\_RESOURCE}& Superare le varie limitazioni sulle risorse.\\
+ \constd{CAP\_SYS\_TIME} & Modificare il tempo di sistema (vedi
+ sez.~\ref{sec:sys_time}).\\
+ \constd{CAP\_SYS\_TTY\_CONFIG}&Simulare un \textit{hangup} della console,
+ con la funzione \func{vhangup}.\\
+ \constd{CAP\_SYSLOG} & Gestire il buffer dei messaggi
+ del kernel, (vedi sez.~\ref{sec:sess_daemon}),
+ introdotta dal kernel 2.6.38 come capacità
+ separata da \const{CAP\_SYS\_ADMIN}.\\
+ \constd{CAP\_WAKE\_ALARM}&Usare i timer di tipo
+ \const{CLOCK\_BOOTTIME\_ALARM} e
+ \const{CLOCK\_REALTIME\_ALARM}, vedi
+ sez.~\ref{sec:sig_timer_adv} (dal kernel 3.0).\\
+ \hline
+ \end{tabular}
+ \caption{Le costanti che identificano le \textit{capabilities} presenti nel
+ kernel.}
+\label{tab:proc_capabilities}
+\end{table}
+
+\constbeg{CAP\_SETPCAP}
+
+Prima di dettagliare il significato della capacità più generiche, conviene
+però dedicare un discorso a parte a \const{CAP\_SETPCAP}, il cui significato è
+stato completamente cambiato con l'introduzione delle \textit{file
+ capabilities} nel kernel 2.6.24. In precedenza questa capacità era quella
+che permetteva al processo che la possedeva di impostare o rimuovere le
+\textit{capabilities} presenti nel suo \textit{permitted set} su un qualunque
+altro processo. In realtà questo non è mai stato l'uso inteso nelle bozze
+dallo standard POSIX, ed inoltre, come si è già accennato, dato che questa
+capacità è sempre stata assente (a meno di specifiche ricompilazioni del
+kernel) nel \textit{capabilities bounding set} usato di default, essa non è
+neanche mai stata realmente disponibile.
+
+Con l'introduzione \textit{file capabilities} e il cambiamento del significato
+del \textit{capabilities bounding set} la possibilità di modificare le
+capacità di altri processi è stata completamente rimossa, e
+\const{CAP\_SETPCAP} ha acquisito quello che avrebbe dovuto essere il suo
+significato originario, e cioè la capacità del processo di poter inserire nel
+suo \textit{inheritable set} qualunque capacità presente nel \textit{bounding
+ set}. Oltre a questo la disponibilità di \const{CAP\_SETPCAP} consente ad un
+processo di eliminare una capacità dal proprio \textit{bounding set} (con la
+conseguente impossibilità successiva di eseguire programmi con quella
+capacità), o di impostare i \textit{securebits} delle \textit{capabilities}.
+
+\constend{CAP\_SETPCAP}
+\constbeg{CAP\_FOWNER}
+
+La prima fra le capacità ``\textsl{ampie}'' che occorre dettagliare
+maggiormente è \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'\ids{UID} effettivo del
+ processo (o meglio l'\ids{UID} di filesystem, 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 dei file e delle ACL (vedi
+sez.~\ref{sec:file_xattr} e \ref{sec:file_ACL}), poter ignorare lo
+\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_close} e sez.~\ref{sec:file_fcntl_ioctl}) senza
+restrizioni.
+
+\constend{CAP\_FOWNER}
+\constbeg{CAP\_NET\_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 \textit{multicasting} (vedi sez.\ref{sec:sock_ipv4_options}), eseguire la
+configurazione delle interfacce di rete (vedi
+sez.~\ref{sec:sock_ioctl_netdevice}) ed impostare la tabella di instradamento.
+
+\constend{CAP\_NET\_ADMIN}
+\constbeg{CAP\_SYS\_ADMIN}
+
+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:filesystem_mounting}), effettuare operazioni di controllo su
+qualunque oggetto dell'IPC di SysV (vedi sez.~\ref{sec:ipc_sysv}), operare
+sugli attributi estesi dei file di classe \texttt{security} o \texttt{trusted}
+(vedi sez.~\ref{sec:file_xattr}), specificare un \ids{UID} arbitrario nella
+trasmissione delle credenziali dei socket (vedi
+sez.~\ref{sec:socket_credential_xxx}), assegnare classi privilegiate
+(\const{IOPRIO\_CLASS\_RT} e prima del kernel 2.6.25 anche
+\const{IOPRIO\_CLASS\_IDLE}) 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 \sysctlfiled{fs/file-max}.}
+effettuare operazioni privilegiate sulle chiavi mantenute dal kernel (vedi
+sez.~\ref{sec:keyctl_management}), usare la funzione \func{lookup\_dcookie},
+usare \const{CLONE\_NEWNS} con \func{unshare} e \func{clone}, (vedi
+sez.~\ref{sec:process_clone}).
+
+\constend{CAP\_SYS\_ADMIN}
+\constbeg{CAP\_SYS\_NICE}
+
+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.
+
+\constend{CAP\_SYS\_NICE}
+\constbeg{CAP\_SYS\_RESOURCE}
+
+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 di un processo (vedi sez.~\ref{sec:sys_resource_limit}) e quelle sul
+numero di processi, ed i limiti sulle dimensioni dei messaggi delle code del
+SysV IPC (vedi sez.~\ref{sec:ipc_sysv_mq}).
+
+\constend{CAP\_SYS\_RESOURCE}
+
+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 di sistema sono
+\funcd{capget} e \funcd{capset} e costituiscono l'interfaccia di gestione
+basso livello; i loro rispettivi prototipi sono:
+
+\begin{funcproto}{
+\fhead{sys/capability.h}
+\fdecl{int capget(cap\_user\_header\_t hdrp, cap\_user\_data\_t datap)}
+\fdesc{Legge le \textit{capabilities}.}
+\fdecl{int capset(cap\_user\_header\_t hdrp, const cap\_user\_data\_t datap)}
+\fdesc{Imposta le \textit{capabilities}.}
+}
+
+{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EFAULT}] si è indicato un puntatore sbagliato o nullo
+ per \param{hdrp} o \param{datap} (quest'ultimo può essere nullo solo se si
+ usa \func{capget} per ottenere la versione delle \textit{capabilities}
+ usata dal kernel).
+ \item[\errcode{EINVAL}] si è specificato un valore non valido per uno dei
+ campi di \param{hdrp}, in particolare una versione non valida della
+ versione delle \textit{capabilities}.
+ \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}.
+ \item[\errcode{ESRCH}] si è fatto riferimento ad un processo inesistente.
+ \end{errlist}
+}
+\end{funcproto}
+
+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 un certo periodo di tempo era anche
+indicato che per poterle utilizzare fosse necessario che la macro
+\macro{\_POSIX\_SOURCE} risultasse non definita (ed era richiesto di inserire
+una istruzione \texttt{\#undef \_POSIX\_SOURCE} prima di includere
+\headfiled{sys/capability.h}) requisito che non risulta più
+presente.\footnote{e non è chiaro neanche quanto sia mai stato davvero
+ necessario.}
+
+\begin{figure}[!htb]
+ \footnotesize
+ \centering
+ \begin{minipage}[c]{0.8\textwidth}
+ \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 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{viene però
+ garantito che le vecchie funzioni continuino a funzionare.} Pertanto se si
+vogliono scrivere programmi portabili che possano essere eseguiti senza
+modifiche o adeguamenti su qualunque versione del kernel è opportuno
+utilizzare le interfacce di alto livello che vedremo più avanti.
+
+La struttura a cui deve puntare l'argomento \param{hdrp} serve ad indicare,
+tramite il campo \var{pid}, il \ids{PID} del processo del quale si vogliono
+leggere o modificare le \textit{capabilities}. Con \func{capset} questo, se si
+usano le \textit{file capabilities}, può essere solo 0 o il \ids{PID} del
+processo chiamante, che sono equivalenti. Non tratteremo, essendo comunque di
+uso irrilevante, il caso in cui, in mancanza di tale supporto, la funzione può
+essere usata per modificare le \textit{capabilities} di altri processi, per il
+quale si rimanda, se interessati, alla lettura della pagina di manuale.
+
+Il campo \var{version} deve essere impostato al valore della versione delle
+stesse usata dal kernel (quello indicato da una delle costanti
+\texttt{\_LINUX\_CAPABILITY\_VERSION\_n} 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
+versione due è comunque deprecata e non deve essere usata, ed il kernel
+stamperà un avviso se lo si fa.
+
+I valori delle \textit{capabilities} devono essere passati come maschere
+binarie;\footnote{e si tenga presente che i valori di
+ tab.~\ref{tab:proc_capabilities} non possono essere combinati direttamente,
+ indicando il numero progressivo del bit associato alla relativa capacità.}
+con l'introduzione delle \textit{capabilities} a 64 bit inoltre il
+puntatore \param{datap} non può essere più considerato come relativo ad una
+singola struttura, ma ad un vettore di due strutture.\footnote{è questo cambio
+ di significato che ha portato a deprecare la versione 2, che con
+ \func{capget} poteva portare ad un buffer overflow per vecchie applicazioni
+ che continuavano a considerare \param{datap} come puntatore ad una singola
+ struttura.}
+
+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 della \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 al compilatore l'uso
+della suddetta libreria attraverso l'opzione \texttt{-lcap}.
+
+\itindbeg{capability~state}
+
+Le funzioni dell'interfaccia alle \textit{capabilities} definite nelle bozze
+dello standard POSIX.1e prevedono l'uso di un tipo di dato opaco,
+\typed{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 fanno 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 i \textit{capability state}, che presentano notevoli affinità,
+essendo parte di bozze dello stesso standard, con quelle già viste per le ACL.
+
+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{funcproto}{
+\fhead{sys/capability.h}
+\fdecl{cap\_t cap\_init(void)}
+\fdesc{Crea ed inizializza un \textit{capability state}.}
+}
+
+{La funzione ritorna un \textit{capability state} in caso di successo e
+ \val{NULL} per un errore, nel qual caso \var{errno} potrà assumere solo il
+ valore \errval{ENOMEM}. }
+\end{funcproto}
+
+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 \val{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{funcproto}{
+\fhead{sys/capability.h}
+\fdecl{int cap\_free(void *obj\_d)}
+\fdesc{Disalloca la memoria allocata per i dati delle \textit{capabilities}..}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} potrà assumere solo il valore \errval{EINVAL}.
+}
+\end{funcproto}
+
+
+La funzione permette di liberare la memoria allocata dalle altre funzioni
+della libreria sia per un \textit{capability state}, nel qual caso l'argomento
+sarà 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 sarà un dato di tipo
+\texttt{char *}. Per questo motivo l'argomento \param{obj\_d} è dichiarato
+come \texttt{void *}, per evitare la necessità di eseguire un \textit{cast},
+ma dovrà comunque corrispondere ad un puntatore ottenuto tramite le altre
+funzioni della libreria, altrimenti la funzione fallirà con un errore di
+\errval{EINVAL}.
+
+Infine si può creare una copia di un \textit{capability state} ottenuto in
+precedenza tramite la funzione \funcd{cap\_dup}, il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/capability.h}
+\fdecl{cap\_t cap\_dup(cap\_t cap\_p)}
+\fdesc{Duplica un \textit{capability state} restituendone una copia.}
+}
+
+{La funzione ritorna un \textit{capability state} in caso di successo e
+ \val{NULL} per un errore, nel qual caso \var{errno} assumerà i valori
+ \errval{ENOMEM} o \errval{EINVAL} nel loro significato generico.}
+\end{funcproto}
+
+
+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, ed alla fine
+delle operazioni si dovrà disallocare anche la copia, oltre all'originale.
+
+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{funcproto}{
+\fhead{sys/capability.h}
+\fdecl{int cap\_clear(cap\_t cap\_p)}
+\fdesc{Inizializza un \textit{capability state} cancellando tutte le
+ \textit{capabilities}.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} potrà assumere solo il valore \errval{EINVAL}.
+}
+\end{funcproto}
+
+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}.
+
+Una variante di \func{cap\_clear} è \funcd{cap\_clear\_flag} che cancella da
+un \textit{capability state} tutte le \textit{capabilities} di un certo
+insieme fra quelli elencati a pag.~\pageref{sec:capabilities_set}, il suo
+prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/capability.h}
+\fdecl{int cap\_clear\_flag(cap\_t cap\_p, cap\_flag\_t flag)}
+\fdesc{Cancella delle \textit{capabilities} da un \textit{capability state}.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} potrà assumere solo il valore \errval{EINVAL}.
+}
+\end{funcproto}
+
+La funzione richiede che si indichi quale degli insiemi si intente cancellare
+da \param{cap\_p} con l'argomento \param{flag}. Questo deve essere specificato
+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
+ \headfile{sys/capability.h}.} uno dei valori illustrati in
+tab.~\ref{tab:cap_set_identifier}.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|l|}
+ \hline
+ \textbf{Valore} & \textbf{Significato} \\
+ \hline
+ \hline
+ \constd{CAP\_EFFECTIVE} & Capacità dell'insieme \textsl{effettivo}.\\
+ \constd{CAP\_PERMITTED} & Capacità dell'insieme \textsl{permesso}.\\
+ \constd{CAP\_INHERITABLE}& Capacità dell'insieme \textsl{ereditabile}.\\
+ \hline
+ \end{tabular}
+ \caption{Valori possibili per il tipo di dato \typed{cap\_flag\_t} che
+ identifica gli insiemi delle \textit{capabilities}.}
+ \label{tab:cap_set_identifier}
+\end{table}
+
+Si possono inoltre confrontare in maniera diretta due diversi
+\textit{capability state} con la funzione \funcd{cap\_compare}; il suo
+prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/capability.h}
+\fdecl{int cap\_compare(cap\_t cap\_a, cap\_t cap\_b)}
+\fdesc{Confronta due \textit{capability state}.}
+}
+
+{La funzione ritorna $0$ se i \textit{capability state} sono identici
+ ed un valore positivo se differiscono, non sono previsti errori.}
+\end{funcproto}
+
+
+La funzione esegue un confronto fra i due \textit{capability state} passati
+come argomenti e ritorna in un valore intero il risultato, questo è nullo se
+sono identici o positivo se vi sono delle differenze. Il valore di ritorno
+della funzione consente inoltre di per ottenere ulteriori informazioni su
+quali sono gli insiemi di \textit{capabilities} che risultano differenti. Per
+questo si può infatti usare la apposita macro \macro{CAP\_DIFFERS}:
+
+{\centering
+\vspace{3pt}
+\begin{funcbox}{
+\fhead{sys/capability.h}
+\fdecl{int \macrod{CAP\_DIFFERS}(value, flag)}
+\fdesc{Controlla lo stato di eventuali differenze delle \textit{capabilities}
+ nell'insieme \texttt{flag}.}
+}
+\end{funcbox}
+}
+
+La macro richiede che si passi nell'argomento \texttt{value} il risultato
+della funzione \func{cap\_compare} e in \texttt{flag} l'indicazione (coi
+valori di tab.~\ref{tab:cap_set_identifier}) dell'insieme che si intende
+controllare; restituirà un valore diverso da zero se le differenze rilevate da
+\func{cap\_compare} sono presenti nell'insieme indicato.
+
+Per la gestione dei singoli valori delle \textit{capabilities} presenti in un
+\textit{capability state} l'interfaccia prevede due funzioni specifiche,
+\funcd{cap\_get\_flag} e \funcd{cap\_set\_flag}, che permettono
+rispettivamente di leggere o impostare il valore di una capacità all'interno
+in uno dei tre insiemi già citati; i rispettivi prototipi sono:
+
+\begin{funcproto}{
+\fhead{sys/capability.h}
+\fdecl{int cap\_get\_flag(cap\_t cap\_p, cap\_value\_t cap, cap\_flag\_t
+flag,\\
+\phantom{int cap\_get\_flag(}cap\_flag\_value\_t *value\_p)}
+\fdesc{Legge il valore di una \textit{capability}.}
+\fdecl{int cap\_set\_flag(cap\_t cap\_p, cap\_flag\_t flag, int ncap,
+ cap\_value\_t *caps, \\
+\phantom{int cap\_set\_flag(}cap\_flag\_value\_t value)}
+\fdesc{Imposta il valore di una \textit{capability}.}
+}
+
+{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} potrà assumere solo il valore \errval{EINVAL}.
+}
+\end{funcproto}
+
+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 si intende operare, sempre con i valori di
+tab.~\ref{tab:cap_set_identifier}. La capacità che si intende controllare o
+impostare invece deve essere specificata attraverso una variabile di tipo
+\typed{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} può indicare una sola capacità.\footnote{in
+ \headfile{sys/capability.h} 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}.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|l|}
+ \hline
+ \textbf{Valore} & \textbf{Significato} \\
+ \hline
+ \hline
+ \constd{CAP\_CLEAR}& La capacità non è impostata.\\
+ \constd{CAP\_SET} & La capacità è impostata.\\
+ \hline
+ \end{tabular}
+ \caption{Valori possibili per il tipo di dato \typed{cap\_flag\_value\_t} che
+ indica lo stato di una capacità.}
+ \label{tab:cap_value_type}
+\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 lo restituisce come \textit{value result argument} nella
+variabile puntata dall'argomento \param{value\_p}. Questa deve essere di tipo
+\type{cap\_flag\_value\_t} ed assumerà uno dei valori di
+tab.~\ref{tab:cap_value_type}. La funzione consente pertanto di leggere solo
+lo 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 ed
+allo stesso valore. 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 attivazione) per le capacità elencate in \param{caps} viene
+indicato dall'argomento \param{value} sempre con i valori di
+tab.~\ref{tab:cap_value_type}.
+
+Per semplificare la gestione delle \textit{capabilities} l'interfaccia prevede
+che sia possibile utilizzare anche una rappresentazione testuale del contenuto
+di un \textit{capability state} e fornisce le opportune funzioni di
+gestione;\footnote{entrambe erano previste dalla bozza dello standard
+ POSIX.1e.} la prima di queste, che consente di ottenere la rappresentazione
+testuale, è \funcd{cap\_to\_text}, il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/capability.h}
+\fdecl{char *cap\_to\_text(cap\_t caps, ssize\_t *length\_p)}
+\fdesc{Genera una visualizzazione testuale delle \textit{capabilities}.}
+}
+
+{La funzione ritorna un puntatore alla stringa con la descrizione delle
+ \textit{capabilities} in caso di successo e \val{NULL} per un errore, nel
+ qual caso \var{errno} assumerà i valori \errval{EINVAL} o \errval{ENOMEM}
+ nel loro significato generico.}
+\end{funcproto}
+
+La funzione ritorna l'indirizzo di una stringa contente la descrizione
+testuale del contenuto del \textit{capability state} \param{caps} passato come
+argomento, e, qualora l'argomento \param{length\_p} sia diverso da \val{NULL},
+restituisce come \textit{value result argument} 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}.
+
+La rappresentazione testuale, che viene usata anche dai programmi di gestione a
+riga di comando, prevede che lo stato venga rappresentato con una stringa di
+testo composta da una serie di proposizioni separate da spazi, ciascuna delle
+quali specifica una operazione da eseguire per creare lo stato finale. Nella
+rappresentazione si fa sempre conto di partire da uno stato in cui tutti gli
+insiemi sono vuoti e si provvede a impostarne i contenuti.
+
+Ciascuna proposizione è nella forma di un elenco di capacità, espresso con i
+nomi di tab.~\ref{tab:proc_capabilities} separati da virgole, seguito da un
+operatore, e dall'indicazione degli insiemi a cui l'operazione si applica. I
+nomi delle capacità possono essere scritti sia maiuscoli che minuscoli, viene
+inoltre riconosciuto il nome speciale \texttt{all} che è equivalente a
+scrivere la lista completa. Gli insiemi sono identificati dalle tre lettere
+iniziali: ``\texttt{p}'' per il \textit{permitted}, ``\texttt{i}'' per
+l'\textit{inheritable} ed ``\texttt{e}'' per l'\textit{effective} che devono
+essere sempre minuscole, e se ne può indicare più di uno.
+
+Gli operatori possibili sono solo tre: ``\texttt{+}'' che aggiunge le capacità
+elencate agli insiemi indicati, ``\texttt{-}'' che le toglie e ``\texttt{=}''
+che le assegna esattamente. I primi due richiedono che sia sempre indicato sia
+un elenco di capacità che gli insiemi a cui esse devono applicarsi, e
+rispettivamente attiveranno o disattiveranno le capacità elencate nell'insieme
+o negli insiemi specificati, ignorando tutto il resto. I due operatori possono
+anche essere combinati nella stessa proposizione, per aggiungere e togliere le
+capacità dell'elenco da insiemi diversi.
+
+L'assegnazione si applica invece su tutti gli insiemi allo stesso tempo,
+pertanto l'uso di ``\texttt{=}'' è equivalente alla cancellazione preventiva
+di tutte le capacità ed alla impostazione di quelle elencate negli insiemi
+specificati, questo significa che in genere lo si usa una sola volta
+all'inizio della stringa. In tal caso l'elenco delle capacità può non essere
+indicato e viene assunto che si stia facendo riferimento a tutte quante senza
+doverlo scrivere esplicitamente.
+
+Come esempi avremo allora che un processo non privilegiato di un utente, che
+non ha nessuna capacità attiva, avrà una rappresentazione nella forma
+``\texttt{=}'' che corrisponde al fatto che nessuna capacità viene assegnata a
+nessun insieme (vale la cancellazione preventiva), mentre un processo con
+privilegi di amministratore avrà una rappresentazione nella forma
+``\texttt{=ep}'' in cui tutte le capacità vengono assegnate agli insiemi
+\textit{permitted} ed \textit{effective} (e l'\textit{inheritable} è ignorato
+in quanto per le regole viste a pag.~\ref{sec:capability-uid-transition} le
+capacità verranno comunque attivate attraverso una \func{exec}). Infine, come
+esempio meno banale dei precedenti, otterremo per \texttt{init} una
+rappresentazione nella forma ``\texttt{=ep cap\_setpcap-e}'' dato che come
+accennato tradizionalmente \const{CAP\_SETPCAP} è sempre stata rimossa da
+detto processo.
+
+Viceversa per ottenere un \textit{capability state} dalla sua rappresentazione
+testuale si può usare la funzione \funcd{cap\_from\_text}, il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/capability.h}
+\fdecl{cap\_t cap\_from\_text(const char *string)}
+\fdesc{Crea un \textit{capability state} dalla sua rappresentazione testuale.}
+}
+
+{La funzione ritorna un \textit{capability state} in caso di successo e
+ \val{NULL} per un errore, nel qual caso \var{errno} assumerà i valori
+ \errval{EINVAL} o \errval{ENOMEM} nel loro significato generico.}
+\end{funcproto}
+
+
+La funzione restituisce il puntatore ad un \textit{capability state}
+inizializzato con i valori indicati nella stringa \param{string} che ne
+contiene la rappresentazione testuale. La memoria per il \textit{capability
+ state} viene allocata automaticamente dalla funzione e dovrà essere liberata
+con \func{cap\_free}.
+
+Alle due funzioni citate se ne aggiungono altre due che consentono di
+convertire i valori delle costanti di tab.~\ref{tab:proc_capabilities} nelle
+stringhe usate nelle rispettive rappresentazioni e viceversa. Le due funzioni,
+\funcd{cap\_to\_name} e \funcd{cap\_from\_name}, sono estensioni specifiche di
+Linux ed i rispettivi prototipi sono:
+
+\begin{funcproto}{
+\fhead{sys/capability.h}
+\fdecl{char *cap\_to\_name(cap\_value\_t cap)}
+\fdesc{Converte il valore numerico di una \textit{capabilities} alla sua
+ rappresentazione testuale.}
+\fdecl{int cap\_from\_name(const char *name, cap\_value\_t *cap\_p)}
+
+\fdesc{Converte la rappresentazione testuale di una \textit{capabilities} al
+ suo valore numerico.}
+}
+
+{La funzione \func{cap\_to\_name} ritorna un puntatore ad una stringa in caso
+ di successo e \val{NULL} per un errore, mentre \func{cap\_to\_name} ritorna
+ $0$ in caso di successo e $-1$ per un errore, per entrambe in caso di errore
+ \var{errno} assumerà i valori \errval{EINVAL} o \errval{ENOMEM} nel loro
+ significato generico.
+}
+\end{funcproto}
+
+La prima funzione restituisce la stringa (allocata automaticamente e che dovrà
+essere liberata con \func{cap\_free}) che corrisponde al valore della
+capacità \param{cap}, mentre la seconda restituisce nella variabile puntata
+da \param{cap\_p}, come \textit{value result argument}, il valore della
+capacità rappresentata dalla stringa \param{name}.
+
+Fin quei abbiamo trattato solo le funzioni di servizio relative alla
+manipolazione dei \textit{capability state} come strutture di dati;
+l'interfaccia di gestione prevede però anche le funzioni per trattare le
+\textit{capabilities} presenti nei processi. La prima di queste funzioni è
+\funcd{cap\_get\_proc} che consente la lettura delle \textit{capabilities} del
+processo corrente, il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/capability.h}
+\fdecl{cap\_t cap\_get\_proc(void)}
+\fdesc{Legge le \textit{capabilities} del processo corrente.}
+}
+
+{La funzione ritorna un \textit{capability state} in caso di successo e
+ \val{NULL} per un errore, nel qual caso \var{errno} assumerà i valori
+ \errval{EINVAL}, \errval{EPERM} o \errval{ENOMEM} nel loro significato
+ generico.}
+\end{funcproto}
+
+La funzione legge il valore delle \textit{capabilities} associate al processo
+da cui viene invocata, restituendo il risultato tramite il puntatore ad un
+\textit{capability 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{cap\_get\_pid}, 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 \headfile{sys/capability.h}.} è:
+
+\begin{funcproto}{
+\fhead{sys/capability.h}
+\fdecl{cap\_t cap\_get\_pid(pid\_t pid)}
+\fdesc{Legge le \textit{capabilities} di un processo.}
+}
+
+{La funzione ritorna un \textit{capability state} in caso di successo e
+ \val{NULL} per un errore, nel qual caso \var{errno} assumerà i valori
+ \errval{ESRCH} o \errval{ENOMEM} nel loro significato generico. }
+\end{funcproto}
+
+La funzione legge il valore delle \textit{capabilities} del processo indicato
+con l'argomento \param{pid}, e restituisce il risultato tramite il puntatore
+ad un \textit{capability state} contenente tutti i dati che provvede ad
+allocare autonomamente e che al solito deve essere disallocato con
+\func{cap\_free}. 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{Console}
+piccardi@hain:~/gapil$ \textbf{cat /proc/1/status}
+...
+CapInh: 0000000000000000
+CapPrm: 00000000fffffeff
+CapEff: 00000000fffffeff
+...
+\end{Console}
+%$
+
+\itindend{capability~state}
+
+Infine per impostare le \textit{capabilities} del processo corrente (nella
+bozza dello standard POSIX.1e 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{funcproto}{
+\fhead{sys/capability.h}
+\fdecl{int cap\_set\_proc(cap\_t cap\_p)}
+\fdesc{Imposta le \textit{capabilities} del processo corrente.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà i valori:
+ \begin{errlist}
+ \item[\errcode{EPERM}] si è cercato di attivare una capacità non permessa.
+ \end{errlist} ed inoltre \errval{EINVAL} nel suo significato generico.}
+\end{funcproto}
+
+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).
+
+Oltre a queste funzioni su Linux sono presenti due ulteriori funzioni,
+\funcm{capgetp} e \funcm{capsetp}, che svolgono un compito analogo. Queste
+funzioni risalgono alla implementazione iniziale delle \textit{capabilities}
+ed in particolare \funcm{capsetp} consentirebbe anche, come possibile in quel
+caso, di cambiare le capacità di un altro processo. Le due funzioni oggi sono
+deprecate e pertanto eviteremo di trattarle, per chi fosse interessato si
+rimanda alla lettura della loro 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 \ids{PID} viene passato come parametro dell'opzione.
+
+\begin{figure}[!htbp]
+ \footnotesize \centering
+ \begin{minipage}[c]{\codesamplewidth}
+ \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 \ids{PID} del processo di cui si vuole
+leggere le \textit{capabilities} e nulla altrimenti. Nel primo caso
+(\texttt{\small 1-6}) si utilizza (\texttt{\small 2}) \func{cap\_get\_proc}
+per ottenere lo stato delle capacità del processo, nel secondo (\texttt{\small
+ 7-13}) si usa invece \func{cap\_get\_pid} (\texttt{\small 8}) per leggere
+il valore delle capacità del processo indicato.
+
+Il passo successivo è utilizzare (\texttt{\small 15}) \func{cap\_to\_text} per
+tradurre in una stringa lo stato, e poi (\texttt{\small 16}) stamparlo; infine
+(\texttt{\small 18-19}) 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/
+
+
+
+\subsection{La gestione dei {chroot}}
+\label{sec:file_chroot}
+
+% TODO: valutare se introdurre una nuova sezione sulle funzionalità di
+% sicurezza avanzate, con dentro chroot SELinux e AppArmor, Tomoyo, Smack,
+% cgroup o altro
+
+% TODO: spostare chroot e le funzioni affini relative ai container da qualche
+% parte diversa se è il caso.
+
+% TODO Inheriting capabilities vedi http://lwn.net/Articles/632520/ eambient
+% capabilities introdotte con il kernel 4.3, vedi
+% http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=58319057b7847667f0c9585b9de0e8932b0fdb08
+
+Benché non abbia niente a che fare con permessi, utenti e gruppi, la funzione
+\func{chroot} viene usata spesso per restringere le capacità di accesso di un
+programma ad una sezione limitata del filesystem, per cui ne parleremo in
+questa sezione.
+
+Come accennato in sez.~\ref{sec:proc_fork} ogni processo oltre ad una
+directory di lavoro, ha anche una directory \textsl{radice}\footnote{entrambe
+ sono contenute in due campi (rispettivamente \var{pwd} e \var{root}) di
+ \kstruct{fs\_struct}; vedi fig.~\ref{fig:proc_task_struct}.} che, pur
+essendo di norma corrispondente alla radice dell'albero dei file dell'intero
+sistema, ha per il processo il significato specifico di directory rispetto
+alla quale vengono risolti i \textit{pathname} assoluti.\footnote{cioè quando
+ un processo chiede la risoluzione di un \textit{pathname}, il kernel usa
+ sempre questa directory come punto di partenza.} Il fatto che questo valore
+sia specificato per ogni processo apre allora la possibilità di modificare le
+modalità di risoluzione dei \textit{pathname} assoluti da parte di un processo
+cambiando questa directory, così come si fa coi \textit{pathname} relativi
+cambiando la directory di lavoro.
+
+Normalmente la directory radice di un processo coincide con la radice generica
+dell'albero dei file, che è la directory che viene montata direttamente dal
+kernel all'avvio secondo quanto illustrato in sez.~\ref{sec:file_pathname}.
+Questo avviene perché, come visto in sez.~\ref{cha:process_handling} la
+directory radice di un processo viene ereditata dal padre attraverso una
+\func{fork} e mantenuta attraverso una \func{exec}, e siccome tutti i processi
+derivano da \cmd{init}, che ha come radice quella montata dal kernel, questa
+verrà mantenuta.
+
+In certe situazioni però è utile poter impedire che un processo possa accedere
+a tutto l'albero dei file iniziale; per far questo si può cambiare la sua
+directory radice con la funzione di sistema \funcd{chroot}, il cui prototipo
+è:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{int chroot(const char *path)}
+\fdesc{Cambia la directory radice del processo.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EPERM}] non si hanno i privilegi di amministratore.
+ \end{errlist}
+ ed inoltre \errval{EFAULT}, \errval{ENAMETOOLONG}, \errval{ENOENT},
+ \errval{ENOMEM}, \errval{ENOTDIR}, \errval{EACCES}, \errval{ELOOP};
+ \errval{EROFS} e \errval{EIO} nel loro significato generico.}
+\end{funcproto}
+
+La funzione imposta la directory radice del processo a quella specificata da
+\param{path} (che ovviamente deve esistere) ed ogni \textit{pathname} assoluto
+usato dalle funzioni chiamate nel processo sarà risolto a partire da essa,
+rendendo impossibile accedere alla parte di albero sovrastante. Si ha così
+quella che viene chiamata una \textit{chroot jail}, in quanto il processo non
+può più accedere a file al di fuori della sezione di albero in cui è stato
+\textsl{imprigionato}.
+
+Solo un processo con i privilegi di amministratore può usare questa
+funzione,\footnote{più precisamente se possiede la capacità
+ \const{CAP\_SYS\_CHROOT}.} e la nuova radice, per quanto detto in
+sez.~\ref{sec:proc_fork}, sarà ereditata da tutti i suoi processi figli. Si
+tenga presente però che la funzione non cambia la directory di lavoro del
+processo, che potrebbe restare fuori dalla \textit{chroot jail}.
+
+Questo è il motivo per cui la funzione è efficace nel restringere un processo
+ad un ramo di albero solo se dopo averla eseguita si cedono i privilegi di
+amministratore. Infatti se per un qualunque motivo il processo resta con la
+sua directory di lavoro al di fuori dalla \textit{chroot jail}, potrà accedere
+a tutto il resto del filesystem usando dei \textit{pathname} relativi, dato
+che in tal caso è possibile, grazie all'uso di ``\texttt{..}'', risalire
+all'indietro fino alla radice effettiva dell'albero dei file.
+
+Potrebbe sembrare che per risolvere il problema sia sufficiente ricordarsi di
+eseguire preventivamente anche una \func{chdir} sulla directory su cui si
+andrà ad eseguire \func{chroot}, così da assicurarsi che le directory di
+lavoro sia all'interno della \textit{chroot jail}. Ma se ad un processo
+restano i privilegi di amministratore esso potrà comunque portare la sua
+directory di lavoro fuori dalla \textit{chroot jail} in cui si trova. Basterà
+infatti eseguire di nuovo \func{chroot} su una qualunque directory contenuta
+nell'attuale directory di lavoro perché quest'ultima risulti al di fuori della
+nuova \textit{chroot jail}. Per questo motivo l'uso di questa funzione non ha
+molto senso quando un processo di cui si vuole limitare l'accesso necessita
+comunque dei privilegi di amministratore per le sue normali operazioni.
+
+Nonostante queste limitazioni la funzione risulta utile qualora la si possa
+applicare correttamente cedendo completamente i privilegi di amministratore
+una volta eseguita. Ed esempio caso tipico di uso di \func{chroot} è quello
+di un server FTP anonimo in si vuole che il server veda solo i file che deve
+trasferire. In tal caso si esegue una \func{chroot} sulla directory che
+contiene i file, che il server dovrà in grado di leggere come utente
+ordinario, e poi si cedono tutti i privilegi di amministratore. Si tenga
+presente però che in casi come questo occorrerà fornire all'interno della
+\textit{chroot jail} un accesso anche a tutti i file (in genere programmi e
+librerie) di cui il server potrebbe avere bisogno.
+
+
+% LocalWords: sez like filesystem unlink MacOS Windows VMS inode kernel unistd
+% LocalWords: int const char oldpath newpath errno EXDEV EPERM st Smack SysV
+% LocalWords: EEXIST EMLINK EACCES ENAMETOOLONG ENOTDIR EFAULT ENOMEM EROFS ls
+% LocalWords: ELOOP ENOSPC EIO pathname nlink stat vfat fsck EISDIR ENOENT cap
+% LocalWords: POSIX socket fifo sticky root system call count crash init linux
+% LocalWords: descriptor remove rename rmdir stdio glibc libc NFS DT obj dup
+% LocalWords: ENOTEMPTY EBUSY mount point EINVAL soft symbolic tab symlink fig
+% LocalWords: dangling access chdir chmod chown creat exec lchown lstat mkdir
+% LocalWords: mkfifo mknod opendir pathconf readlink truncate path buff size
+% LocalWords: grub bootloader grep MAXSYMLINKS cat VFS sys dirname fcntl tv Py
+% LocalWords: dev umask IFREG IFBLK IFCHR IFIFO SVr sgid BSD SVID NULL from to
+% LocalWords: stream dirent EMFILE ENFILE dirfd SOURCE fchdir readdir struct
+% LocalWords: EBADF namlen HAVE thread entry result value argument fileno ext
+% LocalWords: name TYPE OFF RECLEN UNKNOWN REG SOCK CHR BLK type IFTODT DTTOIF
+% LocalWords: DTYPE off reclen seekdir telldir void rewinddir closedir select
+% LocalWords: namelist compar malloc qsort alphasort versionsort strcoll myls
+% LocalWords: strcmp direntry while current working home shell pwd get stddef
+% LocalWords: getcwd ERANGE getwd change fd race condition tmpnam getfacl mark
+% LocalWords: string tmpdir TMP tempnam pfx TMPNAME suid tmp EXCL tmpfile pid
+% LocalWords: EINTR mktemp mkstemp stlib template filename XXXXXX OpenBSD buf
+% LocalWords: mkdtemp fstat filedes nell'header padding ISREG ISDIR ISCHR IFMT
+% LocalWords: ISBLK ISFIFO ISLNK ISSOCK IFSOCK IFLNK IFDIR ISUID UID ISGID GID
+% LocalWords: ISVTX IRUSR IWUSR IXUSR IRGRP IWGRP IXGRP IROTH IWOTH IXOTH OLD
+% LocalWords: blocks blksize holes lseek TRUNC ftruncate ETXTBSY length QCMD
+% LocalWords: hole atime read utime mtime write ctime modification leafnode cp
+% LocalWords: make fchmod fchown utimbuf times actime modtime Mac owner uid fs
+% LocalWords: gid Control List patch mandatory control execute group other all
+% LocalWords: effective passwd IGID locking swap saved text IRWXU IRWXG subcmd
+% LocalWords: IRWXO capability FSETID mask capabilities chroot jail QUOTAOFF
+% LocalWords: FTP filter Attributes Solaris FreeBSD libacl hash at dqblk SYNC
+% LocalWords: XFS SELinux namespace attribute security trusted Draft Modules
+% LocalWords: attributes mime ADMIN FOWNER libattr lattr getxattr lgetxattr of
+% LocalWords: fgetxattr attr ssize ENOATTR ENOTSUP NUL setxattr lsetxattr list
+% LocalWords: fsetxattr flags XATTR REPLACE listxattr llistxattr flistxattr by
+% LocalWords: removexattr lremovexattr fremovexattr attributename acl GETINFO
+% LocalWords: OBJ setfacl len any prefix separator options NUMERIC IDS SMART
+% LocalWords: INDENT major number IDE Documentation makedev proc copy LNK long
+% LocalWords: euidaccess eaccess delete def tag qualifier permset calendar NOW
+% LocalWords: mutt noatime relatime strictatime atim nsec mtim ctim atimensec
+% LocalWords: mtimensec utimes timeval futimes lutimes ENOSYS futimens OMIT PR
+% LocalWords: utimensat timespec sec futimesat LIDS DAC OVERRIDE SEARCH chattr
+% LocalWords: Discrectionary KILL SETGID domain SETUID setuid setreuid SETPCAP
+% LocalWords: setresuid setfsuid IMMUTABLE immutable append only BIND SERVICE
+% LocalWords: BROADCAST broadcast multicast multicasting RAW PACKET IPC LOCK
+% LocalWords: memory mlock mlockall shmctl mmap MODULE RAWIO ioperm iopl PACCT
+% LocalWords: ptrace accounting NICE RESOURCE TTY CONFIG hangup vhangup dell'
+% LocalWords: LEASE lease SETFCAP AUDIT permitted inherited inheritable AND nn
+% LocalWords: bounding execve fork capget capset header hdrp datap ESRCH undef
+% LocalWords: version libcap lcap clear ncap caps pag capgetp CapInh CapPrm RT
+% LocalWords: fffffeff CapEff getcap scheduling lookup dqinfo SETINFO GETFMT
+% LocalWords: NEWNS unshare nice NUMA ioctl journaling close XOPEN fdopendir
+% LocalWords: btrfs mkostemp extN ReiserFS JFS Posix usrquota grpquota EDQUOT
+% LocalWords: aquota quotacheck limit grace period quotactl cmd caddr addr dqb
+% LocalWords: QUOTAON ENODEV ENOPKG ENOTBLK GETQUOTA SETQUOTA SETUSE SETQLIM
+% LocalWords: forced allowed sendmail SYSLOG WAKE ALARM CLOCK BOOTTIME dqstats
+% LocalWords: REALTIME securebits GETSTATS QFMT curspace curinodes btime itime
+% LocalWords: QIF BLIMITS bhardlimit bsoftlimit ILIMITS ihardlimit isoftlimit
+% LocalWords: INODES LIMITS USAGE valid dqi IIF BGRACE bgrace IGRACE igrace is
+% LocalWords: Python Truelite Srl quotamodule Repository who nell' dall' KEEP
+% LocalWords: SECURE KEEPCAPS prctl FIXUP NOROOT LOCKED dell'IPC dell'I IOPRIO
+% LocalWords: CAPBSET CLASS IDLE dcookie overflow DIFFERS Virtual everything
+% LocalWords: dentry register resolution cache dcache operation llseek poll ln
+% LocalWords: multiplexing fsync fasync seek block superblock gapil tex img du
+% LocalWords: second linked journaled source filesystemtype unsigned device
+% LocalWords: mountflags NODEV ENXIO dummy devfs magic MGC RDONLY NOSUID MOVE
+% LocalWords: NOEXEC SYNCHRONOUS REMOUNT MANDLOCK NODIRATIME umount MNT statfs
+% LocalWords: fstatfs fstab mntent ino bound orig new setpcap metadati sysfs
+% LocalWords: bind DIRSYNC lsattr Hierarchy FHS SHARED UNBINDABLE shared REC
+% LocalWords: subtree SILENT log unbindable BUSY EAGAIN EXPIRE DETACH NOFOLLOW
+% LocalWords: lazy encfs sshfs setfsent getfsent getfsfile getfsspec endfsent
+% LocalWords: setmntent getmntent addmntent endmntent hasmntopt such offsetof
+% LocalWords: member scan attack EOVERFLOW BITS blkcnt rdev FDCWD functions
+% LocalWords: faccessat grpid lacl AppArmor capsetp mygetfacl
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End: