X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=blobdiff_plain;f=filedir.tex;h=18bbdc04692e6cb1b66c9ae180762e097dfb203e;hb=af288d909f7313db7ba2c8092a219695de34821d;hp=8cd063d8a41d72ea2fc6096ba54d0f2172fd6331;hpb=516c47edf3aafae9e77eb5a78c26a87f72154314;p=gapil.git

diff --git a/filedir.tex b/filedir.tex
index 8cd063d..18bbdc0 100644
--- a/filedir.tex
+++ b/filedir.tex
@@ -1,4 +1,4 @@
-%% filedir.tex
+4%% filedir.tex
 %%
 %% Copyright (C) 2000-2011 Simone Piccardi.  Permission is granted to
 %% copy, distribute and/or modify this document under the terms of the GNU Free
@@ -16,10 +16,11 @@ In questo capitolo tratteremo in dettaglio le modalità con cui si gestiscono
 file e directory, iniziando dalle funzioni di libreria che si usano per
 copiarli, spostarli e cambiarne i nomi. Esamineremo poi l'interfaccia che
 permette la manipolazione dei vari attributi di file e directory ed alla fine
-faremo una trattazione dettagliata su come è strutturato il sistema base di
-protezioni e controllo dell'accesso ai file e sulle funzioni che ne permettono
-la gestione. Tutto quello che riguarda invece la manipolazione del contenuto
-dei file è lasciato ai capitoli successivi.
+prenderemo in esame la struttura di base del sistema delle protezioni e del
+controllo dell'accesso ai file e le successive estensioni (\textit{Extended
+  Attributes}, ACL, quote disco, \textit{capabilities}). Tutto quello che
+riguarda invece la manipolazione del contenuto dei file è lasciato ai capitoli
+successivi.
 
 
 
@@ -41,8 +42,8 @@ riguarda il comportamento e gli effetti delle varie funzioni.
 \label{sec:file_link}
 
 Una caratteristica comune a diversi sistemi operativi è quella di poter creare
-dei nomi fittizi (come gli alias del MacOS o i collegamenti di Windows o i
-nomi logici del VMS) che permettono di fare riferimento allo stesso file
+dei nomi fittizi (come gli alias del vecchio MacOS o i collegamenti di Windows
+o i nomi logici del VMS) che permettono di fare riferimento allo stesso file
 chiamandolo con nomi diversi o accedendovi da directory diverse.
 
 Questo è possibile anche in ambiente Unix, dove tali collegamenti sono
@@ -4096,7 +4097,6 @@ ACL di default associata a \func{path}.\footnote{questo però è una estensione
   \bodydesc{La funzione restituisce $0$ in caso di successo e $-1$ in caso di
     errore, nel qual caso \var{errno} assumerà uno dei valori:
   \begin{errlist}
-  \item[\errcode{EBADF}].
   \item[\errcode{EINVAL}] o \param{acl} non è una ACL valida, o \param{type}
     ha in valore non corretto.
   \item[\errcode{ENOSPC}] non c'è spazio disco sufficiente per contenere i
@@ -4147,6 +4147,110 @@ ad un altra con \funcd{acl\_copy\_entry} o eliminare una voce da una ACL con
 \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}}
@@ -4187,88 +4291,179 @@ 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
+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 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
+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{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
+\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.
+  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}}
+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 u-sate dal
+  ``\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}
 
+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.
 
 
-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
@@ -4306,10 +4501,10 @@ 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]
+\begin{table}[!h!btp]
   \centering
   \footnotesize
-  \begin{tabular}{|l|p{11.5cm}|}
+  \begin{tabular}{|l|p{11.9cm}|}
     \hline
     \textbf{Capacità}&\textbf{Descrizione}\\
     \hline
@@ -4317,10 +4512,10 @@ che è opportuno dettagliare maggiormente.
 %
 % POSIX-draft defined capabilities.
 %
-    \const{CAP\_AUDIT\_WRITE}&La capacità di scrivere dati nel giornale di
-                              auditing del kernel (dal kernel 2.6.11).\\ 
     \const{CAP\_AUDIT\_CONTROL}& La capacità di abilitare e disabilitare il
                               controllo dell'auditing (dal kernel 2.6.11).\\ 
+    \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
@@ -4347,11 +4542,11 @@ che è opportuno dettagliare maggiormente.
                               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\_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
@@ -4399,12 +4594,8 @@ che è opportuno dettagliare maggiormente.
                               \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\_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
