\end{funcproto}
\footnotetext{più precisamente la \itindex{capabilities} capacità
- \texttt{CAP\_SYS\_ADMIN}.}
+ \const{CAP\_SYS\_ADMIN}.}
La funzione prende il nome della directory su cui il filesystem è montato e
non il file o il dispositivo che è stato montato,\footnote{questo è vero a
state aggiunte ai filesystem standard con opportune estensioni (vedi
sez.~\ref{sec:file_ACL}) per arrivare a meccanismi di controllo ancora più
sofisticati come il \itindex{Mandatory~Access~Control~(MAC)}
- \textit{mandatory access control} di SE-Linux e delle altre estesioni come
- \textit{Smack} o.} ma nella maggior parte dei casi il meccanismo standard è
-più che sufficiente a soddisfare tutte le necessità più comuni. I tre
-permessi di base associati ad ogni file sono:
+ \textit{mandatory access control} di SE-Linux e delle altre estensioni come
+ \textit{Smack} o \textit{AppArmor}.} ma nella maggior parte dei casi il
+meccanismo standard è più che sufficiente a soddisfare tutte le necessità più
+comuni. I tre permessi di base associati ad ogni file sono:
\begin{itemize*}
\item il permesso di lettura (indicato con la lettera \texttt{r}, dall'inglese
\textit{read}).
potrà cancellare, rinominare, o modificare nei permessi o nelle altre
proprietà.
-Entrambi questi attributi attivano queste restrizioni a livello di filesytem,
+Entrambi questi attributi attivano queste restrizioni a livello di filesystem,
per cui a differenza dei permessi ordinari esse varranno per qualunque utente
compreso l'amministratore. L'amministratore è l'unico che può attivare o
disattivare questi attributi,\footnote{più precisamente un processo con la
origina negli anni '70, quando le risorse di calcolo e di spazio disco erano
minime. Con il venir meno di queste restrizioni è incominciata ad emergere
l'esigenza di poter associare ai file delle ulteriori informazioni astratte
-(quelli che abbiam chiamato genericamente \textsl{metadati}) che però non
+(quelli che abbiamo chiamato genericamente \textsl{metadati}) che però non
potevano trovare spazio nei dati classici mantenuti negli \itindex{inode}
\textit{inode}.
Le tre funzioni rimuovono un attributo esteso operando rispettivamente su di
un file, su un collegamento simbolico o un file descriptor, che vengono
specificati dal valore passato con il loro primo argomento. L'attributo da
-rimuovere deve essere anchein questo caso indicato con
+rimuovere deve essere anche in questo caso indicato con
l'argomento \param{name} secondo le stesse modalità già illustrate in
precedenza per le altre funzioni relative alla gestione degli attributi
estesi.
\const{ACL\_OTHER}, nel caso di \const{ACL\_GROUP\_OBJ} questo vale soltanto
se non è presente una voce di tipo \const{ACL\_MASK}, che è quanto avviene
normalmente se non sono presenti ACL aggiuntive rispetto ai permessi
-ordinari.za Se invece questa è presente verranno tolti dai permessi di
+ordinari. Se invece questa è presente verranno tolti dai permessi di
\const{ACL\_GROUP\_OBJ} (cioè dai permessi per il gruppo proprietario del
file) tutti quelli non presenti in \const{ACL\_MASK}.\footnote{questo diverso
comportamento a seconda delle condizioni è stato introdotto dalla
directory, ed il cui prototipo è:
\begin{funcproto}{
-\fhead{sys/types.}
+\fhead{sys/types.h}
\fhead{sys/acl.h}
\fdecl{int acl\_set\_file(const char *path, acl\_type\_t type, acl\_t acl)}
\fdesc{Imposta una ACL su un file o una directory.}
vengono utilizzati tipi di dato ad hoc.\footnote{descritti nelle singole
pagine di manuale.} Si possono poi copiare i valori di una voce da una ACL
ad un altra con \funcm{acl\_copy\_entry} o eliminare una voce da una ACL con
-\funcm{acl\_delete\_entry}.
+\funcm{acl\_delete\_entry} e verificarne la validità prima di usarla con
+\funcm{acl\_valid} o \funcm{acl\_check}.
\itindend{Access~Control~List~(ACL)}
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
-\itindex{inode} \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
+\itindex{inode} \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, per tutti i filesystem che le
supportano, tramite due distinte opzioni di montaggio, \texttt{usrquota} e
\texttt{grpquota} che abilitano le quote rispettivamente per gli utenti e per
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
+relativi al consumo delle risorse da parte degli utenti e dei gruppi, che a
+far rispettare i limiti imposti dal sistema, con la generazione di un errore
+di \errcode{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 \itindex{inode}
-\textit{inode}) e devono pertanto essere specificati per entrambe le risorse.
+riservati nella directory radice del filesystem su cui si sono attivate le
+quote, uno per le quote utente e l'altro per le quote gruppo.\footnote{la cosa
+ vale per tutti i filesystem tranne \textit{XFS} che mantiene i dati
+ internamente.} Con la versione 2 del supporto delle quote, che da anni è
+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 questi file vengono aggiornati soltanto se il filesystem è stato
+montato attivando il supporto delle quote, se si abilita il supporto in un
+secondo tempo, si si sono eseguite delle operazioni sul filesystem quando era
+disabilitato, i dati contenuti possono non corrispondere esattamente allo
+stato corrente del consumo delle risorse. Per questo motivo prima di montare
+in scrittura un filesystem su cui sono abilitate le quote viene richiesto di
+utilizzare il comando \cmd{quotacheck} per verificare e aggiornare i dati.
+
+Le restrizioni sul consumo delle risorse previste dal sistema delle quote
+prevedono sempre la presenza di due diversi limiti, il primo viene detto
+\textit{soft limit} e può essere superato per brevi periodi di tempo senza che
+causare errori, il secondo viene detto \textit{hard limit} non può mai essere
+superato.
+
+Il periodo di tempo per cui è possibile eccedere rispetto alle restrizioni
+indicate dal \textit{soft limit} è detto ``\textsl{periodo di grazia}''
+(\textit{grace period}), che si attiva non appena si supera la quota da esso
+indicata. Se si continua a restare al di sopra del \textit{soft limit} una
+volta scaduto il \textit{grace period} questo verrà trattato allo stesso modo
+dell'\textit{hard limit} e si avrà l'emissione immediata di un errore.
+
+Si tenga presente infine che entrambi i tipi di limiti (\textit{soft limit} e
+\textit{hard limit}) possono essere disposti separatamente su entrambe le
+risorse di un filesystem, essi cioè possono essere presenti in maniera
+indipendente sia sullo spazio disco, con un massimo per il numero di blocchi,
+che sui file, con un massimo per il numero di \itindex{inode} \textit{inode}.
La funzione di sistema che consente di controllare tutti i vari aspetti della
gestione delle quote è \funcd{quotactl}, ed il suo prototipo è:
quote indicato da \param{addr} non esiste o non è un file ordinario.
\item[\errcode{EBUSY}] si è richiesto \const{Q\_QUOTAON}, ma le quote sono
già attive.
+ \item[\errcode{EFAULT}] \param{addr} non è un puntatore valido.
\item[\errcode{EINVAL}] o \param{cmd} non è un comando valido,
o il dispositivo \param{dev} non esiste.
\item[\errcode{EIO}] errore di lettura/scrittura sul file delle quote.
\const{Q\_SETQUOTA}, \const{Q\_SETUSE}, \const{Q\_SETQLIM} per un
filesystem senza quote attivate.
\end{errlist}
- ed inoltre \errval{EFAULT} e nel suo significato generico.
}
\end{funcproto}
% TODO rivedere gli errori
-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 \ids{UID} e \ids{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}:
+La funzione richiede che il filesystem sul quale si vuole operare, che deve
+essere specificato con il nome del relativo file di dispositivo
+nell'argomento \param{dev}, sia montato con il supporto delle quote
+abilitato. Per le operazioni che lo richiedono inoltre si dovrà indicare con
+l'argomento \param{id} l'utente o il gruppo (specificati rispettivamente per
+\ids{UID} e \ids{GID}) su cui si vuole operare, o altri dati relativi
+all'operazione. Alcune operazioni più complesse usano infine
+l'argomento \param{addr} per indicare un indirizzo ad un area di memoria il
+cui utilizzo dipende dall'operazione stessa.
+
+La funzione prevede la possibilità di eseguire una serie operazioni sulle
+quote molto diverse fra loro, la scelta viene effettuata tramite il primo
+argomento, \param{cmd}, che però oltre all'operazione indica anche a quale
+tipo di quota (utente o gruppo) l'operazione deve applicarsi. Per questo il
+valore di questo argomento viene costruito con l'ausilio della di una apposita
+macro \macro{QCMD}:
{\centering
\vspace{3pt}
\end{funcbox}
}
-\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
+La macro consente di specificare, oltre al tipo di operazione, da indicare con
+l'argomento \param{subcmd} se questa deve applicarsi alle quote utente o alle
+quote gruppo. Questo viene indicato dall'argomento \param{type} che deve
+essere sempre definito ed assegnato ad uno fra i due valori \const{USRQUOTA} e
\const{GRPQUOTA}.
-
\begin{table}[htb]
\centering
\footnotesize
\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
- \ids{UID} e \ids{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
- \ids{UID} e \ids{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
+I possibili valori per l'argomento \param{subcmd} di \macro{QCMD} sono
+riportati in tab.~\ref{tab:quotactl_commands}, che illustra brevemente il
+significato delle operazioni associate a ciascuno di essi. In generale le
+operazioni 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.
+
+
+Alcune delle operazioni di tab.~\ref{tab:quotactl_commands} sono alquanto
+complesse e richiedono un approfondimento maggiore. Le due più rilevanti sono
+probabilmente \const{Q\_GETQUOTA} e \const{Q\_SETQUOTA}, che consentono la
+gestione dei limiti delle quote. Entrambe 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.
+singolo utente o gruppo.
\begin{figure}[!htb]
\footnotesize \centering
\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 \itindex{inode} \textit{inode} o il tempo che resta nel caso si
-sia superato un \textit{soft limit}.
+La struttura \struct{dqblk} 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 disco ed \itindex{inode} \textit{inode}, o il tempo che resta nel caso
+si sia superato un \textit{soft limit}.
-\begin{table}[htb]
+Inoltre in caso di modifica di un limite si può voler operare solo su una
+delle risorse (blocchi o \itindex{inode} \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.
+
+\begin{table}[!htb]
\centering
\footnotesize
\begin{tabular}{|l|p{10cm}|}
\label{tab:quotactl_qif_const}
\end{table}
+In lettura con \const{Q\_SETQUOTA} eventuali valori presenti in \struct{dqblk}
+vengono comunque ignorati, al momento la funzione sovrascrive tutti i campi
+che restituisce 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 la dimensione dei
+blocchi dipende da come si è creato il filesystem potrà essere necessario
+effettuare qualche conversione per avere un valore in byte.\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.}
+
+Come accennato realizzazione delle quote disco ha visto diverse revisioni, con
+modifiche sia del formato delle stesse che dei nomi dei file utilizzate. Per
+questo alcune operazioni di gestione (in particolare \const{Q\_QUOTAON} e
+\const{Q\_GETFMT}) e possono fare riferimento a queste versioni, che vengono
+identificate tramite le costanti di tab.~\ref{tab:quotactl_id_format}.
-Inoltre in caso di modifica di un limite si può voler operare solo su una
-delle risorse (blocchi o \itindex{inode} \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.
+\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
+ \ids{UID} e \ids{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
+ \ids{UID} e \ids{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}
-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}.
+
+
+Altre due operazioni che necessitano di ulteriori spiegazioni sono
+\const{Q\_GETINFO} e \const{Q\_SETINFO}, che consentono di ottenere i dati
+relativi alle impostazioni delle altre proprietà delle quote, che al momento
+sono solo la durata del \textit{grace time} per i due tipi di limiti. Queste
+sono due proprietà generali identiche per tutti gli utenti (e i gruppi), 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
Come accennato in sez.~\ref{sec:proc_access_id} l'architettura classica della
gestione dei privilegi in un sistema unix-like ha il sostanziale problema di
-fornire all'amministratore dei poteri troppo ampi, questo comporta che anche
+fornire all'amministratore dei poteri troppo ampi. Questo comporta che anche
quando si siano predisposte delle misure di protezione per in essere in grado
di difendersi dagli effetti di una eventuale compromissione del
sistema,\footnote{come montare un filesystem in sola lettura per impedirne
modifiche, o marcare un file come immutabile.} una volta che questa sia
stata effettuata e si siano ottenuti i privilegi di amministratore, queste
-potranno essere comunque rimosse.\footnote{nei casi elencati nella precedente
- nota si potrà sempre rimontare il sistema in lettura-scrittura, o togliere
- la marcatura di immutabilità.}
+misure potranno essere comunque rimosse.\footnote{nei casi elencati nella
+ precedente nota si potrà sempre rimontare il sistema in lettura-scrittura, o
+ togliere l'attributo di immutabilità.}
Il problema consiste nel fatto che nell'architettura tradizionale di un
sistema unix-like i controlli di accesso sono basati su un solo livello di
separazione: per i processi normali essi sono posti in atto, mentre per i
-processi con i privilegi di amministratore essi non vengono neppure eseguiti;
-per questo motivo non era previsto alcun modo per evitare che un processo con
+processi con i privilegi di amministratore essi non vengono neppure eseguiti.
+Per questo motivo non era previsto alcun modo per evitare che un processo con
diritti di amministratore non potesse eseguire certe operazioni, o per cedere
definitivamente alcuni privilegi da un certo momento in poi.
Per 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
-\sysctlfile{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
+\sysctlfile{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}.}
+ occorre 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
\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}.
+formula espressa dal seguente pseudo-codice C:
+
+\includecodesnip{listati/cap-results.c}
+
+% \begin{figure}[!htbp]
+% \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}
+
+\noindent e si noti come in particolare il \textit{capabilities bounding set}
+non venga comunque modificato e resti lo stesso sia attraverso una \func{fork}
+che attraverso una \func{exec}.
-\begin{figure}[!htbp]
- \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}
\itindend{capabilities~bounding~set}
\begin{table}[!h!btp]
\centering
\footnotesize
- \begin{tabular}{|l|p{10.5cm}|}
+ \begin{tabular}{|l|p{10cm}|}
\hline
\textbf{Capacità}&\textbf{Descrizione}\\
\hline
%
% POSIX-draft defined capabilities.
%
- \const{CAP\_AUDIT\_CONTROL}& La capacità di abilitare e disabilitare il
+ \const{CAP\_AUDIT\_CONTROL}& Abilitare e disabilitare il
controllo dell'auditing (dal kernel 2.6.11).\\
- \const{CAP\_AUDIT\_WRITE}&La capacità di scrivere dati nel giornale di
+ \const{CAP\_AUDIT\_WRITE}&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
+ \const{CAP\_CHOWN} & Cambiare proprietario e gruppo
proprietario di un file (vedi
sez.~\ref{sec:file_ownership_management}).\\
- \const{CAP\_DAC\_OVERRIDE}& La capacità di evitare il controllo dei
+ \const{CAP\_DAC\_OVERRIDE}& Evitare il controllo dei
permessi di lettura, scrittura ed esecuzione dei
- file,\footnotemark (vedi
- sez.~\ref{sec:file_access_control}).\\
- \const{CAP\_DAC\_READ\_SEARCH}& La capacità di evitare il controllo dei
+ file, (vedi sez.~\ref{sec:file_access_control}).\\
+ \const{CAP\_DAC\_READ\_SEARCH}& Evitare il controllo dei
permessi di lettura ed esecuzione per
le directory (vedi
sez.~\ref{sec:file_access_control}).\\
- \const{CAP\_FOWNER} & La capacità di evitare il controllo della
- proprietà di un file per tutte
- le operazioni privilegiate non coperte dalle
- precedenti \const{CAP\_DAC\_OVERRIDE} e
+ \const{CAP\_FOWNER} & Evitare il controllo della proprietà di un file
+ per tutte le operazioni privilegiate non coperte
+ dalle precedenti \const{CAP\_DAC\_OVERRIDE} e
\const{CAP\_DAC\_READ\_SEARCH}.\\
- \const{CAP\_FSETID} & La capacità di evitare la cancellazione
+ \const{CAP\_FSETID} & Evitare la cancellazione
automatica dei bit \itindex{suid~bit} \acr{suid}
e \itindex{sgid~bit} \acr{sgid} quando un file
per i quali sono impostati viene modificato da
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
+ \const{CAP\_KILL} & Mandare segnali a qualunque
processo (vedi sez.~\ref{sec:sig_kill_raise}).\\
- \const{CAP\_SETFCAP} & La capacità di impostare le
+ \const{CAP\_SETFCAP} & Impostare le
\textit{capabilities} di un file (dal kernel
2.6.24).\\
- \const{CAP\_SETGID} & La capacità di manipolare i group ID dei
+ \const{CAP\_SETGID} & Manipolare i group ID dei
processi, sia il principale che i supplementari,
(vedi sez.~\ref{sec:proc_setgroups}) che quelli
trasmessi tramite i socket \textit{unix domain}
(vedi sez.~\ref{sec:unix_socket}).\\
- \const{CAP\_SETUID} & La capacità di manipolare gli user ID del
+ \const{CAP\_SETUID} & Manipolare gli user ID del
processo (vedi sez.~\ref{sec:proc_setuid}) e di
trasmettere un user ID arbitrario nel passaggio
delle credenziali coi socket \textit{unix
% Linux specific capabilities
%
\hline
- \const{CAP\_IPC\_LOCK} & La capacità di effettuare il \textit{memory
+ \const{CAP\_IPC\_LOCK} & Effettuare il \textit{memory
locking} \itindex{memory~locking} con le
funzioni \func{mlock}, \func{mlockall},
\func{shmctl}, \func{mmap} (vedi
sez.~\ref{sec:proc_mem_lock} e
sez.~\ref{sec:file_memory_map}). \\
- \const{CAP\_IPC\_OWNER} & La capacità di evitare il controllo dei permessi
+ \const{CAP\_IPC\_OWNER} & Evitare il controllo dei permessi
per le operazioni sugli oggetti di
intercomunicazione fra processi (vedi
sez.~\ref{sec:ipc_sysv}).\\
- \const{CAP\_LEASE} & La capacità di creare dei \textit{file lease}
+ \const{CAP\_LEASE} & Creare dei \textit{file lease}
\itindex{file~lease} (vedi
sez.~\ref{sec:file_asyncronous_lease})
pur non essendo proprietari del file (dal kernel
2.4).\\
- \const{CAP\_LINUX\_IMMUTABLE}& La capacità di impostare sui file gli
+ \const{CAP\_LINUX\_IMMUTABLE}& Impostare sui file gli
attributi \textit{immutable} e
\itindex{append~mode} \textit{append-only} (vedi
sez.~\ref{sec:file_perm_overview}) se
supportati.\\
- \const{CAP\_MKNOD} & La capacità di creare
+ \const{CAP\_MKNOD} & Creare
\index{file!di~dispositivo} file di dispositivo
con \func{mknod} (vedi
sez.~\ref{sec:file_mknod}) (dal kernel 2.4).\\
- \const{CAP\_NET\_ADMIN} & La capacità di eseguire alcune operazioni
+ \const{CAP\_NET\_ADMIN} & Eseguire alcune operazioni
privilegiate sulla rete.\\
- \const{CAP\_NET\_BIND\_SERVICE}& La capacità di porsi in ascolto
+ \const{CAP\_NET\_BIND\_SERVICE}& Porsi in ascolto
su porte riservate (vedi
sez.~\ref{sec:TCP_func_bind}).\\
- \const{CAP\_NET\_BROADCAST}& La capacità di consentire l'uso di socket in
+ \const{CAP\_NET\_BROADCAST}& Consentire l'uso di socket in
\itindex{broadcast} \textit{broadcast} e
\itindex{multicast} \textit{multicast}.\\
- \const{CAP\_NET\_RAW} & La capacità di usare socket \texttt{RAW} e
+ \const{CAP\_NET\_RAW} & Usare socket \texttt{RAW} e
\texttt{PACKET} (vedi sez.~\ref{sec:sock_type}).\\
- \const{CAP\_SETPCAP} & La capacità di modifiche privilegiate alle
+ \const{CAP\_SETPCAP} & Effettuare modifiche privilegiate alle
\textit{capabilities}.\\
- \const{CAP\_SYS\_ADMIN} & La capacità di eseguire una serie di compiti
+ \const{CAP\_SYS\_ADMIN} & Eseguire una serie di compiti
amministrativi.\\
- \const{CAP\_SYS\_BOOT} & La capacità di fare eseguire un riavvio del
+ \const{CAP\_SYS\_BOOT} & Eseguire un riavvio del
sistema (vedi sez.~\ref{sec:sys_reboot}).\\
- \const{CAP\_SYS\_CHROOT}& La capacità di eseguire la funzione
+ \const{CAP\_SYS\_CHROOT}& Eseguire la funzione
\func{chroot} (vedi sez.~\ref{sec:file_chroot}).\\
- \const{CAP\_MAC\_ADMIN} & La capacità amministrare il \textit{Mandatory
+ \const{CAP\_MAC\_ADMIN} & Amministrare il \textit{Mandatory
Access Control} di Smack (dal kernel 2.6.25).\\
- \const{CAP\_MAC\_OVERRIDE}& La capacità evitare il \textit{Mandatory
+ \const{CAP\_MAC\_OVERRIDE}& 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
+ \const{CAP\_SYS\_MODULE}& Caricare e rimuovere moduli del
kernel.\\
- \const{CAP\_SYS\_NICE} & La capacità di modificare le varie priorità dei
+ \const{CAP\_SYS\_NICE} & Modificare le varie priorità dei
processi (vedi sez.~\ref{sec:proc_priority}).\\
- \const{CAP\_SYS\_PACCT} & La capacità di usare le funzioni di
+ \const{CAP\_SYS\_PACCT} & Usare le funzioni di
\textit{accounting} dei processi (vedi
sez.~\ref{sec:sys_bsd_accounting}).\\
\const{CAP\_SYS\_PTRACE}& La capacità di tracciare qualunque processo con
\func{ptrace} (vedi
sez.~\ref{sec:process_ptrace}).\\
- \const{CAP\_SYS\_RAWIO} & La capacità di operare sulle porte
+ \const{CAP\_SYS\_RAWIO} & Operare sulle porte
di I/O con \func{ioperm} e \func{iopl} (vedi
sez.~\ref{sec:process_io_port}).\\
- \const{CAP\_SYS\_RESOURCE}& La capacità di superare le varie limitazioni
+ \const{CAP\_SYS\_RESOURCE}& Superare le varie limitazioni
sulle risorse.\\
- \const{CAP\_SYS\_TIME} & La capacità di modificare il tempo di sistema
+ \const{CAP\_SYS\_TIME} & Modificare il tempo di sistema
(vedi sez.~\ref{sec:sys_time}).\\
- \const{CAP\_SYS\_TTY\_CONFIG}& La capacità di simulare un \textit{hangup}
+ \const{CAP\_SYS\_TTY\_CONFIG}&Simulare un \textit{hangup}
della console, con la funzione
\func{vhangup}.\\
- \const{CAP\_SYSLOG} & La capacità di gestire il buffer dei messaggi
+ \const{CAP\_SYSLOG} & Gestire il buffer dei messaggi
del kernel, (vedi sez.~\ref{sec:sess_daemon}),
introdotta dal kernel 2.6.38 come capacità
separata da \const{CAP\_SYS\_ADMIN}.\\
- \const{CAP\_WAKE\_ALARM}& La capacità di usare i timer di tipo
+ \const{CAP\_WAKE\_ALARM}& Usare i timer di tipo
\const{CLOCK\_BOOTTIME\_ALARM} e
\const{CLOCK\_REALTIME\_ALARM}, vedi
sez.~\ref{sec:sig_timer_adv} (dal kernel 3.0).\\
\label{tab:proc_capabilities}
\end{table}
-\footnotetext{vale a dire i permessi caratteristici del modello classico del
- controllo di accesso chiamato \itindex{Discrectionary~Access~Control~(DAC)}
- \textit{Discrectionary Access Control} (da cui il nome DAC).}
+% \footnotetext{vale a dire i permessi caratteristici del modello classico del
+% controllo di accesso chiamato \itindex{Discrectionary~Access~Control~(DAC)}
+% \textit{Discrectionary Access Control} (da cui il nome DAC).}
Prima di dettagliare il significato della capacità più generiche, conviene
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 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
+impostazioni degli attributi dei file 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
Per la gestione delle \textit{capabilities} il kernel mette a disposizione due
funzioni che permettono rispettivamente di leggere ed impostare i valori dei
-tre insiemi illustrati in precedenza. Queste due funzioni sono \funcd{capget}
-e \funcd{capset} e costituiscono l'interfaccia di gestione basso livello; i
-loro rispettivi prototipi sono:
+tre insiemi illustrati in precedenza. Queste due funzioni di sistema sono
+\funcd{capget} e \funcd{capset} e costituiscono l'interfaccia di gestione
+basso livello; i loro rispettivi prototipi sono:
\begin{funcproto}{
\fhead{sys/capability.h}
{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{ESRCH}] si è fatto riferimento ad un processo inesistente.
- \item[\errcode{EPERM}] si è tentato di aggiungere una capacità
- nell'insieme delle \textit{capabilities} permesse, o di impostare una
- capacità non presente nell'insieme di quelle permesse negli insieme
- delle effettive o ereditate, o si è cercato di impostare una
- \textit{capability} di un altro processo senza avare
- \const{CAP\_SETPCAP}.
+ \item[\errcode{EFAULT}] si è indicato un puntatore sbagliato o nullo
+ per \param{hdrp} o \param{datap} (quest'ultimo può essere nullo solo se si
+ usa \func{capget} per ottenere la versione delle \textit{capabilities}
+ usata dal kernel).
+ \item[\errcode{EINVAL}] si è specificato un valore non valido per uno dei
+ campi di \param{hdrp}, in particolare una versione non valida della
+ versione delle \textit{capabilities}.
+ \item[\errcode{EPERM}] si è tentato di aggiungere una capacità nell'insieme
+ delle \textit{capabilities} permesse, o di impostare una capacità non
+ presente nell'insieme di quelle permesse negli insieme delle effettive o
+ ereditate, o si è cercato di impostare una \textit{capability} di un altro
+ processo senza avare \const{CAP\_SETPCAP}.
+ \item[\errcode{ESRCH}] si è fatto riferimento ad un processo inesistente.
\end{errlist}
- ed inoltre \errval{EFAULT} ed \errval{EINVAL}
- nel loro significato generico.}
+}
\end{funcproto}
-
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 un certo periodo di tempo era anche
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
\centering
\label{fig:cap_kernel_struct}
\end{figure}
+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.
+
La struttura a cui deve puntare l'argomento \param{hdrp} serve ad indicare,
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 \itindex{file~capabilities} \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
+PID del processo chiamante, che sono equivalenti. Non tratteremo, essendo
+comunque di uso irrilevante, il caso in cui, in mancanza di tale supporto, la
+funzione può essere usata per modificare le \textit{capabilities} di altri
+processi, per il quale si rimanda alla pagina di manuale.
+
+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
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
+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
dello standard POSIX.1e, non fanno parte della \acr{glibc} e sono fornite in
una libreria a parte,\footnote{la libreria è \texttt{libcap2}, nel caso di
Debian può essere installata con il pacchetto omonimo.} pertanto se un
-programma le utilizza si dovrà indicare esplicitamente l'uso della suddetta
-libreria attraverso l'opzione \texttt{-lcap} del compilatore.
-
-Le funzioni dell'interfaccia delle bozze di POSIX.1e prevedono l'uso di un
-\index{tipo!opaco} tipo di dato opaco, \type{cap\_t}, come puntatore ai dati
-mantenuti nel cosiddetto \textit{capability state},\footnote{si tratta in
- sostanza di un puntatore ad una struttura interna utilizzata dalle librerie,
- i cui campi non devono mai essere acceduti direttamente.} in sono
-memorizzati tutti i dati delle \textit{capabilities}. In questo modo è
-possibile mascherare i dettagli della gestione di basso livello, che potranno
-essere modificati senza dover cambiare le funzioni dell'interfaccia, che
-faranno riferimento soltanto ad oggetti di questo tipo. L'interfaccia
-pertanto non soltanto fornisce le funzioni per modificare e leggere le
-\textit{capabilities}, ma anche quelle per gestire i dati attraverso
-\type{cap\_t}.
+programma le utilizza si dovrà indicare esplicitamente al compilatore l'uso
+della suddetta libreria attraverso l'opzione \texttt{-lcap}.
+
+\itindbeg{capability~state}
+
+Le funzioni dell'interfaccia alle \textit{capabilities} definite nelle bozze
+dello standard POSIX.1e prevedono l'uso di un \index{tipo!opaco} tipo di dato
+opaco, \type{cap\_t}, come puntatore ai dati mantenuti nel cosiddetto
+\textit{capability state},\footnote{si tratta in sostanza di un puntatore ad
+ una struttura interna utilizzata dalle librerie, i cui campi non devono mai
+ essere acceduti direttamente.} in sono memorizzati tutti i dati delle
+\textit{capabilities}.
+
+In questo modo è possibile mascherare i dettagli della gestione di basso
+livello, che potranno essere modificati senza dover cambiare le funzioni
+dell'interfaccia, che pertanto fanno riferimento soltanto ad oggetti di questo
+tipo. L'interfaccia pertanto non soltanto fornisce le funzioni per modificare
+e leggere le \textit{capabilities}, ma anche quelle per gestire i dati
+attraverso i \textit{capability state}, che presentano notevoli affinità,
+essendo parte di bozze dello stesso standard, con quelle già viste per le ACL.
La prima funzione dell'interfaccia è quella che permette di inizializzare un
\textit{capability state}, allocando al contempo la memoria necessaria per i
\fdesc{Crea ed inizializza un \textit{capability state}.}
}
-{La funzione ritorna un valore non nullo in caso di successo e\val{NULL} per
- un errore, nel qual caso \var{errno} potrà assumere solo il valore
- \errval{ENOMEM}.
-}
+{La funzione ritorna un \textit{capability state} in caso di successo e
+ \val{NULL} per un errore, nel qual caso \var{errno} potrà assumere solo il
+ valore \errval{ENOMEM}. }
\end{funcproto}
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 \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
-questo l'interfaccia fornisce una apposita funzione, \funcd{cap\_free}, il cui
-prototipo è:
+ed \var{errno} viene impostata a \errval{ENOMEM}.
+
+La memoria necessaria a mantenere i dati viene automaticamente allocata da
+\func{cap\_init}, ma dovrà essere disallocata esplicitamente quando non è più
+necessaria utilizzando, per questo l'interfaccia fornisce una apposita
+funzione, \funcd{cap\_free}, il cui prototipo è:
\begin{funcproto}{
\fhead{sys/capability.h}
\fdesc{Duplica un \textit{capability state} restituendone una copia.}
}
-{La funzione ritorna un valore non nullo in caso di successo e \val{NULL} per
- un errore, nel qual caso \var{errno} assumerà valori \errval{ENOMEM} o
- \errval{EINVAL} nel loro significato generico.}
+{La funzione ritorna un \textit{capability state} in caso di successo e
+ \val{NULL} per un errore, nel qual caso \var{errno} assumerà i valori
+ \errval{ENOMEM} o \errval{EINVAL} nel loro significato generico.}
\end{funcproto}
restituendo uno stato \textsl{vuoto}, analogo a quello che si ottiene nella
creazione con \func{cap\_init}.
+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{funcproto}{
+\fhead{sys/capability.h}
+\fdecl{int cap\_clear\_flag(cap\_t cap\_p, cap\_flag\_t flag)}
+\fdesc{Cancella delle \textit{capabilities} da un \textit{capability state}.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} potrà assumere solo il valore \errval{EINVAL}.
+}
+\end{funcproto}
+
+La funzione richiede che si indichi quale degli insiemi si intente cancellar
+ad \param{cap\_p} 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
+ \headfile{sys/capability.h}.} uno dei valori illustrati in
+tab.~\ref{tab:cap_set_identifier}.
+
\begin{table}[htb]
\centering
\footnotesize
\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{funcproto}{
-\fhead{sys/capability.h}
-\fdecl{int cap\_clear\_flag(cap\_t cap\_p, cap\_flag\_t flag)}
-\fdesc{ncella dal \textit{capability state} \param{cap\_p} tutte le
- \textit{capabilities} dell'insieme \param{flag}.}
-}
-
-{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
- caso \var{errno} potrà assumere solo il valore \errval{EINVAL}.
-}
-\end{funcproto}
-
-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 \headfile{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 è:
\end{funcbox}
}
-La macro che richiede si passi nell'argomento \texttt{value} il risultato
+La macro richiede che 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
\begin{funcproto}{
\fhead{sys/capability.h}
-\fdecl{int cap\_get\_flag(cap\_t cap\_p, cap\_value\_t cap, cap\_flag\_t
- flag, cap\_flag\_value\_t *value\_p)}
+\fdecl{int cap\_get\_flag(cap\_t cap\_p, cap\_value\_t cap, cap\_flag\_t
+flag,\\
+\phantom{int cap\_get\_flag(}cap\_flag\_value\_t *value\_p)}
\fdesc{Legge il valore di una \textit{capability}.}
\fdecl{int cap\_set\_flag(cap\_t cap\_p, cap\_flag\_t flag, int ncap,
- cap\_value\_t *caps, cap\_flag\_value\_t value)}
+ cap\_value\_t *caps, \\
+\phantom{int cap\_set\_flag(}cap\_flag\_value\_t value)}
\fdesc{Imposta il valore di una \textit{capability}.}
}
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 si intende operare, sempre con i valori di
-tab.~\ref{tab:cap_set_identifier}.
-
-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} può indicare una sola capacità.\footnote{in
+tab.~\ref{tab:cap_set_identifier}. 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} può indicare una sola capacità.\footnote{in
\headfile{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}.}
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} lo restituisce nella variabile puntata
+\param{flag} e 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
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
+(cancellazione o attivazione) per le capacità elencate in \param{caps} viene
indicato dall'argomento \param{value} sempre con i valori di
tab.~\ref{tab:cap_value_type}.
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
+La rappresentazione testuale, che viene usata anche dai 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
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.
+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{=}''
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 è:
+Viceversa per ottenere un \textit{capability state} dalla sua rappresentazione
+testuale si può usare la funzione \funcd{cap\_from\_text}, il cui prototipo è:
\begin{funcproto}{
\fhead{sys/capability.h}
\fdesc{Crea un \textit{capability state} dalla sua rappresentazione testuale.}
}
-{La funzione ritorna un puntatore valid in caso di successo e \val{NULL} per
- un errore, nel qual caso \var{errno} assumerà i valori \errval{EINVAL} o
- \errval{ENOMEM} nel loro significato generico.}
+{La funzione ritorna un \textit{capability state} in caso di successo e
+ \val{NULL} per un errore, nel qual caso \var{errno} assumerà i valori
+ \errval{EINVAL} o \errval{ENOMEM} nel loro significato generico.}
\end{funcproto}
\begin{funcproto}{
\fhead{sys/capability.h}
-\fdecl{char * cap\_to\_name(cap\_value\_t cap)}
+\fdecl{char *cap\_to\_name(cap\_value\_t cap)}
+\fdesc{Converte il valore numerico di una \textit{capabilities} alla sua
+ rappresentazione testuale.}
\fdecl{int cap\_from\_name(const char *name, cap\_value\_t *cap\_p)}
-\fdesc{Convertono le \textit{capabilities} dalle costanti alla rappresentazione
- testuale e viceversa.}
+\fdesc{Converte la rappresentazione testuale di una \textit{capabilities} al
+ suo valore numerico.}
}
{La funzione \func{cap\_to\_name} ritorna un puntatore ad una stringa in caso
di successo e \val{NULL} per un errore, mentre \func{cap\_to\_name} ritorna
- $0$ in caso di successo e $-1$ nel qual caso di errore, per entrambe
- \var{errno}può assumere i valori \errval{EINVAL} o \errval{ENOMEM}.
+ $0$ in caso di successo e $-1$ per un errore, per entrambe in caso di errore
+ \var{errno} assumerà i valori \errval{EINVAL} o \errval{ENOMEM} nel loro
+ significato generico.
}
\end{funcproto}
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
+da \param{cap\_p}, come \itindex{value~result~argument} \textit{value result
+ argument}, il valore della capacità rappresentata dalla
stringa \param{name}.
Fin quei abbiamo trattato solo le funzioni di servizio relative alla
\fdesc{Legge le \textit{capabilities} del processo corrente.}
}
-{La funzione ritorna un valore diverso da \val{NULL} in caso di successo e
+{La funzione ritorna un \textit{capability state} in caso di successo e
\val{NULL} per un errore, nel qual caso \var{errno} assumerà i valori
\errval{EINVAL}, \errval{EPERM} o \errval{ENOMEM} nel loro significato
generico.}
non sarà più utilizzato.
Se invece si vogliono leggere le \textit{capabilities} di un processo
-specifico occorre usare la funzione \funcd{capgetp}, il cui
+specifico occorre usare la funzione \funcd{cap\_get\_pid}, il cui
prototipo\footnote{su alcune pagine di manuale la funzione è descritta con un
prototipo sbagliato, che prevede un valore di ritorno di tipo \type{cap\_t},
ma il valore di ritorno è intero, come si può verificare anche dalla
\begin{funcproto}{
\fhead{sys/capability.h}
-\fdecl{int capgetp(pid\_t pid, cap\_t cap\_d)}
+\fdecl{cap\_t cap\_get\_pid(pid\_t pid)}
\fdesc{Legge le \textit{capabilities} di un processo.}
}
-{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
- caso \var{errno} assumerà i valori \errval{EINVAL}, \errval{EPERM} o
- \errval{ENOMEM} nel loro significato generico.}
-\end{funcproto}
+{La funzione ritorna un \textit{capability state} in caso di successo e
+ \val{NULL} per un errore, nel qual caso \var{errno} assumerà i valori:
-%TODO controllare e correggere i codici di errore!!!
+
+ \errval{ESRCH} o \errval{ENOMEM} nel loro significato generico.
+}
+\end{funcproto}
La funzione legge il valore delle \textit{capabilities} del processo indicato
-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
-valori possono essere letti direttamente nel filesystem \textit{proc}, nei
-file \texttt{/proc/<pid>/status}; ad esempio per \texttt{init} si otterrà
-qualcosa del tipo:
-\begin{Verbatim}
+con l'argomento \param{pid}, e restituisce il risultato tramite il puntatore
+ad \textit{capability state} contenente tutti i dati che provvede ad allocare
+autonomamente e che al solito deve essere disallocato con
+\func{cap\_free}. Qualora il processo indicato non esista si avrà un errore di
+\errval{ESRCH}. Gli stessi valori possono essere letti direttamente nel
+filesystem \textit{proc}, nei file \texttt{/proc/<pid>/status}; ad esempio per
+\texttt{init} si otterrà qualcosa del tipo:
+\begin{Command}
+$ cat /proc/1/status
+\end{Command}
+\begin{Terminal}
...
CapInh: 0000000000000000
CapPrm: 00000000fffffeff
CapEff: 00000000fffffeff
...
-\end{Verbatim}
+\end{Terminal}
+%$
+
+\itindend{capability~state}
Infine per impostare le \textit{capabilities} del processo corrente (non
esiste una funzione che permetta di cambiare le \textit{capabilities} di un
}
{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
- caso \var{errno} assumerà i valori \errval{EINVAL}, \errval{EPERM} o
- \errval{ENOMEM} nel loro significato generico.}
+ caso \var{errno} assumerà i valori:
+ \begin{errlist}
+ \item[\errcode{EPERM}] si è cercato di attivare una capacità non permessa.
+ \end{errlist} ed inoltre \errval{EINVAL} nel suo significato generico.}
\end{funcproto}
La funzione modifica le \textit{capabilities} del processo corrente secondo
quanto specificato con l'argomento \param{cap\_p}, posto che questo sia
possibile nei termini spiegati in precedenza (non sarà ad esempio possibile
-impostare capacità non presenti nell'insieme di quelle permesse). In caso di
-successo i nuovi valori saranno effettivi al ritorno della funzione, in caso
-di fallimento invece lo stato delle capacità resterà invariato. Si tenga
-presente che \textsl{tutte} le capacità specificate tramite \param{cap\_p}
-devono essere permesse; se anche una sola non lo è la funzione fallirà, e per
-quanto appena detto, lo stato delle \textit{capabilities} non verrà modificato
-(neanche per le parti eventualmente permesse).
+impostare capacità non presenti nell'insieme di quelle permesse).
+
+In caso di successo i nuovi valori saranno effettivi al ritorno della
+funzione, in caso di fallimento invece lo stato delle capacità resterà
+invariato. Si tenga presente che \textsl{tutte} le capacità specificate
+tramite \param{cap\_p} devono essere permesse; se anche una sola non lo è la
+funzione fallirà, e per quanto appena detto, lo stato delle
+\textit{capabilities} non verrà modificato (neanche per le parti eventualmente
+permesse).
+
+Oltre a queste funzioni sono presenti due ulteriori funzioni, \funcm{capgetp}
+e \funcm{capsetp}, che svolgono un compito analogo. Queste funzioni risalgono
+alla implementazione iniziale delle \textit{capabilities} ed in particolare
+\funcm{capsetp} consentiva anche di cambiare le capacità di un altro
+processo. Le due funzioni oggi sono deprecate e pertanto eviteremo di
+trattarle, per chi fosse interessato si rimanda alla lettura della loro pagina
+di manuale.
Come esempio di utilizzo di queste funzioni nei sorgenti allegati alla guida
si è distribuito il programma \texttt{getcap.c}, che consente di leggere le
l'opzione \texttt{-p} è impostata (nella sezione di gestione delle opzioni,
che si è tralasciata) al valore del \textsl{pid} del processo di cui si vuole
leggere le \textit{capabilities} e nulla altrimenti. Nel primo caso
-(\texttt{\small 1--6}) si utilizza direttamente (\texttt{\small 2})
-\func{cap\_get\_proc} per ottenere lo stato delle capacità del processo, nel
-secondo (\texttt{\small 7--14}) prima si inizializza (\texttt{\small 8}) uno
-stato vuoto e poi (\texttt{\small 9}) si legge il valore delle capacità del
-processo indicato.
-
-Il passo successivo è utilizzare (\texttt{\small 16}) \func{cap\_to\_text} per
-tradurre in una stringa lo stato, e poi (\texttt{\small 17}) stamparlo; infine
-(\texttt{\small 19--20}) si libera la memoria allocata dalle precedenti
+(\texttt{\small 1--6}) si utilizza (\texttt{\small 2}) \func{cap\_get\_proc}
+per ottenere lo stato delle capacità del processo, nel secondo (\texttt{\small
+ 7--13}) si usa invece \func{cap\_get\_pid} (\texttt{\small 8}) per leggere
+il valore delle capacità del processo indicato.
+
+Il passo successivo è utilizzare (\texttt{\small 15}) \func{cap\_to\_text} per
+tradurre in una stringa lo stato, e poi (\texttt{\small 16}) stamparlo; infine
+(\texttt{\small 18--19}) si libera la memoria allocata dalle precedenti
funzioni con \func{cap\_free} per poi ritornare dal ciclo principale della
funzione.
In certe situazioni però è utile poter impedire che un processo possa accedere
a tutto il filesystem; per far questo si può cambiare la sua directory radice
-con la funzione \funcd{chroot}, il cui prototipo è:
+con la funzione di sistema \funcd{chroot}, il cui prototipo è:
\begin{funcproto}{
\fhead{unistd.h}
{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EPERM}] l'\ids{UID} effettivo del processo non è zero.
+ \item[\errcode{EPERM}] non si hanno i privilegi di amministratore.
\end{errlist}
- ed inoltre errval{EFAULT}, \errval{ENAMETOOLONG}, \errval{ENOENT},
+ ed inoltre \errval{EFAULT}, \errval{ENAMETOOLONG}, \errval{ENOENT},
\errval{ENOMEM}, \errval{ENOTDIR}, \errval{EACCES}, \errval{ELOOP};
\errval{EROFS} e \errval{EIO} nel loro significato generico.}
\end{funcproto}
-La funzione la directory radice del processo a quella specificata da
+La funzione imposta la directory radice del processo a quella specificata da
\param{path} (che ovviamente deve esistere) ed ogni
\itindsub{pathname}{assoluto} \textit{pathname} assoluto usato dalle funzioni
chiamate nel processo sarà risolto a partire da essa, rendendo impossibile
a file al di fuori della sezione di albero in cui è stato
\textsl{imprigionato}.
-Solo un processo con i privilegi di amministratore può usare questa funzione,
-e la nuova radice, per quanto detto in sez.~\ref{sec:proc_fork}, sarà ereditata
-da tutti i suoi processi figli. Si tenga presente però che la funzione non
-cambia la directory di lavoro, che potrebbe restare fuori dalla \textit{chroot
- jail}.
+Solo un processo con i privilegi di amministratore può usare questa
+funzione,\footnote{più precisamente la \itindex{capabilities} capacità
+ \const{CAP\_SYS\_CHROOT}.} e la nuova radice, per quanto detto in
+sez.~\ref{sec:proc_fork}, sarà ereditata da tutti i suoi processi figli. Si
+tenga presente però che la funzione non cambia la directory di lavoro, che
+potrebbe restare fuori dalla \textit{chroot jail}.
Questo è il motivo per cui la funzione è efficace solo se dopo averla eseguita
-si cedono i privilegi di root. Infatti se per un qualche motivo il processo
-resta con \index{directory~di~lavoro} la directory di lavoro fuori dalla
-\textit{chroot jail}, potrà comunque accedere a tutto il resto del filesystem
-usando \itindsub{pathname}{relativo}\textit{pathname} relativi, i quali,
-partendo dalla directory di lavoro che è fuori della \textit{chroot jail},
-potranno (con l'uso di ``\texttt{..}'') risalire fino alla radice effettiva
-del filesystem.
+si cedono i privilegi di amministratore. Infatti se per un qualche motivo il
+processo resta con \index{directory~di~lavoro} la directory di lavoro fuori
+dalla \textit{chroot jail}, potrà comunque accedere a tutto il resto del
+filesystem usando \itindsub{pathname}{relativo} dei \textit{pathname}
+relativi, i quali, partendo da una directory di lavoro fuori della
+\textit{chroot jail}, potranno (con l'uso di ``\texttt{..}'') risalire fino
+alla radice effettiva del filesystem.
Ma se ad un processo restano i privilegi di amministratore esso potrà comunque
portare la sua \index{directory~di~lavoro} directory di lavoro fuori dalla
\textit{chroot jail} in cui si trova. Basta infatti creare una nuova
\textit{chroot jail} con l'uso di \func{chroot} su una qualunque directory
contenuta nell'attuale directory di lavoro. Per questo motivo l'uso di questa
-funzione non ha molto senso quando un processo necessita dei privilegi di root
-per le sue normali operazioni.
+funzione non ha molto senso quando un processo necessita dei privilegi di
+amministratore per le sue normali operazioni.
Un caso tipico di uso di \func{chroot} è quello di un server FTP anonimo, in
questo caso infatti si vuole che il server veda solo i file che deve
% LocalWords: lazy encfs sshfs setfsent getfsent getfsfile getfsspec endfsent
% LocalWords: setmntent getmntent addmntent endmntent hasmntopt such offsetof
% LocalWords: member scan attack EOVERFLOW BITS blkcnt rdev FDCWD functions
+% LocalWords: faccessat grpid lacl AppArmor capsetp
%%% Local Variables:
%%% mode: latex
projects / gapil.git / commitdiff