Ancora materiale sulle quote
[gapil.git] / filedir.tex
index d9afc5c4f6a4207a20759763484ef94a976ea43c..18bbdc04692e6cb1b66c9ae180762e097dfb203e 100644 (file)
@@ -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
 %%
 %% 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
 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
 \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
 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}
   \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
   \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,111 @@ ad un altra con \funcd{acl\_copy\_entry} o eliminare una voce da una ACL con
 \itindend{Access~Control~List}
 
 
 \itindend{Access~Control~List}
 
 
+\subsection{La gestione delle quote disco}
+\label{sec:disk_quota}
+
+Quella delle quote disco è una funzionalità introdotta inizialmente da BSD, e
+presente in Linux fino dalla serie 2.0, che consente di porre dei tetti
+massimi al consumo delle risorse di un filesystem (spazio disco e
+\textit{inode}) da parte degli utenti e dei gruppi. Dato che la funzionalità
+ha senso solo per i filesystem su cui si mantengono i dati degli
+utenti\footnote{in genere la si attiva sul filesystem che contiene le
+  \textit{home} degli utenti, dato che non avrebbe senso per i file di sistema
+  che in genere appartengono all'amministratore.} essa deve essere abilitata
+esplicitamente, questo si fa tramite due distinte opzioni di montaggio,
+\texttt{usrquota} e \texttt{grpquota} che la attivano rispettivamente per gli
+utenti e per i gruppi, cosa che consente di abilitare solo quelle che
+interessano veramente.
+
+Il meccanismo delle quote prevede che per ciascun filesystem che le supporta
+(i vari \textit{extN}, \textit{btrfs}, \textit{XFS}, \textit{JFS},
+\textit{ReiserFS}) il kernel provveda sia a mantenere aggiornati i dati
+relativi al consumo delle risorse da parte di utenti e/o gruppi che a far
+rispettare i limiti imposti dal sistema con la generazione di un errore di
+\errval{EDQUOT} per tutte le operazioni sui file che porterebbero ad un
+superamento degli stessi. 
+
+Per il mantenimento dei dati di consumo delle risorse vengono usati due file
+riservati (uno per le quote utente e l'altro per le quote gruppo) nella
+directory radice del filesytem su cui si sono attivate le quote;\footnote{la
+  cosa vale per tutti i fileystem tranne \textit{XFS} che mantiene i dati
+  internamente.} con la versione 2 del supporto delle quote, l'unica rimasta
+in uso, questi file sono \texttt{aquota.user} e \texttt{aquota.group}, in
+precedenza erano \texttt{quota.user} e \texttt{quota.group}. Dato che i file
+vengono aggiornati soltanto se il filesystem è stato montato con il supporto
+delle quote, se si abilita questo in un secondo tempo (o se si eseguono
+operazioni sul filesystem senza averlo abilitato) i dati contenuti possono non
+corrispondere esattamente allo stato corrente del consumo delle risorse; per
+questo in genere prima di montare un filesystem su cui sono abilitate le quote
+viene utilizzato il comando \cmd{quotacheck} per verificare e aggiornare i
+dati.
+
+Le restrizioni sul consumo delle risorse prevedono due limiti, il primo viene
+detto \textit{soft limit} e può essere superato per brevi periodi di tempo, il
+secondo viene detto \textit{hard limit} non può mai essere superato. Il
+periodo di tempo per cui è possibile superare il \textit{soft limit} è detto
+``\textsl{periodo di grazia}'' (\textit{grace period}), passato questo tempo
+il passaggio del \textit{soft limit} viene trattato allo stesso modo
+dell'\textit{hard limit}.  Questi limiti riguardano separatamente sia lo
+spazio disco (i blocchi) che il numero di file (gli \textit{inode}) e devono
+pertanto essere specificati per entrambe le risorse. 
+
+La funzione che consente di controllare tutti i vari aspetti della gestione
+delle quote è \funcd{quotactl}, ed il suo prototipo è:
+\begin{functions}
+  \headdecl{sys/types.h} 
+  \headdecl{sys/quota.h}
+  
+  \funcdecl{quotactl(int cmd, const char *special, int id, caddr\_t addr)}
+
+  Esegue una operazione di controllo sulle quote disco.
+
+  \bodydesc{La funzione restituisce $0$ in caso di successo e $-1$ in caso di
+    errore, nel qual caso \var{errno} assumerà uno dei valori:
+  \begin{errlist}
+  \item[\errcode{EACCES}] il file delle quote non è un file normale.
+  \item[\errcode{EBUSY}] si è richiesto \const{Q\_QUOTAON} ma le quote sono
+    già attive.
+  \item[\errcode{EFAULT}] l'indirizzo \param{addr} non è valido.
+  \item[\errcode{EIO}] errore di lettura/scrittura sul file delle quote.
+  \item[\errcode{EMFILE}] non si può aprire il file delle quote avando
+    superato il limite sul numero di file aperti nel sistema. 
+  \item[\errcode{EINVAL}] o \param{cmd} non è un comando valido,
+    o il dispositivo \param{special} non esiste.
+  \item[\errcode{ENODEV}] \param{special} non corrisponde ad un \textit{mount
+      point} attivo.
+  \item[\errcode{ENOPKG}] il kernel è stato compilato senza supporto per le
+    quote. 
+  \item[\errcode{ENOTBLK}] \param{special} non è un dispositivo a blocchi.
+  \item[\errcode{EPERM}] il .
+  \item[\errcode{ESRCH}] è stato richiesto uno fra \const{Q\_GETQUOTA},
+    \const{Q\_SETQUOTA}, \const{Q\_SETUSE}, \const{Q\_SETQLIM} per un
+    filesystem senza quote attivate.
+  \end{errlist}
+}
+\end{functions}
+
+La funzione richiede che si indichi il filesystem sul quale si vuole operare
+tramite il secondo argomento \param{special} che deve indicare il nome del
+file di dispositivo ad esso associato, la funzione richiede che il filesystem
+sia montato con il supporto per le quote. Il terzo argomento \param{id}
+indica, per le operazioni che lo richiedono l'utente o il gruppo (specificati
+rispettivamente per \acr{uid} e \acr{gid}) su cui si vuole operare, infine
+l'ultimo argomento specifica l'indirizzo di una struttura dati che dipende di
+nuovo dal comando. 
+
+
+Il funzionamento di \func{quotactl} è controllato dal valore del primo
+argomento, che indica l'operazione che si vuole eseguire e se la si vuole
+eseguire per le quote disco o le quote gruppo (posto che siano entrm
+
+
+
+% TODO trattare quote disco 
+% vedi man quotactl
+
+
+
 
 \subsection{La gestione delle \textit{capabilities}}
 \label{sec:proc_capabilities}
 
 \subsection{La gestione delle \textit{capabilities}}
 \label{sec:proc_capabilities}
@@ -4186,14 +4291,14 @@ 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
   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. 
+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
 
 Con questo supporto e con le ulteriori modifiche introdotte con il kernel
 2.6.25 il meccanismo delle \textit{capabilities} è stato totalmente
@@ -4230,13 +4335,13 @@ sono mantenuti i diversi insiemi di identificatori di
 sez.~\ref{sec:proc_setuid}; il loro significato, che è rimasto sostanzialmente
 lo stesso anche dopo le modifiche seguite alla instroduzione delle
 \textit{file capabilities} è il seguente:
 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.0cm}\desclabelstyle{\nextlinelabel}}