@@ -4413,25 +4604,25 @@ che è opportuno dettagliare maggiormente.
     \const{CAP\_SYS\_CHROOT}& La capacità di eseguire la funzione
                               \func{chroot} (vedi
                               sez.~\ref{sec:file_chroot}).\\
-    \const{CAP\_MAC\_ADMIN} & La capacità amministrare il MAC di Smack (dal
-                              kernel 2.6.25).\\  
-    \const{CAP\_MAC\_OVERRIDE}& La capacità evitare il MAC di Smack (dal
-                              kernel 2.6.25).\\  
+    \const{CAP\_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
+                              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
+    \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
+    \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 limitazioni sulle
-                              risorse.\\ 
+    \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}
@@ -4456,12 +4647,37 @@ che è opportuno dettagliare maggiormente.
   controllo di accesso chiamato \itindex{Discrectionary~Access~Control~(DAC)}
   \textit{Discrectionary Access Control} (da cui il nome DAC).}
 
-La prima di queste capacità ``\textsl{ampie}'' è \const{CAP\_FOWNER}, che
-rimuove le restrizioni poste ad un processo che non ha la proprietà di un file
-in un vasto campo di operazioni;\footnote{vale a dire la richiesta che
-  l'user-ID effettivo del processo (o meglio il \textit{filesystem user-ID},
-  vedi sez.~\ref{sec:proc_setuid}) coincida con quello del proprietario.}
-queste comprendono i cambiamenti dei permessi e dei tempi del file (vedi
+
+Prima di dettagliare il significato della capacità più generiche, conviene
+però dedicare un discorso a parte a \const{CAP\_SETPCAP}, il cui significato è
+stato completamente cambiato con l'introduzione delle \textit{file
+  capabilities} nel kernel 2.6.24. In precedenza questa capacità era quella
+che permetteva al processo che la possedeva di impostare o rimuovere le
+\textit{capabilities} che fossero presenti nel \textit{permitted set} del
+chiamante di un qualunque altro processo. In realtà questo non è mai stato
+l'uso inteso nelle bozze dallo standard POSIX, ed inoltre, come si è già
+accennato, dato che questa capacità è assente nel \textit{capabilities
+  bounding set} usato di default, essa non è neanche mai stata realmente
+disponibile.
+
+Con l'introduzione \textit{file capabilities} e il cambiamento del significato
+del \textit{capabilities bounding set} la possibilità di modificare le
+capacità di altri processi è stata completamente rimossa, e
+\const{CAP\_SETPCAP} ha acquisito quello che avrebbe dovuto essere il suo
+significato originario, e cioè la capacità del processo di poter inserire nel
+suo \textit{inheritable set} qualunque capacità presente nel \textit{bounding
+  set}. Oltre a questo la disponibilità di \const{CAP\_SETPCAP} consente ad un
+processo di eliminare una capacità dal proprio \textit{bounding set} (con la
+conseguente impossibilità successiva di eseguire programmi con quella
+capacità), o di impostare i \textit{securebits} delle \textit{capabilities}.
+
+La prima fra le capacità ``\textsl{ampie}'' che occorre dettagliare
+maggiormente è \const{CAP\_FOWNER}, che rimuove le restrizioni poste ad un
+processo che non ha la proprietà di un file in un vasto campo di
+operazioni;\footnote{vale a dire la richiesta che l'user-ID effettivo del
+  processo (o meglio il \textit{filesystem user-ID}, vedi
+  sez.~\ref{sec:proc_setuid}) coincida con quello del proprietario.}  queste
+comprendono i cambiamenti dei permessi e dei tempi del file (vedi
 sez.~\ref{sec:file_perm_management} e sez.~\ref{sec:file_file_times}), le
 impostazioni degli attributi estesi e delle ACL (vedi
 sez.~\ref{sec:file_xattr} e \ref{sec:file_ACL}), poter ignorare lo
@@ -4513,6 +4729,10 @@ filesystem \acr{ext3}, non subire le quote disco, aumentare i limiti sulle
 risorse (vedi sez.~\ref{sec:sys_resource_limit}) e sulle dimensioni dei
 messaggi delle code del SysV IPC (vedi sez.~\ref{sec:ipc_sysv_mq}).
 
+Questo modo di intendere ... da fare ...  per cui
+a partire dal 2.6.24/5 è divenuta quella di impostare una capacità del
+\textit{bounding set} nelle proprie \textit{inheritable} o rimoverla dal
+\textit{bounding set} stesso.
 
 Per la gestione delle \textit{capabilities} il kernel mette a disposizione due
 funzioni che permettono rispettivamente di leggere ed impostare i valori dei