Spostamento della sezione sulle capabilities, inizio aggiornamento
[gapil.git] / filedir.tex
index 69af64b78326fc3f3c12b57bece96847b4e7eb34..eca8d1d3be2bbdadad35813fb41b710432826314 100644 (file)
@@ -1541,9 +1541,10 @@ su un file, su un link simbolico e su un file descriptor.
 La struttura \struct{stat} usata da queste funzioni è definita nell'header
 \file{sys/stat.h} e in generale dipende dall'implementazione; la versione
 usata da Linux è mostrata in fig.~\ref{fig:file_stat_struct}, così come
 La struttura \struct{stat} usata da queste funzioni è definita nell'header
 \file{sys/stat.h} e in generale dipende dall'implementazione; la versione
 usata da Linux è mostrata in fig.~\ref{fig:file_stat_struct}, così come
-riportata dalla pagina di manuale di \func{stat} (in realtà la definizione
+riportata dalla pagina di manuale di \func{stat}in realtà la definizione
 effettivamente usata nel kernel dipende dall'architettura e ha altri campi
 effettivamente usata nel kernel dipende dall'architettura e ha altri campi
-riservati per estensioni come tempi più precisi, o per il padding dei campi).
+riservati per estensioni come tempi dei file più precisi (vedi
+sez.~\ref{sec:file_file_times}), o per il padding dei campi.
 
 \begin{figure}[!htb]
   \footnotesize
 
 \begin{figure}[!htb]
   \footnotesize
@@ -1561,8 +1562,6 @@ Si noti come i vari membri della struttura siano specificati come tipi
 primitivi del sistema (di quelli definiti in
 tab.~\ref{tab:intro_primitive_types}, e dichiarati in \file{sys/types.h}).
 
 primitivi del sistema (di quelli definiti in
 tab.~\ref{tab:intro_primitive_types}, e dichiarati in \file{sys/types.h}).
 
-% TODO: aggiornare con i cambiamenti ai tempi fatti con il 2.6
-
 \subsection{I tipi di file}
 \label{sec:file_types}
 
 \subsection{I tipi di file}
 \label{sec:file_types}
 
@@ -1940,6 +1939,17 @@ file di dispositivo, scrivendo direttamente sul disco senza passare attraverso
 il filesystem, ma ovviamente in questo modo la cosa è molto più complicata da
 realizzare.
 
 il filesystem, ma ovviamente in questo modo la cosa è molto più complicata da
 realizzare.
 
+Infine a partire dal kernel 2.6 la risoluzione dei tempi dei file, che nei
+campi di tab.~\ref{tab:file_file_times} è espressa in secondi, è stata
+portata ai nanosecondi per la gran parte dei filesystem. La ulteriore
+informazione può essere acceduta attraverso altri campi; se si sono definite
+le macro \macro{\_BSD\_SOURCE} o \macro{\_SVID\_SOURCE} questi sono
+\var{st\_atim.tv\_nsec}, \var{st\_mtim.tv\_nsec} e \var{st\_ctim.tv\_nsec} se
+queste non sono definite, \var{st\_atimensec}, \var{st\_mtimensec} e
+\var{st\_mtimensec}. Qualora il supporto per questa maggior precisione sia
+assente questi campi aggiuntivi saranno nulli.
+
+%TODO documentare utimes
 
 
 \section{Il controllo di accesso ai file}
 
 
 \section{Il controllo di accesso ai file}
