+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 \textit{capabilities}}
+\label{sec:proc_capabilities}
+
+\itindbeg{capabilities}
+
+Come accennato in sez.~\ref{sec:proc_access_id} l'architettura classica della
+gestione dei privilegi in un sistema unix-like ha il sostanziale problema di
+fornire all'amministratore dei poteri troppo ampi, questo comporta che anche
+quando si siano predisposte delle misure di protezione per in essere in grado
+di difendersi dagli effetti di una eventuale compromissione del
+sistema,\footnote{come montare un filesystem in sola lettura per impedirne
+ modifiche, o marcare un file come immutabile.} una volta che questa sia
+stata effettuata e si siano ottenuti i privilegi di amministratore, queste
+potranno essere comunque rimosse.\footnote{nei casi elencati nella precedente
+ nota si potrà sempre rimontare il sistema in lettura-scrittura, o togliere
+ la marcatura di immutabilità.}
+
+Il problema consiste nel fatto che nell'architettura tradizionale di un
+sistema unix-like i controlli di accesso sono basati su un solo livello di
+separazione: per i processi normali essi sono posti in atto, mentre per i
+processi con i privilegi di amministratore essi non vengono neppure eseguiti;
+per questo motivo non era previsto alcun modo per evitare che un processo con
+diritti di amministratore non potesse eseguire certe operazioni, o per cedere
+definitivamente alcuni privilegi da un certo momento in poi.
+
+Per ovviare a tutto ciò, a partire dai kernel della serie 2.2, è stato
+introdotto un meccanismo, detto \textit{capabilities}, che consentisse di
+suddividere i vari privilegi tradizionalmente associati all'amministratore in
+un insieme di \textsl{capacità} distinte. L'idea era che queste capacità
+potessero essere abilitate e disabilitate in maniera indipendente per ciascun
+processo con privilegi di amministratore, permettendo così una granularità
+molto più fine nella distribuzione degli stessi che evitasse la originaria
+situazione di ``\textsl{tutto o nulla}''.
+
+Il meccanismo completo delle \textit{capabilities}\footnote{l'implementazione
+ si rifà ad una bozza di quello che doveva diventare lo standard POSIX.1e,
+ poi abbandonato.} prevede inoltre la possibilità di associare le stesse ai
+singoli file eseguibili, in modo da poter stabilire quali capacità possono
+essere utilizzate quando viene messo in esecuzione uno specifico programma; ma
+il supporto per questa funzionalità, 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.
+
+Inoltre il meccanismo delle \textit{capabilities} è stato ulteriormente
+perfezionato nel kernel 2.6.25 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 pesantemente 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{effective},
+\textit{permitted} ed \textit{inherited}. Questi insiemi vengono mantenuti in
+forma di tre diverse maschere binarie,\footnote{il kernel li mantiene, come i
+ vari identificatori di sez.~\ref{sec:proc_setuid}, all'interno della
+ \struct{task\_struct} di ciascun processo (vedi
+ fig.~\ref{fig:proc_task_struct}), nei tre campi \texttt{cap\_effective},
+ \texttt{cap\_inheritable}, \texttt{cap\_permitted} del tipo
+ \texttt{kernel\_cap\_t}; questo 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 è il seguente:
+\begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}}
+\item[\textit{effective}] l'insieme delle \textit{capabilities}
+ ``\textsl{effettive}'', cioè di quelle che vengono effettivamente usate dal
+ kernel quando deve eseguire il controllo di accesso per le varie operazioni
+ compiute dal processo.
+\item[\textit{permitted}] l'insieme delle \textit{capabilities}
+ ``\textsl{permesse}'', cioè l'insieme di quelle capacità che un processo
+ \textsl{può} impostare come \textsl{effettive}. Se un processo cancella una
+ capacità da questo insieme non potrà più riassumerla (almeno che non esegua
+ un programma che è \acr{suid} di root).\footnote{e neanche in questo caso se
+ vengono usate le estensioni introdotte con il kernel 2.6.26 che vedremo
+ più avanti.}
+\item[\textit{inherited}] l'insieme delle \textit{capabilities}
+ ``\textsl{ereditabili}'', cioè quelle che vengono trasmesse ad un nuovo
+ programma eseguito attraverso una chiamata ad \func{exec} (con l'eccezione
+ del caso che questo sia \acr{suid} di root).
+\label{sec:capabilities_set}
+\end{basedescript}
+
+
+Fino al kernel 2.6.25 oltre a questi tre insiemi, che sono relativi al singolo
+processo, il kernel manteneva un insieme generale valido per tutto il sistema,
+chiamato \itindex{capabilities~bounding~set} \textit{capabilities bounding
+ set}. Ogni volta che un programma viene posto in esecuzione con \func{exec}
+il contenuto degli insiemi \textit{effective} e \textit{permitted} vengono
+mascherati con un \textsl{AND} binario del contenuto corrente del
+\textit{capabilities bounding set}, così che il nuovo processo potrà disporre
+soltanto delle capacità in esso elencate.
+
+Il \textit{capabilities bounding set} era un parametro di sistema, accessibile
+attraverso il contenuto del file \procfile{/proc/sys/kernel/cap-bound}, che
+per questa sua caratteristica consentiva di impostare un limite generale alle
+capacità che possono essere accordate ai vari processi. Questo valore poteva
+essere impostato ad un valore arbitrario esclusivamente dal primo processo
+eseguito nel sistema (di norma cioè da \texttt{/sbin/init}), ogni processo
+eseguito successivamente (cioè con \textsl{pid} diverso da 1) anche se
+eseguito con privilegi di amministratore poteva soltanto rimuovere uno dei bit
+già presenti dell'insieme: questo significa che una volta rimossa una
+\textit{capability} dal \textit{capabilities bounding set} essa non sarà più
+disponibile, neanche per l'amministratore, a meno di un riavvio.
+
+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!bt]
+ \centering
+ \footnotesize
+ \begin{tabular}{|l|p{11.5cm}|}
+ \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} & Prima del 2.6.24 la capacità di impostare o
+ rimuovere le \textit{capabilities} da un
+ processo, dopo quella di impostare una capacità
+ del \textit{bounding set} nelle proprie
+ \textit{inheritable} o rimoverla dal
+ \textit{bounding set} stesso.\\
+ \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 priorità dei
+ processi.\\
+ \const{CAP\_SYS\_PACCT} & La capacità di usare le funzioni di
+ \textit{accounting} dei processi (vedi
+ sez.~\ref{sec:sys_bsd_accounting}).\\
+ \const{CAP\_SYS\_PTRACE}& La capacità di tracciare qualunque processo con
+ \func{ptrace} (vedi
+ sez.~\ref{sec:xxx_ptrace}).\\
+ \const{CAP\_SYS\_RAWIO} & La capacità di eseguire operazioni sulle porte
+ di I/O con \func{ioperm} e \func{iopl} (vedi
+ sez.~\ref{sec:file_io_port}).\\
+ \const{CAP\_SYS\_RESOURCE}& La capacità di superare le limitazioni sulle
+ risorse.\\
+ \const{CAP\_SYS\_TIME} & La capacità di modificare il tempo di sistema
+ (vedi sez.~\ref{sec:sys_time}).\\
+ \const{CAP\_SYS\_TTY\_CONFIG}& La capacità di simulare un \textit{hangup}
+ della console, con la funzione
+ \func{vhangup}.\\
+ \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).\\