+\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
 \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 è il comportamento più comune,
-    che prevede però una serie di eccezioni, dipendenti anche dal tipo di
+  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}
     supporto, che vedremo meglio in seguito dato il notevole intreccio nella
     casistica.}
 \item[\textit{inheritable}] l'insieme delle \textit{capabilities}
@@ -4255,78 +4360,109 @@ 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à
   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}.} A differenza delle precedenti 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 di alcuni programmi con maggiori privilegi, in sostanza
-una estensione dell'uso del \acr{suid} di root.  Anche questi tre insiemi sono
-identicati con gli stessi nomi, ma il loro significato è:
-\begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}}
+  \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
 \item[\textit{permitted}] (chiamato originariamente \textit{forced}) l'insieme
-  delle capacità che con l'esecuzione del file verranno comunque aggiunte alle
+  delle capacità che con l'esecuzione del programma verranno aggiunte alle
   capacità \textsl{permesse} del processo.
 \item[\textit{inheritable}] (chiamato originariamente \textit{allowed})
   capacità \textsl{permesse} del processo.
 \item[\textit{inheritable}] (chiamato originariamente \textit{allowed})
-  l'insieme delle capacità che con l'esecuzione del file possono essere
-  ereditate dal processo originario (che cioè vengono tolte dalle
-  \textsl{ereditabili} del processo originale all'esecuzione di
+  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
   \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è le effettive restano vuote).