@@ -2346,7 +2356,15 @@ eseguendo un programma coi privilegi di un altro utente (ad esempio attraverso
 l'uso del \itindex{suid~bit} \textit{suid bit}) che vuole controllare se
 l'utente originale ha i permessi per accedere ad un certo file.
 
 l'uso del \itindex{suid~bit} \textit{suid bit}) che vuole controllare se
 l'utente originale ha i permessi per accedere ad un certo file.
 
-% TODO documentare euidaccess (e eaccess)
+Del tutto analoghe a \func{access} sono le due funzioni \funcd{euidaccess} e
+\funcd{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à \func{eaccess} è solo un sinonimo di
+  \func{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
 
 Per cambiare i permessi di un file il sistema mette ad disposizione due
 funzioni \funcd{chmod} e \funcd{fchmod}, che operano rispettivamente su un
@@ -2712,6 +2730,737 @@ scopi di sicurezza, che sono state introdotte nelle versioni pi
 Linux.
 
 
 Linux.
 
 
+\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
+  di Linux si rifà ad una bozza per quello che dovrebbe divenire lo standard
+  POSIX.1e, che prevede questa funzionalità.} prevederebbe anche la
+possibilità di associare le stesse \textit{capabilities} anche ai singoli file
+eseguibili,\footnote{una descrizione sommaria di questa funzionalità è
+  riportata nella pagina di manuale che descrive l'implementazione delle
+  \textit{capabilities} con Linux (accessibile con \texttt{man capabilities}),
+  ma non essendo implementata non ne tratteremo qui.} in modo da poter
+stabilire quali capacità possono essere utilizzate quando viene messo in
+esecuzione uno specifico programma; attualmente però questa funzionalità non è
+implementata.\footnote{per attualmente si intende fino al kernel 2.6.23;
+  benché l'infrastruttura per crearla sia presente (vedi anche
+  sez.~\ref{sec:file_xattr}) finora non è disponibile nessuna realizzazione
+  delle specifiche POSIX.1e, esistono però dei patch di sicurezza del kernel,
+  come LIDS (vedi \href{http://www.lids.org}{\textsf{http://www.lids.org/})}
+  che realizzano qualcosa di simile.}
+
+% 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 del 2.6.26, vedi
+% http://lwn.net/Articles/280279/  
+
+\begin{table}[!h!btp]
+  \centering
+  \footnotesize
+  \begin{tabular}{|l|p{12cm}|}
+    \hline
+    \textbf{Capacità}&\textbf{Descrizione}\\
+    \hline
+    \hline
+%
+% POSIX-draft defined capabilities.
+%
+    \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, (vedi sez.~\ref{sec:file_access_control})
+                              caratteristici del modello classico del
+                              controllo di accesso chiamato
+                              \itindex{Discrectionary~Access~Control~(DAC)} 
+                              \textit{Discrectionary Access Control} (da cui
+                              il nome DAC).\\  
+    \const{CAP\_DAC\_READ\_SEARCH}& La capacità di evitare il controllo dei
+                              permessi di lettura, scrittura ed esecuzione per
+                              le directory (vedi
+                              sez.~\ref{sec:file_access_control}).\\
+    \const{CAP\_FOWNER}     & La capacità di evitare il controllo che 
+                              l'user-ID effettivo del processo (o meglio il
+                              \textit{filesystem user-ID}, vedi
+                              sez.~\ref{sec:proc_setuid}) coincida con
+                              quello del proprietario di un file per tutte
+                              le operazioni privilegiate non coperte dalle
+                              precedenti \const{CAP\_DAC\_OVERRIDE} e
+                              \const{CAP\_DAC\_READ\_SEARCH}. Queste
+                              comprendono i cambiamenti dei permessi e dei
+                              tempi del file (vedi
+                              sez.~\ref{sec:file_perm_management} e 
+                              sez.~\ref{sec:file_file_times}), le impostazioni 
+                              degli attributi estesi (con il comando 
+                              \cmd{chattr}) e delle ACL, poter ignorare lo
+                              \itindex{sticky~bit} \textit{sticky bit} nella
+                              cancellazione dei file (vedi
+                              sez.~\ref{sec:file_special_perm}), la possibilità
+                              di impostare il flag di \const{O\_NOATIME} con
+                              \func{open} e \func{fcntl} (vedi
+                              sez.~\ref{sec:file_open} e
+                              sez.~\ref{sec:file_fcntl}).\\
+    \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\_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 (con \func{setuid}, \func{setreuid},
+                              \func{setresuid}, \func{setfsuid}) e di
+                              trasmettere un valore arbitrario
+                              dell'\textsl{uid} nel passaggio delle
+                              credenziali coi socket \textit{unix domain} (vedi
+                              sez.~\ref{sec:unix_socket}).\\ 
+%
+% Linux specific capabilities
+%
+\hline
+    \const{CAP\_SETPCAP}    & La capacità di impostare o rimuovere una capacità
+                              (limitatamente a quelle che il processo
+                              chiamante ha nel suo insieme di capacità
+                              permesse) da qualunque processo.\\
+% TODO cambiata nel 2.4.24 rc1 ? 
+    \const{CAP\_LINUX\_IMMUTABLE}& La capacità di impostare gli attributi
+                              \textit{immutable} e \itindex{append~mode}
+                              \textit{append only} per i file su un
+                              filesystem che supporta questi 
+                              attributi estesi.\\ 
+    \const{CAP\_NET\_BIND\_SERVICE}& La capacità di porre in ascolto server
+                              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\_ADMIN} & La capacità di eseguire alcune operazioni
+                              privilegiate sulla rete (impostare le opzioni
+                              privilegiate dei socket, abilitare il
+                              \itindex{multicast} \textit{multicasting},
+                              impostare interfacce di rete e 
+                              tabella di instradamento).\\
+    \const{CAP\_NET\_RAW}   & La capacità di usare socket \texttt{RAW} e
+                              \texttt{PACKET} (quelli che permettono di creare
+                              pacchetti nei protocolli di basso livello).\\
+    \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\_SYS\_MODULE}& La capacità di caricare e rimuovere moduli del
+                              kernel. \\ 
+    \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\_CHROOT}& La capacità di eseguire la funzione
+                              \func{chroot} (vedi
+                              sez.~\ref{sec:file_chroot}).\\
+    \const{CAP\_SYS\_PTRACE}& Consente di tracciare qualunque processo con
+                              \func{ptrace} (vedi 
+                              sez.~\ref{sec:xxx_ptrace}).\\
+    \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\_ADMIN} & La capacità di eseguire una serie di compiti
+                              amministrativi (come impostare le quote,
+                              attivare e disattivare la swap, montare,
+                              rimontare e smontare filesystem, ecc.). \\
+    \const{CAP\_SYS\_BOOT}  & La capacità di fare eseguire un riavvio del
+                              sistema.\\
+% TODO trattare reboot e kexec 
+    \const{CAP\_SYS\_NICE}  & La capacità di modificare le priorità dei
+                              processi (vedi sez.~\ref{sec:proc_priority}). \\ 
+    \const{CAP\_SYS\_RESOURCE}& La capacità di superare le limitazioni sulle
+                              risorse, aumentare le quote disco, usare lo
+                              spazio disco riservato all'amministratore.\\ 
+    \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\_MKNOD}      & La capacità di creare file di dispositivo con la
+                              funzione \func{mknod} (vedi
+                              sez.~\ref{sec:file_mknod}).\footnotemark\\ 
+    \const{CAP\_LEASE}      & La capacità di creare dei \textit{file lease}
+                              \index{file!lease} su di un file (vedi
+                              sez.~\ref{sec:file_asyncronous_lease})
+                              indipendentemente dalla proprietà dello
+                              stesso.\footnotemark\\
+    \const{CAP\_SETFCAP}    & La capacità di impostare le
+                              \textit{capabilities} di un file (non
+                              supportata).\\ 
+    \const{CAP\_AUDIT\_WRITE}&consente la scrittura di dati nel giornale di
+                              auditing del kernel.\\ 
+    \const{CAP\_AUDIT\_CONTROL}& consente di abilitare e disabilitare il
+                              controllo dell'auditing.\footnotemark\\ 
+% TODO verificare questa roba dell'auditing
+    \hline
+  \end{tabular}
+  \caption{Le costanti che identificano le \textit{capabilities} presenti nel
+    kernel.}
+\label{tab:proc_capabilities}
+\end{table}
+
+\footnotetext[21]{questa capacità è presente soltanto a partire dai kernel
+  della serie 2.4.x.}
+
+\footnotetext[22]{questa capacità è presente soltanto a partire dai kernel della
+  serie 2.4.x.}
+
+\footnotetext{queste ultime due capacità sono presenti  soltanto a partire dai
+  kernel della serie 2.6.11.}
+
+Per gestire questo nuovo meccanismo ciascun processo porta con sé tre distinti
+insiemi di \textit{capabilities}, che vengono denominati rispettivamente
+\textit{effective}, \textit{permitted} ed \textit{inherited}. Questi insiemi
+vengono mantenuti in forma di tre diverse maschere binarie,\footnote{il kernel
+  li mantiene, come i vari identificatori di sez.~\ref{sec:proc_setuid},
+  all'interno della \struct{task\_struct} di ciascun processo (vedi
+  fig.~\ref{fig:proc_task_struct}), nei tre campi \texttt{cap\_effective},
+  \texttt{cap\_inheritable}, \texttt{cap\_permitted} del tipo
+  \texttt{kernel\_cap\_t}; questo è attualmente definito come intero a 32 bit,
+  il che comporta un massimo di 32 \textit{capabilities} distinte.} in cui
+ciascun bit corrisponde ad una capacità diversa; se ne è riportato
+l'elenco,\footnote{si tenga presente che l'elenco delle \textit{capabilities}
+  presentato questa tabella, ripreso dalla relativa pagina di manuale
+  (accessibile con \texttt{man capabilities}) e dalle definizioni in
+  \texttt{sys/capabilities.h}, è quello aggiornato al kernel 2.6.6.} con una
+breve descrizione, ed il nome delle costanti che identificano i singoli bit,
+in tab.~\ref{tab:proc_capabilities}; la tabella è divisa in due parti, la
+prima riporta le \textit{capabilities} previste nella bozza dello standard
+POSIX1.e, la seconda quelle specifiche di Linux.
+
+L'utilizzo di tre distinti insiemi serve a fornire una interfaccia flessibile
+per l'uso delle \textit{capabilities}, con scopi analoghi a quelli per cui
+sono mantenuti i diversi insiemi di identificatori di
+sez.~\ref{sec:proc_setuid}; il loro significato è il seguente:
+\begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}}
+\item[\textit{effective}] l'insieme delle \textit{capabilities}
+  ``\textsl{effettive}'', cioè di quelle che vengono effettivamente usate dal
+  kernel quando deve eseguire il controllo di accesso per le varie operazioni
+  compiute dal processo.
+\item[\textit{permitted}] l'insieme delle \textit{capabilities}
+  ``\textsl{permesse}'', cioè l'insieme di quelle capacità che un processo
+  \textsl{può} impostare come \textsl{effettive}. Se un processo cancella una
+  capacità da questo insieme non potrà più riassumerla (almeno che non esegua
+  un programma che è \acr{suid} di root).
+\item[\textit{inherited}] l'insieme delle \textit{capabilities}
+  ``\textsl{ereditabili}'', cioè quelle che vengono trasmesse ad un nuovo
+  programma eseguito attraverso una chiamata ad \func{exec} (con l'eccezione
+  del caso che questo sia \acr{suid} di root).
+\label{sec:capabilities_set}
+\end{basedescript}
+
+Oltre a questi tre insiemi, che sono relativi al singolo processo, il kernel
+mantiene un insieme generale valido per tutto il sistema, chiamato
+\itindex{capabilities~bounding~set} \textit{capabilities bounding set}. Ogni
+volta che un programma viene posto in esecuzione con \func{exec} il contenuto
+degli insiemi \textit{effective} e \textit{permitted} vengono mascherati con
+un \textsl{AND} binario del contenuto corrente del \textit{capabilities
+  bounding set}, così che il nuovo processo potrà disporre soltanto delle
+capacità in esso elencate.
+
+Il \textit{capabilities bounding set} è un parametro di sistema, accessibile
+attraverso il contenuto del file \procfile{/proc/sys/kernel/cap-bound}, che per
+questa sua caratteristica consente di impostare un limite generale alle
+capacità che possono essere accordate ai vari processi.  Questo valore può
+essere impostato ad un valore arbitrario esclusivamente dal primo processo
+eseguito nel sistema (di norma cioè da \texttt{/sbin/init}), ogni processo
+eseguito successivamente (cioè con \textsl{pid} diverso da 1) anche se
+eseguito con privilegi di amministratore potrà soltanto rimuovere uno dei bit
+già presenti dell'insieme: questo significa che una volta rimossa una
+\textit{capability} dal \textit{capabilities bounding set} essa non sarà più
+disponibile, neanche per l'amministratore, a meno di un riavvio.
+
+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.
+
+Per la gestione delle \textit{capabilities} il kernel mette a disposizione due
+funzioni che permettono rispettivamente di leggere ed impostare i valori dei
+tre insiemi illustrati in precedenza. Queste due funzioni sono \funcd{capget}
+e \funcd{capset} e costituiscono l'interfaccia di gestione basso livello; i
+loro rispettivi prototipi sono:
+\begin{functions}
+  \headdecl{sys/capability.h}
+
+  \funcdecl{int capget(cap\_user\_header\_t hdrp, cap\_user\_data\_t datap)}
+  Legge le \textit{capabilities}.
+
+  \funcdecl{int capset(cap\_user\_header\_t hdrp, const cap\_user\_data\_t
+    datap)} 
+  Imposta le \textit{capabilities}.
+
+  
+  \bodydesc{Entrambe le funzioni ritornano 0 in caso di successo e -1 in caso
+    di errore, nel qual caso \var{errno} può assumere i valori:
+    \begin{errlist}
+    \item[\errcode{ESRCH}] si è fatto riferimento ad un processo inesistente.
+    \item[\errcode{EPERM}] si è tentato di aggiungere una capacità
+      nell'insieme delle \textit{capabilities} permesse, o di impostare una
+      capacità non presente nell'insieme di quelle permesse negli insieme
+      delle effettive o ereditate, o si è cercato di impostare una
+      \textit{capability} di un altro processo senza avare
+      \const{CAP\_SETPCAP}. 
+  \end{errlist}
+  ed inoltre \errval{EFAULT} ed \errval{EINVAL}.
+}
+
+\end{functions}
+
+Queste due funzioni prendono come argomenti due tipi di dati dedicati,
+definiti come puntatori a due strutture specifiche di Linux, illustrate in
+fig.~\ref{fig:cap_kernel_struct}. Per poterle utilizzare occorre anche
+cancellare la macro \macro{\_POSIX\_SOURCE}.\footnote{per farlo occorre
+  utilizzare la direttiva di preprocessore \direct{undef}; si dovrà cioè
+  inserire una istruzione \texttt{\#undef \_POSIX\_SOURCE} prima di includere
+  \texttt{sys/capability.h}.} Si tenga presente che le strutture di
+fig.~\ref{fig:cap_kernel_struct}, come i prototipi delle due funzioni
+\func{capget} e \func{capset}, sono soggette ad essere modificate con il
+cambiamento del kernel (in particolare i tipi di dati delle strutture) ed
+anche se finora l'interfaccia è risultata stabile, non c'è nessuna
+assicurazione che questa venga mantenuta.\footnote{anzi, visto lo scarso
+  utilizzo di questa funzionalità ci sono state varie discussioni fra gli
+  sviluppatori del kernel relative all'eliminarla o al modificarla
+  radicalmente.} Pertanto se si vogliono scrivere programmi portabili che
+possano essere eseguiti su qualunque versione del kernel è opportuno
+utilizzare le interfacce di alto livello.
+
+\begin{figure}[!htb]
+  \footnotesize
+  \centering
+  \begin{minipage}[c]{15cm}
+    \includestruct{listati/cap_user_header_t.h}
+  \end{minipage} 
+  \normalsize 
+  \caption{Definizione delle strutture a cui fanno riferimento i puntatori
+    \structd{cap\_user\_header\_t} e \structd{cap\_user\_data\_t} usati per
+    l'interfaccia di gestione di basso livello delle \textit{capabilities}.}
+  \label{fig:cap_kernel_struct}
+\end{figure}
+
+La struttura a cui deve puntare l'argomento \param{hdrp} serve ad indicare,
+tramite il campo \var{pid}, il processo del quale si vogliono leggere o
+modificare le \textit{capabilities}. Il campo \var{version} deve essere
+impostato al valore della versione delle usata dal kernel (quello indicato
+dalla costante \const{\_LINUX\_CAPABILITY\_VERSION} di
+fig.~\ref{fig:cap_kernel_struct}) altrimenti le funzioni ritorneranno con un
+errore di \errcode{EINVAL}, restituendo nel campo stesso il valore corretto
+della versione in uso.  La struttura a cui deve puntare l'argomento
+\param{datap} invece conterrà i valori letti o da impostare per i tre insiemi
+delle capacità del processo.
+
+Dato che le precedenti funzioni, oltre ad essere specifiche di Linux, non
+garantiscono la stabilità nell'interfaccia, è sempre opportuno effettuare la
+gestione delle \textit{capabilities} utilizzando le funzioni di libreria a
+questo dedicate. Queste funzioni, che seguono quanto previsto nelle bozze
+dello standard POSIX.1e, non fanno parte delle \acr{glibc} e sono fornite in
+una libreria a parte,\footnote{la libreria è \texttt{libcap2}, nel caso di
+  Debian può essere installata con il pacchetto omonimo.} pertanto se un
+programma le utilizza si dovrà indicare esplicitamente l'uso della suddetta
+libreria attraverso l'opzione \texttt{-lcap} del compilatore.
+
+Le funzioni dell'interfaccia delle bozze di POSIX.1e prevedono l'uso di uno
+tipo di dato opaco, \type{cap\_t}, come puntatore ai dati mantenuti nel
+cosiddetto \textit{capability state},\footnote{si tratta in sostanza di un
+  puntatore ad una struttura interna utilizzata dalle librerie, i cui campi
+  non devono mai essere acceduti direttamente.} in sono memorizzati tutti i
+dati delle \textit{capabilities}. In questo modo è possibile mascherare i
+dettagli della gestione di basso livello, che potranno essere modificati senza
+dover cambiare le funzioni dell'interfaccia, che faranno riferimento soltanto
+ad oggetti di questo tipo.  L'interfaccia pertanto non soltanto fornisce le
+funzioni per modificare e leggere le \textit{capabilities}, ma anche quelle
+per gestire i dati attraverso \type{cap\_t}.
+
+La prima funzione dell'interfaccia è quella che permette di inizializzare un
+\textit{capability state}, allocando al contempo la memoria necessaria per i
+relativi dati. La funzione è \funcd{cap\_init} ed il suo prototipo è:
+\begin{functions}
+  \headdecl{sys/capability.h}
+
+  \funcdecl{cap\_t cap\_init(void)} 
+  Crea ed inizializza un \textit{capability state}.
+  
+  \bodydesc{La funzione ritorna un valore non nullo in caso di successo e
+    \macro{NULL} in caso di errore, nel qual caso \var{errno} assumerà il
+    valore \errval{ENOMEM}.
+  }
+\end{functions}
+
+La funzione restituisce il puntatore \type{cap\_t} ad uno stato inizializzato
+con tutte le \textit{capabilities} azzerate. In caso di errore (cioè quando
+non c'è memoria sufficiente ad allocare i dati) viene restituito \macro{NULL}
+ed \var{errno} viene impostata a \errval{ENOMEM}.  La memoria necessaria a
+mantenere i dati viene automaticamente allocata da \func{cap\_init}, ma dovrà
+essere disallocata esplicitamente quando non è più necessaria utilizzando, per
+questo l'interfaccia fornisce una apposita funzione, \funcd{cap\_free}, il cui
+prototipo è:
+\begin{functions}
+  \headdecl{sys/capability.h}
+
+  \funcdecl{int cap\_free(void *obj\_d)} 
+  Disalloca la memoria allocata per i dati delle \textit{capabilities}.
+  
+  \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
+    errore, nel qual caso \var{errno} assumerà il valore \errval{EINVAL}.
+  }
+\end{functions}
+
+La funzione permette di liberare la memoria allocata dalle altre funzioni
+della libreria sia per un \textit{capability state}, nel qual caso l'argomento
+dovrà essere un dato di tipo \type{cap\_t}, che per una descrizione testuale
+dello stesso,\footnote{cioè quanto ottenuto tramite la funzione
+  \func{cap\_to\_text}.} nel qual caso l'argomento dovrà essere un dato di
+tipo \texttt{char *}. Per questo l'argomento \param{obj\_d} è dichiarato come
+\texttt{void *} e deve sempre corrispondere ad un puntatore ottenuto tramite
+le altre funzioni della libreria, altrimenti la funzione fallirà con un errore
+di \errval{EINVAL}.
+
+Infine si può creare una copia di un \textit{capability state} ottenuto in
+precedenza tramite la funzione \funcd{cap\_dup}, il cui prototipo è:
+\begin{functions}
+  \headdecl{sys/capability.h}
+
+  \funcdecl{cap\_t cap\_dup(cap\_t cap\_p)} 
+  Duplica un \textit{capability state} restituendone una copia.
+  
+  \bodydesc{La funzione ritorna un valore non nullo in caso di successo e
+    \macro{NULL} in caso di errore, nel qual caso \var{errno} potrà assumere i
+    valori \errval{ENOMEM} o \errval{EINVAL}.  
+  }
+\end{functions}
+
+La funzione crea una copia del \textit{capability state} posto all'indirizzo
+\param{cap\_p} che si è passato come argomento, restituendo il puntatore alla
+copia, che conterrà gli stessi valori delle \textit{capabilities} presenti
+nell'originale. La memoria necessaria viene allocata automaticamente dalla
+funzione. Una volta effettuata la copia i due \textit{capability state}
+potranno essere modificati in maniera completamente
+indipendente.\footnote{alla fine delle operazioni si ricordi però di
+  disallocare anche la copia, oltre all'originale. }
+
+Una seconda classe di funzioni di servizio previste dall'interfaccia sono
+quelle per la gestione dei dati contenuti all'interno di un \textit{capability
+  state}; la prima di queste è \funcd{cap\_clear}, il cui prototipo è:
+\begin{functions}
+  \headdecl{sys/capability.h}
+
+  \funcdecl{int cap\_clear(cap\_t cap\_p)} 
+  Inizializza un \textit{capability state} cancellando tutte le
+  \textit{capabilities}.
+  
+  \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
+    errore, nel qual caso \var{errno} assumerà il valore \errval{EINVAL}.
+  }
+\end{functions}
+
+La 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}.
+
+Per la gestione dei valori delle \textit{capabilities} presenti in un
+\textit{capability state} l'interfaccia prevede due funzioni,
+\funcd{cap\_get\_flag} e \funcd{cap\_set\_flag}, che permettono
+rispettivamente di leggere o impostare il valore di un flag delle
+\textit{capabilities}; i rispettivi prototipi sono:
+\begin{functions}
+  \headdecl{sys/capability.h}
+
+  \funcdecl{int cap\_get\_flag(cap\_t cap\_p, cap\_value\_t cap, cap\_flag\_t
+    flag, cap\_flag\_value\_t *value\_p)}
+  Legge il valore di una \textit{capability}.
+
+  \funcdecl{int cap\_set\_flag(cap\_t cap\_p, cap\_flag\_t flag, int ncap,
+    cap\_value\_t *caps, cap\_flag\_value\_t value)} 
+  Imposta il valore di una \textit{capability}.
+  
+  \bodydesc{Le funzioni ritornano 0 in caso di successo e $-1$ in caso di
+    errore, nel qual caso \var{errno} assumerà il valore \errval{EINVAL}.
+}
+\end{functions}
+
+In entrambe le funzioni l'argomento \param{cap\_p} indica il puntatore al
+\textit{capability state} su cui operare, mentre l'argomento \param{flag}
+indica su quale dei tre insiemi illustrati a
+pag.~\pageref{sec:capabilities_set} si intende operare. Questi devono essere
+specificati con una variabile di tipo \type{cap\_flag\_t} che può assumere
+esclusivamente\footnote{si tratta in effetti di un tipo enumerato, come si può
+  verificare dalla sua definizione che si trova in
+  \texttt{/usr/include/sys/capability.h}.} uno dei valori illustrati in
+tab.~\ref{tab:cap_set_identifier}.
+
+\begin{table}[htb]
+  \centering
+  \footnotesize
+  \begin{tabular}[c]{|l|l|}
+    \hline
+    \textbf{Valore} & \textbf{Significato} \\
+    \hline
+    \hline
+    \const{CAP\_EFFECTIVE}  & Capacità dell'insieme \textsl{effettivo}.\\
+    \const{CAP\_PERMITTED}  & Capacità dell'insieme \textsl{permesso}.\\ 
+    \const{CAP\_INHERITABLE}& Capacità dell'insieme \textsl{ereditabile}.\\
+    \hline
+  \end{tabular}
+  \caption{Valori possibili per il tipo di dato \type{cap\_flag\_t} che
+    identifica gli insiemi delle \textit{capabilities}.}
+  \label{tab:cap_set_identifier}
+\end{table}
+
+La capacità che si intende controllare o impostare invece deve essere
+specificata attraverso una variabile di tipo \type{cap\_value\_t}, che può
+prendere come valore uno qualunque di quelli riportati in
+tab.~\ref{tab:proc_capabilities}, in questo caso però non è possibile
+combinare diversi valori in una maschera binaria, una variabile di tipo
+\type{cap\_value\_t} deve indicare una sola capacità.\footnote{nel file di
+  header citato nella nota precedente il tipo \type{cap\_value\_t} è definito
+  come \ctyp{int}, ma i valori validi sono soltanto quelli di
+  tab.~\ref{tab:proc_capabilities}.}  
+
+Infine lo stato di una capacità è descritto ad una variabile di tipo
+\type{cap\_flag\_value\_t}, che a sua volta può assumere soltanto
+uno\footnote{anche questo è un tipo enumerato.} dei valori di
+tab.~\ref{tab:cap_value_type}.
+
+\begin{table}[htb]
+  \centering
+  \footnotesize
+  \begin{tabular}[c]{|l|l|}
+    \hline
+    \textbf{Valore} & \textbf{Significato} \\
+    \hline
+    \hline
+    \const{CAP\_CLEAR}& La capacità non è impostata.\\ 
+    \const{CAP\_SET}  & La capacità è impostata.\\
+    \hline
+  \end{tabular}
+  \caption{Valori possibili per il tipo di dato \type{cap\_flag\_value\_t} che
+    indica lo stato di una capacità.}
+  \label{tab:cap_value_type}
+\end{table}
+
+La funzione \func{cap\_get\_flag} legge lo stato della capacità indicata
+dall'argomento \param{cap} all'interno dell'insieme indicato dall'argomento
+\param{flag} e ne restituisce il valore nella variabile posta all'indirizzo
+puntato dall'argomento \param{value\_p}; è possibile cioè leggere soltanto uno
+stato di una capacità alla volta.
+
+La funzione \func{cap\_set\_flag} può invece impostare in una sola chiamata
+più \textit{capabilities}, anche se solo all'interno dello stesso insieme. Per
+questo motivo essa prende un vettore di valori di tipo \type{cap\_value\_t}
+nell'argomento \param{caps}, la cui dimensione viene specificata dall'argomento
+\param{ncap}. Il tipo di impostazione da eseguire (cancellazione o
+impostazione) viene indicato dall'argomento \param{value}.
+
+Per la visualizzazione dello stato delle \textit{capabilities} l'interfaccia
+prevede una funzione apposita, \funcd{cap\_to\_text}, il cui prototipo è:
+\begin{functions}
+  \headdecl{sys/capability.h}
+
+  \funcdecl{char * cap\_to\_text(cap\_t caps, ssize\_t * length\_p)}
+
+  Genera una visualizzazione testuale delle \textit{capabilities}.
+  
+  \bodydesc{La funzione ritorna un puntatore alla stringa con la descrizione
+    delle \textit{capabilities} in caso di successo e \val{NULL} in caso di
+    errore, nel qual caso \var{errno} può assumere i valori \errval{EINVAL} o
+    \errval{ENOMEM}.
+  }
+\end{functions}
+
+La funzione ritorna l'indirizzo di una stringa contente la descrizione
+testuale del contenuto del \textit{capabilities state} \param{caps} passato
+come argomento, e, qualora l'argomento \param{length\_p} sia diverso da
+\val{NULL}, restituisce nella variabile intera da questo puntata la lunghezza
+della stringa. La stringa restituita viene allocata automaticamente dalla
+funzione e pertanto dovrà essere liberata con \func{cap\_free}.
+
+Fin quei abbiamo trattato solo le funzioni di servizio relative alla
+manipolazione dei \textit{capabilities state}; l'interfaccia di gestione
+prevede però anche le funzioni per la gestione delle \textit{capabilities}
+stesse. La prima di queste è \funcd{cap\_get\_proc} che consente la lettura
+delle \textit{capabilities} del processo corrente, il suo prototipo è:
+\begin{functions}
+  \headdecl{sys/capability.h}
+
+  \funcdecl{cap\_t cap\_get\_proc(void)}
+  Legge le \textit{capabilities} del processo corrente.
+  
+  \bodydesc{La funzione ritorna un valore diverso da \val{NULL} in caso di
+    successo e \val{NULL} in caso di errore, nel qual caso \var{errno} può
+    assumere i valori \errval{EINVAL}, \errval{EPERM} o \errval{ENOMEM}.  }
+\end{functions}
+
+La funzione legge il valore delle \textit{capabilities} associate al processo
+da cui viene invocata, restituendo il risultato tramite il puntatore ad un
+\textit{capabilities state} contenente tutti i dati che provvede ad allocare
+autonomamente e che di nuovo occorrerà liberare con \func{cap\_free} quando
+non sarà più utilizzato.
+
+Se invece si vogliono leggere le \textit{capabilities} di un processo
+specifico occorre usare la funzione \funcd{capgetp}, il cui
+prototipo\footnote{su alcune pagine di manuale la funzione è descritta con un
+  prototipo sbagliato, che prevede un valore di ritorno di tipo \type{cap\_t},
+  ma il valore di ritorno è intero, come si può verificare anche dalla
+  dichiarazione della stessa in \texttt{sys/capability.h}.} è:
+\begin{functions}
+  \headdecl{sys/capability.h}
+
+  \funcdecl{int capgetp(pid\_t pid, cap\_t cap\_d)}
+  Legge le \textit{capabilities} del processo indicato da \param{pid}.
+  
+  \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
+    errore, nel qual caso \var{errno} può assumere i valori \errval{EINVAL},
+    \errval{EPERM} o \errval{ENOMEM}.  
+  }
+\end{functions}
+%TODO controllare e correggere i codici di errore!!!
+
+La funzione legge il valore delle \textit{capabilities} del processo indicato
+con l'argomento \param{pid}, e restituisce il risultato nel
+\textit{capabilities state} posto all'indirizzo indicato con l'argomento
+\param{cap\_d}; a differenza della precedente in questo caso il
+\textit{capability state} deve essere stato creato in precedenza. Qualora il
+processo indicato non esista si avrà un errore di \errval{ESRCH}. Gli stessi
+valori possono essere letti direttamente nel filesystem \textit{proc}, nei
+file \texttt{/proc/<pid>/status}; ad esempio per \texttt{init} si otterrà
+qualcosa del tipo:
+\begin{Verbatim}
+...
+CapInh: 0000000000000000
+CapPrm: 00000000fffffeff
+CapEff: 00000000fffffeff  
+...
+\end{Verbatim}
+
+Infine per impostare le \textit{capabilities} del processo corrente (non
+esiste una funzione che permetta di cambiare le \textit{capabilities} di un
+altro processo) si deve usare la funzione \funcd{cap\_set\_proc}, il cui
+prototipo è:
+\begin{functions}
+  \headdecl{sys/capability.h}
+
+  \funcdecl{int cap\_set\_proc(cap\_t cap\_p)}
+  Imposta le \textit{capabilities} del processo corrente.
+  
+  \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
+    errore, nel qual caso \var{errno} può assumere i valori \errval{EINVAL},
+    \errval{EPERM} o \errval{ENOMEM}.  
+  }
+\end{functions}
+
+La funzione modifica le \textit{capabilities} del processo corrente secondo
+quanto specificato con l'argomento \param{cap\_p}, posto che questo sia
+possibile nei termini spiegati in precedenza (non sarà ad esempio possibile
+impostare capacità non presenti nell'insieme di quelle permesse). In caso di
+successo i nuovi valori saranno effettivi al ritorno della funzione, in caso
+di fallimento invece lo stato delle capacità resterà invariato. Si tenga
+presente che \textsl{tutte} le capacità specificate tramite \param{cap\_p}
+devono essere permesse; se anche una sola non lo è la funzione fallirà, e per
+quanto appena detto, lo stato delle \textit{capabilities} non verrà modificato
+(neanche per le parti eventualmente permesse).
+
+Come esempio di utilizzo di queste funzioni nei sorgenti allegati alla guida
+si è distribuito il programma \texttt{getcap.c}, che consente di leggere le
+\textit{capabilities} del processo corrente\footnote{vale a dire di sé stesso,
+  quando lo si lancia, il che può sembrare inutile, ma serve a mostrarci quali
+  sono le \textit{capabilities} standard che ottiene un processo lanciato
+  dalla riga di comando.} o tramite l'opzione \texttt{-p}, quelle di un
+processo qualunque il cui pid viene passato come parametro dell'opzione.
+
+\begin{figure}[htb]
+  \footnotesize \centering
+  \begin{minipage}[c]{15cm}
+    \includecodesample{listati/getcap.c}
+  \end{minipage} 
+  \normalsize
+  \caption{Corpo principale del programma \texttt{getcap.c}.}
+  \label{fig:proc_getcap}
+\end{figure}
+
+La sezione principale del programma è riportata in fig.~\ref{fig:proc_getcap},
+e si basa su una condizione sulla variabile \var{pid} che se si è usato
+l'opzione \texttt{-p} è impostata (nella sezione di gestione delle opzioni,
+che si è tralasciata) al valore del \textsl{pid} del processo di cui si vuole
+leggere le \textit{capabilities} e nulla altrimenti. Nel primo caso
+(\texttt{\small 1--6}) si utilizza direttamente (\texttt{\small 2})
+\func{cap\_get\_proc} per ottenere lo stato delle capacità del processo, nel
+secondo (\texttt{\small 7--14}) prima si inizializza (\texttt{\small 8}) uno
+stato vuoto e poi (\texttt{\small 9}) si legge il valore delle capacità del
+processo indicato.
+
+Il passo successivo è utilizzare (\texttt{\small 16}) \func{cap\_to\_text} per
+tradurre in una stringa lo stato, e poi (\texttt{\small 17}) stamparlo; infine
+(\texttt{\small 19--20}) si libera la memoria allocata dalle precedenti
+funzioni con \func{cap\_free} per poi ritornare dal ciclo principale della
+funzione.
+
+\itindend{capabilities}
+
+% TODO vedi http://lwn.net/Articles/198557/ e 
+% http://www.madore.org/~david/linux/newcaps/
+% TODO documentare prctl ...
+
 \subsection{Gli attributi estesi}
 \label{sec:file_xattr}
 
 \subsection{Gli attributi estesi}
 \label{sec:file_xattr}
 
