+La funzione è del tutto è analoga a \funcd{acl\_set\_file} ma opera
+esclusivamente sui file identificati tramite un file descriptor. Non dovendo
+avere a che fare con directory (e con la conseguente possibilità di avere una
+ACL di default) la funzione non necessita che si specifichi il tipo di ACL,
+che sarà sempre di accesso, e prende come unico argomento, a parte il file
+descriptor, la ACL da impostare.
+
+Le funzioni viste finora operano a livello di una intera ACL, eseguendo in una
+sola volta tutte le operazioni relative a tutte le voci in essa contenuta. In
+generale è possibile modificare un singolo valore all'interno di una singola
+voce direttamente con le funzioni previste dallo standard POSIX.1e. Queste
+funzioni però sono alquanto macchinose da utilizzare per cui è molto più
+semplice operare direttamente sulla rappresentazione testuale. Questo è il
+motivo per non tratteremo nei dettagli dette funzioni, fornendone solo una
+descrizione sommaria; chi fosse interessato potrà ricorrere alle pagina di
+manuale.
+
+Se si vuole operare direttamente sui contenuti di un oggetto di tipo
+\type{acl\_t} infatti occorre fare riferimento alle singole voci tramite gli
+opportuni puntatori di tipo \type{acl\_entry\_t}, che possono essere ottenuti
+dalla funzione \funcd{acl\_get\_entry} (per una voce esistente) o dalla
+funzione \funcd{acl\_create\_entry} per una voce da aggiungere. Nel caso della
+prima funzione si potrà poi ripetere la lettura per ottenere i puntatori alle
+singole voci successive alla prima.
+
+Una volta ottenuti detti puntatori si potrà operare sui contenuti delle singole
+voci; con le funzioni \funcd{acl\_get\_tag\_type}, \funcd{acl\_get\_qualifier},
+\funcd{acl\_get\_permset} si potranno leggere rispettivamente tipo,
+qualificatore e permessi mentre con le corrispondente funzioni
+\funcd{acl\_set\_tag\_type}, \funcd{acl\_set\_qualifier},
+\funcd{acl\_set\_permset} si possono impostare i valori; in entrambi i casi
+vengono utilizzati tipi di dato ad hoc.\footnote{descritti nelle singole
+ pagine di manuale.} Si possono poi copiare i valori di una voce da una ACL
+ad un altra con \funcd{acl\_copy\_entry} o eliminare una voce da una ACL con
+\funcd{acl\_delete\_entry}.
+
+\itindend{Access~Control~List}
+
+
+\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 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 degli utenti e dei 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 abilitata
+esplicitamente, questo si fa tramite due distinte opzioni di montaggio,
+\texttt{usrquota} e \texttt{grpquota} che la attivano rispettivamente per gli
+utenti e per i gruppi, cosa che consente di abilitare solo quelle che
+interessano veramente.
+
+Il meccanismo delle quote prevede che per ciascun filesystem che le supporta
+(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 di utenti e/o gruppi che a far
+rispettare i limiti imposti dal sistema con la generazione di un errore di
+\errval{EDQUOT} per tutte le operazioni sui file che porterebbero ad un
+superamento degli stessi.
+
+Per il mantenimento dei dati di consumo delle risorse vengono usati due file
+riservati (uno per le quote utente e l'altro per le quote gruppo) nella
+directory radice del filesytem su cui si sono attivate le quote;\footnote{la
+ cosa vale per tutti i fileystem tranne \textit{XFS} che mantiene i dati
+ internamente.} con la versione 2 del supporto delle quote, 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 i file
+vengono aggiornati soltanto se il filesystem è stato montato con il supporto
+delle quote, se si abilita questo in un secondo tempo (o se si eseguono
+operazioni sul filesystem senza averlo abilitato) i dati contenuti possono non
+corrispondere esattamente allo stato corrente del consumo delle risorse; per
+questo in genere prima di montare un filesystem su cui sono abilitate le quote
+viene utilizzato il comando \cmd{quotacheck} per verificare e aggiornare i
+dati.
+
+Le restrizioni sul consumo delle risorse prevedono due limiti, il primo viene
+detto \textit{soft limit} e può essere superato per brevi periodi di tempo, il
+secondo viene detto \textit{hard limit} non può mai essere superato. Il
+periodo di tempo per cui è possibile superare il \textit{soft limit} è detto
+``\textsl{periodo di grazia}'' (\textit{grace period}), passato questo tempo
+il passaggio del \textit{soft limit} viene trattato allo stesso modo
+dell'\textit{hard limit}. Questi limiti riguardano separatamente sia lo
+spazio disco (i blocchi) che il numero di file (gli \textit{inode}) e devono
+pertanto essere specificati per entrambe le risorse.
+
+La funzione che consente di controllare tutti i vari aspetti della gestione
+delle quote è \funcd{quotactl}, ed il suo prototipo è:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/quota.h}
+
+ \funcdecl{quotactl(int cmd, const char *special, int id, caddr\_t addr)}
+
+ Esegue una operazione di controllo sulle quote disco.
+
+ \bodydesc{La funzione restituisce $0$ in caso di successo e $-1$ in caso di
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EACCES}] il file delle quote non è un file normale.
+ \item[\errcode{EBUSY}] si è richiesto \const{Q\_QUOTAON} ma le quote sono
+ già attive.
+ \item[\errcode{EFAULT}] l'indirizzo \param{addr} non è valido.
+ \item[\errcode{EIO}] errore di lettura/scrittura sul file delle quote.
+ \item[\errcode{EMFILE}] non si può aprire il file delle quote avando
+ superato il limite sul numero di file aperti nel sistema.
+ \item[\errcode{EINVAL}] o \param{cmd} non è un comando valido,
+ o il dispositivo \param{special} non esiste.
+ \item[\errcode{ENODEV}] \param{special} non corrisponde ad un \textit{mount
+ point} attivo.
+ \item[\errcode{ENOPKG}] il kernel è stato compilato senza supporto per le
+ quote.
+ \item[\errcode{ENOTBLK}] \param{special} non è un dispositivo a blocchi.
+ \item[\errcode{EPERM}] il .
+ \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{functions}
+
+La funzione richiede che si indichi il filesystem sul quale si vuole operare
+tramite il secondo argomento \param{special} che deve indicare il nome del
+file di dispositivo ad esso associato, la funzione richiede che il filesystem
+sia montato con il supporto per le quote. Il terzo argomento \param{id}
+indica, per le operazioni che lo richiedono l'utente o il gruppo (specificati
+rispettivamente per \acr{uid} e \acr{gid}) su cui si vuole operare, infine
+l'ultimo argomento specifica l'indirizzo di una struttura dati che dipende di
+nuovo dal comando.
+
+
+Il funzionamento di \func{quotactl} è controllato dal valore del primo
+argomento, che indica l'operazione che si vuole eseguire e se la si vuole
+eseguire per le quote disco o le quote gruppo (posto che siano entrm
+
+
+
+% TODO trattare quote disco
+% vedi man quotactl
+
+
+
+
+\subsection{La gestione delle \textit{capabilities}}
+\label{sec:proc_capabilities}
+
+\itindbeg{capabilities}
+
+Come accennato in sez.~\ref{sec:proc_access_id} l'architettura classica della
+gestione dei privilegi in un sistema unix-like ha il sostanziale problema di
+fornire all'amministratore dei poteri troppo ampi, questo comporta che anche
+quando si siano predisposte delle misure di protezione per in essere in grado
+di difendersi dagli effetti di una eventuale compromissione del
+sistema,\footnote{come montare un filesystem in sola lettura per impedirne
+ modifiche, o marcare un file come immutabile.} una volta che questa sia
+stata effettuata e si siano ottenuti i privilegi di amministratore, queste
+potranno essere comunque rimosse.\footnote{nei casi elencati nella precedente
+ nota si potrà sempre rimontare il sistema in lettura-scrittura, o togliere
+ la marcatura di immutabilità.}
+
+Il problema consiste nel fatto che nell'architettura tradizionale di un
+sistema unix-like i controlli di accesso sono basati su un solo livello di
+separazione: per i processi normali essi sono posti in atto, mentre per i
+processi con i privilegi di amministratore essi non vengono neppure eseguiti;
+per questo motivo non era previsto alcun modo per evitare che un processo con
+diritti di amministratore non potesse eseguire certe operazioni, o per cedere
+definitivamente alcuni privilegi da un certo momento in poi.
+
+Per ovviare a tutto ciò, a partire dai kernel della serie 2.2, è stato
+introdotto un meccanismo, detto \textit{capabilities}, che consentisse di
+suddividere i vari privilegi tradizionalmente associati all'amministratore in
+un insieme di \textsl{capacità} distinte. L'idea era che queste capacità
+potessero essere abilitate e disabilitate in maniera indipendente per ciascun
+processo con privilegi di amministratore, permettendo così una granularità
+molto più fine nella distribuzione degli stessi che evitasse la originaria
+situazione di ``\textsl{tutto o nulla}''.
+
+Il meccanismo completo delle \textit{capabilities}\footnote{l'implementazione
+ si rifà ad una bozza di quello che doveva diventare lo standard POSIX.1e,
+ poi abbandonato.} prevede inoltre la possibilità di associare le stesse ai
+singoli file eseguibili, in modo da poter stabilire quali capacità possono
+essere utilizzate quando viene messo in esecuzione uno specifico programma
+(una sorta di \acr{suid} anch'esso parcellizzato); 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 \index{SELinux} 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 intezioni originali dello standard
+POSIX, rimovendo il significato che fino ad allora aveva avuto la capacità
+\macro{CAP\_SETPCAP} e le modalità di funzionamento del cosiddetto
+\itindex{capabilities~bounding~set} \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
+ \struct{task\_struct} di ciascun processo (vedi
+ fig.~\ref{fig:proc_task_struct}), nei tre campi \texttt{cap\_effective},
+ \texttt{cap\_inheritable}, \texttt{cap\_permitted} del tipo
+ \texttt{kernel\_cap\_t}; questo 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 instroduzione 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à
+ \macro{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 dell'uso del
+\acr{suid} di root. Anche questi tre insiemi sono identicati con gli stessi
+nomi, 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è 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} resta 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
+\procfile{/proc/sys/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, anche se eseguito con
+privilegi di amministratore,\footnote{per essere precisi occorreva la capacità
+ \const{CAP\_SYS\_MODULE}.} è in grado soltanto di rimuovere una delle
+\textit{capabilities} già presenti dell'insieme.
+
+In questo caso l'effetto 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 si 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 orginale.}
+
+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
+\procfile{/proc/sys/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} solo se questa è anche nel \textit{bounding
+ set}. In questo modo si possono rimuovere definitivamente certe capacità da
+un processo, anche qualora questo dovesse eseguire un programma
+privilegiato.
+
+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, 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 con \func{capset}, sempre nel senso che queste devono
+essere presenti nel \textit{bounding set} oltre che nel \textit{permitted set}
+del processo.
+
+\itindend{capabilities~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
+sappiano tener conto,\footnote{si ebbe un grosso problema di sicurezza con
+ \texttt{sendmail}, riuscendo a rimuovere \const{CAP\_SETGID}
+ dall'\textit{inheritable set} si ottenne di far fallire una \func{setuid},
+ in maniera inaspettata per il programma (che aspettandosi 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.
+
+
+
+Quando un programma viene messo in esecuzione\footnote{cioè quando viene
+ eseguita la \func{execve} con cui lo si lancia; in corrispondenza di una
+ \func{fork} le \textit{capabilities} non vengono modificate.} esso eredita
+(nel senso che assume negli insiemi \textit{effective} e \textit{permitted})
+le \textit{capabilities} mantenute nell'insieme \textit{inherited}, a meno che
+non sia eseguito un programma \acr{suid} di root o la \func{exec} sia stata
+eseguita da un programma con \textsl{uid} reale zero; in tal caso il programma
+ottiene tutte le \textit{capabilities} presenti nel \textit{capabilities
+ bounding set}. In questo modo si può far si che ad un processo eseguito in
+un secondo tempo possano essere trasmesse solo un insieme limitato di
+capacità, impedendogli di recuperare quelle assenti nell'insieme
+\textit{inherited}. Si tenga presente invece che attraverso una \func{fork}
+vengono mantenute le stesse capacità del processo padre.
+
+
+% TODO verificare per process capability bounding set, vedi:
+% http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3b7391de67da515c91f48aa371de77cb6cc5c07e
+
+% TODO capire cosa cambia con i patch vari, 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{linux/capabilities.h}, è
+ aggiornato al kernel 2.6.26.} la tabella è divisa in due parti, la prima
+riporta le \textit{capabilities} previste anche nella bozza dello standard
+POSIX1.e, la seconda quelle specifiche di Linux. Come si può notare dalla
+tabella alcune \textit{capabilities} attengono a singole funzionalità e sono
+molto specializzate, mentre altre hanno un campo di applicazione molto vasto,
+che è opportuno dettagliare maggiormente.
+
+\begin{table}[!h!btp]
+ \centering
+ \footnotesize
+ \begin{tabular}{|l|p{11.9cm}|}
+ \hline
+ \textbf{Capacità}&\textbf{Descrizione}\\
+ \hline
+ \hline
+%
+% POSIX-draft defined capabilities.
+%
+ \const{CAP\_AUDIT\_CONTROL}& La capacità di abilitare e disabilitare il
+ controllo dell'auditing (dal kernel 2.6.11).\\
+ \const{CAP\_AUDIT\_WRITE}&La capacità di scrivere dati nel giornale di
+ auditing del kernel (dal kernel 2.6.11).\\
+ % TODO verificare questa roba dell'auditing
+ \const{CAP\_CHOWN} & La capacità di cambiare proprietario e gruppo
+ proprietario di un file (vedi
+ sez.~\ref{sec:file_ownership_management}).\\
+ \const{CAP\_DAC\_OVERRIDE}& La capacità di evitare il controllo dei
+ permessi di lettura, scrittura ed esecuzione dei
+ file,\footnotemark (vedi
+ sez.~\ref{sec:file_access_control}).\\
+ \const{CAP\_DAC\_READ\_SEARCH}& La capacità di evitare il controllo dei
+ permessi di lettura ed esecuzione per
+ le directory (vedi
+ sez.~\ref{sec:file_access_control}).\\
+ \const{CAP\_FOWNER} & La capacità di evitare il controllo della
+ proprietà di un file per tutte
+ le operazioni privilegiate non coperte dalle
+ precedenti \const{CAP\_DAC\_OVERRIDE} e
+ \const{CAP\_DAC\_READ\_SEARCH}.\\
+ \const{CAP\_FSETID} & La capacità di evitare la cancellazione
+ automatica dei bit \itindex{suid~bit} \acr{suid}
+ e \itindex{sgid~bit} \acr{sgid} quando un file
+ per i quali sono impostati viene modificato da
+ un processo senza questa capacità e la capacità
+ di impostare il bit \acr{sgid} su un file anche
+ quando questo è relativo ad un gruppo cui non si
+ appartiene (vedi
+ sez.~\ref{sec:file_perm_management}).\\
+ \const{CAP\_KILL} & La capacità di mandare segnali a qualunque
+ processo (vedi sez.~\ref{sec:sig_kill_raise}).\\
+ \const{CAP\_SETFCAP} & La capacità di impostare le
+ \textit{capabilities} di un file (dal kernel
+ 2.6.24).\\
+ \const{CAP\_SETGID} & La capacità di manipolare i group ID dei
+ processi, sia il principale che i supplementari,
+ (vedi sez.~\ref{sec:proc_setgroups}) che quelli
+ trasmessi tramite i socket \textit{unix domain}
+ (vedi sez.~\ref{sec:unix_socket}).\\
+ \const{CAP\_SETUID} & La capacità di manipolare gli user ID del
+ processo (vedi sez.~\ref{sec:proc_setuid}) e di
+ trasmettere un user ID arbitrario nel passaggio
+ delle credenziali coi socket \textit{unix
+ domain} (vedi sez.~\ref{sec:unix_socket}).\\
+%
+% Linux specific capabilities
+%
+\hline
+ \const{CAP\_IPC\_LOCK} & La capacità di effettuare il \textit{memory
+ locking} \itindex{memory~locking} con le
+ funzioni \func{mlock}, \func{mlockall},
+ \func{shmctl}, \func{mmap} (vedi
+ sez.~\ref{sec:proc_mem_lock} e
+ sez.~\ref{sec:file_memory_map}). \\
+ \const{CAP\_IPC\_OWNER} & La capacità di evitare il controllo dei permessi
+ per le operazioni sugli oggetti di
+ intercomunicazione fra processi (vedi
+ sez.~\ref{sec:ipc_sysv}).\\
+ \const{CAP\_LEASE} & La capacità di creare dei \textit{file lease}
+ \index{file!lease} (vedi
+ sez.~\ref{sec:file_asyncronous_lease})
+ pur non essendo proprietari del file (dal kernel
+ 2.4).\\
+ \const{CAP\_LINUX\_IMMUTABLE}& La capacità di impostare sui file gli
+ attributi \textit{immutable} e
+ \itindex{append~mode} \textit{append only} (se
+ supportati).\\
+ \const{CAP\_MKNOD} & La capacità di creare
+ \index{file!di~dispositivo} file di dispositivo
+ con \func{mknod} (vedi
+ sez.~\ref{sec:file_mknod}) (dal kernel 2.4).\\
+ \const{CAP\_NET\_ADMIN} & La capacità di eseguire alcune operazioni
+ privilegiate sulla rete.\\
+ \const{CAP\_NET\_BIND\_SERVICE}& La capacità di porsi in ascolto
+ su porte riservate (vedi
+ sez.~\ref{sec:TCP_func_bind}).\\
+ \const{CAP\_NET\_BROADCAST}& La capacità di consentire l'uso di socket in
+ \itindex{broadcast} \textit{broadcast} e
+ \itindex{multicast} \textit{multicast}.\\
+ \const{CAP\_NET\_RAW} & La capacità di usare socket \texttt{RAW} e
+ \texttt{PACKET} (vedi sez.~\ref{sec:sock_type}).\\
+ \const{CAP\_SETPCAP} & La capacità di modifiche privilegiate alle
+ \textit{capabilities}.\\
+ \const{CAP\_SYS\_ADMIN} & La capacità di eseguire una serie di compiti
+ amministrativi. \\
+ \const{CAP\_SYS\_BOOT} & La capacità di fare eseguire un riavvio del
+ sistema.\\
+% TODO trattare reboot e kexec
+ \const{CAP\_SYS\_CHROOT}& La capacità di eseguire la funzione
+ \func{chroot} (vedi
+ sez.~\ref{sec:file_chroot}).\\
+ \const{CAP\_MAC\_ADMIN} & La capacità amministrare il \textit{Mandatory
+ Access Control} di Smack (dal kernel 2.6.25).\\
+ \const{CAP\_MAC\_OVERRIDE}& La capacità evitare il \textit{Mandatory
+ Access Control} di Smack (dal kernel 2.6.25).\\
+ \const{CAP\_SYS\_MODULE}& La capacità di caricare e rimuovere moduli del
+ kernel.\\
+ \const{CAP\_SYS\_NICE} & La capacità di modificare le varie priorità dei
+ processi.\\
+ \const{CAP\_SYS\_PACCT} & La capacità di usare le funzioni di
+ \textit{accounting} dei processi (vedi
+ sez.~\ref{sec:sys_bsd_accounting}).\\
+ \const{CAP\_SYS\_PTRACE}& La capacità di tracciare qualunque processo con
+ \func{ptrace} (vedi
+ sez.~\ref{sec:xxx_ptrace}).\\
+ \const{CAP\_SYS\_RAWIO} & La capacità di operare sulle porte
+ di I/O con \func{ioperm} e \func{iopl} (vedi
+ sez.~\ref{sec:file_io_port}).\\
+ \const{CAP\_SYS\_RESOURCE}& La capacità di superare le varie limitazioni
+ sulle risorse.\\
+ \const{CAP\_SYS\_TIME} & La capacità di modificare il tempo di sistema
+ (vedi sez.~\ref{sec:sys_time}).\\
+ \const{CAP\_SYS\_TTY\_CONFIG}& La capacità di simulare un \textit{hangup}
+ della console, con la funzione
+ \func{vhangup}.\\
+ \const{CAP\_SYSLOG} & La capacità di 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}.\\
+ \const{CAP\_WAKE\_ALARM}& La capacità di usare i timer di tipo
+ \macro{CLOCK\_BOOTTIME\_ALARM} e
+ \macro{CLOCK\_REALTIME\_ALARM}, vedi
+ sez.~\ref{sec:sig_timer_adv} (dal kernel 3.0).\\