+  capacità verrà attivata (cioè l'\textit{effective set} resta vuoto).
 \end{basedescript}
 
 \end{basedescript}
 
-Infine come accennato, esiste un altro insieme, il
-\itindex{capabilities~bounding~set} \textit{capabilities bounding set}, il cui
-scopo è quello di costituire un limite alle capacità che possono essere
-attivate per un processo, ma il suo significato è stato completamente
-modificato con l'introduzione delle \textit{file capabilities}. 
-
-
-a meno che non sia dotato della capacità
-    \macro{CAP\_SETPCAP} nel qual caso potrà, come vedremo in seguito,
-    impostarne anche altre. 
-
-che non esegua un programma che è \acr{suid} di root o
-  che ce l'ha nelle \textit{capabilities} presenti sul file
-  eseguibile.\footnote{e neanche in questo caso se vengono usate le estensioni
-    introdotte con il kernel 2.6.26 che vedremo più avanti.}
-
-Fino al kernel 2.6.25 oltre a questi tre insiemi, che sono relativi al singolo
-processo, il kernel manteneva un ulteriore insieme unico 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}
-venivano mascherati con un \textsl{AND} binario del contenuto corrente del
-\textit{capabilities bounding set}, così che il nuovo processo potesse
-disporre soltanto delle capacità in esso elencate.
-
-A lungo il \textit{capabilities bounding set} è stato un parametro generale di
-sistema, accessibile attraverso il contenuto del file
-\procfile{/proc/sys/kernel/cap-bound}, usato per impostare un limite
-universale alle capacità che possono essere accordate ai vari processi.  Il
-suo valore poteva essere impostato 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, era in grado soltanto di rimuovere uno dei bit
-già presenti dell'insieme: questo significava che tolta una
-\textit{capability} dal \textit{capabilities bounding set} questa non era più
-disponibile, neanche per l'amministratore, a meno di un riavvio.
-
-Qualora invece si sia abilitato nel kernel il supporto per le
-\textit{capabilities} dei file il \textit{capabilities bounding set} mantiene
-il suo significato di limite alle capacità che possono essere assegnate al
-processo, ma diventa una proprietà dello stesso (un quarto insieme che il
-processo si porta dietro). In questo 
-
-
-
- viene a costituire un doppio limite:
-
-
+\itindbeg{capabilities~bounding~set}
+
+Infine come accennato, esiste un ulteriore insieme, chiamato
+\textit{capabilities bounding set}, il cui scopo è quello di costituire un
+limite alle capacità che possono essere attivate per un programma. Il suo
+funzionamento però è stato notevolmente modificato con l'introduzione delle
+\textit{file capabilities} e si deve pertanto prendere in considerazione una
+casistica assai complessa.
+
+Per i kernel fino al 2.6.25, o se non si attiva il supporto per le
+\textit{file capabilities}, il \textit{capabilities bounding set} è un
+parametro generale di sistema, il cui valore viene riportato nel file
+\procfile{/proc/sys/kernel/cap-bound}. Il suo valore iniziale è definito in
+sede di compilazione del kernel, e da sempre ha previsto come default la
+presenza di tutte le \textit{capabilities} eccetto \const{CAP\_SETPCAP}. In
+questa situazione solo il primo processo eseguito nel sistema (quello con
+\textsl{pid} 1, di norma \texttt{/sbin/init}) ha la possibilità di
+modificarlo, ogni processo eseguito successivamente, anche se eseguito con
+privilegi di amministratore,\footnote{per essere precisi occorreva la capacità
+  \const{CAP\_SYS\_MODULE}.} è in grado soltanto di rimuovere una delle
+\textit{capabilities} già presenti dell'insieme.
+
+In questo caso l'effetto del \textit{capabilities bounding set} è che solo le
+capacità in esso presenti possono essere trasmesse ad un altro programma
+attraverso una \func{exec}. Questo in sostanza significa che se si elimina da
+esso una capacità, considerato che \texttt{init} (almeno nelle versioni
+ordinarie) non supporta la reimpostazione del \textit{bounding set}, questa
+non sarà più disponibile per nessun processo a meno di un riavvio, eliminando
+così in forma definitiva quella capacità per tutti, compreso
+l'amministratore.\footnote{la qual cosa, visto il default usato per il
+  \textit{capabilities bounding set}, significa anche che \const{CAP\_SETPCAP}
+  non è stata praticamente mai usata nella sua forma orginale.}
+
+Con il kernel 2.6.25 e le \textit{file capabilities} il \textit{bounding set}
+è diventato una proprietà di ciascun processo, che viene propagata invariata
+sia attraverso una \func{fork} che una \func{exec}. In questo caso il file
+\procfile{/proc/sys/kernel/cap-bound} non esiste e \texttt{init} non ha nessun
+ruolo speciale, inoltre in questo caso all'avvio il valore iniziale prevede la
+presenza di tutte le capacità (compresa \const{CAP\_SETPCAP}). 
+
+Con questo nuovo meccanismo il \textit{bounding set} continua a ricoprire un
+ruolo analogo al precedente nel passaggio attraverso una \func{exec}, come
+limite alle capacità che possono essere aggiunte al processo in quanto
+presenti nel \textit{permitted set} del programma messo in esecuzione, in
+sostanza il nuovo programma eseguito potrà ricevere una capacità presente nel
+suo \textit{permitted set} solo se questa è anche nel \textit{bounding
+  set}. In questo modo si possono rimuovere definitivamente certe capacità da
+un processo, anche qualora questo dovesse eseguire un programma
+privilegiato. 
+
+Si tenga presente però che in questo caso il \textit{bounding set} blocca
+esclusivamente le capacità indicate nel \textit{permitted set} del programma
+che verrebbero attivate in caso di esecuzione, non quelle eventualmente già
+presenti nell'\textit{inheritable set} del processo (ad esempio perché
+presenti prima di averle rimosse dal \textit{bounding set}). In questo caso
+eseguendo un programma che abbia anche lui dette capacità nel suo
+\textit{inheritable set} queste verrebbero assegnate.
+
+In questa seconda versione inoltre il \textit{bounding set} costituisce anche
+un limite per le capacità che possono essere aggiunte all'\textit{inheritable
+  set} del processo con \func{capset}, sempre nel senso che queste devono
+essere presenti nel \textit{bounding set} oltre che nel \textit{permitted set}
+del processo.
  
  
+\itindend{capabilities~bounding~set}
  
  
+Come si può notare per fare ricorso alle \textit{capabilities} occorre
+comunque farsi carico di una notevole complessità di gestione, aggravata dalla
+presenza di una radicale modifica del loro funzionamento con l'introduzione
+delle \textit{file capabilities}. Considerato che il meccanismo originale era
+incompleto e decisamente problematico nel caso di programmi che non ne
+sappiano tener conto,\footnote{si ebbe un grosso problema di sicurezza con
+  \texttt{sendmail}, riuscendo a rimuovere \const{CAP\_SETGID}
+  dall'\textit{inheritable set} si ottenne di far fallire una \func{setuid},
+  in maniera inaspettata per il programma (che aspettandosi il successo della
+  funzione non ne controllava lo stato di uscita) con la conseguenza di
+  effettuare come amministratore operazioni che altrimenti sarebbero state
+  eseguite, senza poter apportare danni, da utente normale.}  ci soffermeremo
+solo sulla implementazione completa presente a partire dal kernel 2.6.25,
+tralasciando ulteriori dettagli riguardo la versione precedente.
+
 
 
 Quando un programma viene messo in esecuzione\footnote{cioè quando viene
 
 
 Quando un programma viene messo in esecuzione\footnote{cioè quando viene
@@ -4365,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.
 
 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
   \centering
   \footnotesize
-  \begin{tabular}{|l|p{11.5cm}|}
+  \begin{tabular}{|l|p{11.9cm}|}
     \hline
     \textbf{Capacità}&\textbf{Descrizione}\\
     \hline
     \hline
     \textbf{Capacità}&\textbf{Descrizione}\\
     \hline
@@ -4458,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}).\\
                               \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
     \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
@@ -4483,10 +4615,10 @@ che è opportuno dettagliare maggiormente.
     \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\_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}).\\
                               \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 varie limitazioni
                               di I/O con \func{ioperm} e \func{iopl} (vedi
                               sez.~\ref{sec:file_io_port}).\\
     \const{CAP\_SYS\_RESOURCE}& La capacità di superare le varie limitazioni
@@ -4515,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).}
 
   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
 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
@@ -4572,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}).
 
 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
 
 Per la gestione delle \textit{capabilities} il kernel mette a disposizione due
 funzioni che permettono rispettivamente di leggere ed impostare i valori dei