@@ -2784,7 +3533,7 @@ classi di attributi riportate in tab.~\ref{tab:extended_attribute_class}.
 \begin{table}[htb]
   \centering
   \footnotesize
 \begin{table}[htb]
   \centering
   \footnotesize
-  \begin{tabular}{|c|p{10cm}|}
+  \begin{tabular}{|l|p{10cm}|}
     \hline
     \textbf{Nome} & \textbf{Descrizione} \\
     \hline
     \hline
     \textbf{Nome} & \textbf{Descrizione} \\
     \hline
@@ -2823,10 +3572,10 @@ impiega per realizzare delle estensioni (come le \itindex{Access~Control~List}
 ACL, \index{SELinux} SELinux, ecc.) al tradizionale meccanismo dei controlli
 di accesso di Unix, l'accesso ai loro valori viene regolato in maniera diversa
 a seconda sia della loro classe sia di quali, fra le estensioni che li
 ACL, \index{SELinux} SELinux, ecc.) al tradizionale meccanismo dei controlli
 di accesso di Unix, l'accesso ai loro valori viene regolato in maniera diversa
 a seconda sia della loro classe sia di quali, fra le estensioni che li
-utilizzano, sono poste in uso.  In particolare, per ciascuna delle classi
+utilizzano, sono poste in uso. In particolare, per ciascuna delle classi
 riportate in tab.~\ref{tab:extended_attribute_class}, si hanno i seguenti
 casi:
 riportate in tab.~\ref{tab:extended_attribute_class}, si hanno i seguenti
 casi:
