tipo \const{ACL\_USER} e \const{ACL\_GROUP}.} e da un insieme di permessi.
Ad ogni oggetto sul filesystem si può associare una ACL che ne governa i
permessi di accesso, detta \textit{access ACL}. Inoltre per le directory si
-può impostare una ACL aggiuntiva, detta \textit{default ACL}, che serve ad
+può impostare una ACL aggiuntiva, detta ``\textit{Default ACL}'', che serve ad
indicare quale dovrà essere la ACL assegnata di default nella creazione di un
file all'interno della directory stessa. Come avviene per i permessi le ACL
possono essere impostate solo del proprietario del file, o da un processo con
\const{ACL\_GROUP} e \const{ACL\_GROUP\_OBJ}. Se in una di queste voci si
fosse specificato un permesso non presente in \const{ACL\_MASK} questo
verrebbe ignorato. L'uso di una ACL di tipo \const{ACL\_MASK} è di particolare
-utilità quando essa associata ad una \textit{default ACL} su una directory, in
+utilità quando essa associata ad una \textit{Default ACL} su una directory, in
quanto i permessi così specificati verranno ereditati da tutti i file creati
nella stessa directory. Si ottiene così una sorta di \itindex{umask}
\textit{umask} associata ad un oggetto sul filesystem piuttosto che a un
Dato che le ACL vengono a costituire una estensione dei permessi ordinari, uno
dei problemi che si erano posti nella loro standardizzazione era appunto
quello della corrispondenza fra questi e le ACL. Come accennato i permessi
-ordinari vengono mappati le tre voci di tipo \const{ACL\_USER\_OBJ},
+ordinari vengono mappati nelle tre voci di tipo \const{ACL\_USER\_OBJ},
\const{ACL\_GROUP\_OBJ} e \const{ACL\_OTHER} che devono essere presenti in
qualunque ACL; un cambiamento ad una di queste voci viene automaticamente
riflesso sui permessi ordinari dei file e viceversa.\footnote{per permessi
\func{creat} (vedi sez.~\ref{sec:file_open}), \func{mkdir} (vedi
sez.~\ref{sec:file_dir_creat_rem}), \func{mknod} e \func{mkfifo} (vedi
sez.~\ref{sec:file_mknod}).} che come accennato può essere modificato dalla
-presenza di una \textit{default ACL} sulla directory che andrà a contenerli.
+presenza di una \textit{Default ACL} sulla directory che andrà a contenerli.
Se questa non c'è valgono le regole usuali illustrate in
sez.~\ref{sec:file_perm_management}, per cui essi sono determinati dalla
\itindex{umask} \textit{umask} del processo, e la sola differenza è che i
opaco che identifica ``\textsl{l'oggetto}'' ACL, il valore restituito dalla
funzione non è altro che un puntatore all'area di memoria allocata per i dati
richiesti. Pertanto in caso di fallimento verrà restituito un puntatore nullo
-e si dovrà, in questa come in tutte le funzioni seguenti che restituiscono un
-oggetto di tipo \type{acl\_t}, confrontare il valore di ritorno della funzione
-con ``\code{(acl\_t) NULL}''.\footnote{dato che il valore \var{NULL} in questo
- caso viene restituito come oggetto di tipo \type{acl\_t}, un confronto del
- risultato della funzione con \var{NULL} darebbe un errore di compilazione
- per la differenza di tipo.}
+di tipo ``\code{(acl\_t) NULL}'' e si dovrà, in questa come in tutte le
+funzioni seguenti che restituiscono un oggetto di tipo \type{acl\_t},
+confrontare il valore di ritorno della funzione con \val{NULL}.\footnote{a
+ voler essere estremamente pignoli si dovrebbe usare ``\code{(acl\_t)
+ NULL}'', ma è sufficiente fare un confronto direttamente con \val{NULL}
+ essendo cura del compilatore fare le conversioni necessarie.}
Una volta che si siano completate le operazioni sui dati di una ACL la memoria
allocata per un oggetto \type{acl\_t} dovrà essere liberata esplicitamente
\begin{funcproto}{
\fhead{sys/types.h}
\fhead{sys/acl.h}
-\fdecl{int acl\_free(void * obj\_p)}
+\fdecl{int acl\_free(void *obj\_p)}
\fdesc{Disalloca la memoria riservata per una ACL.}
}
*}'', essa infatti può essere usata non solo per liberare la memoria
allocata per i dati di una ACL, ma anche per quella usata per creare le
stringhe di descrizione testuale delle ACL o per ottenere i valori dei
-qualificatori della una voce di una ACL.
-
-Pertanto a seconda dei casi occorrerà eseguire un \textit{cast} a ``\ctyp{void
- *}'' del tipo di dato di cui si vuole eseguire la disallocazione. Si tenga
-presente poi che oltre a \func{acl\_init} ci sono molte altre funzioni che
-possono allocare memoria per i dati delle ACL, è pertanto opportuno tenere
-traccia di tutte le chiamate a queste funzioni perché alla fine delle
-operazioni tutta la memoria allocata dovrà essere liberata con
+qualificatori della una voce di una ACL. L'uso del tipo generico ``\ctyp{void
+ *}'' consente di evitare di eseguire un \textit{cast} al tipo di dato di cui
+si vuole effettuare la disallocazione.
+
+Si tenga presente poi che oltre a \func{acl\_init} ci sono molte altre
+funzioni che possono allocare memoria per i dati delle ACL, è pertanto
+opportuno tenere traccia di tutte le chiamate a queste funzioni perché alla
+fine delle operazioni tutta la memoria allocata dovrà essere liberata con
\func{acl\_free}.
Una volta che si abbiano a disposizione i dati di una ACL tramite il
\begin{funcproto}{
\fhead{sys/types.h}
\fhead{sys/acl.h}
-\fdecl{char * acl\_to\_text(acl\_t acl, ssize\_t *len\_p)}
+\fdecl{char *acl\_to\_text(acl\_t acl, ssize\_t *len\_p)}
\fdesc{Produce la rappresentazione testuale di una ACL.}
}
\textit{value result argument}) la dimensione della stringa con la
rappresentazione testuale, non comprendente il carattere nullo finale.
-La seconda funzione, che permette di controllare con dovizia di dettagli la
-generazione della stringa contenente la rappresentazione testuale della ACL, è
-\funcd{acl\_to\_any\_text}, ed il suo prototipo è:
+La seconda funzione, che permette di controllare con una gran dovizia di
+particolari la generazione della stringa contenente la rappresentazione
+testuale della ACL, è \funcd{acl\_to\_any\_text}, ed il suo prototipo è:
\begin{funcproto}{
\fhead{sys/types.h}
\fhead{sys/acl.h}
-\fdecl{char * acl\_to\_any\_text(acl\_t acl, const char *prefix, char
+\fdecl{char *acl\_to\_any\_text(acl\_t acl, const char *prefix, char
separator, int options)}
\fdesc{Produce la rappresentazione testuale di una ACL.}
}
\itindend{Access~Control~List~(ACL)}
+Come esempio di utilizzo di queste funzioni nei sorgenti allegati alla guida
+si è distribuito il programma \texttt{mygetfacl.c}, che consente di leggere le
+ACL di un file, passato come argomento.
+
+\begin{figure}[!htbp]
+ \footnotesize \centering
+ \begin{minipage}[c]{\codesamplewidth}
+ \includecodesample{listati/mygetfacl.c}
+ \end{minipage}
+ \normalsize
+ \caption{Corpo principale del programma \texttt{mygetfacl.c}.}
+ \label{fig:proc_mygetfacl}
+\end{figure}
+
+La sezione principale del programma, da cui si è rimossa la sezione sulla
+gestione delle opzioni, è riportata in fig.~\ref{fig:proc_mygetfacl}. Il
+programma richiede un unico argomento (\texttt{\small 16--20}) che indica il
+file di cui si vuole leggere la ACL. Se questo è presente si usa
+(\texttt{\small 22}) la funzione \func{get\_acl\_file} per leggerne la ACL, e
+si controlla (\texttt{\small 23--26}) se l'operazione ha successo, uscendo con
+un messaggio di errore in caso contrario.
+
+Ottenuta la ACL la si converte in formato testuale (\texttt{\small 27}) con la
+funzione \func{acl\_to\_text}, controllando di nuovo se l'operazione ha
+successo (\texttt{\small 23--26}) ed uscendo in caso contrario. Si provvede
+infine a stampare la rappresentazione testuale (\texttt{\small 28}) e dopo
+aver liberato (\texttt{\small 29--30}) le risorse allocate automaticamente,
+si conclude l'esecuzione.
+
\subsection{La gestione delle quote disco}
\label{sec:disk_quota}
-Quella delle quote disco è una funzionalità introdotta inizialmente da BSD, e
+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.
+\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
+attivata esplicitamente. 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
i gruppi. Così è possibile usare le limitazioni sulle quote o sugli utenti o
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.
+separati, il primo si attiva al montaggio del filesystem con il supporto per
+le quote, il secondo deve essere abilitato esplicitamente.
Per il mantenimento dei dati di consumo delle risorse vengono usati due file
riservati nella directory radice del filesystem su cui si sono attivate le
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.
+secondo tempo e nel frattempo sono state eseguite delle operazioni sul
+filesystem quando il supporto 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.
+causare errori per lo sforamento delle quote, il secondo viene detto
+\textit{hard limit} e 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}''
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
+essere sempre definito ed assegnato ad uno fra i due valori \const{USRQUOTA} o
\const{GRPQUOTA}.
\begin{table}[htb]
un insieme di \textsl{capacità} distinte. L'idea era che queste capacità
potessero essere abilitate e disabilitate in maniera indipendente per ciascun
processo con privilegi di amministratore, permettendo così una granularità
-molto più fine nella distribuzione degli stessi che evitasse la originaria
-situazione di ``\textsl{tutto o nulla}''.
+molto più fine nella distribuzione degli stessi che evitasse la situazione
+originaria di ``\textsl{tutto o nulla}''.
\itindbeg{file~capabilities}
\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
+Per l'impostazione di questi flag sono state 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
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.
+\textit{capabilities} presenti nel suo \textit{permitted set} su 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à è sempre stata assente (a meno di specifiche ricompilazioni del
+kernel) nel \textit{capabilities bounding set} usato di default, essa non è
+neanche mai stata realmente disponibile.
Con l'introduzione \itindex{file~capabilities} \textit{file capabilities} e
il cambiamento del significato del \textit{capabilities bounding set} la
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. 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.
+tramite il campo \var{pid}, il \ids{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 il \ids{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, se
+interessati, alla lettura della 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).
+versione due è comunque deprecata e non deve essere usata, ed il kernel
+stamperà un avviso se lo si fa.
I valori delle \textit{capabilities} devono essere passati come maschere
binarie;\footnote{e si tenga presente che i valori di
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
+dell'interfaccia, che 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 funzione permette di liberare la memoria allocata dalle altre funzioni
della libreria sia per un \textit{capability state}, nel qual caso l'argomento
-dovrà essere un dato di tipo \type{cap\_t}, che per una descrizione testuale
-dello stesso,\footnote{cioè quanto ottenuto tramite la funzione
- \func{cap\_to\_text}.} nel qual caso l'argomento dovrà essere un dato di
-tipo \texttt{char *}. Per questo 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}.
+sarà 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 sarà un dato di tipo
+\texttt{char *}. Per questo motivo l'argomento \param{obj\_d} è dichiarato
+come \texttt{void *}, per evitare la necessità di eseguire un \textit{cast},
+ma dovrà comunque 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 è:
copia, che conterrà gli stessi valori delle \textit{capabilities} presenti
nell'originale. La memoria necessaria viene allocata automaticamente dalla
funzione. Una volta effettuata la copia i due \textit{capability state}
-potranno essere modificati in maniera completamente
-indipendente.\footnote{alla fine delle operazioni si ricordi però di
- disallocare anche la copia, oltre all'originale. }
+potranno essere modificati in maniera completamente indipendente, ed alla fine
+delle operazioni si dovrà disallocare anche la copia, oltre all'originale.
Una seconda classe di funzioni di servizio previste dall'interfaccia sono
quelle per la gestione dei dati contenuti all'interno di un \textit{capability
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
-è:
+insieme fra quelli elencati a pag.~\pageref{sec:capabilities_set}, il suo
+prototipo è:
\begin{funcproto}{
\fhead{sys/capability.h}
}
\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
+La funzione richiede che si indichi quale degli insiemi si intente cancellare
+da \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
\fdesc{Imposta il valore di una \textit{capability}.}
}
-{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+{Le funzioni ritornano $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 \func{cap\_get\_flag} legge lo stato della capacità indicata
dall'argomento \param{cap} all'interno dell'insieme indicato dall'argomento
-\param{flag} e lo restituisce nella variabile puntata
+\param{flag} e lo restituisce come \itindex{value~result~argument}
+\textit{value result argument} 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
\begin{funcproto}{
\fhead{sys/capability.h}
-\fdecl{char * cap\_to\_text(cap\_t caps, ssize\_t * length\_p)}
+\fdecl{char *cap\_to\_text(cap\_t caps, ssize\_t *length\_p)}
\fdesc{Genera una visualizzazione testuale delle \textit{capabilities}.}
}
La funzione ritorna l'indirizzo di una stringa contente la descrizione
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
+restituisce come \itindex{value~result~argument} \textit{value result
+ argument} 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 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{ESRCH} o \errval{ENOMEM} nel loro significato generico.
-}
+ \val{NULL} per un errore, nel qual caso \var{errno} assumerà i valori
+ \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 tramite il puntatore
-ad \textit{capability state} contenente tutti i dati che provvede ad allocare
-autonomamente e che al solito deve essere disallocato con
+ad un \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
\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
-altro processo) si deve usare la funzione \funcd{cap\_set\_proc}, il cui
-prototipo è:
+Infine per impostare le \textit{capabilities} del processo corrente (nella
+bozza dello standard POSIX.1e non esiste una funzione che permetta di cambiare
+le \textit{capabilities} di un altro processo) si deve usare la funzione
+\funcd{cap\_set\_proc}, il cui prototipo è:
\begin{funcproto}{
\fhead{sys/capability.h}
\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.
+Oltre a queste funzioni su Linux 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} consentirebbe anche, come possibile in quel
+caso, 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
quando lo si lancia, il che può sembrare inutile, ma serve a mostrarci quali
sono le \textit{capabilities} standard che ottiene un processo lanciato
dalla riga di comando.} o tramite l'opzione \texttt{-p}, quelle di un
-processo qualunque il cui pid viene passato come parametro dell'opzione.
+processo qualunque il cui \ids{PID} viene passato come parametro dell'opzione.
\begin{figure}[!htbp]
\footnotesize \centering
La sezione principale del programma è riportata in fig.~\ref{fig:proc_getcap},
e si basa su una condizione sulla variabile \var{pid} che se si è usato
l'opzione \texttt{-p} è impostata (nella sezione di gestione delle opzioni,
-che si è tralasciata) al valore del \textsl{pid} del processo di cui si vuole
+che si è tralasciata) al valore del \ids{PID} del processo di cui si vuole
leggere le \textit{capabilities} e nulla altrimenti. Nel primo caso
(\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
\subsection{La gestione dei {chroot}}
\label{sec:file_chroot}
-% TODO introdurre nuova sezione sulle funzionalità di sicurezza avanzate, con
-% dentro chroot SELinux e AppArmor, Tomoyo, Smack, cgroup o che altro ???
+% TODO: valutare se introdurre una nuova sezione sulle funzionalità di
+% sicurezza avanzate, con dentro chroot SELinux e AppArmor, Tomoyo, Smack,
+% cgroup o altro
+
+% TODO: trattare la funzione setns e i namespace file descriptors (vedi
+% http://lwn.net/Articles/407495/) introdotti con il kernel 3.0
+
+% TODO: spostare chroot e le funzioni affini relative ai container da qualche
+% parte diversa se è il caso.
-% 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
programma ad una sezione limitata del filesystem, per cui ne parleremo in
questa sezione.
-% TODO riferimenti ai bind mount, link simbolici ecc.
-
Come accennato in sez.~\ref{sec:proc_fork} ogni processo oltre ad una
\index{directory~di~lavoro} directory di lavoro, ha anche una directory
\textsl{radice}\footnote{entrambe sono contenute in due campi (rispettivamente
\var{pwd} e \var{root}) di \kstruct{fs\_struct}; vedi
fig.~\ref{fig:proc_task_struct}.} che, pur essendo di norma corrispondente
-alla radice dell'albero di file e directory come visto dal kernel (ed
-illustrato in sez.~\ref{sec:file_pathname}), ha per il processo il significato
-specifico di directory rispetto alla quale vengono risolti i
+alla radice dell'albero dei file dell'intero sistema, ha per il processo il
+significato specifico di directory rispetto alla quale vengono risolti i
\itindsub{pathname}{assoluto}\textit{pathname} assoluti.\footnote{cioè quando
un processo chiede la risoluzione di un \textit{pathname}, il kernel usa
sempre questa directory come punto di partenza.} Il fatto che questo valore
sia specificato per ogni processo apre allora la possibilità di modificare le
-modalità di risoluzione dei \textit{pathname} assoluti da parte di un processo
-cambiando questa directory, così come si fa coi
-\itindsub{pathname}{relativo}\textit{pathname} relativi cambiando la
+modalità di risoluzione dei \itindsub{pathname}{assoluto} \textit{pathname}
+assoluti da parte di un processo cambiando questa directory, così come si fa
+coi \itindsub{pathname}{relativo} \textit{pathname} relativi cambiando la
\index{directory~di~lavoro} directory di lavoro.
-Normalmente la directory radice di un processo coincide anche con la radice
-del filesystem usata dal kernel, e dato che il suo valore viene ereditato dal
-padre da ogni processo figlio, in generale i processi risolvono i
-\itindsub{pathname}{assoluto} \textit{pathname} assoluti a partire sempre
-dalla stessa directory, che corrisponde alla radice del sistema.
+Normalmente la directory radice di un processo coincide con la radice generica
+dell'albero dei file, che è la directory che viene montata direttamente dal
+kernel all'avvio secondo quanto illustrato in sez.~\ref{sec:file_pathname}.
+Questo avviene perché, come visto in sez.~\ref{cha:process_handling} la
+directory radice di un processo viene ereditata dal padre attraverso una
+\func{fork} e mantenuta attraverso una \func{exec}, e siccome tutti i processi
+derivano da \cmd{init}, che ha come radice quella montata dal kernel, questa
+verrà mantenuta.
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 di sistema \funcd{chroot}, il cui prototipo è:
+a tutto l'albero dei file iniziale; per far questo si può cambiare la sua
+directory radice con la funzione di sistema \funcd{chroot}, il cui prototipo
+è:
\begin{funcproto}{
\fhead{unistd.h}
\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
-accedere alla parte di albero sovrastante. Si ha così quella che viene
+accedere alla parte di albero sovrastante. Si ha così quella che viene
chiamata una \textit{chroot jail}, in quanto il processo non può più accedere
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,\footnote{più precisamente la \itindex{capabilities} capacità
- \const{CAP\_SYS\_CHROOT}.} e la nuova radice, per quanto detto in
+funzione,\footnote{più precisamente se possiede 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 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
-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
-trasferire, per cui in genere si esegue una \func{chroot} sulla directory che
-contiene i file. Si tenga presente però che in questo caso occorrerà
-replicare all'interno della \textit{chroot jail} tutti i file (in genere
-programmi e librerie) di cui il server potrebbe avere bisogno.
-
-
-
-% TODO: trattare la funzione setns e i namespace file descriptors (vedi
-% http://lwn.net/Articles/407495/) introdotti con il kernel 3.0
+tenga presente però che la funzione non cambia la directory di lavoro del
+processo, che potrebbe restare fuori dalla \textit{chroot jail}.
+
+Questo è il motivo per cui la funzione è efficace nel restringere un processo
+ad un ramo di albero solo se dopo averla eseguita si cedono i privilegi di
+amministratore. Infatti se per un qualunque motivo il processo resta con la
+sua \index{directory~di~lavoro} directory di lavoro al di fuori dalla
+\textit{chroot jail}, potrà accedere a tutto il resto del filesystem usando
+\itindsub{pathname}{relativo} dei \textit{pathname} relativi, dato che in tal
+caso è possibile, grazie all'uso di ``\texttt{..}'', risalire all'indietro
+fino alla radice effettiva dell'albero dei file.
+
+Potrebbe sembrare che per risolvere il problema sia sufficiente ricordarsi di
+eseguire preventivamente anche una \func{chdir} sulla directory su cui si
+andrà ad eseguire \func{chroot}, così da assicurarsi che le directory di
+lavoro sia all'interno della \textit{chroot jail}. 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. Basterà infatti eseguire di nuovo \func{chroot} su
+una qualunque directory contenuta nell'attuale directory di lavoro perché
+quest'ultima risulti al di fuori della nuova \textit{chroot jail}. Per questo
+motivo l'uso di questa funzione non ha molto senso quando un processo di cui
+si vuole limitare l'accesso necessita comunque dei privilegi di amministratore
+per le sue normali operazioni.
+
+Nonostante queste limitazioni la funzione risulta utile qualora la si possa
+applicare correttamente cedendo completamente i privilegi di amministratore
+una volta eseguita. Ed esempio caso tipico di uso di \func{chroot} è quello
+di un server FTP anonimo in si vuole che il server veda solo i file che deve
+trasferire. In tal caso si esegue una \func{chroot} sulla directory che
+contiene i file, che il server dovrà in grado di leggere come utente
+ordinario, e poi si cedono tutti i privilegi di amministratore. Si tenga
+presente però che in casi come questo occorrerà fornire all'interno della
+\textit{chroot jail} un accesso anche a tutti i file (in genere programmi e
+librerie) di cui il server potrebbe avere bisogno.
-% TODO: spostare chroot e le funzioni affini relative ai container da qualche
-% parte diversa se è il caso.
% LocalWords: sez like filesystem unlink MacOS Windows VMS inode kernel unistd
% LocalWords: int const char oldpath newpath errno EXDEV EPERM st Smack SysV
projects / gapil.git / commitdiff