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.
\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
\end{errlist}}
\end{prototype}
-La funzionne genera un nome univoco sostituendo le \code{XXXXXX} finali di
+La funzionane genera un nome univoco sostituendo le \code{XXXXXX} finali di
\param{template}; dato che \param{template} deve poter essere modificata dalla
funzione non si può usare una stringa costante. Tutte le avvertenze riguardo
alle possibili \itindex{race~condition} \textit{race condition} date per
\errval{EACCES}, \errval{ENOMEM}, \errval{ENAMETOOLONG}.}
\end{functions}
-La funzione \func{stat} legge le informazion del file il cui pathname è
+La funzione \func{stat} legge le informazioni del file il cui pathname è
specificato dalla stringa puntata da \param{file\_name} e le inserisce nel
buffer puntato dall'argomento \param{buf}; la funzione \func{lstat} è identica
a \func{stat} eccetto che se \param{file\_name} è un link simbolico vengono
\errval{EROFS}, \errval{EIO}, \errval{EFAULT}, \errval{ELOOP}.}
\end{functions}
-Emtrambe le funzioni fan sì che la dimensione del file sia troncata ad un
+Entrambe le funzioni fan sì che la dimensione del file sia troncata ad un
valore massimo specificato da \param{length}, e si distinguono solo per il
-fatto che il file viene indicato con il pathame \param{file\_name} per
+fatto che il file viene indicato con il pathname \param{file\_name} per
\func{truncate} e con il file descriptor \param{fd} per \funcd{ftruncate}; se
il file è più lungo della lunghezza specificata i dati in eccesso saranno
perduti.
\index{file!\textit{hole}} \textsl{buco} nel \itindex{sparse~file} file e ad
una lettura si otterranno degli zeri; si tenga presente però che questo
comportamento è supportato solo per filesystem nativi, ad esempio su un
-filesystem non nativo come il VFAT di windows questo non è possibile.
+filesystem non nativo come il VFAT di Windows questo non è possibile.
\subsection{I tempi dei file}
\label{sec:file_file_times}
usando la funzione \funcd{utime}, il cui prototipo è:
\begin{prototype}{utime.h}
{int utime(const char *filename, struct utimbuf *times)}
- Modidica i tempi di ultimo accesso e modifica di un file.
+ Modifica i tempi di ultimo accesso e modifica di un file.
\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{prototype}
{sys/time.h}
{int utimes(const char *filename, struct timeval times[2])}
- Modidica i tempi di ultimo accesso e modifica di un file.
+ Modifica i tempi di ultimo accesso e modifica di un file.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
errore, nel qual caso \var{errno} assumerà uno dei valori:
Come per le precedenti funzioni il primo elemento di \param{times} indica il
tempo di ultimo accesso ed il secondo quello di ultima modifica, e se si usa
-il valore \const{NULL} verrà impostato il tempo corrente sia per l'ultimo
+il valore \val{NULL} verrà impostato il tempo corrente sia per l'ultimo
accesso che per l'ultima modifica. Nei singoli elementi di \param{times} si
possono inoltre utilizzare due valori speciali per il campo \var{tv\_nsec}:
con \const{UTIME\_NOW} si richiede l'uso del tempo corrente, mentre con
\end{enumerate}
Per alcuni filesystem\footnote{i filesystem più comuni (\textsl{ext2},
- \textsl{ext3}, \textsl{ext4}, \textsl{reiserfs}) supportano questa
+ \textsl{ext3}, \textsl{ext4}, \textsl{ReiserFS}) supportano questa
caratteristica, che è mutuata da BSD.} è inoltre prevista un'ulteriore
misura di sicurezza, volta a scongiurare l'abuso dei \itindex{suid~bit} bit
\acr{suid} e \acr{sgid}; essa consiste nel cancellare automaticamente questi
Inizializza un'area di lavoro per una ACL di \param{count} voci.
\bodydesc{La funzione restituisce un puntatore all'area di lavoro in caso di
- successo e \const{NULL} in caso di errore, nel qual caso \var{errno}
+ successo e \val{NULL} in caso di errore, nel qual caso \var{errno}
assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EINVAL}] il valore di \param{count} è negativo.
Produce la rappresentazione testuale di una ACL.
\bodydesc{La funzione restituisce il puntatore ad una stringa con la
- rappresentazione testuale della ACL in caso di successo e \code{NULL} in
+ rappresentazione testuale della ACL in caso di successo e \val{NULL} in
caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
\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
\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 dai kernel 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 di utenti e 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 esplicitamente richiesta;
+questo si fa tramite due distinte opzioni di montaggio, \texttt{usrquota} e
+\texttt{grpquota} che abilitano le quote rispettivamente per gli utenti e per
+i gruppi. Grazie a questo è possibile usare le limitazioni sulle quote solo
+sugli utenti o solo sui gruppi.
+
+Il meccanismo prevede che per ciascun filesystem che supporta le quote disco
+(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. Si tenga presente che questi due compiti sono
+separati, il primo si attiva al montaggio del filesystem con le quote
+attivate, il secondo deve essere abilitato esplicitamente.
+
+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 filesystem su cui si sono attivate le quote;\footnote{la
+ cosa vale per tutti i filesystem 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 in scrittura un filesystem su cui sono
+abilitate le quote in genere 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 *dev, 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 ordinario.
+ \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 avendo
+ superato il limite sul numero di file aperti nel sistema.
+ \item[\errcode{EINVAL}] o \param{cmd} non è un comando valido,
+ o il dispositivo \param{dev} non esiste.
+ \item[\errcode{ENODEV}] \param{dev} non corrisponde ad un \textit{mount
+ point} attivo.
+ \item[\errcode{ENOPKG}] il kernel è stato compilato senza supporto per le
+ quote.
+ \item[\errcode{ENOTBLK}] \param{dev} non è un dispositivo a blocchi.
+ \item[\errcode{EPERM}] non si hanno i permessi per l'operazione richiesta.
+ \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 il filesystem sul quale si vuole operare sia montato
+con il supporto delle quote abilitato; esso deve essere specificato con il
+nome del file di dispositivo nell'argomento \param{dev}. Per le operazioni che
+lo richiedono inoltre si dovrà indicare con l'argomento \param{id} l'utente o
+il gruppo (specificati rispettivamente per \acr{uid} e \acr{gid}) su cui si
+vuole operare. Alcune operazioni usano l'argomento \param{addr} per indicare
+un indirizzo ad un area di memoria il cui utilizzo dipende dall'operazione
+stessa.
+
+Il tipo di operazione che si intende effettuare deve essere indicato tramite
+il primo argomento \param{cmd}, questo in genere viene specificato con
+l'ausilio della macro \macro{QCMD}:
+\begin{functions}
+ \funcdecl{int QCMD(subcmd,type)} Imposta il comando \param{subcmd} per il
+ tipo di quote (utente o gruppo) \param{type}.
+\end{functions}
+\noindent che consente di specificare, oltre al tipo di operazione, se questa
+deve applicarsi alle quote utente o alle quote gruppo, nel qual
+caso \param{type} deve essere rispettivamente \const{USRQUOTA} o
+\const{GRPQUOTA}.
+
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}{|l|p{10cm}|}
+ \hline
+ \textbf{Comando} & \textbf{Descrizione} \\
+ \hline
+ \hline
+ \const{Q\_QUOTAON} & Attiva l'applicazione delle quote disco per il
+ filesystem indicato da \param{dev}, si deve passare
+ in \param{addr} il pathname al file che mantiene le
+ quote, che deve esistere, e \param{id} deve indicare
+ la versione del formato con uno dei valori di
+ tab.~\ref{tab:quotactl_id_format}; l'operazione
+ richiede i privilegi di amministratore.\\
+ \const{Q\_QUOTAOFF} & Disattiva l'applicazione delle quote disco per il
+ filesystem indicato da \param{dev}, \param{id}
+ e \param{addr} vengono ignorati; l'operazione
+ richiede i privilegi di amministratore.\\
+ \const{Q\_GETQUOTA} & Legge i limiti ed i valori correnti delle quote nel
+ filesystem indicato da \param{dev} per l'utente o
+ il gruppo specificato da \param{id}; si devono avere
+ i privilegi di amministratore per leggere i dati
+ relativi ad altri utenti o a gruppi di cui non si fa
+ parte, il risultato viene restituito in una struttura
+ \struct{dqblk} all'indirizzo indicato
+ da \param{addr}.\\
+ \const{Q\_SETQUOTA} & Imposta i limiti per le quote nel filesystem
+ indicato da \param{dev} per l'utente o il gruppo
+ specificato da \param{id} secondo i valori ottenuti
+ dalla struttura \struct{dqblk} puntata
+ da \param{addr}; l'operazione richiede i privilegi
+ di amministratore.\\
+ \const{Q\_GETINFO} & Legge le informazioni (in sostanza i \textit{grace
+ time}) delle quote del filesystem indicato
+ da \param{dev} sulla struttura \struct{dqinfo}
+ puntata da \param{addr}, \param{id} viene ignorato.\\
+ \const{Q\_SETINFO} & Imposta le informazioni delle quote del filesystem
+ indicato da \param{dev} come ottenuti dalla
+ struttura \struct{dqinfo} puntata
+ da \param{addr}, \param{id} viene ignorato;
+ l'operazione richiede i privilegi di amministratore.\\
+ \const{Q\_GETFMT} & Richiede il valore identificativo (quello di
+ tab.~\ref{tab:quotactl_id_format}) per il formato
+ delle quote attualmente in uso sul filesystem
+ indicato da \param{dev}, che sarà memorizzato
+ sul buffer di 4 byte puntato da \param{addr}.\\
+ \const{Q\_SYNC} & Aggiorna la copia su disco dei dati delle quote del
+ filesystem indicato da \param{dev}; in questo
+ caso \param{dev} può anche essere \val{NULL} nel
+ qual caso verranno aggiornati i dati per tutti i
+ filesystem con quote attive, \param{id}
+ e \param{addr} vengono comunque ignorati.\\
+ \const{Q\_GETSTATS} & Ottiene statistiche ed altre informazioni generali
+ relative al sistema delle quote per il filesystem
+ indicato da \param{dev}, richiede che si
+ passi come argomento \param{addr} l'indirizzo di una
+ struttura \struct{dqstats}, mentre i valori
+ di \param{id} e \param{dev} vengono ignorati;
+ l'operazione è obsoleta e non supportata nei kernel
+ più recenti, che espongono la stessa informazione
+ nei file sotto \procfile{/proc/self/fs/quota/}.\\
+% \const{} & .\\
+ \hline
+ \end{tabular}
+ \caption{Possibili valori per l'argomento \param{subcmd} di
+ \macro{QCMD}.}
+ \label{tab:quotactl_commands}
+\end{table}
+
+
+Le diverse operazioni supportate da \func{quotactl}, da indicare con
+l'argomento \param{subcmd} di \macro{QCMD}, sono riportate in
+tab.~\ref{tab:quotactl_commands}. In generale le operazione di attivazione,
+disattivazione e di modifica dei limiti delle quote sono riservate e
+richiedono i privilegi di amministratore.\footnote{per essere precisi tutte le
+ operazioni indicate come privilegiate in tab.~\ref{tab:quotactl_commands}
+ richiedono la \textit{capability} \const{CAP\_SYS\_ADMIN}.} Inoltre gli
+utenti possono soltanto richiedere i dati relativi alle proprie quote, solo
+l'amministratore può ottenere i dati di tutti.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}{|l|p{10cm}|}
+ \hline
+ \textbf{Identificatore} & \textbf{Descrizione} \\
+ \hline
+ \hline
+ \const{QFMT\_VFS\_OLD}& il vecchio (ed obsoleto) formato delle quote.\\
+ \const{QFMT\_VFS\_V0} & la versione 0 usata dal VFS di Linux (supporta
+ \acr{uid} e \acr{gid} a 32 bit e limiti fino a
+ $2^{42}$ byte e $2^{32}$ file.\\
+ \const{QFMT\_VFS\_V1} & la versione 1 usata dal VFS di Linux (supporta
+ \acr{uid} e \acr{GID} a 32 bit e limiti fino a
+ $2^{64}$ byte e $2^{64}$ file.\\
+ \hline
+ \end{tabular}
+ \caption{Valori di identificazione del formato delle quote.}
+ \label{tab:quotactl_id_format}
+\end{table}
+
+Alcuni dei comandi di tab.~\ref{tab:quotactl_commands} sono alquanto complessi
+e richiedono un approfondimento maggiore, in particolare \const{Q\_GETQUOTA} e
+\const{Q\_SETQUOTA} fanno riferimento ad una specifica struttura
+\struct{dqblk}, la cui definizione è riportata in
+fig.~\ref{fig:dqblk_struct},\footnote{la definizione mostrata è quella usata
+ fino dal kernel 2.4.22, non prenderemo in considerazione le versioni
+ obsolete.} nella quale vengono inseriti i dati relativi alle quote di un
+singolo utente.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \includestruct{listati/dqblk.h}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{dqblk} per i dati delle quote disco.}
+ \label{fig:dqblk_struct}
+\end{figure}
+
+La struttura viene usata sia con \const{Q\_GETQUOTA} per ottenere i valori
+correnti dei limiti e dell'occupazione delle risorse, che con
+\const{Q\_SETQUOTA} per effettuare modifiche ai limiti; come si può notare ci
+sono alcuni campi (in sostanza \val{dqb\_curspace}, \val{dqb\_curinodes},
+\val{dqb\_btime}, \val{dqb\_itime}) che hanno senso solo in lettura in quanto
+riportano uno stato non modificabile da \func{quotactl}, come l'uso corrente
+di spazio e \textit{inode} o il tempo che resta nel caso si sia superato un
+\textit{soft limit}.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}{|l|p{10cm}|}
+ \hline
+ \textbf{Costante} & \textbf{Descrizione} \\
+ \hline
+ \hline
+ \const{QIF\_BLIMITS}& Limiti sui blocchi di
+ spazio disco (\val{dqb\_bhardlimit} e
+ \val{dqb\_bsoftlimit}).\\
+ \const{QIF\_SPACE} & Uso corrente
+ dello spazio disco (\val{dqb\_curspace}).\\
+ \const{QIF\_ILIMITS}& Limiti sugli \textit{inode}
+ (\val{dqb\_ihardlimit} e \val{dqb\_isoftlimit}).\\
+ \const{QIF\_INODES} & Uso corrente
+ degli \textit{inode} (\val{dqb\_curinodes}).\\
+ \const{QIF\_BTIME} & Tempo di
+ sforamento del \textit{soft limit} sul numero di
+ blocchi (\val{dqb\_btime}).\\
+ \const{QIF\_ITIME} & Tempo di
+ sforamento del \textit{soft limit} sul numero di
+ \textit{inode} (\val{dqb\_itime}).\\
+ \const{QIF\_LIMITS} & L'insieme di \const{QIF\_BLIMITS} e
+ \const{QIF\_ILIMITS}.\\
+ \const{QIF\_USAGE} & L'insieme di \const{QIF\_SPACE} e
+ \const{QIF\_INODES}.\\
+ \const{QIF\_TIMES} & L'insieme di \const{QIF\_BTIME} e
+ \const{QIF\_ITIME}.\\
+ \const{QIF\_ALL} & Tutti i precedenti.\\
+ \hline
+ \end{tabular}
+ \caption{Costanti per il campo \val{dqb\_valid} di \struct{dqblk}.}
+ \label{tab:quotactl_qif_const}
+\end{table}
+
+
+Inoltre in caso di modifica di un limite si può voler operare solo su una
+delle risorse (blocchi o \textit{inode});\footnote{non è possibile modificare
+ soltanto uno dei limiti (\textit{hard} o \textit{soft}) occorre sempre
+ rispecificarli entrambi.} per questo la struttura prevede un campo apposito,
+\val{dqb\_valid}, il cui scopo è quello di indicare quali sono gli altri campi
+che devono essere considerati validi. Questo campo è una maschera binaria che
+deve essere espressa nei termini di OR aritmetico delle apposite costanti di
+tab.~\ref{tab:quotactl_qif_const}, dove si è riportato il significato di
+ciascuna di esse ed i campi a cui fanno riferimento.
+
+In lettura con \const{Q\_SETQUOTA} eventuali valori presenti in \struct{dqblk}
+vengono comunque ignorati, al momento la funzione sovrascrive tutti i campi e
+li marca come validi in \val{dqb\_valid}. Si possono invece usare
+\const{QIF\_BLIMITS} o \const{QIF\_ILIMITS} per richiedere di impostare solo
+la rispettiva tipologia di limiti con \const{Q\_SETQUOTA}. Si tenga presente
+che il sistema delle quote richiede che l'occupazione di spazio disco sia
+indicata in termini di blocchi e non di byte; dato che questo dipende da come
+si è creato il filesystem potrà essere necessario effettuare qualche
+controllo.\footnote{in genere viene usato un default di 1024 byte per blocco,
+ ma quando si hanno file di dimensioni medie maggiori può convenire usare
+ valori più alti per ottenere prestazioni migliori in conseguenza di un
+ minore frazionamento dei dati e di indici più corti.}
+
+Altre due operazioni che necessitano di un approfondimento sono
+\const{Q\_GETINFO} e \const{Q\_SETINFO}, che sostanzialmente consentono di
+ottenere i dati relativi alle impostazioni delle altre proprietà delle quote,
+che si riducono poi alla durata del \textit{grace time} per i due tipi di
+limiti. In questo caso queste si proprietà generali sono identiche per tutti
+gli utenti, per cui viene usata una operazione distinta dalle
+precedenti. Anche in questo caso le due operazioni richiedono l'uso di una
+apposita struttura \struct{dqinfo}, la cui definizione è riportata in
+fig.~\ref{fig:dqinfo_struct}.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \includestruct{listati/dqinfo.h}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{dqinfo} per i dati delle quote disco.}
+ \label{fig:dqinfo_struct}
+\end{figure}
+
+Come per \struct{dqblk} anche in questo caso viene usato un campo della
+struttura, \val{dqi\_valid} come maschera binaria per dichiarare quale degli
+altri campi sono validi; le costanti usate per comporre questo valore sono
+riportate in tab.~\ref{tab:quotactl_iif_const} dove si è riportato il
+significato di ciascuna di esse ed i campi a cui fanno riferimento.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}{|l|l|}
+ \hline
+ \textbf{Costante} & \textbf{Descrizione} \\
+ \hline
+ \hline
+ \const{IIF\_BGRACE}& Il \textit{grace period} per i blocchi
+ (\val{dqi\_bgrace}).\\
+ \const{IIF\_IGRACE}& Il \textit{grace period} per gli \textit{inode}
+ (\val{dqi\_igrace}).\\
+ \const{IIF\_FLAGS} & I flag delle quote (\val{dqi\_flags}) (inusato ?).\\
+ \const{IIF\_ALL} & Tutti i precedenti.\\
+ \hline
+ \end{tabular}
+ \caption{Costanti per il campo \val{dqi\_valid} di \struct{dqinfo}.}
+ \label{tab:quotactl_iif_const}
+\end{table}
+
+Come in precedenza con \const{Q\_GETINFO} tutti i valori vengono letti
+sovrascrivendo il contenuto di \struct{dqinfo} e marcati come validi in
+\val{dqi\_valid}. In scrittura con \const{Q\_SETINFO} si può scegliere quali
+impostare, si tenga presente che i tempi dei campi \val{dqi\_bgrace} e
+\val{dqi\_igrace} devono essere specificati in secondi.
+
+Come esempi dell'uso di \func{quotactl} utilizzeremo estratti del codice di un
+modulo Python usato per fornire una interfaccia diretta a \func{quotactl}
+senza dover passare dalla scansione dei risultati di un comando. Il modulo si
+trova fra i pacchetti Debian messi a disposizione da Truelite Srl,
+all'indirizzo \url{http://labs.truelite.it/projects/packages}.\footnote{in
+ particolare il codice C del modulo è nel file \texttt{quotamodule.c}
+ visionabile a partire dall'indirizzo indicato nella sezione
+ \textit{Repository}.}
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15.6cm}
+ \includecodesample{listati/get_quota.c}
+ \end{minipage}
+ \caption{Esempio di codice per ottenere i dati delle quote.}
+ \label{fig:get_quota}
+\end{figure}
+
+Il primo esempio, riportato in fig.~\ref{fig:get_quota}, riporta il codice
+della funzione che consente di leggere le quote. La funzione fa uso
+dell'interfaccia dal C verso Python, che definisce i vari simboli \texttt{Py*}
+(tipi di dato e funzioni). Non staremo ad approfondire i dettagli di questa
+interfaccia, per la quale esistono numerose trattazioni dettagliate, ci
+interessa solo esaminare l'uso di \func{quotactl}.
+
+In questo caso la funzione prende come argomenti (\texttt{\small 1}) l'intero
+\texttt{who} che indica se si vuole operare sulle quote utente o gruppo,
+l'identificatore \texttt{id} dell'utente o del gruppo scelto, ed il nome del
+file di dispositivo del filesystem su cui si sono attivate le
+quote.\footnote{questi vengono passati come argomenti dalle funzioni mappate
+ come interfaccia pubblica del modulo (una per gruppi ed una per gli utenti)
+ che si incaricano di decodificare i dati passati da una chiamata nel codice
+ Python.} Questi argomenti vengono passati direttamente alla chiamata a
+\func{quotactl} (\texttt{\small 5}), a parte \texttt{who} che viene abbinato
+con \macro{QCMD} al comando \const{Q\_GETQUOTA} per ottenere i dati.
+
+La funzione viene eseguita all'interno di un condizionale (\texttt{\small
+ 5--16}) che in caso di successo provvede a costruire (\texttt{\small 6--12})
+opportunamente una risposta restituendo tramite la opportuna funzione di
+interfaccia un oggetto Python contenente i dati della struttura \struct{dqblk}
+relativi a uso corrente e limiti sia per i blocchi che per gli
+\textit{inode}. In caso di errore (\texttt{\small 13--15}) si usa un'altra
+funzione dell'interfaccia per passare il valore di \var{errno} come eccezione.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15.6cm}
+ \includecodesample{listati/set_block_quota.c}
+ \end{minipage}
+ \caption{Esempio di codice per impostare i limiti sullo spazio disco.}
+ \label{fig:set_block_quota}
+\end{figure}
+
+Per impostare i limiti sullo spazio disco si potrà usare una seconda funzione,
+riportata in fig.~\ref{fig:set_block_quota}, che prende gli stessi argomenti
+della precedente, con lo stesso significato, a cui si aggiungono i valori per
+il \textit{soft limit} e l'\textit{hard limit}. In questo caso occorrerà,
+prima di chiamare \func{quotactl}, inizializzare opportunamente
+(\texttt{\small 5--7}) i campi della struttura \struct{dqblk} che si vogliono
+utilizzare (quelli relativi ai limiti sui blocchi) e specificare gli stessi
+con \const{QIF\_BLIMITS} in \var{dq.dqb\_valid}.
+
+Fatto questo la chiamata a \func{quotactl}, stavolta con il comando
+\const{Q\_SETQUOTA}, viene eseguita come in precedenza all'interno di un
+condizionale (\texttt{\small 9--14}). In questo caso non essendovi da
+restituire nessun dato in caso di successo si usa (\texttt{\small 10}) una
+apposita funzione di uscita, mentre si restituisce come prima una eccezione
+con il valore di \var{errno} in caso di errore (\texttt{\small 12--13}).
\subsection{La gestione delle \textit{capabilities}}
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
+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 intenzioni originali dello
+standard POSIX, rimuovendo il significato che fino ad allora aveva avuto la
+capacità \const{CAP\_SETPCAP} e cambiando 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 introduzione 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à
+ \const{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 del
+\acr{suid} bit limitato ai privilegi di amministratore. Anche questi tre
+insiemi sono identificati con gli stessi nomi di quello dei processi, 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è non 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} resterà 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, se dotato dei privilegi
+di amministratore, è in grado soltanto di rimuovere una delle
+\textit{capabilities} già presenti dell'insieme.\footnote{per essere precisi
+ occorreva la capacità \const{CAP\_SYS\_MODULE}.}
+
+In questo caso l'effetto complessivo 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 un
+qualunque programma 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
+ originale.}
+
+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} (quello del file) solo se questa è anche nel
+\textit{bounding set} (del processo). In questo modo si possono rimuovere
+definitivamente certe capacità da un processo, anche qualora questo dovesse
+eseguire un programma privilegiato che prevede di riassegnarle.
+
+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, e 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 stesso con \func{capset}, sempre nel senso che queste
+devono essere presenti nel \textit{bounding set} oltre che nel
+\textit{permitted set} del processo. Questo limite vale anche per processi con
+i privilegi di amministratore,\footnote{si tratta sempre di avere la
+ \textit{capability} \const{CAP\_SETPCAP}.} per i quali invece non vale la
+condizione che le \textit{capabilities} da aggiungere nell'\textit{inheritable
+ set} debbano essere presenti nel proprio \textit{permitted set}.\footnote{lo
+ scopo anche in questo caso è ottenere una rimozione definitiva della
+ possibilità di passare una capacità rimossa dal \textit{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
+sapessero tener conto,\footnote{c'è stato un grosso problema di sicurezza con
+ \texttt{sendmail}, riuscendo a rimuovere \const{CAP\_SETGID}
+ dall'\textit{inheritable set} di un processo si ottenne di far fallire
+ \func{setuid} in maniera inaspettata per il programma (che aspettandosi
+ sempre 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.
+
+Riassumendo le regole finora illustrate tutte le \textit{capabilities} vengono
+ereditate senza modifiche attraverso una \func{fork} mentre, indicati con
+\texttt{orig\_*} i valori degli insiemi del processo chiamante, con
+\texttt{file\_*} quelli del file eseguito e con \texttt{bound\_set} il
+\textit{capabilities bounding set}, dopo l'invocazione di \func{exec} il
+processo otterrà dei nuovi insiemi di capacità \texttt{new\_*} secondo la
+formula (espressa in pseudo-codice C) di fig.~\ref{fig:cap_across_exec}; si
+noti come in particolare il \textit{capabilities bounding set} non viene
+comunque modificato e resta lo stesso sia attraverso una \func{fork} che
+attraverso una \func{exec}.
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{12cm}
+ \includecodesnip{listati/cap-results.c}
+ \end{minipage}
+ \caption{Espressione della modifica delle \textit{capabilities} attraverso
+ una \func{exec}.}
+ \label{fig:cap_across_exec}
+\end{figure}
-Fino al kernel 2.6.25 oltre a questi tre insiemi, che sono relativi al singolo
-processo, il kernel manteneva un insieme generale valido per tutto il sistema,
-chiamato \itindex{capabilities~bounding~set} \textit{capabilities bounding
- set}. Ogni volta che un programma viene posto in esecuzione con \func{exec}
-il contenuto degli insiemi \textit{effective} e \textit{permitted} vengono
-mascherati con un \textsl{AND} binario del contenuto corrente del
-\textit{capabilities bounding set}, così che il nuovo processo potrà disporre
-soltanto delle capacità in esso elencate.
-
-Il \textit{capabilities bounding set} era un parametro di sistema, accessibile
-attraverso il contenuto del file \procfile{/proc/sys/kernel/cap-bound}, che
-per questa sua caratteristica consentiva di impostare un limite generale alle
-capacità che possono essere accordate ai vari processi. Questo valore poteva
-essere impostato ad un valore arbitrario esclusivamente dal primo processo
-eseguito nel sistema (di norma cioè da \texttt{/sbin/init}), ogni processo
-eseguito successivamente (cioè con \textsl{pid} diverso da 1) anche se
-eseguito con privilegi di amministratore poteva soltanto rimuovere uno dei bit
-già presenti dell'insieme: questo significa che una volta rimossa una
-\textit{capability} dal \textit{capabilities bounding set} essa non sarà più
-disponibile, neanche per l'amministratore, a meno di un riavvio.
-
-Quando un programma viene messo in esecuzione\footnote{cioè quando viene
- eseguita la \func{execve} con cui lo si lancia; in corrispondenza di una
- \func{fork} le \textit{capabilities} non vengono modificate.} esso eredita
-(nel senso che assume negli insiemi \textit{effective} e \textit{permitted})
-le \textit{capabilities} mantenute nell'insieme \textit{inherited}, a meno che
-non sia eseguito un programma \acr{suid} di root o la \func{exec} sia stata
-eseguita da un programma con \textsl{uid} reale zero; in tal caso il programma
-ottiene tutte le \textit{capabilities} presenti nel \textit{capabilities
- bounding set}. In questo modo si può far si che ad un processo eseguito in
-un secondo tempo possano essere trasmesse solo un insieme limitato di
-capacità, impedendogli di recuperare quelle assenti nell'insieme
-\textit{inherited}. Si tenga presente invece che attraverso una \func{fork}
-vengono mantenute le stesse capacità del processo padre.
+\itindend{capabilities~bounding~set}
+
+A queste regole se ne aggiungono delle altre che servono a riprodurre il
+comportamento tradizionale di un sistema unix-like in tutta una serie di
+circostanze. La prima di queste è relativa a quello che avviene quando si
+esegue un file senza \textit{capabilities}; se infatti si considerasse questo
+equivalente al non averne assegnata alcuna, non essendo presenti capacità né
+nel \textit{permitted set} né nell'\textit{inheritable set} del file,
+nell'esecuzione di un qualunque programma l'amministratore perderebbe tutti i
+privilegi originali dal processo.
+
+Per questo motivo se un programma senza \textit{capabilities} assegnate viene
+eseguito da un processo con \textit{real user-ID} 0, esso verrà trattato come
+se tanto il \textit{permitted set} che l'\textit{inheritable set} fossero con
+tutte le \textit{capabilities} abilitate, con l'\textit{effective set} attivo,
+col risultato di fornire comunque al processo tutte le capacità presenti nel
+proprio \textit{bounding set}. Lo stesso avviene quando l'eseguibile ha attivo
+il \acr{suid} bit ed appartiene all'amministratore, in entrambi i casi si
+riesce così a riottenere il comportamento classico di un sistema unix-like.
+
+Una seconda circostanza è quella relativa a cosa succede alle
+\textit{capabilities} di un processo nelle possibili transizioni da
+\textit{user-ID} nullo a \textit{user-ID} non nullo o viceversa (corrispondenti
+rispettivamente a cedere o riottenere i i privilegi di amministratore) che si
+possono effettuare con le varie funzioni viste in
+sez.~\ref{sec:proc_setuid}. In questo caso la casistica è di nuovo alquanto
+complessa, considerata anche la presenza dei diversi gruppi di identificatori
+illustrati in tab.~\ref{tab:proc_uid_gid}, si avrà allora che:
+\begin{enumerate*}
+\item se si passa da \textit{effective user-ID} nullo a non nullo
+ l'\textit{effective set} del processo viene totalmente azzerato, se
+ viceversa si passa da \textit{effective user-ID} non nullo a nullo il
+ \textit{permitted set} viene copiato nell'\textit{effective set};
+\item se si passa da \textit{file system user-ID} nullo a non nullo verranno
+ cancellate dall'\textit{effective set} del processo tutte le capacità
+ attinenti i file, e cioè \const{CAP\_LINUX\_IMMUTABLE}, \const{CAP\_MKNOD},
+ \const{CAP\_DAC\_OVERRIDE}, \const{CAP\_DAC\_READ\_SEARCH},
+ \const{CAP\_MAC\_OVERRIDE}, \const{CAP\_CHOWN}, \const{CAP\_FSETID} e
+ \const{CAP\_FOWNER} (le prime due a partire dal kernel 2.2.30), nella
+ transizione inversa verranno invece inserite nell'\textit{effective set}
+ quelle capacità della precedente lista che sono presenti nel suo
+ \textit{permitted set}.
+\item se come risultato di una transizione riguardante gli identificativi dei
+ gruppi \textit{real}, \textit{saved} ed \textit{effective} in cui si passa
+ da una situazione in cui uno di questi era nullo ad una in cui sono tutti
+ non nulli,\footnote{in sostanza questo è il caso di quando si chiama
+ \func{setuid} per rimuovere definitivamente i privilegi di amministratore
+ da un processo.} verranno azzerati completamente sia il \textit{permitted
+ set} che l'\textit{effective set}.
+\end{enumerate*}
+\label{sec:capability-uid-transition}
+
+La combinazione di tutte queste regole consente di riprodurre il comportamento
+ordinario di un sistema di tipo Unix tradizionale, ma può risultare
+problematica qualora si voglia passare ad una configurazione di sistema
+totalmente basata sull'applicazione delle \textit{capabilities}; in tal caso
+infatti basta ad esempio eseguire un programma con \acr{suid} bit di proprietà
+dell'amministratore per far riottenere ad un processo tutte le capacità
+presenti nel suo \textit{bounding set}, anche se si era avuta la cura di
+cancellarle dal \textit{permitted set}.
+
+\itindbeg{securebits}
+
+Per questo motivo a partire dal kernel 2.6.26, se le \textit{file
+ capabilities} sono abilitate, ad ogni processo viene stata associata una
+ulteriore maschera binaria, chiamata \textit{securebits flags}, su cui sono
+mantenuti una serie di flag (vedi tab.~\ref{tab:securebits_values}) il cui
+valore consente di modificare queste regole speciali che si applicano ai
+processi con \textit{user-ID} nullo. La maschera viene sempre mantenuta
+attraverso una \func{fork}, mentre attraverso una \func{exec} viene sempre
+cancellato il flag \const{SECURE\_KEEP\_CAPS}.
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}{|l|p{10cm}|}
+ \hline
+ \textbf{Flag} & \textbf{Descrizione} \\
+ \hline
+ \hline
+ \const{SECURE\_KEEP\_CAPS}& Il processo non subisce la cancellazione delle
+ sue \textit{capabilities} quando tutti i suoi
+ \textit{user-ID} passano ad un valore non
+ nullo (regola di compatibilità per il cambio
+ di \textit{user-ID} n. 3 del precedente
+ elenco), sostituisce il precedente uso
+ dell'operazione \const{PR\_SET\_KEEPCAPS} di
+ \func{prctl}.\\
+ \const{SECURE\_NO\_SETUID\_FIXUP}&Il processo non subisce le modifiche
+ delle sue \textit{capabilities} nel passaggio
+ da nullo a non nullo degli \textit{user-ID}
+ dei gruppi \textit{effective} e
+ \textit{file system} (regole di compatibilità
+ per il cambio di \textit{user-ID} nn. 1 e 2 del
+ precedente elenco).\\
+ \const{SECURE\_NOROOT} & Il processo non assume nessuna capacità
+ aggiuntiva quando esegue un programma, anche
+ se ha \textit{user-ID} nullo o il programma ha
+ il \acr{suid} bit attivo ed appartiene
+ all'amministratore (regola di compatibilità
+ per l'esecuzione di programmi senza
+ \textit{capabilities}).\\
+ \hline
+ \end{tabular}
+ \caption{Costanti identificative dei flag che compongono la maschera dei
+ \textit{securebits}.}
+ \label{tab:securebits_values}
+\end{table}
+
+A ciascuno dei flag di tab.~\ref{tab:securebits_values} è inoltre abbinato un
+corrispondente flag di blocco, identificato da una costante omonima con
+l'estensione \texttt{\_LOCKED}, la cui attivazione è irreversibile ed ha
+l'effetto di rendere permanente l'impostazione corrente del corrispondente
+flag ordinario; in sostanza con \const{SECURE\_KEEP\_CAPS\_LOCKED} si rende
+non più modificabile \const{SECURE\_KEEP\_CAPS}, ed analogamente avviene con
+\const{SECURE\_NO\_SETUID\_FIXUP\_LOCKED} per
+\const{SECURE\_NO\_SETUID\_FIXUP} e con \const{SECURE\_NOROOT\_LOCKED} per
+\const{SECURE\_NOROOT}.
+
+Per l'impostazione di questi flag sono stata predisposte due specifiche
+operazioni di \func{prctl} (vedi sez.~\ref{sec:process_prctl}),
+\const{PR\_GET\_SECUREBITS}, che consente di ottenerne il valore, e
+\const{PR\_SET\_SECUREBITS}, che consente di modificarne il valore; per
+quest'ultima sono comunque necessari i privilegi di amministratore ed in
+particolare la capacità \const{CAP\_SETPCAP}. Prima dell'introduzione dei
+\textit{securebits} era comunque possibile ottenere lo stesso effetto di
+\const{SECURE\_KEEP\_CAPS} attraverso l'uso di un'altra operazione di
+\func{prctl}, \const{PR\_SET\_KEEPCAPS}.
+
+\itindend{securebits}
+
+Oltre alla gestione dei \textit{securebits} la nuova versione delle
+\textit{file capabilities} prevede l'uso di \func{prctl} anche per la gestione
+del \textit{capabilities bounding set}, attraverso altre due operazioni
+dedicate, \const{PR\_CAPBSET\_READ} per controllarne il valore e
+\const{PR\_CAPBSET\_DROP} per modificarlo; quest'ultima di nuovo è una
+operazione privilegiata che richiede la capacità \const{CAP\_SETPCAP} e che,
+come indica chiaramente il nome, permette solo la rimozione di una
+\textit{capability} dall'insieme; per i dettagli sull'uso di tutte queste
+operazioni si rimanda alla rilettura di sez.~\ref{sec:process_prctl}.
% 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
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
%
% 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
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
\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. \\
+ amministrativi.\\
\const{CAP\_SYS\_BOOT} & La capacità di fare eseguire un riavvio del
- sistema.\\
-% TODO trattare reboot e kexec
+ sistema (vedi sez.~\ref{sec:sys_reboot}).\\
\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).\\
+ \func{chroot} (vedi sez.~\ref{sec:file_chroot}).\\
+ \const{CAP\_MAC\_ADMIN} & La capacità amministrare il \textit{Mandatory
+ Access Control} di Smack (dal kernel 2.6.25).\\
+ \const{CAP\_MAC\_OVERRIDE}& La capacità evitare il \textit{Mandatory
+ Access Control} di Smack (dal kernel 2.6.25).\\
\const{CAP\_SYS\_MODULE}& La capacità di caricare e rimuovere moduli del
- kernel. \\
- \const{CAP\_SYS\_NICE} & La capacità di modificare le priorità dei
- processi.\\
+ kernel.\\
+ \const{CAP\_SYS\_NICE} & La capacità di modificare le varie priorità dei
+ processi (vedi sez.~\ref{sec:proc_priority}).\\
\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
+ sez.~\ref{sec:process_ptrace}).\\
+ \const{CAP\_SYS\_RAWIO} & La capacità di operare sulle porte
di I/O con \func{ioperm} e \func{iopl} (vedi
- sez.~\ref{sec:file_io_port}).\\
- \const{CAP\_SYS\_RESOURCE}& La capacità di superare le limitazioni sulle
- risorse.\\
+ sez.~\ref{sec:process_io_port}).\\
+ \const{CAP\_SYS\_RESOURCE}& La capacità di superare le varie limitazioni
+ sulle risorse.\\
\const{CAP\_SYS\_TIME} & La capacità di modificare il tempo di sistema
(vedi sez.~\ref{sec:sys_time}).\\
\const{CAP\_SYS\_TTY\_CONFIG}& La capacità di simulare un \textit{hangup}
introdotta dal kernel 2.6.38 come capacità
separata da \const{CAP\_SYS\_ADMIN}.\\
\const{CAP\_WAKE\_ALARM}& La capacità di usare i timer di tipo
- \macro{CLOCK\_BOOTTIME\_ALARM} e
- \macro{CLOCK\_REALTIME\_ALARM}, vedi
+ \const{CLOCK\_BOOTTIME\_ALARM} e
+ \const{CLOCK\_REALTIME\_ALARM}, vedi
sez.~\ref{sec:sig_timer_adv} (dal kernel 3.0).\\
\hline
\end{tabular}
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
+impostazioni degli attributi dei file (vedi sez.~\ref{sec:file_ioctl}) e delle
+ACL (vedi sez.~\ref{sec:file_xattr} e \ref{sec:file_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
\const{CAP\_SYS\_ADMIN}, che copre una serie di operazioni amministrative,
come impostare le quote disco (vedi sez.\ref{sec:disk_quota}), attivare e
disattivare la swap, montare, rimontare e smontare filesystem (vedi
-sez.~\ref{sec:sys_file_config}), effettuare operazioni di controllo sugli
-oggetti dell'IPC di SysV (vedi sez.~\ref{sec:ipc_sysv}), operare sugli
-attributi estesi di classe \texttt{security} o \texttt{trusted} (vedi
-sez.~\ref{sec:file_xattr}), specificare un user-ID arbitrario nella
-trasmissione delle credenziali dei socket (vedi sez.~\ref{sec:socket_xxx}),
-assegnare classi privilegiate per lo scheduling dell'I/O (vedi
+sez.~\ref{sec:sys_file_config}), effettuare operazioni di controllo su
+qualunque oggetto dell'IPC di SysV (vedi sez.~\ref{sec:ipc_sysv}), operare
+sugli attributi estesi dei file di classe \texttt{security} o \texttt{trusted}
+(vedi sez.~\ref{sec:file_xattr}), specificare un \textit{user-ID} arbitrario
+nella trasmissione delle credenziali dei socket (vedi
+sez.~\ref{sec:socket_credential_xxx}), assegnare classi privilegiate
+(\const{IOPRIO\_CLASS\_RT} e prima del kernel 2.6.25 anche
+\const{IOPRIO\_CLASS\_IDLE}) per lo scheduling dell'I/O (vedi
sez.~\ref{sec:io_priority}), superare il limite di sistema sul numero massimo
di file aperti,\footnote{quello indicato da \procfile{/proc/sys/fs/file-max}.}
effettuare operazioni privilegiate sulle chiavi mantenute dal kernel (vedi
-sez.~\ref{sec:io_priority}), usare la funzione \func{lookup\_dcookie} (vedi
-sez.~\ref{sec:xxx_profiling}), usare \const{CLONE\_NEWNS} con \func{unshare},
-(vedi sez.~\ref{sec:process_clone}).
+sez.~\ref{sec:keyctl_management}), usare la funzione \func{lookup\_dcookie},
+usare \const{CLONE\_NEWNS} con \func{unshare} e \func{clone}, (vedi
+sez.~\ref{sec:process_clone}).
Originariamente \const{CAP\_SYS\_NICE} riguardava soltanto la capacità di
aumentare le priorità di esecuzione dei processi, come la diminuzione del
lo spazio disco riservato all'amministratore sui filesystem che lo supportano,
usare la funzione \func{ioctl} per controllare il \textit{journaling} sul
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 di un processo (vedi sez.~\ref{sec:sys_resource_limit}) e quelle sul
+numero di processi, ed i limiti sulle dimensioni dei messaggi delle code del
+SysV IPC (vedi sez.~\ref{sec:ipc_sysv_mq}).
Per la gestione delle \textit{capabilities} il kernel mette a disposizione due
funzioni che permettono rispettivamente di leggere ed impostare i valori dei
\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.
+fig.~\ref{fig:cap_kernel_struct}. Per un certo periodo di tempo era anche
+indicato che per poterle utilizzare fosse necessario che la macro
+\macro{\_POSIX\_SOURCE} risultasse non definita (ed era richiesto di inserire
+una istruzione \texttt{\#undef \_POSIX\_SOURCE} prima di includere
+\texttt{sys/capability.h}) requisito che non risulta più presente.\footnote{e
+ non è chiaro neanche quanto sia mai stato davvero necessario.}
+
+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{viene però
+ garantito che le vecchie funzioni continuino a funzionare.} Pertanto se si
+vogliono scrivere programmi portabili che possano essere eseguiti senza
+modifiche o adeguamenti su qualunque versione del kernel è opportuno
+utilizzare le interfacce di alto livello che vedremo più avanti.
\begin{figure}[!htb]
\footnotesize
\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
+tramite il campo \var{pid}, il PID del processo del quale si vogliono leggere
+o modificare le \textit{capabilities}. Con \func{capset} questo, se si usano
+le \textit{file capabilities}, può essere solo 0 o PID del processo chiamante,
+che sono equivalenti. Il campo \var{version} deve essere impostato al valore
+della versione delle stesse usata dal kernel (quello indicato da una delle
+costanti \texttt{\_LINUX\_CAPABILITY\_VERSION\_n} 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.
+della versione in uso. La versione due è comunque deprecata e non deve essere
+usata (il kernel stamperà un avviso). I valori delle \textit{capabilities}
+devono essere passati come maschere binarie;\footnote{e si tenga presente che
+ i valori di tab.~\ref{tab:proc_capabilities} non possono essere combinati
+ direttamente, indicando il numero progressivo del bit associato alla
+ relativa capacità.} con l'introduzione delle \textit{capabilities} a 64 bit
+inoltre il puntatore \param{datap} non può essere più considerato come
+relativo ad una singola struttura, ma ad un vettore di due
+strutture.\footnote{è questo cambio di significato che ha portato a deprecare
+ la versione 2, che con \func{capget} poteva portare ad un buffer overflow
+ per vecchie applicazioni che continuavano a considerare \param{datap} come
+ puntatore ad una singola struttura.}
Dato che le precedenti funzioni, oltre ad essere specifiche di Linux, non
garantiscono la stabilità nell'interfaccia, è sempre opportuno effettuare la
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
+ \val{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}
+non c'è memoria sufficiente ad allocare i dati) viene restituito \val{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
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}.
+tipo \texttt{char *}. Per questo motivo 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 è:
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
+ \val{NULL} in caso di errore, nel qual caso \var{errno} potrà assumere i
valori \errval{ENOMEM} o \errval{EINVAL}.
}
\end{functions}
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,
+\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}
+
+Una variante di \func{cap\_clear} è \funcd{cap\_clear\_flag} che cancella da
+un \textit{capability state} tutte le \textit{capabilities} di un certo
+insieme fra quelli di pag.~\pageref{sec:capabilities_set}, il suo prototipo
+è:
+\begin{functions}
+ \headdecl{sys/capability.h}
+
+ \funcdecl{int cap\_clear\_flag(cap\_t cap\_p, cap\_flag\_t flag)}
+
+ Cancella dal \textit{capability state} \param{cap\_p} tutte le
+ \textit{capabilities} dell'insieme \param{flag}.
+
+ \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 richiede che si indichi quale degli insiemi si intente cancellare
+con l'argomento \param{flag}. Questo deve essere specificato 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}.
+
+Si possono inoltre confrontare in maniera diretta due diversi
+\textit{capability state} con la funzione \funcd{cap\_compare}; il suo
+prototipo è:
+\begin{functions}
+ \headdecl{sys/capability.h}
+ \funcdecl{int cap\_compare(cap\_t cap\_a, cap\_t cap\_b)}
+
+ Confronta due \textit{capability state}.
+
+ \bodydesc{La funzione ritorna 0 se i \textit{capability state} sono identici
+ ed un valore positivo se differiscono, non sono previsti errori.}
+\end{functions}
+
+La funzione esegue un confronto fra i due \textit{capability state} passati
+come argomenti e ritorna in un valore intero il risultato, questo è nullo se
+sono identici o positivo se vi sono delle differenze. Il valore di ritorno
+della funzione consente inoltre di per ottenere ulteriori informazioni su
+quali sono gli insiemi di \textit{capabilities} che risultano differenti. Per
+questo si può infatti usare la apposita macro \macro{CAP\_DIFFERS}:
+\begin{functions}
+ \funcdecl{int CAP\_DIFFERS(value, flag)} Controlla lo stato di eventuali
+ differenze delle \textit{capabilities} nell'insieme \texttt{flag}.
+\end{functions}
+
+La macro che richiede si passi nell'argomento \texttt{value} il risultato
+della funzione \func{cap\_compare} e in \texttt{flag} l'indicazione (coi
+valori di tab.~\ref{tab:cap_set_identifier}) dell'insieme che si intende
+controllare; restituirà un valore diverso da zero se le differenze rilevate da
+\func{cap\_compare} sono presenti nell'insieme indicato.
+
+Per la gestione dei singoli valori delle \textit{capabilities} presenti in un
+\textit{capability state} l'interfaccia prevede due funzioni specifiche,
\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:
+rispettivamente di leggere o impostare il valore di una capacità all'interno
+in uno dei tre insiemi già citati; i rispettivi prototipi sono:
\begin{functions}
\headdecl{sys/capability.h}
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
+indica su quale dei tre insiemi si intende operare, sempre con i valori di
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}.}
+\type{cap\_value\_t} può indicare una sola capacità.\footnote{in
+ \texttt{sys/capability.h} 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
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.
+\param{flag} lo restituisce nella variabile puntata
+dall'argomento \param{value\_p}. Questa deve essere di tipo
+\type{cap\_flag\_value\_t} ed assumerà uno dei valori di
+tab.~\ref{tab:cap_value_type}. La funzione consente pertanto di leggere solo
+lo 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 è:
+più \textit{capabilities}, anche se solo all'interno dello stesso insieme ed
+allo stesso valore. 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) per le capacità elencate in \param{caps} viene
+indicato dall'argomento \param{value} sempre con i valori di
+tab.~\ref{tab:cap_value_type}.
+
+Per semplificare la gestione delle \textit{capabilities} l'interfaccia prevede
+che sia possibile utilizzare anche una rappresentazione testuale del contenuto
+di un \textit{capability state} e fornisce le opportune funzioni di
+gestione;\footnote{entrambe erano previste dalla bozza dello standard
+ POSIX.1e.} la prima di queste, che consente di ottenere la rappresentazione
+testuale, è \funcd{cap\_to\_text}, il cui prototipo è:
\begin{functions}
\headdecl{sys/capability.h}
\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}.
+testuale del contenuto del \textit{capability 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}.
+
+La rappresentazione testuale, che viene usata anche di programmi di gestione a
+riga di comando, prevede che lo stato venga rappresentato con una stringa di
+testo composta da una serie di proposizioni separate da spazi, ciascuna delle
+quali specifica una operazione da eseguire per creare lo stato finale. Nella
+rappresentazione si fa sempre conto di partire da uno stato in cui tutti gli
+insiemi sono vuoti e si provvede a impostarne i contenuti.
+
+Ciascuna proposizione è nella forma di un elenco di capacità, espresso con i
+nomi di tab.~\ref{tab:proc_capabilities} separati da virgole, seguito da un
+operatore, e dall'indicazione degli insiemi a cui l'operazione si applica. I
+nomi delle capacità possono essere scritti sia maiuscoli che minuscoli, viene
+inoltre riconosciuto il nome speciale \texttt{all} che è equivalente a
+scrivere la lista completa. Gli insiemi sono identificati dalle tre lettere
+iniziali: ``\texttt{p}'' per il \textit{permitted}, ``\texttt{i}'' per
+l'\textit{inheritable} ed ``\texttt{e}'' per l'\textit{effective} che devono
+essere sempre minuscole e se ne può indicare più di uno.
+
+Gli operatori possibili sono solo tre: ``\texttt{+}'' che aggiunge le capacità
+elencate agli insiemi indicati, ``\texttt{-}'' che le toglie e ``\texttt{=}''
+che le assegna esattamente. I primi due richiedono che sia sempre indicato sia
+un elenco di capacità che gli insiemi a cui esse devono applicarsi, e
+rispettivamente attiveranno o disattiveranno le capacità elencate nell'insieme
+o negli insiemi specificati, ignorando tutto il resto. I due operatori possono
+anche essere combinati nella stessa proposizione, per aggiungere e togliere le
+capacità dell'elenco da insiemi diversi.
+
+L'assegnazione si applica invece su tutti gli insiemi allo stesso tempo,
+pertanto l'uso di ``\texttt{=}'' è equivalente alla cancellazione preventiva
+di tutte le capacità ed alla impostazione di quelle elencate negli insiemi
+specificati, questo significa che in genere lo si usa una sola volta
+all'inizio della stringa. In tal caso l'elenco delle capacità può non essere
+indicato e viene assunto che si stia facendo riferimento a tutte quante senza
+doverlo scrivere esplicitamente.
+
+Come esempi avremo allora che un processo non privilegiato di un utente, che
+non ha nessuna capacità attiva, avrà una rappresentazione nella forma
+``\texttt{=}'' che corrisponde al fatto che nessuna capacità viene assegnata a
+nessun insieme (vale la cancellazione preventiva), mentre un processo con
+privilegi di amministratore avrà una rappresentazione nella forma
+``\texttt{=ep}'' in cui tutte le capacità vengono assegnate agli insiemi
+\textit{permitted} ed \textit{effective} (e l'\textit{inheritable} è ignorato
+in quanto per le regole viste a pag.~\ref{sec:capability-uid-transition} le
+capacità verranno comunque attivate attraverso una \func{exec}). Infine, come
+esempio meno banale dei precedenti, otterremo per \texttt{init} una
+rappresentazione nella forma ``\texttt{=ep cap\_setpcap-e}'' dato che come
+accennato tradizionalmente \const{CAP\_SETPCAP} è sempre stata rimossa da
+detto processo.
+
+Viceversa per passare ottenere un \textit{capability state} dalla sua
+rappresentazione testuale si può usare \funcd{cap\_from\_text}, il cui
+prototipo è:
+\begin{functions}
+ \headdecl{sys/capability.h}
+
+ \funcdecl{cap\_t cap\_from\_text(const char *string)}
+
+ Crea un \textit{capability state} dalla sua rappresentazione testuale.
+
+ \bodydesc{La funzione ritorna un puntatore valido 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 restituisce il puntatore ad un \textit{capability state}
+inizializzato con i valori indicati nella stringa \param{string} che ne
+contiene la rappresentazione testuale. La memoria per il \textit{capability
+ state} viene allocata automaticamente dalla funzione e dovrà essere liberata
+con \func{cap\_free}.
+
+Alle due funzioni citate se ne aggiungono altre due che consentono di
+convertire i valori delle costanti di tab.~\ref{tab:proc_capabilities} nelle
+stringhe usate nelle rispettive rappresentazioni e viceversa. Le due funzioni,
+\func{cap\_to\_name} e \func{cap\_from\_name}, sono estensioni specifiche di
+Linux ed i rispettivi prototipi sono:
+\begin{functions}
+ \headdecl{sys/capability.h}
+
+ \funcdecl{char * cap\_to\_name(cap\_value\_t cap)}
+ \funcdecl{int cap\_from\_name(const char *name, cap\_value\_t *cap\_p)}
+ Convertono le \textit{capabilities} dalle costanti alla rappresentazione
+ testuale e viceversa.
+
+ \bodydesc{La funzione \func{cap\_to\_name} ritorna un valore diverso da
+ \val{NULL} in caso di successo e \val{NULL} in caso di errore, mentre
+ \func{cap\_to\_name} ritorna rispettivamente 0 e $-1$; per entrambe in
+ caso di errore \var{errno} può assumere i valori \errval{EINVAL} o
+ \errval{ENOMEM}. }
+\end{functions}
+
+La prima funzione restituisce la stringa (allocata automaticamente e che dovrà
+essere liberata con \func{cap\_free}) che corrisponde al valore della
+capacità \param{cap}, mentre la seconda restituisce nella variabile puntata
+da \param{cap\_p} il valore della capacità rappresentata dalla
+stringa \param{name}.
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 è:
+manipolazione dei \textit{capability state} come strutture di dati;
+l'interfaccia di gestione prevede però anche le funzioni per trattare le
+\textit{capabilities} presenti nei processi. La prima di queste funzioni è
+\funcd{cap\_get\_proc} che consente la lettura delle \textit{capabilities} del
+processo corrente, il suo prototipo è:
\begin{functions}
\headdecl{sys/capability.h}
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
+\textit{capability 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.
%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
+con l'argomento \param{pid}, e restituisce il risultato nel \textit{capability
+ 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
% TODO vedi http://lwn.net/Articles/198557/ e
% http://www.madore.org/~david/linux/newcaps/
-% TODO documentare prctl ...
+
\subsection{La funzione \func{chroot}}
\label{sec:file_chroot}
% TODO introdurre nuova sezione sulle funzionalità di sicurezza avanzate, con
-% dentro chroot SELinux e AppArmor ???
+% dentro chroot SELinux e AppArmor, Tomoyo, Smack, cgroup o che altro ???
+
+% inserire setns (introdotta con il 3.0, vedi http://lwn.net/Articles/407495/)
+% e le funzionalità di isolamento dei container
Benché non abbia niente a che fare con permessi, utenti e gruppi, la funzione
\func{chroot} viene usata spesso per restringere le capacità di accesso di un
% LocalWords: int const char oldpath newpath errno EXDEV EPERM st Smack SysV
% LocalWords: EEXIST EMLINK EACCES ENAMETOOLONG ENOTDIR EFAULT ENOMEM EROFS ls
% LocalWords: ELOOP ENOSPC EIO pathname nlink stat vfat fsck EISDIR ENOENT cap
-% LocalWords: POSIX socket fifo sticky root system call count crash nell' init
+% LocalWords: POSIX socket fifo sticky root system call count crash init linux
% LocalWords: descriptor remove rename rmdir stdio glibc libc NFS DT obj dup
% LocalWords: ENOTEMPTY EBUSY mount point EINVAL soft symbolic tab symlink fig
% LocalWords: dangling access chdir chmod chown creat exec lchown lstat mkdir
% LocalWords: mkfifo mknod opendir pathconf readlink truncate path buff size
-% LocalWords: grub bootloader grep linux MAXSYMLINKS cat VFS sys dirname fcntl
+% LocalWords: grub bootloader grep MAXSYMLINKS cat VFS sys dirname fcntl tv Py
% LocalWords: dev umask IFREG IFBLK IFCHR IFIFO SVr sgid BSD SVID NULL from to
% LocalWords: stream dirent EMFILE ENFILE dirfd SOURCE fchdir readdir struct
-% LocalWords: EBADF namlen HAVE thread entry result value argument fileno ino
+% LocalWords: EBADF namlen HAVE thread entry result value argument fileno ext
% LocalWords: name TYPE OFF RECLEN UNKNOWN REG SOCK CHR BLK type IFTODT DTTOIF
% LocalWords: DTYPE off reclen seekdir telldir void rewinddir closedir select
% LocalWords: namelist compar malloc qsort alphasort versionsort strcoll myls
% LocalWords: EINTR mktemp mkstemp stlib template filename XXXXXX OpenBSD buf
% LocalWords: mkdtemp fstat filedes nell'header padding ISREG ISDIR ISCHR IFMT
% LocalWords: ISBLK ISFIFO ISLNK ISSOCK IFSOCK IFLNK IFDIR ISUID UID ISGID GID
-% LocalWords: ISVTX IRUSR IWUSR IXUSR IRGRP IWGRP IXGRP IROTH IWOTH IXOTH du
-% LocalWords: blocks blksize holes lseek TRUNC ftruncate length lenght ETXTBSY
+% LocalWords: ISVTX IRUSR IWUSR IXUSR IRGRP IWGRP IXGRP IROTH IWOTH IXOTH OLD
+% LocalWords: blocks blksize holes lseek TRUNC ftruncate ETXTBSY length QCMD
% LocalWords: hole atime read utime mtime write ctime modification leafnode cp
% LocalWords: make fchmod fchown utimbuf times actime modtime Mac owner uid fs
% LocalWords: gid Control List patch mandatory control execute group other all
-% LocalWords: dell' effective passwd IGID locking swap saved text IRWXU IRWXG
-% LocalWords: IRWXO ext reiser capability FSETID mask capabilities chroot jail
-% LocalWords: FTP Di filter reiserfs Attributes Solaris FreeBSD libacl hash
+% LocalWords: effective passwd IGID locking swap saved text IRWXU IRWXG subcmd
+% LocalWords: IRWXO capability FSETID mask capabilities chroot jail QUOTAOFF
+% LocalWords: FTP filter Attributes Solaris FreeBSD libacl hash at dqblk SYNC
% LocalWords: XFS SELinux namespace attribute security trusted Draft Modules
% LocalWords: attributes mime ADMIN FOWNER libattr lattr getxattr lgetxattr of
% LocalWords: fgetxattr attr ssize ENOATTR ENOTSUP NUL setxattr lsetxattr list
% LocalWords: fsetxattr flags XATTR REPLACE listxattr llistxattr flistxattr by
-% LocalWords: removexattr lremovexattr fremovexattr attributename lacl acl tv
+% LocalWords: removexattr lremovexattr fremovexattr attributename acl GETINFO
% LocalWords: OBJ setfacl len any prefix separator options NUMERIC IDS SMART
-% LocalWords: INDENT major number IDE Documentation makedev proc copy
+% LocalWords: INDENT major number IDE Documentation makedev proc copy LNK long
% LocalWords: euidaccess eaccess delete def tag qualifier permset calendar NOW
% LocalWords: mutt noatime relatime strictatime atim nsec mtim ctim atimensec
-% LocalWords: mtimensec utimes timeval futimes lutimes ENOSYS futimens OMIT
+% LocalWords: mtimensec utimes timeval futimes lutimes ENOSYS futimens OMIT PR
% LocalWords: utimensat timespec sec futimesat LIDS DAC OVERRIDE SEARCH chattr
% LocalWords: Discrectionary KILL SETGID domain SETUID setuid setreuid SETPCAP
% LocalWords: setresuid setfsuid IMMUTABLE immutable append only BIND SERVICE
% LocalWords: BROADCAST broadcast multicast multicasting RAW PACKET IPC LOCK
% LocalWords: memory mlock mlockall shmctl mmap MODULE RAWIO ioperm iopl PACCT
-% LocalWords: PTRACE ptrace accounting NICE RESOURCE TTY CONFIG hangup vhangup
-% LocalWords: LEASE lease SETFCAP AUDIT permitted inherited inheritable AND
+% LocalWords: ptrace accounting NICE RESOURCE TTY CONFIG hangup vhangup dell'
+% LocalWords: LEASE lease SETFCAP AUDIT permitted inherited inheritable AND nn
% LocalWords: bounding execve fork capget capset header hdrp datap ESRCH undef
-% LocalWords: version libcap lcap clear ncap caps pag capgetp CapInh CapPrm
-% LocalWords: fffffeff CapEff getcap dell'IPC scheduling dell'I lookup dcookie
+% LocalWords: version libcap lcap clear ncap caps pag capgetp CapInh CapPrm RT
+% LocalWords: fffffeff CapEff getcap scheduling lookup dqinfo SETINFO GETFMT
% LocalWords: NEWNS unshare nice NUMA ioctl journaling close XOPEN fdopendir
+% LocalWords: btrfs mkostemp extN ReiserFS JFS Posix usrquota grpquota EDQUOT
+% LocalWords: aquota quotacheck limit grace period quotactl cmd caddr addr dqb
+% LocalWords: QUOTAON ENODEV ENOPKG ENOTBLK GETQUOTA SETQUOTA SETUSE SETQLIM
+% LocalWords: forced allowed sendmail SYSLOG WAKE ALARM CLOCK BOOTTIME dqstats
+% LocalWords: REALTIME securebits GETSTATS QFMT curspace curinodes btime itime
+% LocalWords: QIF BLIMITS bhardlimit bsoftlimit ILIMITS ihardlimit isoftlimit
+% LocalWords: INODES LIMITS USAGE valid dqi IIF BGRACE bgrace IGRACE igrace
+% LocalWords: Python Truelite Srl quotamodule Repository who nell' dall' KEEP
+% LocalWords: SECURE KEEPCAPS prctl FIXUP NOROOT LOCKED dell'IPC dell'I IOPRIO
+% LocalWords: CAPBSET CLASS IDLE dcookie overflow DIFFERS
%%% Local Variables:
%%% mode: latex