-\begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}}
+\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
 \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
@@ -2857,58 +3606,51 @@ casi:
   controllo che accedono ad informazioni non disponibili ai processi ordinari.
 
 \item[\texttt{user}] L'accesso agli \textit{extended user attributes} è
   controllo che accedono ad informazioni non disponibili ai processi ordinari.
 
 \item[\texttt{user}] L'accesso agli \textit{extended user attributes} è
-  regolato dagli ordinari permessi dei file a cui essi fanno riferimento:
-  occorre avere il permesso di lettura per leggerli e quello di scrittura per
-  scriverli o modificarli. Dato l'uso di questi attributi, si è scelto cioè di
-  applicare per il loro accesso gli stessi criteri che si usano per l'accesso
-  al contenuto dei file (o delle directory) cui essi fanno riferimento.
-
-  Questa scelta vale però soltanto per i file e le directory ordinarie, se
-  valesse in generale infatti si avrebbe un serio problema di sicurezza dato
-  che esistono diversi oggetti sul filesystem per i quali è normale avere
-  avere il permesso di scrittura consentito a tutti gli utenti, come i link
-  simbolici, o alcuni 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 che abbiamo indicato 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
-  link simbolici questi vengono semplicemente ignorati: in nessuno dei due
-  casi hanno a che fare con il contenuto del file, e nella discussione
-  relativa all'uso degli \textit{extended user attributes} nessuno è mai stato
-  capace di indicare una qualche forma sensata di utilizzo degli stessi per
-  link simbolici o file di dispositivo, e neanche per le fifo o i socket.
-
-  Per questo motivo gli \textit{extended user attributes} 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}.  Questo è un altro caso particolare, in cui il premesso di
-  scrittura viene usato, unito alla presenza dello \itindex{sticky~bit}
-  \textit{sticky bit}, per garantire il permesso di creazione di nuovi file.
-  Per questo motivo, per evitare eventuali abusi, se una directory ha lo
-  \itindex{sticky~bit} \textit{sticky bit} attivo sarà consentito scrivere i
-  suoi \textit{extended user attributes} soltanto se si è proprietari della
-  stessa, o si hanno i privilegi amministrativi della capability
-  \index{capabilities} \const{CAP\_FOWNER}.
+  regolato dai normali permessi dei file: occorre avere il permesso di lettura
+  per leggerli e quello di scrittura per scriverli o modificarli. Dato l'uso
+  di questi attributi si è scelto di applicare al loro accesso gli stessi
+  criteri che si usano per l'accesso al contenuto dei file (o delle directory)
+  cui essi fanno riferimento. Questa scelta vale però soltanto per i file e le
+  directory ordinarie, se valesse in generale infatti si avrebbe un serio
+  problema di sicurezza dato che esistono diversi oggetti sul filesystem per i
+  quali è normale avere avere il permesso di scrittura consentito a tutti gli
+  utenti, come i link simbolici, o alcuni 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 link
+  simbolici questi vengono semplicemente ignorati: in nessuno dei due casi
+  hanno a che fare con il contenuto del file, e nella discussione relativa
+  all'uso degli \textit{extended user attributes} nessuno è mai stato capace
+  di indicare una qualche forma sensata di utilizzo degli stessi per link
+  simbolici o file di dispositivo, e neanche per le fifo o i socket.  Per
+  questo motivo essi sono stati completamente disabilitati per tutto ciò che
+  non sia un file regolare o una directory.\footnote{si può verificare la
+    semantica adottata consultando il file \texttt{fs/xattr.c} dei sorgenti
+    del kernel.} Inoltre per le directory è stata introdotta una ulteriore
+  restrizione, dovuta di nuovo alla presenza ordinaria di permessi di
+  scrittura completi su directory come \texttt{/tmp}. Per questo motivo, per
+  evitare eventuali abusi, se una directory ha lo \itindex{sticky~bit}
+  \textit{sticky bit} attivo sarà consentito scrivere i suoi \textit{extended
+    user attributes} soltanto se si è proprietari della stessa, o si hanno i
+  privilegi amministrativi della capability \index{capabilities}
+  \const{CAP\_FOWNER}.
 \end{basedescript}
 
 Le funzioni per la gestione degli attributi estesi, come altre funzioni di
 gestione avanzate specifiche di Linux, non fanno parte delle \acr{glibc}, e
 sono fornite da una apposita libreria, \texttt{libattr}, che deve essere
 installata a parte;\footnote{la versione corrente della libreria è
 \end{basedescript}
 
 Le funzioni per la gestione degli attributi estesi, come altre funzioni di
 gestione avanzate specifiche di Linux, non fanno parte delle \acr{glibc}, e
 sono fornite da una apposita libreria, \texttt{libattr}, che deve essere
 installata a parte;\footnote{la versione corrente della libreria è
-  \texttt{libattr1}, e nel caso si usi Debian la si può installare con il
-  pacchetto omonimo ed il collegato \texttt{libattr1-dev}.}  pertanto se un
-programma le utilizza si dovrà indicare esplicitamente l'uso della suddetta
-libreria invocando il compilatore con l'opzione \texttt{-lattr}.
+  \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,
 \funcd{getxattr}, \funcd{lgetxattr} e \funcd{fgetxattr}, che consentono
 
 Per poter leggere gli attributi estesi sono disponibili tre diverse funzioni,
 \funcd{getxattr}, \funcd{lgetxattr} e \funcd{fgetxattr}, che consentono
@@ -2939,9 +3681,8 @@ simbolico e ad un file descriptor; i rispettivi prototipi sono:
   \item[\errcode{ENOTSUP}] gli attributi estesi non sono supportati dal
     filesystem o sono disabilitati.
   \end{errlist}
   \item[\errcode{ENOTSUP}] gli attributi estesi non sono supportati dal
     filesystem o sono disabilitati.
   \end{errlist}
-  Oltre a questi potranno essere restituiti tutti gli errori di \func{stat},
-  ed in particolare \errcode{EPERM} se non si hanno i permessi di accesso
-  all'attributo.  }
+  e tutti gli errori di \func{stat}, come \errcode{EPERM} se non si hanno i
+  permessi di accesso all'attributo. }
 \end{functions}
 
 Le funzioni \func{getxattr} e \func{lgetxattr} prendono come primo argomento
 \end{functions}
 
 Le funzioni \func{getxattr} e \func{lgetxattr} prendono come primo argomento
@@ -3109,10 +3850,6 @@ illustrate in precedenza per le altre funzioni relative agli attributi estesi.
 
 \itindend{Extended~Attributes}
 
 
 \itindend{Extended~Attributes}
 
-% TODO trattare gli attributi estesi e le funzioni la documentazione di
-% sistema è nei pacchetti libxattr1-dev e attr
-
-
 \subsection{Le \textit{Access  Control List}}
 \label{sec:file_ACL}
 
 \subsection{Le \textit{Access  Control List}}
 \label{sec:file_ACL}
 
@@ -3783,8 +4520,9 @@ della ACL rappresentata dai dati contenuti nel buffer puntato da
 utilizzo.
 
 Una volta che si disponga della ACL desiderata, questa potrà essere impostata
 utilizzo.
 
 Una volta che si disponga della ACL desiderata, questa potrà essere impostata
-su un file o una directory. Per far questo sono disponibili due funzioni; la
-prima è \funcd{acl\_set\_file}, il cui prototipo è:
+su un file o una directory. Per impostare una ACL sono disponibili due
+funzioni; la prima è \funcd{acl\_set\_file}, che opera sia su file che su
+directory, ed il cui prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/acl.h}
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/acl.h}
@@ -3792,7 +4530,7 @@ prima 
   \funcdecl{int acl\_set\_file(const char *path, acl\_type\_t type, acl\_t
     acl)}
 
   \funcdecl{int acl\_set\_file(const char *path, acl\_type\_t type, acl\_t
     acl)}
 
-  Imposta una ACL su un file.
+  Imposta una ACL su un file o una directory.
 
   \bodydesc{La funzione restituisce $0$ in caso di successo e $-1$ in caso di
     errore, nel qual caso \var{errno} assumerà uno dei valori:
 
   \bodydesc{La funzione restituisce $0$ in caso di successo e $-1$ in caso di
     errore, nel qual caso \var{errno} assumerà uno dei valori:
@@ -3812,12 +4550,20 @@ prima 
 }
 \end{functions}
 
 }
 \end{functions}
 
-La funzione ...
-
-%TODO: finire
-
-La seconda funzione che consente di impostare una ACL è
-\funcd{acl\_set\_fd}, il cui prototipo è:
+La funzione consente di assegnare la ACL contenuta in \param{acl} al file o
+alla directory indicate dal pathname \param{path}, mentre con \param{type} si
+indica il tipo di ACL utilizzando le constanti di tab.~\ref{tab:acl_type}, ma
+si tenga presente che le ACL di default possono essere solo impostate
+qualora \param{path} indichi una directory. Inoltre perché la funzione abbia
+successo la ACL dovrà essere valida, e contenere tutti le voci necessarie,
+unica eccezione è quella in cui si specifica una ACL vuota per cancellare la
+ACL di default associata a \func{path}.\footnote{questo però è una estensione
+  della implementazione delle ACL di Linux, la bozza di standard POSIX.1e
+  prevedeva l'uso della apposita funzione \funcd{acl\_delete\_def\_file}, che
+  prende come unico argomento il pathname della directory di cui si vuole
+  cancellare l'ACL di default, per i dettagli si ricorra alla pagina di
+  manuale.}  La seconda funzione che consente di impostare una ACL è
+\funcd{acl\_set\_fd}, ed il suo prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/acl.h}
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/acl.h}
@@ -3841,12 +4587,19 @@ La seconda funzione che consente di impostare una ACL 
 }
 \end{functions}
 
 }
 \end{functions}
 
+La funzione è del tutto è analoga a \funcd{acl\_set\_file} ma opera
+esclusivamente sui file identificati tramite un file descriptor. Non dovendo
+avere a che fare con directory (e con la conseguente possibilità di avere una
+ACL di default) la funzione non necessita che si specifichi il tipo di ACL,
+che sarà sempre di accesso, e prende come unico argomento, a parte il file
+descriptor, la ACL da impostare.
+
 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
 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 standardo POSIX.1e.  Queste
-funzioni però sono alquanto macchinose da utilizzare per cui è probabilmente
-più semplice operare direttamente sulla rappresentazione testuale. Questo è il
+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.
 motivo per non tratteremo nei dettagli dette funzioni, fornendone solo una
 descrizione sommaria; chi fosse interessato potrà ricorrere alle pagina di
 manuale.
@@ -3857,19 +4610,22 @@ 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
 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
-singoli voci. 
-
-Una volta ottenuti detti puntatori si porà operare sui contenuti delle singole
-voci ...
-
-
-%TODO: finire
+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}
 
 
 \itindend{Access~Control~List}
 
-
-% TODO trattare le ACL, la documentazione di sistema è nei pacchetti
-% libacl1-dev e acl 
+% la documentazione di sistema è nei pacchetti libacl1-dev e acl 
 % vedi anche http://www.suse.de/~agruen/acl/linux-acls/online/
 
 
 % vedi anche http://www.suse.de/~agruen/acl/linux-acls/online/
 
 
@@ -3999,7 +4755,8 @@ programmi e librerie) di cui il server potrebbe avere bisogno.
 % LocalWords:  fsetxattr flags XATTR REPLACE listxattr llistxattr flistxattr by
 % LocalWords:  removexattr lremovexattr fremovexattr attributename  lacl acl
 % LocalWords:  OBJ setfacl len any prefix separator options NUMERIC IDS SMART
 % LocalWords:  fsetxattr flags XATTR REPLACE listxattr llistxattr flistxattr by
 % LocalWords:  removexattr lremovexattr fremovexattr attributename  lacl acl
 % LocalWords:  OBJ setfacl len any prefix separator options NUMERIC IDS SMART
-% LocalWords:  INDENT major number IDE Documentation makedev fopendir proc
+% LocalWords:  INDENT major number IDE Documentation makedev fopendir proc copy
+% LocalWords:  euidaccess eaccess delete def tag qualifier permset
 
 %%% Local Variables: 
 %%% mode: latex
 
 %%% Local Variables: 
 %%% mode: latex