cambiare i nomi di file e directory e l'interfaccia che permette la
manipolazione dei loro attributi. Tratteremo inoltre la struttura di base del
sistema delle protezioni e del controllo dell'accesso ai file e le successive
-estensioni (\textit{Extended Attributes}, ACL, quote disco,
-\textit{capabilities}). Tutto quello che riguarda invece la gestione dell'I/O
-sui file è lasciato al capitolo successivo.
+estensioni (\textit{Extended Attributes}, ACL, quote disco). Tutto quello che
+riguarda invece la gestione dell'I/O sui file è lasciato al capitolo
+successivo.
sez.~\ref{sec:file_arch_overview} il \textit{Virtual File System} di Linux e
come il kernel può gestire diversi tipi di filesystem, descrivendo prima le
caratteristiche generali di un filesystem di un sistema unix-like, per poi
-fare una panoramica sul filesystem più usato con Linux, l'\acr{ext2} ed i suoi
-successori.
+fare una panoramica sul filesystem tradizionalmente più usato con Linux,
+l'\acr{ext2} ed i suoi successori.
\subsection{Il funzionamento del \textit{Virtual File System} di Linux}
opportuno tenere sempre presente che:
-\begin{enumerate}
+\begin{enumerate*}
\item L'\textit{inode} contiene i cosiddetti \textsl{metadati}, vale dire le
informazioni riguardanti le proprietà del file come oggetto del filesystem:
per gli \textit{inode}. Nel primo caso non sarà possibile allocare ulteriore
spazio, ma si potranno creare file (vuoti), nel secondo non si potranno
creare nuovi file, ma si potranno estendere quelli che ci
- sono.\footnote{questo comportamento non è generale, alcuni filesystem
- evoluti possono evitare il problema dell'esaurimento degli \textit{inode}
- riallocando lo spazio disco libero per i blocchi.}
+ sono.\footnote{questo comportamento non è generale, alcuni filesystem più
+ sofisticati possono evitare il problema dell'esaurimento degli
+ \textit{inode} riallocando lo spazio disco libero per i blocchi.}
-\end{enumerate}
+\end{enumerate*}
\begin{figure}[!htb]
\centering
grande sviluppo e diverse evoluzioni, fra cui l'aggiunta del
\textit{journaling} con il passaggio ad \acr{ext3}, che probabilmente è ancora
il filesystem più diffuso, ed una serie di ulteriori miglioramenti con il
-successivo \acr{ext4}, che sta iniziando a sostituirlo gradualmente. In futuro
-è previsto che questo debba essere sostituito da un filesystem completamente
-diverso, \acr{btrfs}, che dovrebbe diventare il filesystem standard di Linux,
-ma questo al momento è ancora in fase di sviluppo.\footnote{si fa riferimento
- al momento dell'ultima revisione di di questo paragrafo, l'inizio del 2012.}
+successivo \acr{ext4}. In futuro è previsto che questo debba essere sostituito
+da un filesystem completamente diverso, \acr{btrfs}, che dovrebbe diventare il
+filesystem standard di Linux, ma questo al momento è ancora in fase di
+sviluppo.\footnote{si fa riferimento al momento dell'ultima revisione di
+ questo paragrafo, l'inizio del 2012.}
Il filesystem \acr{ext2} nasce come filesystem nativo per Linux a partire
dalle prime versioni del kernel e supporta tutte le caratteristiche di un
Oltre alle caratteristiche standard, \acr{ext2} fornisce alcune estensioni che
non sono presenti su un classico filesystem di tipo Unix; le principali sono
le seguenti:
-\begin{itemize}
+\begin{itemize*}
\item gli attributi estesi (vedi sez.~\ref{sec:file_xattr}) che consentono di
estendere le informazioni salvabili come metadati e le ACL (vedi
sez.~\ref{sec:file_ACL}) che consentono di estendere il modello tradizionale
cioè essere soltanto letti) per la protezione di file di configurazione
sensibili, o come \textit{append-only} (che possono essere aperti in
scrittura solo per aggiungere dati) per la protezione dei file di log.
-\end{itemize}
+\end{itemize*}
La struttura di \acr{ext2} è stata ispirata a quella del filesystem di BSD: un
filesystem è composto da un insieme di blocchi, la struttura generale è quella
\textit{superblock} non valido, o si è cercato di rimontare un filesystem
non ancora montato, o di montarlo senza che \param{target} sia un
\textit{mount point} o di spostarlo quando \param{target} non è un
- \textit{mount point} o è la radice.
+ \textit{mount point} o è la radice o si è usato un valore di
+ \param{mountflags} non valido.
\item[\errcode{ELOOP}] si è cercato di spostare un \textit{mount point} su
una sottodirectory di \param{source} o si sono incontrati troppi
collegamenti simbolici nella risoluzione di un nome.
\itindbeg{mount~point}
-La funzione monta sulla directory indicata da \param{target}, detta
-\textit{mount point}, il filesystem contenuto nel file di dispositivo indicato
-da \param{source}. In entrambi i casi, come daremo per assunto da qui in
-avanti tutte le volte che si parla di directory o file nel passaggio di un
-argomento di una funzione, si intende che questi devono essere indicati con la
-stringa contenente il loro \textit{pathname}.
+L'uso più comune della funzione è quello di montare sulla directory indicata
+da \param{target}, detta \textit{mount point}, il filesystem contenuto nel
+file di dispositivo indicato da \param{source}. In entrambi i casi, come
+daremo per assunto da qui in avanti tutte le volte che si parla di directory o
+file nel passaggio di un argomento di una funzione, si intende che questi
+devono essere indicati con la stringa contenente il loro \textit{pathname}.
Normalmente un filesystem è contenuto su un disco o una partizione, ma come
illustrato in sez.~\ref{sec:file_vfs_work} la struttura del \textit{Virtual
un file qualunque (come l'immagine di un CD-ROM o di un floppy) che contiene
l'immagine di un filesystem, inoltre alcuni tipi di filesystem, come
\texttt{proc} o \texttt{sysfs} sono virtuali e non hanno un supporto che ne
-contenga i dati, che invece sono generati al volo ad ogni lettura, e passati
-indietro al kernel ad ogni scrittura.\footnote{costituiscono quindi un
- meccanismo di comunicazione, attraverso l'ordinaria interfaccia dei file,
- con il kernel.}
+contenga i dati che sono generati al volo dal kernel ad ogni lettura, e
+inviati al kernel ad ogni scrittura (costituiscono quindi un meccanismo di
+comunicazione, attraverso l'ordinaria interfaccia dei file, con il kernel).
Il tipo di filesystem che si vuole montare è specificato
dall'argomento \param{filesystemtype}, che deve essere una delle stringhe
filesystem e ciascuno ha i suoi, pertanto si rimanda alla documentazione della
pagina di manuale di questo comando e dei singoli filesystem.
-Dopo l'esecuzione della funzione il contenuto del filesystem viene resto
-disponibile nella directory specificata come \textit{mount point}, il
+Dopo l'esecuzione della funzione il contenuto del filesystem viene reso
+disponibile nella directory specificata come \textit{mount point} ed il
precedente contenuto di detta directory viene mascherato dal contenuto della
directory radice del filesystem montato. Fino ai kernel della serie 2.2.x non
-era possibile montare un filesystem se un \textit{mount point} era già in uso.
-
-A partire dal kernel 2.4.x inoltre è divenuto possibile sia spostare
-atomicamente un \textit{mount point} da una directory ad un'altra, sia montare
-lo stesso filesystem in diversi \textit{mount point}, sia montare più
-filesystem sullo stesso \textit{mount point} impilandoli l'uno sull'altro, nel
-qual caso vale comunque quanto detto in precedenza, e cioè che solo il
-contenuto dell'ultimo filesystem montato sarà visibile.
+era possibile montare un filesystem se un \textit{mount point} era già in uso,
+coi kernel successivi è possibile montare più filesystem sullo stesso
+\textit{mount point} impilandoli l'uno sull'altro, anche in questo caso vale
+quanto appena detto, e solo il contenuto dell'ultimo filesystem montato sarà
+visibile, mascherando quelli sottostanti.
+
+In realtà quella di montare un filesystem è solo una delle operazioni che si
+possono effettuare con \func{mount}, la funzione infatti è dedicata a tutte le
+operazioni relative alla gestione del montaggio dei filesystem e dei
+\textit{mount point}. Ad esempio fin dalle sue origini poteva essere
+utilizzata per effettuare il rimontaggio di un filesystem con opzioni diverse,
+ed a partire dal kernel 2.4.x è divenuto possibile usarla per spostare
+atomicamente un \textit{mount point} da una directory ad un'altra, per montare
+lo stesso filesystem in diversi \textit{mount point}, per montare una
+directory su un'altra (il cosiddetto \textit{bind mount}).
\itindend{mount~point}
-Oltre alle opzioni specifiche di ciascun filesystem, che si passano nella
-forma della lista di parole chiave indicata con l'argomento \param{data},
-esistono pure alcune opzioni che si possono applicare in generale, anche se
-non è detto che tutti i filesystem le supportino, che si specificano tramite
-l'argomento \param{mountflags}. L'argomento inoltre può essere utilizzato per
-modificare il comportamento della funzione \func{mount}, facendole compiere
-una operazione diversa (ad esempio un rimontaggio, invece che un montaggio).
-
-In Linux \param{mountflags} deve essere un intero a 32 bit; fino ai kernel
-della serie 2.2.x i 16 più significativi avevano un valore riservato che
-doveva essere specificato obbligatoriamente,\footnote{il valore era il
- \textit{magic number} \code{0xC0ED}, si può usare la costante
+Il tipo di operazione compiuto da \func{mount} viene stabilito in base al
+valore dell'argomento \param{mountflags}, che oltre alla selezione del tipo di
+operazione da compiere, consente anche di indicare alcune opzioni generiche
+valide per qualunque filesystem.\footnote{benché queste siano espresse nel
+ comando \cmd{mount} con l'opzione \texttt{-o} esse non vengono impostate nei
+ valori di \param{data}, che serve solo per le opzioni specifiche di ogni
+ filesystem.} Il valore dell'argomento deve essere espresso come maschera
+binaria e i vari bit che lo compongono, detti anche \textit{mount flags},
+devono essere impostati con un OR aritmetico dei valori dalle opportune
+costanti che illustreremo a breve.
+
+In Linux \param{mountflags} deve essere un intero a 32 bit;
+fino ai kernel della serie 2.2.x i 16 più significativi avevano un valore
+riservato che doveva essere specificato obbligatoriamente,\footnote{il valore
+ era il \textit{magic number} \code{0xC0ED}, si può usare la costante
\constd{MS\_MGC\_MSK} per ottenere la parte di \param{mountflags} riservata
al \textit{magic number}, mentre per specificarlo si può dare un OR
- aritmetico con la costante \constd{MS\_MGC\_VAL}.} e si potevano usare solo i
-16 meno significativi. Oggi invece, con un numero di opzioni superiore, sono
+ aritmetico con la costante \constd{MS\_MGC\_VAL}.} e si potevano usare solo
+i 16 meno significativi. Oggi invece, con un numero di opzioni superiore, sono
utilizzati tutti e 32 i bit, ma qualora nei 16 più significativi sia presente
-detto valore, che non esprime una combinazione valida, esso viene ignorato. Il
-valore dell'argomento deve essere espresso come maschera binaria e i vari bit
-che lo compongono, detti anche \textit{mount flags}, devono essere impostati
-con un OR aritmetico dei valori dalle costanti riportate nell'elenco seguente:
+detto valore, che non esprime una combinazione valida, esso viene ignorato.
+
+Come accennato il tipo di operazione eseguito da \func{mount} viene stabilito
+in base al contenuto di \param{mountflags}, la scelta viene effettuata
+controllando nell'ordine:
+\begin{enumerate*}
+\item se è presente il flag \const{MS\_REMOUNT}, nel qual caso verrà eseguito
+ il rimontaggio del filesystem, con le nuove opzioni indicate da \param{data}
+ e dagli altri flag di \param{mountflags};
+\item se è presente il flag \const{MS\_BIND}, nel qual caso verrà eseguito un
+ \textit{bind mount} (argomento che tratteremo più avanti);
+\item se è presente uno fra \const{MS\_SHARED}, \const{MS\_PRIVATE},
+ \const{MS\_SLAVE}, \const{MS\_UNBINDABLE}, nel qual caso verrà cambiata la
+ modalità di propagazione del montaggio (detti valori sono mutualmente
+ esclusivi).
+\item se è presente \const{MS\_MOVE}, nel qual caso verrà effettuato uno
+ spostamento del \textit{mount point};
+\item se nessuno dei precedenti è presente si tratta di una ordinaria
+ operazione di montaggio di un filesystem.
+\end{enumerate*}
+
+Il fatto che questi valori vengano controllati in quest'ordine significa che
+l'effetto di alcuni di questi flag possono cambiare se usati in combinazione
+con gli altri che vengono prima nella sequenza (è quanto avviene ad esempio
+per \const{MS\_BIND} usato con \const{MS\_REMOUNT}). Tratteremo questi
+\textit{mount flags} speciali per primi, nell'ordine appena illustrato,
+tornando sugli altri più avanti.
+
+Usando il flag \constd{MS\_REMOUNT} si richiede a \func{mount} di rimontare un
+filesystem già montato cambiandone le opzioni di montaggio in maniera atomica
+(non è cioè necessario smontare e rimontare il filesystem per effettuare il
+cambiamento). Questa operazione consente di modificare le opzioni del
+filesystem anche se questo è in uso. Gli argomenti \param{source} e
+\param{target} devono essere gli stessi usati per il montaggio originale,
+mentre sia \param{data} che \param{mountflags} conterranno le nuove opzioni,
+\param{filesystemtype} viene ignorato. Perché l'operazione abbia successo
+occorre comunque che il cambiamento sia possibile (ad esempio non sarà
+possibile rimontare in sola lettura un filesystem su cui sono aperti file per
+la lettura/scrittura).
+
+Qualunque opzione specifica del filesystem indicata con \param{data} può
+essere modificata (ma si dovranno rielencare tutte quelle volute), mentre con
+\param{mountflags} possono essere modificate solo alcune opzioni generiche:
+\const{MS\_LAZYTIME}, \const{MS\_MANDLOCK}, \const{MS\_NOATIME},
+\const{MS\_NODEV}, \const{MS\_NODIRATIME}, \const{MS\_NOEXEC},
+\const{MS\_NOSUID}, \const{MS\_RELATIME}, \const{MS\_RDONLY},
+\const{MS\_STRICTATIME} e \const{MS\_SYNCHRONOUS}. Inoltre dal kernel 3.17 il
+comportamento relativo alle opzioni che operano sui tempi di ultimo accesso
+dei file (vedi sez.~\ref{sec:file_file_times}) è cambiato e se non si è
+indicato nessuno dei vari \texttt{MS\_*ATIME} vengono mantenute le
+impostazioni esistenti anziché forzare l'uso di \const{MS\_RELATIME}.
-\begin{basedescript}{\desclabelwidth{1.9cm}\desclabelstyle{\nextlinelabel}}
\itindbeg{bind~mount}
-\item[\constd{MS\_BIND}] Effettua un cosiddetto \textit{bind mount}, in cui è
- possibile montare una directory di un filesystem in un'altra directory,
- l'opzione è disponibile a partire dai kernel della serie 2.4. In questo caso
- verranno presi in considerazione solo gli argomenti \param{source}, che
- stavolta indicherà la directory che si vuole montare e non un file di
- dispositivo, e \param{target} che indicherà la directory su cui verrà
- effettuato il \textit{bind mount}. Gli argomenti \param{filesystemtype}
- e \param{data} vengono ignorati.
-
- In sostanza quello che avviene è che in corrispondenza del \textit{pathname}
- indicato da \param{target} viene montato l'\textit{inode} di \param{source},
- così che la porzione di albero dei file presente sotto \param{source}
- diventi visibile allo stesso modo sotto \param{target}. Trattandosi
- esattamente dei dati dello stesso filesystem, ogni modifica fatta in uno
- qualunque dei due rami di albero sarà visibile nell'altro, visto che
- entrambi faranno riferimento agli stessi \textit{inode}.
-
- Dal punto di vista del VFS l'operazione è analoga al montaggio di un
- filesystem proprio nel fatto che anche in questo caso si inserisce in
- corrispondenza della \textit{dentry} di \texttt{target} un diverso
- \textit{inode}, che stavolta, invece di essere quello della radice del
- filesystem indicato da un file di dispositivo, è quello di una directory già
- montata.
-
- Si tenga presente che proprio per questo sotto \param{target} comparirà il
- contenuto che è presente sotto \param{source} all'interno del filesystem in
- cui quest'ultima è contenuta. Questo potrebbe non corrispondere alla
- porzione di albero che sta sotto \param{source} qualora in una
- sottodirectory di quest'ultima si fosse effettuato un altro montaggio. In
- tal caso infatti nella porzione di albero sotto \param{source} si troverebbe
- il contenuto del nuovo filesystem (o di un altro \textit{bind mount}) mentre
- sotto \param{target} ci sarebbe il contenuto presente nel filesystem
- originale.\footnote{questo evita anche il problema dei \textit{loop} di
- fig.~\ref{fig:file_link_loop}, dato che se anche si montasse su
- \param{target} una directory in cui essa è contenuta, il cerchio non
- potrebbe chiudersi perché ritornati a \param{target} dentro il
- \textit{bind mount} vi si troverebbe solo il contenuto originale e non si
- potrebbe tornare indietro.}
-
- Fino al kernel 2.6.26 questo flag doveva essere usato da solo, in quanto il
- \textit{bind mount} continuava ad utilizzare le stesse opzioni del montaggio
- originale, dal 2.6.26 è stato introdotto il supporto per il cosiddetto
- \textit{read-only bind mount} e viene onorata la presenza aggiuntiva del
- flag \const{MS\_RDONLY}. In questo modo si ottiene che l'accesso ai file
- sotto \param{target} sia effettuabile esclusivamente in sola lettura.
-
- Il supporto per il \textit{bind mount} consente di superare i limiti
- presenti per gli \textit{hard link} (di cui parleremo in
- sez.~\ref{sec:link_symlink_rename}) con la possibilità di fare riferimento
- alla porzione dell'albero dei file di un filesystem presente a partire da
- una certa directory, utilizzando una qualunque altra directory, anche se
- questa sta su un filesystem diverso. Si può così fornire una alternativa
- all'uso dei collegamenti simbolici (di cui parleremo in
- sez.~\ref{sec:link_symlink_rename}) che funziona correttamente anche
- all'intero di un \textit{chroot} (argomento su cui torneremo in
- sez.~\ref{sec:file_chroot}).
+
+Usando il flag \constd{MS\_BIND} si richiede a \func{mount} di effettuare un
+cosiddetto \textit{bind mount}, l'operazione che consente di montare una
+directory di un filesystem in un'altra directory. L'opzione è disponibile a
+partire dai kernel della serie 2.4. In questo caso verranno presi in
+considerazione solo gli argomenti \param{source}, che stavolta indicherà la
+directory che si vuole montare e non un file di dispositivo, e \param{target}
+che indicherà la directory su cui verrà effettuato il \textit{bind mount}. Gli
+argomenti \param{filesystemtype} e \param{data} vengono ignorati.
+
+Quello che avviene con questa operazione è che in corrispondenza del
+\textit{pathname} indicato da \param{target} viene montato l'\textit{inode} di
+\param{source}, così che la porzione di albero dei file presente sotto
+\param{source} diventi visibile allo stesso modo sotto
+\param{target}. Trattandosi esattamente dei dati dello stesso filesystem, ogni
+modifica fatta in uno qualunque dei due rami di albero sarà visibile
+nell'altro, visto che entrambi faranno riferimento agli stessi \textit{inode}.
+
+Dal punto di vista del VFS l'operazione è analoga al montaggio di un
+filesystem proprio nel fatto che anche in questo caso si inserisce in
+corrispondenza della \textit{dentry} di \texttt{target} un diverso
+\textit{inode}, che stavolta, invece di essere quello della radice del
+filesystem indicato da un file di dispositivo, è quello di una directory già
+montata.
+
+Si tenga presente che proprio per questo sotto \param{target} comparirà il
+contenuto che è presente sotto \param{source} all'interno del filesystem in
+cui quest'ultima è contenuta. Questo potrebbe non corrispondere alla porzione
+di albero che sta sotto \param{source} qualora in una sottodirectory di
+quest'ultima si fosse effettuato un altro montaggio. In tal caso infatti nella
+porzione di albero sotto \param{source} si troverebbe il contenuto del nuovo
+filesystem (o di un altro \textit{bind mount}) mentre sotto \param{target} ci
+sarebbe il contenuto presente nel filesystem originale.
+
+L'unico altro \textit{mount flag} usabile direttamente con \const{MS\_BIND} è
+\const{MS\_REC} che consente di eseguire una operazione di \textit{bind mount}
+ricorsiva, in cui sotto \param{target} vengono montati ricorsivamente anche
+tutti gli eventuali ulteriori \textit{bind mount} già presenti sotto
+\param{source}.
+
+E' però possibile, a partire dal kernel 2.6.26, usare questo flag insieme a
+\const{MS\_REMOUNT}, nel qual caso consente di effettuare una modifica delle
+opzioni di montaggio del \textit{bind mount} ed in particolare effettuare il
+cosiddetto \textit{read-only bind mount} in cui viene onorata anche la
+presenza aggiuntiva del flag \const{MS\_RDONLY}. In questo modo si ottiene che
+l'accesso ai file sotto \param{target} sia effettuabile esclusivamente in sola
+lettura, mantenendo il normale accesso in lettura/scrittura sotto
+\param{source}.
+
+Il supporto per il \textit{bind mount} consente di superare i limiti presenti
+per gli \textit{hard link} (di cui parleremo in
+sez.~\ref{sec:link_symlink_rename}) con la possibilità di fare riferimento
+alla porzione dell'albero dei file di un filesystem presente a partire da una
+certa directory utilizzando una qualunque altra directory, anche se questa sta
+su un filesystem diverso.\footnote{e non c'è neanche il problema di non esser
+ più in grado di cancellare un \textit{hard link} ad una directory sullo
+ stesso filesystem (vedi sez.~\ref{sec:link_symlink_rename}), per cui su
+ Linux questi non sono possibili, dato che in questo caso per la rimozione
+ del collegamento basta smontare \param{target}.} Si può così fornire una
+alternativa all'uso dei collegamenti simbolici (di cui parleremo in
+sez.~\ref{sec:link_symlink_rename}) che funziona correttamente anche
+all'intero di un \textit{chroot} (argomento su cui torneremo in
+sez.~\ref{sec:file_chroot}).
\itindend{bind~mount}
+\itindbeg{shared~subtree}
+
+I quattro flag \const{MS\_PRIVATE}, \const{MS\_SHARED}, \const{MS\_SLAVE} e
+\const{MS\_UNBINDABLE} sono stati introdotti a partire dal kernel 2.6.15 per
+realizzare l'infrastruttura dei cosiddetti \textit{shared subtree}, che
+estendono le funzionalità dei \textit{bind mount}. La funzionalità nasce
+dalle esigenze di poter utilizzare a pieno le funzionalità di isolamento
+fornite dal kernel per i processi (i \textit{namespace}, che tratteremo in
+sez.~\ref{sec:process_namespaces}) in particolare per quanto riguarda la
+possibilità di far avere ad un processo una visione ristretta dei filesystem
+montati (il \textit{mount namespace}), ma l'applicazione è comunque rilevante
+anche con un classico \textit{chroot} (vedi sez.~\ref{sec:file_chroot}).
+
+\itindbeg{submount}
+
+Abbiamo visto come nella modalità ordinaria in cui si esegue un
+\textit{bind mount} sotto \param{target} compaia lo stesso ramo di albero dei
+file presente sotto \param{source}, ma limitato a quanto presente nel
+filesystem di \param{source}; i risultati di un eventuale
+``\textit{submount}'' effettuato all'interno di \param{source} non saranno
+visibili. Ed anche se quelli presenti al momento dell'uso di \const{MS\_BIND}
+possono essere riottenuti usando \const{MS\_REC}, ogni eventuale
+``\textit{submount}'' successivo (che avvenga sotto \param{source} o sotto
+\param{target}) resterà ``\textsl{privato}'' al ramo di albero su cui è
+avvenuto.
+
+\itindend{submount}
+\itindbeg{mount peer group}
+
+Ci sono casi però in cui può risultare utile che eventuali
+``\textit{submount}'' siano visibili sui rami di albero presenti al di sotto
+di tutte le directory coinvolte in un \textit{bind mount}, anche se effettuati
+in un secondo tempo. Per poter ottenere questa funzionalità i
+\textit{bind mount} sono stati estesi introducendo i \textit{mount peer
+ group}, che consentono di raggrupparli in modo da poter inviare a ciascuno
+di essi tutti gli eventi relativi a montaggi o smontaggi effettuati al loro
+interno ed avere sempre una propagazione degli stessi che li renda coerenti.
+
+Quando si effettua un montaggio ordinario, o si esegue un \textit{bind mount},
+di default non viene utilizzato nessun \textit{mount peer group} ed il
+\textit{mount point} viene classificato come ``\textsl{privato}'', nel senso
+che abbiamo appena visto. Si può però marcare un \textit{mount point} come
+``\textsl{condiviso}'', ed in questo modo esso verrà associato ad un
+\textit{mount peer group} insieme a tutti gli altri ulteriori \textit{mount
+ point} per i quali sia stato eseguito un \textit{bind mount}. Questo fa sì
+che tutte le volte che si effettua un montaggio o uno smontaggio all'interno
+di uno qualunque dei \textit{mount point} del gruppo, questo venga propagato
+anche su tutti gli altri e sotto tutti sia visibile sempre lo stesso ramo di
+albero dei file.
+
+A completare l'infrastruttura degli \textit{shared subtree} sono state
+previste due ulteriori funzionalità: la prima è quella di marcare un
+\textit{mount point} come ``\textit{slave}'', in tal caso le operazioni di
+montaggio e smontaggio effettuate al suo interno non verranno più propagate
+agli altri membri del \textit{mount peer group} di cui fa parte, ma continuerà
+a ricevere quelle eseguite negli altri membri.
+
+La seconda funzionalità è quella di marcare un \textit{mount point} come
+``\textit{unbindable}''; questo anzitutto impedirà che possa essere usato come
+sorgente di un \textit{bind mount} ed inoltre lo renderà privato, con la
+conseguenza che quando è presente all'interno di altri \textit{bind mount},
+all'interno di questi si vedrà solo il contenuto originale e non quello
+risultante da eventuali ulteriori montaggi effettuati al suo interno.
+
+\itindend{mount peer group}
+
+I \textit{mount flag} che controllano le operazioni relative agli
+\textit{shared subtree} sono descritti nella lista seguente. Si ricordi che
+sono mutuamente esclusivi, e compatibili solo con l'uso degli ulteriori flag
+\const{MS\_REC} (che applica ricorsivamente l'operazione a tutti gli eventuali
+\textit{mount point} sottostanti) e \const{MS\_SILENT}; in tutti gli altri
+casi \func{mount} fallirà con un errore di \errval{EINVAL}. L'unico altro
+argomento che deve essere specificato quando li si usano è \param{target};
+\param{source}, \param{data} e \param{filesystem} sono ignorati.
+
+\begin{basedescript}{\desclabelwidth{1.9cm}\desclabelstyle{\nextlinelabel}}
+
+\item[\constd{MS\_PRIVATE}] Marca un \textit{mount point} come \textit{private
+ mount}. Di default, finché non lo si marca altrimenti con una delle altre
+ opzioni dell'interfaccia, ogni \textit{mount point} è privato. Ogni
+ \textit{bind mount} ottenuto da un \textit{mount point} privato si comporta
+ come descritto nella trattazione di \const{MS\_BIND}. Si usa questo flag
+ principalmente per revocare gli effetti delle altre opzioni e riportare il
+ comportamento a quello ordinario.
+
+\item[\constd{MS\_SHARED}] Marca un \textit{mount point} come \textit{shared
+ mount}. Lo scopo dell'opzione è ottenere che tutti i successivi
+ \textit{bind mount} ottenuti da un \textit{mount point} così marcato siano
+ di tipo \textit{shared} e vengano inseriti nello stesso \textit{mount peer
+ group} in modo da ``\textsl{condividere}'' ogni ulteriore operazione di
+ montaggio o smontaggio. Con questa opzione le operazioni di montaggio e
+ smontaggio effettuate al di sotto di uno \textit{shared mount} vengono
+ automaticamente ``\textsl{propagate}'' a tutti gli altri membri del
+ \textit{mount peer group} di cui fa parte, in modo che la sezione di albero
+ dei file visibile al di sotto di ciascuno di essi sia sempre la stessa.
+
+\item[\constd{MS\_SLAVE}] Marca un \textit{mount point} come \textit{slave
+ mount}. Se il \textit{mount point} è parte di un \textit{mount peer group}
+ esso diventerà di tipo \textit{slave}: le operazioni di montaggio e
+ smontaggio al suo interno non verranno più propagate agli altri membri del
+ gruppo, ma continuerà a ricevere quelle eseguite negli altri membri. Se non
+ esistono altri membri nel gruppo il \textit{mount point} diventerà privato,
+ negli altri casi non subirà nessun cambiamento.
+
+\item[\constd{MS\_UNBINDABLE}] Marca un \textit{mount point} come
+ \textit{unbindable mount}. Un \textit{mount point} marcato in questo modo
+ non può essere usato per un \textit{bind mount} del suo contenuto. Si
+ comporta cioè come allo stesso modo di un \textit{mount point} ordinario di
+ tipo \textit{private} con in più la restrizione che nessuna sua
+ sottodirectory (anche se relativa ad un ulteriore montaggio) possa essere
+ utilizzata come sorgente di un \textit{bind mount}.
+
+\end{basedescript}
+\itindend{shared~subtree}
+L'ultimo \textit{mount flag} che controlla una modalità operativa di
+\func{mount} è \constd{MS\_MOVE}, che consente di effettuare lo spostamento
+del \textit{mount point} di un filesystem. La directory del \textit{mount
+ point} originale deve essere indicata nell'argomento \param{source}, e la
+sua nuova posizione nell'argomento \param{target}. Tutti gli altri argomenti
+della funzione vengono ignorati.
+
+Lo spostamento avviene atomicamente, ed il ramo di albero presente sotto
+\param{source} sarà immediatamente visibile sotto \param{target}. Non esiste
+cioè nessun momento in cui il filesystem non risulti montato in una o
+nell'altra directory e pertanto è garantito che la risoluzione di
+\textit{pathname} relativi all'interno del filesystem non possa fallire.
+
+Elenchiamo infine i restanti \textit{mount flag}, il cui utilizzo non attiene
+alle operazioni di \func{mount}, ma soltanto l'impostazione di opzioni
+generiche relative al funzionamento di un filesystem e che vengono per lo più
+utilizzati solo in fase di montaggio:
+
+\begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}}
\item[\constd{MS\_DIRSYNC}] Richiede che ogni modifica al contenuto di una
directory venga immediatamente registrata su disco in maniera sincrona
(introdotta a partire dai kernel della serie 2.6). L'opzione si applica a
tutte le directory del filesystem, ma su alcuni filesystem è possibile
- impostarla a livello di singole directory o per i sottorami di una directory
+ impostarla a livello di singole directory o per i sotto-rami di una directory
con il comando \cmd{chattr}.\footnote{questo avviene tramite delle opportune
\texttt{ioctl} (vedi sez.~\ref{sec:file_fcntl_ioctl}).}
operazioni sulle directory non saranno più bufferizzate e si bloccheranno
fino all'arrivo dei dati sul disco prima che un programma possa proseguire.
+\item[\constd{MS\_LAZYTIME}] Modifica la modalità di registrazione di tempi
+ dei file (vedi sez.~\ref{sec:file_file_times}) per ridurre al massimo gli
+ accessi a disco (particolarmente utile per i portatili). Attivandolo i tempi
+ dei file vengono mantenuti in memoria e vengono salvati su disco solo in
+ quattro casi: quando c'è da eseguire un aggiornamento dei dati
+ dell'\textit{inode} per altri motivi, se viene usata una delle funzioni di
+ sincronizzazione dei dati su disco (vedi sez.~\ref{sec:file_sync}), se
+ l'\textit{inode} viene rimosso dalla memoria, o se è passato un giorno
+ dall'ultima registrazione. Introdotto a partire dal kernel 4.0.
+
+ In questo modo si possono ridurre significativamente le scritture su disco
+ mantenendo tutte le informazioni riguardo ai tempi dei file, riducendo anche
+ l'impatto dell'uso di \const{MS\_STRICTATIME}. Il costo da pagare è il
+ rischio, in caso di crash del sistema, di avere dati vecchi fino a 24 ore
+ per quel che riguarda i tempi dei file.
+
\item[\constd{MS\_MANDLOCK}] Consente l'uso del \textit{mandatory locking}
(vedi sez.~\ref{sec:file_mand_locking}) sui file del filesystem. Per poterlo
utilizzare effettivamente però esso dovrà essere comunque attivato
esplicitamente per i singoli file impostando i permessi come illustrato in
sez.~\ref{sec:file_mand_locking}.
-\item[\constd{MS\_MOVE}] Effettua uno del spostamento del \textit{mount point}
- di un filesystem. La directory del \textit{mount point} originale deve
- essere indicata nell'argomento \param{source}, e la sua nuova posizione
- nell'argomento \param{target}. Tutti gli altri argomenti della funzione
- vengono ignorati.
-
- Lo spostamento avviene atomicamente, ed il ramo di albero presente
- sotto \param{source} sarà immediatamente visibile sotto \param{target}. Non
- esiste cioè nessun momento in cui il filesystem non risulti montato in una o
- nell'altra directory e pertanto è garantito che la risoluzione di
- \textit{pathname} relativi all'interno del filesystem non possa fallire.
-
\item[\constd{MS\_NOATIME}] Viene disabilitato sul filesystem l'aggiornamento
dell'\textit{access time} (vedi sez.~\ref{sec:file_file_times}) per
- qualunque tipo di file. Dato che l'aggiornamento dell'\textit{access time}
- è una funzionalità la cui utilità è spesso irrilevante ma comporta un costo
+ qualunque tipo di file. Dato che l'aggiornamento dell'\textit{access time} è
+ una funzionalità la cui utilità è spesso irrilevante ma comporta un costo
elevato visto che una qualunque lettura comporta comunque una scrittura su
- disco,\footnote{e questo ad esempio ha conseguenze molto pesanti nell'uso
- della batteria sui portatili.} questa opzione consente di disabilitarla
- completamente. La soluzione può risultare troppo drastica dato che
- l'informazione viene comunque utilizzata da alcuni programmi, per cui nello
- sviluppo del kernel sono state introdotte altre opzioni che forniscono
- soluzioni più appropriate e meno radicali.
+ disco, questa opzione consente di disabilitarla completamente. La soluzione
+ può risultare troppo drastica dato che l'informazione viene comunque
+ utilizzata da alcuni programmi, per cui nello sviluppo del kernel sono state
+ introdotte altre opzioni che forniscono soluzioni più appropriate e meno
+ radicali.
\item[\constd{MS\_NODEV}] Viene disabilitato sul filesystem l'accesso ai file
di dispositivo eventualmente presenti su di esso. L'opzione viene usata come
di un altro utente, che gli consentirebbe di eseguirlo per conto di
quest'ultimo.
-\item[\constd{MS\_PRIVATE}] Marca un \textit{mount point} come privato. Si
- tratta di una delle nuove opzioni (insieme a \const{MS\_SHARED},
- \const{MS\_SLAVE} e \const{MS\_UNBINDABLE}) facenti parte
- dell'infrastruttura degli \textit{shared subtree} introdotta a partire dal
- kernel 2.6.15, che estendono le funzionalità dei \textit{bind mount}. In
- questo caso \param{target} dovrà fare riferimento al \textit{mount point}
- che si intende marcare, e tutti gli altri argomenti verranno ignorati.
-
- Di default, finché non lo si marca altrimenti con una delle altre opzioni
- dell'interfaccia come \textit{shared subtree}, ogni \textit{mount point} è
- privato. Ogni \textit{bind mount} ottenuto da un \textit{mount point} di
- tipo \textit{private} si comporta come descritto nella trattazione di
- \const{MS\_BIND}. Si usa questo flag principalmente per revocare gli effetti
- delle altre opzioni e riportare il comportamento a quello ordinario.
-
\item[\constd{MS\_RDONLY}] Esegue il montaggio del filesystem in sola lettura,
non sarà possibile nessuna modifica ai suoi contenuti. Viene usato tutte le
volte che si deve accedere ai contenuti di un filesystem con la certezza che
questo non venga modificato (ad esempio per ispezionare un filesystem
corrotto). All'avvio di default il kernel monta la radice in questa
- modalità.
+ modalità. Si tenga presente che se non viene indicato il filesystem verrà
+ montato, o rimontato nel caso lo si usi con \const{MS\_REMOUNT}, in
+ lettura/scrittura; questo significa in sostanza che non esiste una opzione
+ separata per indicare il montaggio in lettura/scrittura.
\item[\constd{MS\_REC}] Applica ricorsivamente a tutti i \textit{mount point}
presenti al di sotto del \textit{mount point} indicato gli effetti della
- opzione degli \textit{shared subtree} associata. Anche questo caso
- l'argomento \param{target} deve fare riferimento ad un \textit{mount point}
- e tutti gli altri argomenti sono ignorati, ed il flag deve essere indicato
- assieme ad una fra \const{MS\_PRIVATE}, \const{MS\_SHARED},
- \const{MS\_SLAVE} e \const{MS\_UNBINDABLE}.
-
- % TODO trattare l'opzione \texttt{lazytime} introdotta con il kernel 4.0,
- % vedi http://lwn.net/Articles/621046/
+ opzione degli \textit{shared subtree} associata. In questo caso l'argomento
+ \param{target} deve fare riferimento ad un \textit{mount point} e tutti gli
+ altri argomenti sono ignorati, ed il flag deve essere indicato con uno fra
+ \const{MS\_PRIVATE}, \const{MS\_SHARED}, \const{MS\_SLAVE} e
+ \const{MS\_UNBINDABLE}. Può anche essere usato con \const{MS\_BIND} per
+ richiedere il montaggio ricorsivo anche degli eventuali ulteriori
+ \textit{bind mount} presenti sotto \param{target}.
\item[\constd{MS\_RELATIME}] Indica di effettuare l'aggiornamento
dell'\textit{access time} sul filesystem soltanto quando questo risulti
l'introduzione di questo comportamento l'uso delle alternative
\const{MS\_NOATIME} e \const{MS\_NODIRATIME} è sostanzialmente inutile.
-\item[\constd{MS\_REMOUNT}] Consente di rimontare un filesystem già montato
- cambiandone le opzioni di montaggio in maniera atomica. In questo modo si
- possono modificare le opzioni del filesystem anche se questo è in uso. Gli
- argomenti \param{source} e \param{target} devono essere gli stessi usati per
- il montaggio originale, mentre sia \param{data} che \param{mountflags}
- conterranno le nuove opzioni, \param{filesystemtype} viene ignorato.
-
- Qualunque opzione specifica del filesystem indicata con \param{data} può
- essere modificata, mentre con \param{mountflags} possono essere modificate
- solo alcune opzioni generiche. Con i kernel più recenti queste sono soltanto
- \const{MS\_MANDLOCK}, \const{MS\_RDONLY} e \const{MS\_SYNCHRONOUS}, prima
- del kernel 2.6.16 potevano essere modificate anche le ulteriori
- \const{MS\_NOATIME} e \const{MS\_NODIRATIME}, ed infine prima del kernel
- 2.4.10 anche \const{MS\_NODEV}, \const{MS\_NOEXEC} e \const{MS\_NOSUID}.
-
-\itindbeg{shared~subtree}
-
-\item[\constd{MS\_SHARED}] Marca un \textit{mount point} come \textit{shared
- mount}. Si tratta di una delle nuove opzioni (insieme a
- \const{MS\_PRIVATE}, \const{MS\_SLAVE} e \const{MS\_UNBINDABLE}) facenti
- parte dell'infrastruttura dei cosiddetti \textit{shared subtree} introdotta
- a partire dal kernel 2.6.15, che estendono le funzionalità dei \textit{bind
- mount}. In questo caso \param{target} dovrà fare riferimento al
- \textit{mount point} che si intende marcare, e tutti gli altri argomenti
- verranno ignorati.
-
- Lo scopo dell'opzione è ottenere che tutti i successivi \textit{bind mount}
- effettuati da un \textit{mount point} marcato da essa siano di tipo
- \textit{shared}, cioè ``\textsl{condividano}'' con l'originale e fra di loro
- ogni ulteriore operazione di montaggio o smontaggio che avviene su una
- directory al di sotto di uno qualunque di essi. Le operazioni di montaggio e
- smontaggio effettuate al di sotto di un qualunque \textit{mount point} così
- marcato verranno ``\textsl{propagate}'' a tutti i \textit{mount point} della
- stessa condivisione, e la sezione di albero di file vista al di sotto di
- ciascuno di essi sarà sempre identica.
-
-\itindend{shared~subtree}
-
\item[\constd{MS\_SILENT}] Richiede la soppressione di alcuni messaggi di
avvertimento nei log del kernel (vedi sez.~\ref{sec:sess_daemon}). L'opzione
è presente a partire dal kernel 2.6.17 e sostituisce, utilizzando un nome
non fuorviante, la precedente \const{MS\_VERBOSE}, introdotta nel kernel
2.6.12, che aveva lo stesso effetto.
-\item[\constd{MS\_SLAVE}] Marca un \textit{mount point} come \textit{slave
- mount}. Si tratta di una delle nuove opzioni (insieme a
- \const{MS\_PRIVATE}, \const{MS\_SHARED} e \const{MS\_UNBINDABLE}) facenti
- parte dell'infrastruttura degli \textit{shared subtree} introdotta a partire
- dal kernel 2.6.15, che estendono le funzionalità dei \textit{bind mount}.
- In questo caso \param{target} dovrà fare riferimento al \textit{mount point}
- che si intende marcare, e tutti gli altri argomenti verranno ignorati.
-
- Lo scopo dell'opzione è ottenere che tutti i successivi \textit{bind mount}
- effettuati da un \textit{mount point} marcato da essa siano di tipo
- \textit{slave}, cioè ``\textsl{condividano}'' ogni ulteriore operazione di
- montaggio o smontaggio che avviene su una directory al di sotto del
- \textit{mount point} originale. Le operazioni di montaggio e smontaggio in
- questo caso vengono ``\textsl{propagate}'' soltanto dal \textit{mount point}
- originale (detto anche \textit{master}) verso gli \textit{slave}, mentre
- essi potranno eseguire al loro interno ulteriori montaggi che non saranno
- propagati né negli altri né nel \textit{mount point} originale.
-
\item[\constd{MS\_STRICTATIME}] Ripristina il comportamento tradizionale per
cui l'\textit{access time} viene aggiornato ad ogni accesso al
file. L'opzione è disponibile solo a partire dal kernel 2.6.30 quando il
compromesso in cui questo comportamento avviene solo per le directory, ed ha
quindi una incidenza nettamente minore, si può usare \const{MS\_DIRSYNC}.
-\item[\constd{MS\_UNBINDABLE}] Marca un \textit{mount point} come
- \textit{unbindable mount}. Si tratta di una delle nuove opzioni (insieme a
- \const{MS\_PRIVATE}, \const{MS\_SHARED} e \const{MS\_SLAVE}) facenti parte
- dell'infrastruttura degli \textit{shared subtree} introdotta a partire dal
- kernel 2.6.15, che estendono le funzionalità dei \textit{bind mount}. In
- questo caso \param{target} dovrà fare riferimento al \textit{mount point}
- che si intende marcare, e tutti gli altri argomenti verranno ignorati.
-
- Un \textit{mount point} marcato in questo modo disabilita la capacità di
- eseguire dei \textit{bind mount} del suo contenuto. Si comporta cioè come
- allo stesso modo di un \textit{mount point} ordinario di tipo
- \textit{private} con in più la restrizione che nessuna sua sottodirectory
- (anche se relativa ad un ulteriore montaggio) possa essere utilizzata per un
- come sorgente di un \textit{bind mount}.
-
\end{basedescript}
+% NOTE: per l'opzione \texttt{lazytime} introdotta con il kernel 4.0,
+% vedi http://lwn.net/Articles/621046/
+
% NOTE per \const{MS\_SLAVE},\const{MS\_SHARE}, \const{MS\_PRIVATE} e
% \const{MS\_UNBINDABLE} dal 2.6.15 vedi shared subtrees, in particolare
% * http://lwn.net/Articles/159077/ e
questo è un collegamento simbolico (vedi
sez.~\ref{sec:link_symlink_rename}). Questa è una misura di sicurezza
introdotta per evitare, per quei filesystem per il quale è prevista una
-gestione diretta da parte degli utenti, come quelli basati su
+gestione diretta da parte degli utenti, come quelli basati su \itindex{FUSE}
FUSE,\footnote{il \textit{Filesystem in USEr space} (FUSE) è una delle più
interessanti applicazioni del VFS che consente, tramite un opportuno modulo,
di implementarne le funzioni in \textit{user space}, così da rendere
otterranno lo stesso file.
Quando si vuole aggiungere ad una directory una voce che faccia riferimento ad
-un file già esistente nella modalità appena descritta, per ottenere quello che
-viene denominato ``\textsl{collegamento diretto}'' (o \textit{hard link}), si
-deve usare la funzione di sistema \funcd{link}, il cui prototipo è:
+un file già esistente come appena descritto, per ottenere quello che viene
+denominato ``\textsl{collegamento diretto}'' (o \textit{hard link}), si deve
+usare la funzione di sistema \funcd{link}, il cui prototipo è:
\begin{funcproto}{
\fhead{unistd.h}
(il numero massimo è specificato dalla variabile \const{LINK\_MAX}, vedi
sez.~\ref{sec:sys_limits}).
\item[\errcode{EPERM}] il filesystem che contiene \param{oldpath} e
- \param{newpath} non supporta i collegamenti diretti o è una directory.
+ \param{newpath} non supporta i collegamenti diretti, è una directory o per
+ \param{oldpath} non si rispettano i criteri per i \textit{protected
+ hardlink}.\footnotemark
\item[\errcode{EXDEV}] i file \param{oldpath} e \param{newpath} non fanno
riferimento ad un filesystem montato sullo stesso
\textit{mount point}.
- \end{errlist} ed inoltre \errval{EACCES}, \errval{EFAULT}, \errval{EIO},
- \errval{ELOOP}, \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM},
- \errval{ENOSPC}, \errval{ENOTDIR}, \errval{EROFS} nel loro significato
- generico.}
+ \end{errlist} ed inoltre \errval{EACCES}, \errval{EDQUOT}, \errval{EFAULT},
+ \errval{EIO}, \errval{ELOOP}, \errval{ENAMETOOLONG}, \errval{ENOENT},
+ \errval{ENOMEM}, \errval{ENOSPC}, \errval{ENOTDIR}, \errval{EROFS} nel loro
+ significato generico.}
\end{funcproto}
+\footnotetext{i \textit{protected hardlink} sono una funzionalità di
+ protezione introdotta con il kernel 3.16 (si veda
+ sez.~\ref{sec:procadv_security_misc} per i dettagli) che limita la capacità
+ di creare un \textit{hard link} ad un file qualunque.}
+
La funzione crea in \param{newpath} un collegamento diretto al file indicato
da \param{oldpath}. Per quanto detto la creazione di un nuovo collegamento
diretto non copia il contenuto del file, ma si limita a creare la voce
specificata da \param{newpath} nella directory corrispondente e l'unica
proprietà del file che verrà modificata sarà il numero di riferimenti al file
(il campo \var{i\_nlink} della struttura \kstruct{inode}, vedi
-fig.~\ref{fig:kstruct_inode}) che verrà aumentato di di uno. In questo modo lo
+fig.~\ref{fig:kstruct_inode}) che verrà aumentato di uno. In questo modo lo
stesso file potrà essere acceduto sia con \param{newpath} che
con \param{oldpath}.
tenga presente infatti, come detto in sez.~\ref{sec:filesystem_mounting},
che a partire dal kernel 2.4 uno stesso filesystem può essere montato più
volte su directory diverse.}
-
La funzione inoltre opera sia sui file ordinari che sugli altri oggetti del
filesystem, con l'eccezione delle directory. In alcune versioni di Unix solo
l'amministratore è in grado di creare un collegamento diretto ad un'altra
directory: questo viene fatto perché con una tale operazione è possibile
creare dei \textit{loop} nel filesystem (vedi fig.~\ref{fig:file_link_loop})
-che molti programmi non sono in grado di gestire e la cui rimozione
-diventerebbe piuttosto complicata.\footnote{in genere per questo tipo di
- errori occorre eseguire il programma \cmd{fsck} per riparare il filesystem,
- in quanto in caso di \textit{loop} la directory creata non sarebbe vuota e
- non si potrebbe più rimuoverla.}
-
-Data la pericolosità di questa operazione e la disponibilità dei collegamenti
-simbolici (che vedremo a breve) e dei \textit{bind mount}
-(già visti in sez.~\ref{sec:filesystem_mounting}) che possono fornire la
-stessa funzionalità senza questi problemi, nel caso di Linux questa capacità è
-stata completamente disabilitata, e al tentativo di creare un collegamento
-diretto ad una directory la funzione \func{link} restituisce sempre l'errore
-\errcode{EPERM}.
+la cui rimozione diventerebbe piuttosto complicata.\footnote{occorrerebbe
+ infatti eseguire il programma \cmd{fsck} per riparare il filesystem, perché
+ in caso di \textit{loop} la directory non potrebbe essere più svuotata,
+ contenendo comunque se stessa, e quindi non potrebbe essere rimossa.}
+
+Data la pericolosità di questa operazione, e visto che i collegamenti
+simbolici (che tratteremo a breve) ed i \textit{bind mount} (già visti in
+sez.~\ref{sec:filesystem_mounting}) possono fornire la stessa funzionalità
+senza questi problemi, nel caso di Linux questa capacità è stata completamente
+disabilitata, e al tentativo di creare un collegamento diretto ad una
+directory la funzione \func{link} restituisce sempre l'errore \errcode{EPERM}.
Un ulteriore comportamento peculiare di Linux è quello in cui si crea un
\textit{hard link} ad un collegamento simbolico. In questo caso lo standard
{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{EACCES}] o non si hanno i permessi sulla directory in cui
+ creare il \textit{link}.
\item[\errcode{EEXIST}] esiste già un file \param{newpath}.
\item[\errcode{ENOENT}] una componente di \param{newpath} non esiste o
\param{oldpath} è una stringa vuota.
supporta i collegamenti simbolici.
\item[\errcode{EROFS}] \param{newpath} è su un filesystem montato in sola
lettura.
- \end{errlist} ed inoltre \errval{EACCES}, \errval{EFAULT}, \errval{EIO},
+ \end{errlist} ed inoltre \errval{EDQUOT}, \errval{EFAULT}, \errval{EIO},
\errval{ELOOP}, \errval{ENAMETOOLONG}, \errval{ENOMEM}, \errval{ENOSPC} e
\errval{ENOTDIR} nel loro significato generico.}
\end{funcproto}
+
La funzione crea un nuovo collegamento simbolico \param{newpath} che fa
riferimento ad \param{oldpath}. Si tenga presente che la funzione non
effettua nessun controllo sull'esistenza di un file di nome \param{oldpath},
simbolico. Pertanto un collegamento simbolico può anche riferirsi ad un file
che non esiste ed in questo caso si ha quello che viene chiamato un
\itindex{dangling~link} \textit{dangling link}, letteralmente un
-\index{collegamento!ciondolante} ``\textsl{collegamento ciondolante}''.
+\index{collegamento!ciondolante} ``\textsl{collegamento ciondolante}''. Ad
+esempio possiamo usare il comando \cmd{ln} per creare un collegamento
+simbolico nella nostra directory con:
+\begin{Console}
+piccardi@hain:~/gapil$ \textbf{ln -s /tmp/tmp_file symlink}
+\end{Console}
+%$
+e questo avrà successo anche se \file{/tmp/tmp\_file} non esiste:
+\begin{Console}
+piccardi@hain:~/gapil$ \textbf{ls symlink}
+symlink
+\end{Console}
+%$
+ma questo può generare confusione, perché accedendo in lettura a
+\file{symlink}, ad esempio con \cmd{cat}, otterremmo:
+\begin{Console}
+piccardi@hain:~/gapil$ \textbf{cat symlink}
+cat: symlink: No such file or directory
+\end{Console}
+%$
+con un errore che può sembrare sbagliato, dato che \cmd{ls} ci ha mostrato in
+precedenza l'esistenza di \file{symlink}. Se invece andassimo a scrivere su
+\file{symlink}, l'effetto sarebbe quello di ottenere la creazione di
+\file{/tmp/tmp\_file} (che a quel punto verrebbe creato) senza errori.
Come accennato i collegamenti simbolici sono risolti automaticamente dal
kernel all'invocazione delle varie \textit{system call}. In
sez.~\ref{sec:file_open_close}) e tutte le operazioni seguenti fanno
riferimento solo a quest'ultimo.
+Si tenga anche presente che a partire dal kernel 3.16, se si abilita la
+funzionalità dei \textit{protected symlinks} (attiva di default in tutte le
+distribuzioni più recenti) la risoluzione dei nomi attraverso un collegamento
+simbolico può fallire per una serie di restrizione di sicurezza aggiuntive
+imposte dal meccanismo (si consulti sez.~\ref{sec:procadv_security_misc} per i
+dettagli del meccanismo).
+
Dato che, come indicato in tab.~\ref{tab:file_symb_effect}, funzioni come la
\func{open} seguono i collegamenti simbolici, occorrono funzioni apposite per
accedere alle informazioni del collegamento invece che a quelle del file a cui
\begin{funcproto}{
\fhead{unistd.h}
-\fdecl{int readlink(const char *path, char *buff, size\_t size)}
+\fdecl{int readlink(const char *pathname, char *buff, size\_t size)}
\fdesc{Legge il contenuto di un collegamento simbolico.}
}
{La funzione ritorna il numero di caratteri letti dentro \param{buff} in caso
di successo e $-1$ per un errore, nel qual caso \var{errno} assumerà uno
dei valori:
\begin{errlist}
- \item[\errcode{EINVAL}] \param{path} non è un collegamento simbolico
+ \item[\errcode{EACCES}] non si hanno i permessi di attraversamento di una
+ delle directory del pathname
+ \item[\errcode{EINVAL}] \param{pathname} non è un collegamento simbolico
o \param{size} non è positiva.
- \end{errlist} ed inoltre \errval{EACCES}, \errval{EFAULT}, \errval{EIO},
- \errval{ELOOP}, \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM} e
- \errval{ENOTDIR} nel loro significato generico.}
+ \end{errlist} ed inoltre \errval{EFAULT}, \errval{EIO}, \errval{ELOOP},
+ \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM} e \errval{ENOTDIR}
+ nel loro significato generico.}
\end{funcproto}
La funzione legge il \textit{pathname} a cui fa riferimento il collegamento
-simbolico indicato dall'argomento \param{path} scrivendolo sul
-buffer \param{buff} di dimensione \param{size}. Si tenga presente che la
-funzione non termina la stringa con un carattere nullo e che se questa è
-troppo lunga la tronca alla dimensione specificata da \param{size} per evitare
-di sovrascrivere oltre le dimensioni del buffer.
+simbolico indicato dall'argomento \param{pathname} scrivendolo sul buffer
+\param{buff} di dimensione \param{size}. Si tenga presente che la funzione non
+termina la stringa con un carattere nullo e che se questa è troppo lunga la
+tronca alla dimensione specificata da \param{size} per evitare di scrivere
+dati oltre le dimensioni del buffer.
\begin{figure}[htb]
\centering
- \includegraphics[width=8.5cm]{img/link_loop}
+ \includegraphics[width=8cm]{img/link_loop}
\caption{Esempio di loop nel filesystem creato con un collegamento
simbolico.}
\label{fig:file_link_loop}
dei nomi che non possono essere eliminati facilmente. Invece è sempre
possibile, ed in genere anche molto utile, creare un collegamento simbolico ad
una directory, anche se in questo caso si potranno ottenere anche dei
-\textit{loop}. La situazione è illustrata in fig.~\ref{fig:file_link_loop},
-che riporta la struttura della directory \file{/boot}. Come si vede si è
-creato al suo interno un collegamento simbolico che punta di nuovo a
+\textit{loop}.
+
+La situazione è illustrata in fig.~\ref{fig:file_link_loop}, che riporta la
+struttura della directory \file{/boot}. Come si vede si è creato al suo
+interno un collegamento simbolico che punta di nuovo a
\file{/boot}.\footnote{il \textit{loop} mostrato in
- fig.~\ref{fig:file_link_loop} è stato usato per poter permettere a
- \cmd{grub} (un bootloader in grado di leggere direttamente da vari
- filesystem il file da lanciare come sistema operativo) di vedere i file
- contenuti nella directory \file{/boot} con lo stesso \textit{pathname} con
- cui verrebbero visti dal sistema operativo, anche se essi si trovano, come
- accade spesso, su una partizione separata (che \cmd{grub} all'avvio vedrebbe
- come \file{/}).}
-
-Questo però può causare problemi per tutti quei programmi che effettuano la
-scansione di una directory senza tener conto dei collegamenti simbolici, ad
-esempio se lanciassimo un comando del tipo \code{grep -r linux *}, il loop
-nella directory porterebbe il comando ad esaminare \file{/boot},
-\file{/boot/boot}, \file{/boot/boot/boot} e così via.
+ fig.~\ref{fig:file_link_loop} è stato usato per poter permettere a al
+ \textit{bootloader} \cmd{grub} di vedere i file contenuti nella directory
+ \file{/boot} con lo stesso \textit{pathname} con cui verrebbero visti dal
+ sistema operativo, anche quando si trovano, come accade spesso, su una
+ partizione separata (che \cmd{grub} all'avvio vedrebbe come \file{/}).} Un
+\textit{loop} di di questo tipo però può causare problemi per tutti i
+programmi che effettuano la scansione di una directory, e ad esempio se
+lanciassimo un comando come \code{grep -r linux *}, il \textit{loop} nella
+directory porterebbe ad esaminare \file{/boot}, \file{/boot/boot},
+\file{/boot/boot/boot} e così via.
Per questo motivo il kernel e le librerie prevedono che nella risoluzione di
un \textit{pathname} possano essere seguiti fino ad un certo numero massimo di
collegamenti simbolici, il cui valore limite è specificato dalla costante
-\constd{MAXSYMLINKS}. Qualora questo limite venga superato viene generato un
-errore ed \var{errno} viene impostata al valore \errcode{ELOOP}, che nella
-quasi totalità dei casi indica appunto che si è creato un collegamento
-simbolico che fa riferimento ad una directory del suo stesso
-\textit{pathname}.
-
-Un altro punto da tenere sempre presente è che, come abbiamo accennato, un
-collegamento simbolico può fare riferimento anche ad un file che non esiste;
-ad esempio possiamo usare il comando \cmd{ln} per creare un collegamento
-simbolico nella nostra directory con:
-\begin{Console}
-piccardi@hain:~/gapil$ \textbf{ln -s /tmp/tmp_file symlink}
-\end{Console}
-%$
-e questo avrà successo anche se \file{/tmp/tmp\_file} non esiste:
-\begin{Console}
-piccardi@hain:~/gapil$ \textbf{ls symlink}
-symlink
-\end{Console}
-%$
-ma questo può generare confusione, perché accedendo in sola lettura a
-\file{symlink}, ad esempio con \cmd{cat}, otterremmo un errore:
-\begin{Console}
-piccardi@hain:~/gapil$ \textbf{cat symlink}
-cat: symlink: No such file or directory
-\end{Console}
-%$
-con un errore che può sembrare sbagliato, dato che \cmd{ls} ci ha mostrato
-l'esistenza di \file{symlink}, se invece scrivessimo su \file{symlink}
-otterremmo la creazione di \file{/tmp/tmp\_file} senza errori.
+\constd{MAXSYMLINKS}. Se il limite viene superato si ha un errore ed
+\var{errno} viene impostata al valore \errcode{ELOOP}, che nella quasi
+totalità dei casi indica appunto che si è creato un collegamento simbolico che
+fa riferimento ad una directory del suo stesso \textit{pathname}.
\itindend{symbolic~link}
\index{collegamento!simbolico|)}
Un'altra funzione relativa alla gestione dei nomi dei file, anche se a prima
-vista parrebbe riguardare un argomento completamente diverso, è quella che per
-la cancellazione di un file. In realtà una \textit{system call} che serva
-proprio a cancellare un file non esiste neanche perché, come accennato in
+vista parrebbe riguardare un argomento completamente diverso, è quella per la
+cancellazione di un file. In realtà una \textit{system call} che serva proprio
+a cancellare un file non esiste neanche perché, come accennato in
sez.~\ref{sec:file_filesystem}, quando in un sistema unix-like si richiede la
-rimozione di un file quella che si va a cancellare è soltanto la voce che
+rimozione di un file, quello che si va a cancellare è soltanto la voce che
referenzia il suo \textit{inode} all'interno di una directory.
La funzione di sistema che consente di effettuare questa operazione, il cui
nel qual caso \var{errno} assumerà uno dei valori:\footnotemark
\begin{errlist}
\item[\errcode{EACCES}] non si ha il permesso di scrittura sulla directory
- che contiene \param{pathname} o di attraversamento di una delle directory
- superiori.
+ che contiene \param{pathname} o quello di attraversamento per una delle
+ directory superiori.
+ \item[\errcode{EBUSY}] \param{pathname} non può essere rimosso perché è in
+ uso da parte del sistema (in particolare per i cosiddetti \textit{silly
+ renames} di NFS).
\item[\errcode{EISDIR}] \param{pathname} si riferisce ad una
directory.
\item[\errcode{EPERM}] il filesystem non consente l'operazione, o la
directory che contiene \param{pathname} ha lo \textit{sticky bit} e non si
- è il proprietario o non si hanno privilegi amministrativi.
+ è il proprietario del file o non si hanno privilegi amministrativi.
\end{errlist} ed inoltre \errval{EFAULT}, \errval{EIO}, \errval{ELOOP},
\errval{ENOENT}, \errval{ENOMEM}, \errval{ENOTDIR}, \errval{EROFS} nel loro
significato generico.}
La funzione elimina il nome specificato dall'argomento \param{pathname} nella
directory che lo contiene e decrementa il numero di riferimenti nel relativo
-\textit{inode}.\footnote{come per \func{link} queste due operazioni sono
- effettuate all'interno della \textit{system call} in maniera atomica.} Nel
-caso di socket, \textit{fifo} o file di dispositivo rimuove il nome, ma come
-per i file normali i processi che hanno aperto uno di questi oggetti possono
-continuare ad utilizzarli. Nel caso di cancellazione di un collegamento
-simbolico, che consiste solo nel rimando ad un altro file, questo viene
-immediatamente eliminato.
+\textit{inode}; come per \func{link} queste due operazioni sono effettuate
+all'interno della \textit{system call} in maniera atomica rispetto ai
+processi.
+
+Si ricordi che, anche se se ne è rimosso il nome, un file viene realmente
+cancellato soltanto quando il numero di collegamenti mantenuto
+nell'\textit{inode} diventa nullo; solo allora l'\textit{inode} viene
+disallocato e lo spazio che il file occupava sul disco viene liberato.
+
+Si tenga presente comunque che a questo si aggiunge sempre un'ulteriore
+condizione e cioè che non ci siano processi che stiano ancora lavorando sul il
+file. Come vedremo in sez.~\ref{sec:file_unix_interface} il kernel una tabella
+di tutti file aperti da ciascun processo, che a sua volta contiene i
+riferimenti agli \textit{inode} ad essi relativi. Prima di procedere alla
+cancellazione dello spazio occupato su disco dal contenuto di un file il
+kernel controlla anche questa tabella, per verificare che anche in essa non ci
+sia più nessun riferimento all'\textit{inode} in questione, assicurandosi con
+questo che nessun processo stia ancora usando il file.
+
+Nel caso di socket, \textit{fifo} o file di dispositivo la funzione rimuove il
+nome, e come per i file normali i processi che hanno aperto uno di questi
+oggetti possono continuare ad utilizzarli. Nel caso di cancellazione di un
+\textit{link} simbolico, che consiste solo nel rimando ad un altro file,
+questo viene immediatamente eliminato e non sarà più utilizzabile.
Per cancellare una voce in una directory è necessario avere il permesso di
scrittura su di essa, dato che si va a rimuovere una voce dal suo contenuto, e
il diritto di esecuzione/attraversamento sulla directory che la contiene
(affronteremo in dettaglio l'argomento dei permessi di file e directory in
-sez.~\ref{sec:file_access_control}). Se inoltre lo \textit{sticky bit} (vedi
-sez.~\ref{sec:file_special_perm}) è impostato occorrerà anche essere
-proprietari del file o proprietari della directory o avere i privilegi di
-amministratore.
-
-Si ricordi inoltre che anche se se ne è rimosso il nome da una directory, un
-file non viene eliminato dal disco fintanto che tutti i riferimenti ad esso
-sono stati cancellati: solo quando il numero di collegamenti mantenuto
-nell'\textit{inode} diventa nullo, questo viene disallocato e lo spazio
-occupato su disco viene liberato. Si tenga presente comunque che a questo si
-aggiunge sempre un'ulteriore condizione e cioè che non ci siano processi che
-abbiano il suddetto file aperto.\footnote{come vedremo in
- sez.~\ref{sec:file_unix_interface} il kernel mantiene anche una tabella dei
- file aperti nei vari processi, che a sua volta contiene i riferimenti agli
- \textit{inode} ad essi relativi; prima di procedere alla cancellazione dello
- spazio occupato su disco dal contenuto di un file il kernel controlla anche
- questa tabella, per verificare che anche in essa non ci sia più nessun
- riferimento all'\textit{inode} in questione.}
-
-Questa caratteristica del sistema può essere usata per essere sicuri di non
-lasciare file temporanei su disco in caso di crash di un programma. La tecnica
-è quella di aprire un nuovo file e chiamare \func{unlink} su di esso subito
+sez.~\ref{sec:file_access_control}). Se inoltre per la directory è impostato
+lo \textit{sticky bit} (vedi sez.~\ref{sec:file_special_perm}), occorrerà
+anche essere proprietari del file o proprietari della directory o avere i
+privilegi di amministratore.
+
+Questa caratteristica del sistema, che consente di usare un file anche se lo
+si è ``cancellato'', può essere usata per essere sicuri di non lasciare file
+temporanei su disco in caso di uscita imprevista di un programma. La tecnica è
+quella di aprire un nuovo file e chiamare \func{unlink} su di esso subito
dopo, in questo modo il contenuto del file sarà sempre disponibile all'interno
del processo attraverso il suo file descriptor (vedi sez.~\ref{sec:file_fd}),
-ma non ne resta traccia in nessuna directory, e lo spazio occupato su disco
-viene immediatamente rilasciato alla conclusione del processo, quando tutti i
-file vengono chiusi.
+ma non ne resterà traccia in nessuna directory, inoltre lo spazio occupato su
+disco verrà immediatamente rilasciato alla conclusione del processo, quando
+tutti i file vengono chiusi.
Al contrario di quanto avviene con altri Unix, in Linux non è possibile usare
-la funzione \func{unlink} sulle directory, nel qual caso si otterrebbe un
+la funzione \func{unlink} sulle directory, che in tal caso fallisce con un
errore di \errcode{EISDIR}. Per cancellare una directory si deve usare la
apposita funzione di sistema \func{rmdir} (che vedremo in
sez.~\ref{sec:file_dir_creat_rem}), oppure la funzione \func{remove}.
+
Quest'ultima è la funzione prevista dallo standard ANSI C per effettuare una
-cancellazione generica di un file o di una directory e funziona anche per i
-sistemi operativo che non supportano gli \textit{hard link}. Nei sistemi
-unix-like \funcd{remove} è equivalente ad usare in maniera trasparente
+cancellazione generica di un file o di una directory e viene usata in generale
+anche per i sistemi operativi che non supportano gli \textit{hard link}. Nei
+sistemi unix-like \funcd{remove} è equivalente ad usare in maniera trasparente
\func{unlink} per i file ed \func{rmdir} per le directory; il suo prototipo è:
\begin{funcproto}{
\func{unlink} e \func{rmdir}.}
\end{funcproto}
-La funzione utilizza la funzione \func{unlink} per cancellare i file e la
-funzione \func{rmdir} (vedi sez.~\ref{sec:file_dir_creat_rem}) per cancellare
-le directory.\footnote{questo vale usando la \acr{glibc}; nella libc4 e nella
- libc5 la funzione \func{remove} era un semplice alias alla funzione
- \func{unlink} e quindi non poteva essere usata per le directory.} Si tenga
-presente che per alcune implementazioni del protocollo NFS utilizzare questa
-funzione può comportare la scomparsa di file ancora in uso.
+La funzione utilizza la funzione \func{unlink} per cancellare i file (e si
+applica anche a link simbolici, socket, \textit{fifo} e file di dispositivo) e
+la funzione \func{rmdir} (vedi sez.~\ref{sec:file_dir_creat_rem}) per
+cancellare le directory.\footnote{questo vale usando la \acr{glibc}; nella
+ \acr{libc4} e nella \acr{libc5} la funzione \func{remove} era un semplice
+ alias alla funzione \func{unlink} e quindi non poteva essere usata per le
+ directory.} Si tenga presente che, per alcune limitazioni del protocollo
+NFS, utilizzare questa funzione su file che usano questo filesystem di rete
+può comportare la scomparsa di file ancora in uso.
Infine per cambiare nome ad un file o a una directory si usa la funzione di
sistema \funcd{rename},\footnote{la funzione è definita dallo standard ANSI C,
{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{EACCESS}] non c'è permesso di scrivere nelle directory
+ \item[\errcode{EACCESS}] manca il permesso di scrittura sulle directory
contenenti \param{oldpath} e \param{newpath} o di attraversare
- quelle dei loro \textit{pathname} o di scrivere su \param{newpath}
+ il loro \textit{pathname} o di scrivere su \param{newpath}
se questa è una directory.
\item[\errcode{EBUSY}] o \param{oldpath} o \param{newpath} sono in uso da
parte di qualche processo (come directory di lavoro o come radice) o del
in ``\file{.}'' e ``\file{..}'' anche se validi in altri contesti, causeranno
il fallimento della funzione.
+Inoltre per eseguire la cancellazione, oltre ad essere vuota, occorre anche
+che la directory non sia utilizzata, questo vuol dire anche che non deve
+essere la directory di lavoro (vedi sez.~\ref{sec:file_work_dir}) o la
+directory radice (vedi sez.~\ref{sec:file_chroot}) di nessun processo, od
+essere utilizzata come \textit{mount point}.
+
Se la directory cancellata risultasse aperta in qualche processo per una
lettura dei suoi contenuti (vedi sez.~\ref{sec:file_dir_read}), pur
scomparendo dal filesystem e non essendo più possibile accedervi o crearvi
\func{versionsort}, che ordina i nomi tenendo conto del numero di versione,
cioè qualcosa per cui \texttt{file10} viene comunque dopo \texttt{file4}.
-\begin{figure}[!htbp]
+\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{\codesamplewidth}
\includecodesample{listati/my_ls.c}
nome del file e la dimensione riportata in \var{data}.
Dato che la funzione verrà chiamata all'interno di \myfunc{dir\_scan} per ogni
-voce presente questo è sufficiente a stampare la lista completa dei file e
+voce presente, questo è sufficiente a stampare la lista completa dei file e
delle relative dimensioni. Si noti infine come si restituisca sempre 0 come
valore di ritorno per indicare una esecuzione senza errori.
-\begin{figure}[!htbp]
+\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{\codesamplewidth}
\includecodesample{listati/dir_scan.c}
caso sarà \code{do\_ls}), ritornando con un codice di errore (\texttt{\small
28}) qualora questa presenti una anomalia, identificata da un codice di
ritorno negativo. Una volta terminato il ciclo la funzione si conclude con la
-chiusura (\texttt{\small 32}) dello \textit{stream}\footnote{nel nostro caso,
+chiusura (\texttt{\small 31}) dello \textit{stream}\footnote{nel nostro caso,
uscendo subito dopo la chiamata, questo non servirebbe, in generale però
l'operazione è necessaria, dato che la funzione può essere invocata molte
volte all'interno dello stesso processo, per cui non chiudere i
\index{directory~di~lavoro|(}
Come accennato in sez.~\ref{sec:proc_fork} a ciascun processo è associata una
-directory nel filesystem,\footnote{questa viene mantenuta all'interno dei dati
- della sua \kstruct{task\_struct} (vedi fig.~\ref{fig:proc_task_struct}), più
- precisamente nel campo \texttt{pwd} della sotto-struttura
- \kstruct{fs\_struct}.} che è chiamata \textsl{directory corrente} o
-\textsl{directory di lavoro} (in inglese \textit{current working directory}).
-La directory di lavoro è quella da cui si parte quando un \textit{pathname} è
-espresso in forma relativa, dove il ``\textsl{relativa}'' fa riferimento
-appunto a questa directory.
+directory nell'albero dei file,\footnote{questa viene mantenuta all'interno
+ dei dati della sua \kstruct{task\_struct} (vedi
+ fig.~\ref{fig:proc_task_struct}), più precisamente nel campo \texttt{pwd}
+ della sotto-struttura \kstruct{fs\_struct}.} che è chiamata
+\textsl{directory corrente} o \textsl{directory di lavoro} (in inglese
+\textit{current working directory}). La directory di lavoro è quella da cui
+si parte quando un \textit{pathname} è espresso in forma relativa, dove il
+``\textsl{relativa}'' fa riferimento appunto a questa directory.
Quando un utente effettua il login, questa directory viene impostata alla
\textit{home directory} del suo account. Il comando \cmd{cd} della shell
-
-
\section{La manipolazione delle caratteristiche dei file}
\label{sec:file_infos}
la funzione \func{stat}, che permette l'accesso a tutti i dati memorizzati
nell'\textit{inode}; esamineremo poi le varie funzioni usate per manipolare
tutte queste informazioni, eccetto quelle che riguardano la gestione del
-controllo di accesso, trattate in in sez.~\ref{sec:file_access_control}.
+controllo di accesso, trattate in sez.~\ref{sec:file_access_control}.
\subsection{La lettura delle caratteristiche dei file}
contenuto della directory.
Questo significa che se si ha il permesso di esecuzione senza permesso di
-lettura si potrà lo stesso aprire un file all'interno di una una directory (se
-si hanno i permessi adeguati per il medesimo) ma non si potrà vederlo con
+lettura si potrà lo stesso aprire un file all'interno di una directory (se si
+hanno i permessi adeguati per il medesimo) ma non si potrà vederlo con
\cmd{ls} mancando il permesso di leggere il contenuto della directory. Per
crearlo o rinominarlo o cancellarlo invece occorrerà avere anche il permesso
di scrittura per la directory.
\fdesc{Imposta la maschera dei permessi.}
}
-{La funzione ritorna ritorna il precedente valore della maschera, non sono
- previste condizioni di errore.}
+{La funzione ritorna il precedente valore della maschera, non sono previste
+ condizioni di errore.}
\end{funcproto}
La funzione imposta la maschera dei permessi dei bit al valore specificato
cui essi fanno riferimento. Questa scelta vale però soltanto per i file e le
directory ordinarie, se valesse in generale infatti si avrebbe un serio
problema di sicurezza dato che esistono diversi oggetti sul filesystem per i
- quali è normale avere avere il permesso di scrittura consentito a tutti gli
+ quali è normale avere il permesso di scrittura consentito a tutti gli
utenti, come i collegamenti simbolici, o alcuni file di dispositivo come
\texttt{/dev/null}. Se fosse possibile usare su di essi gli \textit{extended
user attributes} un utente qualunque potrebbe inserirvi dati a
{La funzione ritorna un oggetto di tipo \type{acl\_t} in caso di successo in
caso di successo e \val{NULL} per un errore, nel qual caso \var{errno}
- assumerà assumerà uno dei valori:
+ assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EINVAL}] l'argomento \param{acl} non è un puntatore valido
per una ACL.
indicata viene utilizzata come prefisso per le singole voci.
L'ultimo argomento, \param{options}, consente di controllare la modalità con
-cui viene generata la rappresentazione testuale. Un valore nullo fa si che
+cui viene generata la rappresentazione testuale. Un valore nullo fa sì che
vengano usati gli identificatori standard \texttt{user}, \texttt{group},
\texttt{other} e \texttt{mask} con i nomi di utenti e gruppi risolti rispetto
ai loro valori numerici. Altrimenti si può specificare un valore in forma di
apposita funzione di uscita, mentre si restituisce come prima una eccezione
con il valore di \var{errno} in caso di errore (\texttt{\small 12-13}).
-
-\subsection{La gestione delle \textit{capabilities}}
-\label{sec:proc_capabilities}
-
-\itindbeg{capabilities}
-
-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
-quando si siano predisposte delle misure di protezione per in essere in grado
-di difendersi dagli effetti di una eventuale compromissione del sistema (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 misure potranno essere comunque
-rimosse (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
-diritti di amministratore non potesse eseguire certe operazioni, o per cedere
-definitivamente alcuni privilegi da un certo momento in poi.
-
-Per risolvere questo problema sono possibili varie soluzioni ed ad esempio dai
-kernel 2.5 è stata introdotta la struttura dei
-\itindex{Linux~Security~Modules} \textit{Linux Security Modules} che han
-permesso di aggiungere varie forme di \itindex{Mandatory~Access~Control~(DAC)}
-\textit{Mandatory Access Control} (MAC), in cui si potessero parcellizzare e
-controllare nei minimi dettagli tutti i privilegi e le modalità in cui questi
-possono essere usati dai programmi e trasferiti agli utenti, con la creazione
-di varie estensioni (come \textit{SELinux}, \textit{Smack}, \textit{Tomoyo},
-\textit{AppArmor}) che consentono di superare l'architettura tradizionale dei
-permessi basati sul modello classico del controllo di accesso chiamato
-\itindex{Discrectionary~Access~Control~(DAC)} \textit{Discrectionary Access
- Control} (DAC).
-
-Ma già in precedenza, a partire dai kernel della serie 2.2, era stato
-introdotto un meccanismo, detto \textit{capabilities}, che consentisse di
-suddividere i vari privilegi tradizionalmente associati all'amministratore in
-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 situazione
-originaria di ``\textsl{tutto o nulla}''.
-
-\itindbeg{file~capabilities}
-
-Il meccanismo completo delle \textit{capabilities} (l'implementazione si rifà
-ad una bozza di quello che doveva diventare lo standard POSIX.1e, poi
-abbandonato) prevede inoltre la possibilità di associare le stesse ai singoli
-file eseguibili, in modo da poter stabilire quali capacità possono essere
-utilizzate quando viene messo in esecuzione uno specifico programma; ma il
-supporto per questa funzionalità, chiamata \textit{file capabilities}, è stato
-introdotto soltanto a partire dal kernel 2.6.24. Fino ad allora doveva essere
-il programma stesso ad eseguire una riduzione esplicita delle sue capacità,
-cosa che ha reso l'uso di questa funzionalità poco diffuso, vista la presenza
-di meccanismi alternativi per ottenere limitazioni delle capacità
-dell'amministratore a livello di sistema operativo, come \textit{SELinux}.
-
-Con questo supporto e con le ulteriori modifiche introdotte con il kernel
-2.6.25 il meccanismo delle \textit{capabilities} è stato totalmente
-rivoluzionato, rendendolo più aderente alle intenzioni originali dello
-standard POSIX, rimuovendo il significato che fino ad allora aveva avuto la
-capacità \const{CAP\_SETPCAP} e cambiando le modalità di funzionamento del
-cosiddetto \textit{capabilities bounding set}. Ulteriori modifiche sono state
-apportate con il kernel 2.6.26 per consentire la rimozione non ripristinabile
-dei privilegi di amministratore. Questo fa sì che il significato ed il
-comportamento del kernel finisca per dipendere dalla versione dello stesso e
-dal fatto che le nuove \textit{file capabilities} siano abilitate o meno. Per
-capire meglio la situazione e cosa è cambiato conviene allora spiegare con
-maggiori dettagli come funziona il meccanismo delle \textit{capabilities}.
-
-Il primo passo per frazionare i privilegi garantiti all'amministratore,
-supportato fin dalla introduzione iniziale del kernel 2.2, è stato quello in
-cui a ciascun processo sono stati associati tre distinti insiemi di
-\textit{capabilities}, denominati rispettivamente \textit{permitted},
-\textit{inheritable} ed \textit{effective}. Questi insiemi vengono mantenuti
-in forma di tre diverse maschere binarie,\footnote{il kernel li mantiene, come
- i vari identificatori di sez.~\ref{sec:proc_setuid}, all'interno della
- \texttt{task\_struct} di ciascun processo (vedi
- fig.~\ref{fig:proc_task_struct}), nei tre campi \texttt{cap\_effective},
- \texttt{cap\_inheritable}, \texttt{cap\_permitted} del tipo
- \texttt{kernel\_cap\_t}; questo era, fino al kernel 2.6.25 definito come
- intero a 32 bit per un massimo di 32 \textit{capabilities} distinte,
- attualmente è stato aggiornato ad un vettore in grado di mantenerne fino a
- 64.} in cui ciascun bit corrisponde ad una capacità diversa.
-
-L'utilizzo di tre distinti insiemi serve a fornire una interfaccia flessibile
-per l'uso delle \textit{capabilities}, con scopi analoghi a quelli per cui
-sono mantenuti i diversi insiemi di identificatori di
-sez.~\ref{sec:proc_setuid}; il loro significato, che è rimasto sostanzialmente
-lo stesso anche dopo le modifiche seguite alla introduzione delle
-\textit{file capabilities} è il seguente:
-\begin{basedescript}{\desclabelwidth{2.1cm}\desclabelstyle{\nextlinelabel}}
-\item[\textit{permitted}] l'insieme delle \textit{capabilities}
- ``\textsl{permesse}'', cioè l'insieme di quelle capacità che un processo
- \textsl{può} impostare come \textsl{effettive} o come
- \textsl{ereditabili}. Se un processo cancella una capacità da questo insieme
- non potrà più riassumerla.\footnote{questo nei casi ordinari, sono
- previste però una serie di eccezioni, dipendenti anche dal tipo di
- supporto, che vedremo meglio in seguito dato il notevole intreccio nella
- casistica.}
-\item[\textit{inheritable}] l'insieme delle \textit{capabilities}
- ``\textsl{ereditabili}'', cioè di quelle che verranno trasmesse come insieme
- delle \textsl{permesse} ad un nuovo programma eseguito attraverso una
- chiamata ad \func{exec}.
-\item[\textit{effective}] l'insieme delle \textit{capabilities}
- ``\textsl{effettive}'', cioè di quelle che vengono effettivamente usate dal
- kernel quando deve eseguire il controllo di accesso per le varie operazioni
- compiute dal processo.
-\label{sec:capabilities_set}
-\end{basedescript}
-
-Con l'introduzione delle \textit{file capabilities} sono stati introdotti
-altri tre insiemi associabili a ciascun file.\footnote{la realizzazione viene
- eseguita con l'uso di uno specifico attributo esteso,
- \texttt{security.capability}, la cui modifica è riservata, (come illustrato
- in sez.~\ref{sec:file_xattr}) ai processi dotato della capacità
- \const{CAP\_SYS\_ADMIN}.} Le \textit{file capabilities} hanno effetto
-soltanto quando il file che le porta viene eseguito come programma con una
-\func{exec}, e forniscono un meccanismo che consente l'esecuzione dello stesso
-con maggiori privilegi; in sostanza sono una sorta di estensione del
-\acr{suid} bit limitato ai privilegi di amministratore. Anche questi tre
-insiemi sono identificati con gli stessi nomi di quello dei processi, ma il
-loro significato è diverso:
-\begin{basedescript}{\desclabelwidth{2.1cm}\desclabelstyle{\nextlinelabel}}
-\item[\textit{permitted}] (chiamato originariamente \textit{forced}) l'insieme
- delle capacità che con l'esecuzione del programma verranno aggiunte alle
- capacità \textsl{permesse} del processo.
-\item[\textit{inheritable}] (chiamato originariamente \textit{allowed})
- l'insieme delle capacità che con l'esecuzione del programma possono essere
- ereditate dal processo originario (che cioè non vengono tolte
- dall'\textit{inheritable set} del processo originale all'esecuzione di
- \func{exec}).
-\item[\textit{effective}] in questo caso non si tratta di un insieme ma di un
- unico valore logico; se attivo all'esecuzione del programma tutte le
- capacità che risulterebbero \textsl{permesse} verranno pure attivate,
- inserendole automaticamente nelle \textsl{effettive}, se disattivato nessuna
- capacità verrà attivata (cioè l'\textit{effective set} resterà vuoto).
-\end{basedescript}
-
-\itindbeg{capabilities~bounding~set}
-
-Infine come accennato, esiste un ulteriore insieme, chiamato
-\textit{capabilities bounding set}, il cui scopo è quello di costituire un
-limite alle capacità che possono essere attivate per un programma. Il suo
-funzionamento però è stato notevolmente modificato con l'introduzione delle
-\textit{file capabilities} e si deve pertanto prendere in considerazione una
-casistica assai complessa.
-
-Per i kernel fino al 2.6.25, o se non si attiva il supporto per le
-\textit{file capabilities}, il \textit{capabilities bounding set} è un
-parametro generale di sistema, il cui valore viene riportato nel file
-\sysctlfiled{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
- 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
-programma attraverso una \func{exec}. Questo in sostanza significa che se un
-qualunque programma elimina da esso una capacità, considerato che
-\texttt{init} (almeno nelle versioni ordinarie) non supporta la reimpostazione
-del \textit{bounding set}, questa non sarà più disponibile per nessun processo
-a meno di un riavvio, eliminando così in forma definitiva quella capacità per
-tutti, compreso l'amministratore.\footnote{la qual cosa, visto il default
- usato per il \textit{capabilities bounding set}, significa anche che
- \const{CAP\_SETPCAP} non è stata praticamente mai usata nella sua forma
- originale.}
-
-Con il kernel 2.6.25 e le \textit{file capabilities} il \textit{bounding set}
-è diventato una proprietà di ciascun processo, che viene propagata invariata
-sia attraverso una \func{fork} che una \func{exec}. In questo caso il file
-\sysctlfile{kernel/cap-bound} non esiste e \texttt{init} non ha nessun
-ruolo speciale, inoltre in questo caso all'avvio il valore iniziale prevede la
-presenza di tutte le capacità (compresa \const{CAP\_SETPCAP}).
-
-Con questo nuovo meccanismo il \textit{bounding set} continua a ricoprire un
-ruolo analogo al precedente nel passaggio attraverso una \func{exec}, come
-limite alle capacità che possono essere aggiunte al processo in quanto
-presenti nel \textit{permitted set} del programma messo in esecuzione, in
-sostanza il nuovo programma eseguito potrà ricevere una capacità presente nel
-suo \textit{permitted set} (quello del file) solo se questa è anche nel
-\textit{bounding set} (del processo). In questo modo si possono rimuovere
-definitivamente certe capacità da un processo, anche qualora questo dovesse
-eseguire un programma privilegiato che prevede di riassegnarle.
-
-Si tenga presente però che in questo caso il \textit{bounding set} blocca
-esclusivamente le capacità indicate nel \textit{permitted set} del programma
-che verrebbero attivate in caso di esecuzione, e non quelle eventualmente già
-presenti nell'\textit{inheritable set} del processo (ad esempio perché
-presenti prima di averle rimosse dal \textit{bounding set}). In questo caso
-eseguendo un programma che abbia anche lui dette capacità nel suo
-\textit{inheritable set} queste verrebbero assegnate.
-
-In questa seconda versione inoltre il \textit{bounding set} costituisce anche
-un limite per le capacità che possono essere aggiunte all'\textit{inheritable
- set} del processo stesso con \func{capset}, sempre nel senso che queste
-devono essere presenti nel \textit{bounding set} oltre che nel
-\textit{permitted set} del processo. Questo limite vale anche per processi con
-i privilegi di amministratore,\footnote{si tratta sempre di avere la
- \textit{capability} \const{CAP\_SETPCAP}.} per i quali invece non vale la
-condizione che le \textit{capabilities} da aggiungere nell'\textit{inheritable
- set} debbano essere presenti nel proprio \textit{permitted set}.\footnote{lo
- scopo anche in questo caso è ottenere una rimozione definitiva della
- possibilità di passare una capacità rimossa dal \textit{bounding set}.}
-
-Come si può notare per fare ricorso alle \textit{capabilities} occorre
-comunque farsi carico di una notevole complessità di gestione, aggravata dalla
-presenza di una radicale modifica del loro funzionamento con l'introduzione
-delle \textit{file capabilities}. Considerato che il meccanismo originale era
-incompleto e decisamente problematico nel caso di programmi che non ne
-sapessero tener conto,\footnote{c'è stato un grosso problema di sicurezza con
- \texttt{sendmail}, riuscendo a rimuovere \const{CAP\_SETGID}
- dall'\textit{inheritable set} di un processo si ottenne di far fallire
- \func{setuid} in maniera inaspettata per il programma (che aspettandosi
- sempre il successo della funzione non ne controllava lo stato di uscita) con
- la conseguenza di effettuare come amministratore operazioni che altrimenti
- sarebbero state eseguite, senza poter apportare danni, da utente normale.}
-ci soffermeremo solo sulla implementazione completa presente a partire dal
-kernel 2.6.25, tralasciando ulteriori dettagli riguardo la versione
-precedente.
-
-Riassumendo le regole finora illustrate tutte le \textit{capabilities} vengono
-ereditate senza modifiche attraverso una \func{fork} mentre, indicati con
-\texttt{orig\_*} i valori degli insiemi del processo chiamante, con
-\texttt{file\_*} quelli del file eseguito e con \texttt{bound\_set} il
-\textit{capabilities bounding set}, dopo l'invocazione di \func{exec} il
-processo otterrà dei nuovi insiemi di capacità \texttt{new\_*} secondo la
-formula espressa 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}.
-
-
-\itindend{capabilities~bounding~set}
-
-A queste regole se ne aggiungono delle altre che servono a riprodurre il
-comportamento tradizionale di un sistema unix-like in tutta una serie di
-circostanze. La prima di queste è relativa a quello che avviene quando si
-esegue un file senza \textit{capabilities}; se infatti si considerasse questo
-equivalente al non averne assegnata alcuna, non essendo presenti capacità né
-nel \textit{permitted set} né nell'\textit{inheritable set} del file,
-nell'esecuzione di un qualunque programma l'amministratore perderebbe tutti i
-privilegi originali dal processo.
-
-Per questo motivo se un programma senza \textit{capabilities} assegnate viene
-eseguito da un processo con \ids{UID} reale 0, esso verrà trattato come
-se tanto il \textit{permitted set} che l'\textit{inheritable set} fossero con
-tutte le \textit{capabilities} abilitate, con l'\textit{effective set} attivo,
-col risultato di fornire comunque al processo tutte le capacità presenti nel
-proprio \textit{bounding set}. Lo stesso avviene quando l'eseguibile ha attivo
-il \acr{suid} bit ed appartiene all'amministratore, in entrambi i casi si
-riesce così a riottenere il comportamento classico di un sistema unix-like.
-
-Una seconda circostanza è quella relativa a cosa succede alle
-\textit{capabilities} di un processo nelle possibili transizioni da \ids{UID}
-nullo a \ids{UID} non nullo o viceversa (corrispondenti rispettivamente a
-cedere o riottenere i i privilegi di amministratore) che si possono effettuare
-con le varie funzioni viste in sez.~\ref{sec:proc_setuid}. In questo caso la
-casistica è di nuovo alquanto complessa, considerata anche la presenza dei
-diversi gruppi di identificatori illustrati in tab.~\ref{tab:proc_uid_gid}, si
-avrà allora che:
-\begin{enumerate*}
-\item se si passa da \ids{UID} effettivo nullo a non nullo
- l'\textit{effective set} del processo viene totalmente azzerato, se
- viceversa si passa da \ids{UID} effettivo non nullo a nullo il
- \textit{permitted set} viene copiato nell'\textit{effective set};
-\item se si passa da \textit{file system} \ids{UID} nullo a non nullo verranno
- cancellate dall'\textit{effective set} del processo tutte le capacità
- attinenti i file, e cioè \const{CAP\_LINUX\_IMMUTABLE}, \const{CAP\_MKNOD},
- \const{CAP\_DAC\_OVERRIDE}, \const{CAP\_DAC\_READ\_SEARCH},
- \const{CAP\_MAC\_OVERRIDE}, \const{CAP\_CHOWN}, \const{CAP\_FSETID} e
- \const{CAP\_FOWNER} (le prime due a partire dal kernel 2.2.30), nella
- transizione inversa verranno invece inserite nell'\textit{effective set}
- quelle capacità della precedente lista che sono presenti nel suo
- \textit{permitted set}.
-\item se come risultato di una transizione riguardante gli identificativi dei
- gruppi \textit{real}, \textit{saved} ed \textit{effective} in cui si passa
- da una situazione in cui uno di questi era nullo ad una in cui sono tutti
- non nulli,\footnote{in sostanza questo è il caso di quando si chiama
- \func{setuid} per rimuovere definitivamente i privilegi di amministratore
- da un processo.} verranno azzerati completamente sia il \textit{permitted
- set} che l'\textit{effective set}.
-\end{enumerate*}
-\label{sec:capability-uid-transition}
-
-La combinazione di tutte queste regole consente di riprodurre il comportamento
-ordinario di un sistema di tipo Unix tradizionale, ma può risultare
-problematica qualora si voglia passare ad una configurazione di sistema
-totalmente basata sull'applicazione delle \textit{capabilities}; in tal caso
-infatti basta ad esempio eseguire un programma con \acr{suid} bit di proprietà
-dell'amministratore per far riottenere ad un processo tutte le capacità
-presenti nel suo \textit{bounding set}, anche se si era avuta la cura di
-cancellarle dal \textit{permitted set}.
-
-\itindbeg{securebits}
-
-Per questo motivo a partire dal kernel 2.6.26, se le \textit{file
- capabilities} sono abilitate, ad ogni processo viene stata associata una
-ulteriore maschera binaria, chiamata \textit{securebits flags}, su cui sono
-mantenuti una serie di flag (vedi tab.~\ref{tab:securebits_values}) il cui
-valore consente di modificare queste regole speciali che si applicano ai
-processi con \ids{UID} nullo. La maschera viene sempre mantenuta
-attraverso una \func{fork}, mentre attraverso una \func{exec} viene sempre
-cancellato il flag \const{SECURE\_KEEP\_CAPS}.
-
-\begin{table}[htb]
- \centering
- \footnotesize
- \begin{tabular}{|l|p{10cm}|}
- \hline
- \textbf{Flag} & \textbf{Descrizione} \\
- \hline
- \hline
- \constd{SECURE\_KEEP\_CAPS}&Il processo non subisce la cancellazione delle
- sue \textit{capabilities} quando tutti i suoi
- \ids{UID} passano ad un valore non
- nullo (regola di compatibilità per il cambio
- di \ids{UID} n.~3 del precedente
- elenco), sostituisce il precedente uso
- dell'operazione \const{PR\_SET\_KEEPCAPS} di
- \func{prctl}.\\
- \constd{SECURE\_NO\_SETUID\_FIXUP}&Il processo non subisce le modifiche
- delle sue \textit{capabilities} nel passaggio
- da nullo a non nullo degli \ids{UID}
- dei gruppi \textit{effective} e
- \textit{file system} (regole di compatibilità
- per il cambio di \ids{UID} nn.~1 e 2 del
- precedente elenco).\\
- \constd{SECURE\_NOROOT} & Il processo non assume nessuna capacità
- aggiuntiva quando esegue un programma, anche
- se ha \ids{UID} nullo o il programma ha
- il \acr{suid} bit attivo ed appartiene
- all'amministratore (regola di compatibilità
- per l'esecuzione di programmi senza
- \textit{capabilities}).\\
- \hline
- \end{tabular}
- \caption{Costanti identificative dei flag che compongono la maschera dei
- \textit{securebits}.}
- \label{tab:securebits_values}
-\end{table}
-
-A ciascuno dei flag di tab.~\ref{tab:securebits_values} è inoltre abbinato un
-corrispondente flag di blocco, identificato da una costante omonima con
-l'estensione \texttt{\_LOCKED}, la cui attivazione è irreversibile ed ha
-l'effetto di rendere permanente l'impostazione corrente del corrispondente
-flag ordinario; in sostanza con \constd{SECURE\_KEEP\_CAPS\_LOCKED} si rende
-non più modificabile \const{SECURE\_KEEP\_CAPS}, ed analogamente avviene con
-\constd{SECURE\_NO\_SETUID\_FIXUP\_LOCKED} per
-\const{SECURE\_NO\_SETUID\_FIXUP} e con \constd{SECURE\_NOROOT\_LOCKED} per
-\const{SECURE\_NOROOT}.
-
-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
-quest'ultima sono comunque necessari i privilegi di amministratore ed in
-particolare la capacità \const{CAP\_SETPCAP}. Prima dell'introduzione dei
-\textit{securebits} era comunque possibile ottenere lo stesso effetto di
-\const{SECURE\_KEEP\_CAPS} attraverso l'uso di un'altra operazione di
-\func{prctl}, \const{PR\_SET\_KEEPCAPS}.
-
-\itindend{securebits}
-
-Oltre alla gestione dei \textit{securebits} la nuova versione delle
-\textit{file capabilities} prevede l'uso di \func{prctl} anche per la gestione
-del \textit{capabilities bounding set}, attraverso altre due operazioni
-dedicate, \const{PR\_CAPBSET\_READ} per controllarne il valore e
-\const{PR\_CAPBSET\_DROP} per modificarlo; quest'ultima di nuovo è una
-operazione privilegiata che richiede la capacità \const{CAP\_SETPCAP} e che,
-come indica chiaramente il nome, permette solo la rimozione di una
-\textit{capability} dall'insieme; per i dettagli sull'uso di tutte queste
-operazioni si rimanda alla rilettura di sez.~\ref{sec:process_prctl}.
-
-\itindend{file~capabilities}
-
-
-% NOTE per dati relativi al process capability bounding set, vedi:
-% http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3b7391de67da515c91f48aa371de77cb6cc5c07e
-
-% NOTE riferimenti ai vari cambiamenti vedi:
-% http://lwn.net/Articles/280279/
-% http://lwn.net/Articles/256519/
-% http://lwn.net/Articles/211883/
-
-
-Un elenco delle delle \textit{capabilities} disponibili su Linux, con una
-breve descrizione ed il nome delle costanti che le identificano, è riportato
-in tab.~\ref{tab:proc_capabilities};\footnote{l'elenco presentato questa
- tabella, ripreso dalla pagina di manuale (accessibile con \texttt{man
- capabilities}) e dalle definizioni in
- \texttt{include/linux/capabilities.h}, è aggiornato al kernel 3.2.} la
-tabella è divisa in due parti, la prima riporta le \textit{capabilities}
-previste anche nella bozza dello standard POSIX1.e, la seconda quelle
-specifiche di Linux. Come si può notare dalla tabella alcune
-\textit{capabilities} attengono a singole funzionalità e sono molto
-specializzate, mentre altre hanno un campo di applicazione molto vasto, che è
-opportuno dettagliare maggiormente.
-
-\begin{table}[!h!btp]
- \centering
- \footnotesize
- \begin{tabular}{|l|p{10cm}|}
- \hline
- \textbf{Capacità}&\textbf{Descrizione}\\
- \hline
- \hline
-%
-% POSIX-draft defined capabilities.
-%
- \constd{CAP\_AUDIT\_CONTROL}& Abilitare e disabilitare il
- controllo dell'auditing (dal kernel 2.6.11).\\
- \constd{CAP\_AUDIT\_WRITE}&Scrivere dati nel giornale di
- auditing del kernel (dal kernel 2.6.11).\\
- % TODO verificare questa roba dell'auditing
- \constd{CAP\_BLOCK\_SUSPEND}&Utilizzare funzionalità che possono bloccare
- la sospensione del sistema (dal kernel 3.5).\\
- \constd{CAP\_CHOWN} & Cambiare proprietario e gruppo
- proprietario di un file (vedi
- sez.~\ref{sec:file_ownership_management}).\\
- \constd{CAP\_DAC\_OVERRIDE}& Evitare il controllo dei
- permessi di lettura, scrittura ed esecuzione dei
- file, (vedi sez.~\ref{sec:file_access_control}).\\
- \constd{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} & 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}.\\
- \constd{CAP\_FSETID} & Evitare la cancellazione automatica dei bit
- \acr{suid} e \acr{sgid} quando un file
- per i quali sono impostati viene modificato da
- un processo senza questa capacità e la capacità
- di impostare il bit \acr{sgid} su un file anche
- quando questo è relativo ad un gruppo cui non si
- appartiene (vedi
- sez.~\ref{sec:file_perm_management}).\\
- \constd{CAP\_KILL} & Mandare segnali a qualunque
- processo (vedi sez.~\ref{sec:sig_kill_raise}).\\
- \constd{CAP\_SETFCAP} & Impostare le \textit{capabilities} di un file
- (dal kernel 2.6.24).\\
- \constd{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}).\\
- \constd{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
- domain} (vedi sez.~\ref{sec:unix_socket}).\\
-%
-% Linux specific capabilities
-%
-\hline
- \constd{CAP\_IPC\_LOCK} & Effettuare il \textit{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}). \\
-% TODO verificare l'interazione con SHM_HUGETLB
- \constd{CAP\_IPC\_OWNER}& Evitare il controllo dei permessi
- per le operazioni sugli oggetti di
- intercomunicazione fra processi (vedi
- sez.~\ref{sec:ipc_sysv}).\\
- \constd{CAP\_LEASE} & Creare dei \textit{file lease} (vedi
- sez.~\ref{sec:file_asyncronous_lease})
- pur non essendo proprietari del file (dal kernel
- 2.4).\\
- \constd{CAP\_LINUX\_IMMUTABLE}& Impostare sui file gli attributi
- \textit{immutable} e \textit{append-only} (vedi
- sez.~\ref{sec:file_perm_overview}) se
- supportati.\\
- \constd{CAP\_MAC\_ADMIN}& Amministrare il \textit{Mandatory
- Access Control} di \textit{Smack} (dal kernel
- 2.6.25).\\
- \constd{CAP\_MAC\_OVERRIDE}& Evitare il \textit{Mandatory
- Access Control} di \textit{Smack} (dal kernel
- 2.6.25).\\
- \constd{CAP\_MKNOD} & Creare file di dispositivo con \func{mknod} (vedi
- sez.~\ref{sec:file_mknod}) (dal kernel 2.4).\\
- \const{CAP\_NET\_ADMIN} & Eseguire alcune operazioni
- privilegiate sulla rete.\\
- \constd{CAP\_NET\_BIND\_SERVICE}& Porsi in ascolto su porte riservate (vedi
- sez.~\ref{sec:TCP_func_bind}).\\
- \constd{CAP\_NET\_BROADCAST}& Consentire l'uso di socket in
- \textit{broadcast} e \textit{multicast}.\\
- \constd{CAP\_NET\_RAW} & Usare socket \texttt{RAW} e \texttt{PACKET}
- (vedi sez.~\ref{sec:sock_type}).\\
- \const{CAP\_SETPCAP} & Effettuare modifiche privilegiate alle
- \textit{capabilities}.\\
- \const{CAP\_SYS\_ADMIN} & Eseguire una serie di compiti amministrativi.\\
- \constd{CAP\_SYS\_BOOT} & Eseguire un riavvio del sistema (vedi
- sez.~\ref{sec:sys_reboot}).\\
- \constd{CAP\_SYS\_CHROOT}& Eseguire la funzione \func{chroot} (vedi
- sez.~\ref{sec:file_chroot}).\\
- \constd{CAP\_SYS\_MODULE}& Caricare e rimuovere moduli del kernel.\\
- \const{CAP\_SYS\_NICE} & Modificare le varie priorità dei processi (vedi
- sez.~\ref{sec:proc_priority}).\\
- \constd{CAP\_SYS\_PACCT}& Usare le funzioni di \textit{accounting} dei
- processi (vedi
- sez.~\ref{sec:sys_bsd_accounting}).\\
- \constd{CAP\_SYS\_PTRACE}& La capacità di tracciare qualunque processo con
- \func{ptrace} (vedi
- sez.~\ref{sec:process_ptrace}).\\
- \constd{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}& Superare le varie limitazioni sulle risorse.\\
- \constd{CAP\_SYS\_TIME} & Modificare il tempo di sistema (vedi
- sez.~\ref{sec:sys_time}).\\
- \constd{CAP\_SYS\_TTY\_CONFIG}&Simulare un \textit{hangup} della console,
- con la funzione \func{vhangup}.\\
- \constd{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}.\\
- \constd{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).\\
- \hline
- \end{tabular}
- \caption{Le costanti che identificano le \textit{capabilities} presenti nel
- kernel.}
-\label{tab:proc_capabilities}
-\end{table}
-
-\constbeg{CAP\_SETPCAP}
-
-Prima di dettagliare il significato della capacità più generiche, conviene
-però dedicare un discorso a parte a \const{CAP\_SETPCAP}, il cui significato è
-stato completamente cambiato con l'introduzione delle \textit{file
- capabilities} nel kernel 2.6.24. In precedenza questa capacità era quella
-che permetteva al processo che la possedeva di impostare o rimuovere le
-\textit{capabilities} 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 \textit{file capabilities} e il cambiamento del significato
-del \textit{capabilities bounding set} la possibilità di modificare le
-capacità di altri processi è stata completamente rimossa, e
-\const{CAP\_SETPCAP} ha acquisito quello che avrebbe dovuto essere il suo
-significato originario, e cioè la capacità del processo di poter inserire nel
-suo \textit{inheritable set} qualunque capacità presente nel \textit{bounding
- set}. Oltre a questo la disponibilità di \const{CAP\_SETPCAP} consente ad un
-processo di eliminare una capacità dal proprio \textit{bounding set} (con la
-conseguente impossibilità successiva di eseguire programmi con quella
-capacità), o di impostare i \textit{securebits} delle \textit{capabilities}.
-
-\constend{CAP\_SETPCAP}
-\constbeg{CAP\_FOWNER}
-
-La prima fra le capacità ``\textsl{ampie}'' che occorre dettagliare
-maggiormente è \const{CAP\_FOWNER}, che rimuove le restrizioni poste ad un
-processo che non ha la proprietà di un file in un vasto campo di
-operazioni;\footnote{vale a dire la richiesta che l'\ids{UID} effettivo del
- processo (o meglio l'\ids{UID} di filesystem, vedi
- sez.~\ref{sec:proc_setuid}) coincida con quello del proprietario.} queste
-comprendono i cambiamenti dei permessi e dei tempi del file (vedi
-sez.~\ref{sec:file_perm_management} e sez.~\ref{sec:file_file_times}), le
-impostazioni degli attributi dei file e delle ACL (vedi
-sez.~\ref{sec:file_xattr} e \ref{sec:file_ACL}), poter ignorare lo
-\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
-sez.~\ref{sec:file_open_close} e sez.~\ref{sec:file_fcntl_ioctl}) senza
-restrizioni.
-
-\constend{CAP\_FOWNER}
-\constbeg{CAP\_NET\_ADMIN}
-
-Una seconda capacità che copre diverse operazioni, in questo caso riguardanti
-la rete, è \const{CAP\_NET\_ADMIN}, che consente di impostare le opzioni
-privilegiate dei socket (vedi sez.~\ref{sec:sock_generic_options}), abilitare
-il \textit{multicasting} (vedi sez.\ref{sec:sock_ipv4_options}), eseguire la
-configurazione delle interfacce di rete (vedi
-sez.~\ref{sec:sock_ioctl_netdevice}) ed impostare la tabella di instradamento.
-
-\constend{CAP\_NET\_ADMIN}
-\constbeg{CAP\_SYS\_ADMIN}
-
-Una terza \textit{capability} con vasto campo di applicazione è
-\const{CAP\_SYS\_ADMIN}, che copre una serie di operazioni amministrative,
-come impostare le quote disco (vedi sez.\ref{sec:disk_quota}), attivare e
-disattivare la swap, montare, rimontare e smontare filesystem (vedi
-sez.~\ref{sec:filesystem_mounting}), effettuare operazioni di controllo su
-qualunque oggetto dell'IPC di SysV (vedi sez.~\ref{sec:ipc_sysv}), operare
-sugli attributi estesi dei file di classe \texttt{security} o \texttt{trusted}
-(vedi sez.~\ref{sec:file_xattr}), specificare un \ids{UID} arbitrario nella
-trasmissione delle credenziali dei socket (vedi
-sez.~\ref{sec:socket_credential_xxx}), assegnare classi privilegiate
-(\const{IOPRIO\_CLASS\_RT} e prima del kernel 2.6.25 anche
-\const{IOPRIO\_CLASS\_IDLE}) per lo scheduling dell'I/O (vedi
-sez.~\ref{sec:io_priority}), superare il limite di sistema sul numero massimo
-di file aperti,\footnote{quello indicato da \sysctlfiled{fs/file-max}.}
-effettuare operazioni privilegiate sulle chiavi mantenute dal kernel (vedi
-sez.~\ref{sec:keyctl_management}), usare la funzione \func{lookup\_dcookie},
-usare \const{CLONE\_NEWNS} con \func{unshare} e \func{clone}, (vedi
-sez.~\ref{sec:process_clone}).
-
-\constend{CAP\_SYS\_ADMIN}
-\constbeg{CAP\_SYS\_NICE}
-
-Originariamente \const{CAP\_SYS\_NICE} riguardava soltanto la capacità di
-aumentare le priorità di esecuzione dei processi, come la diminuzione del
-valore di \textit{nice} (vedi sez.~\ref{sec:proc_sched_stand}), l'uso delle
-priorità \textit{real-time} (vedi sez.~\ref{sec:proc_real_time}), o
-l'impostazione delle affinità di processore (vedi
-sez.~\ref{sec:proc_sched_multiprocess}); ma con l'introduzione di priorità
-anche riguardo le operazioni di accesso al disco, e, nel caso di sistemi NUMA,
-alla memoria, essa viene a coprire anche la possibilità di assegnare priorità
-arbitrarie nell'accesso a disco (vedi sez.~\ref{sec:io_priority}) e nelle
-politiche di allocazione delle pagine di memoria ai nodi di un sistema NUMA.
-
-\constend{CAP\_SYS\_NICE}
-\constbeg{CAP\_SYS\_RESOURCE}
-
-Infine la \textit{capability} \const{CAP\_SYS\_RESOURCE} attiene alla
-possibilità di superare i limiti imposti sulle risorse di sistema, come usare
-lo spazio disco riservato all'amministratore sui filesystem che lo supportano,
-usare la funzione \func{ioctl} per controllare il \textit{journaling} sul
-filesystem \acr{ext3}, non subire le quote disco, aumentare i limiti sulle
-risorse di un processo (vedi sez.~\ref{sec:sys_resource_limit}) e quelle sul
-numero di processi, ed i limiti sulle dimensioni dei messaggi delle code del
-SysV IPC (vedi sez.~\ref{sec:ipc_sysv_mq}).
-
-\constend{CAP\_SYS\_RESOURCE}
-
-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 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}
-\fdecl{int capget(cap\_user\_header\_t hdrp, cap\_user\_data\_t datap)}
-\fdesc{Legge le \textit{capabilities}.}
-\fdecl{int capset(cap\_user\_header\_t hdrp, const cap\_user\_data\_t datap)}
-\fdesc{Imposta le \textit{capabilities}.}
-}
-
-{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
- caso \var{errno} assumerà uno dei valori:
- \begin{errlist}
- \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}
-}
-\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
-indicato che per poterle utilizzare fosse necessario che la macro
-\macro{\_POSIX\_SOURCE} risultasse non definita (ed era richiesto di inserire
-una istruzione \texttt{\#undef \_POSIX\_SOURCE} prima di includere
-\headfiled{sys/capability.h}) requisito che non risulta più
-presente.\footnote{e non è chiaro neanche quanto sia mai stato davvero
- necessario.}
-
-\begin{figure}[!htb]
- \footnotesize
- \centering
- \begin{minipage}[c]{0.8\textwidth}
- \includestruct{listati/cap_user_header_t.h}
- \end{minipage}
- \normalsize
- \caption{Definizione delle strutture a cui fanno riferimento i puntatori
- \structd{cap\_user\_header\_t} e \structd{cap\_user\_data\_t} usati per
- l'interfaccia di gestione di basso livello delle \textit{capabilities}.}
- \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 \ids{PID} del processo del quale si vogliono
-leggere o modificare le \textit{capabilities}. Con \func{capset} questo, se si
-usano le \textit{file capabilities}, può essere solo 0 o 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, 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
- tab.~\ref{tab:proc_capabilities} non possono essere combinati direttamente,
- indicando il numero progressivo del bit associato alla relativa capacità.}
-con l'introduzione delle \textit{capabilities} a 64 bit inoltre il
-puntatore \param{datap} non può essere più considerato come relativo ad una
-singola struttura, ma ad un vettore di due strutture.\footnote{è questo cambio
- di significato che ha portato a deprecare la versione 2, che con
- \func{capget} poteva portare ad un buffer overflow per vecchie applicazioni
- che continuavano a considerare \param{datap} come puntatore ad una singola
- struttura.}
-
-Dato che le precedenti funzioni, oltre ad essere specifiche di Linux, non
-garantiscono la stabilità nell'interfaccia, è sempre opportuno effettuare la
-gestione delle \textit{capabilities} utilizzando le funzioni di libreria a
-questo dedicate. Queste funzioni, che seguono quanto previsto nelle bozze
-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 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 tipo di dato opaco,
-\typed{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 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
-relativi dati. La funzione è \funcd{cap\_init} ed il suo prototipo è:
-
-\begin{funcproto}{
-\fhead{sys/capability.h}
-\fdecl{cap\_t cap\_init(void)}
-\fdesc{Crea ed inizializza un \textit{capability state}.}
-}
-
-{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 è:
-
-\begin{funcproto}{
-\fhead{sys/capability.h}
-\fdecl{int cap\_free(void *obj\_d)}
-\fdesc{Disalloca la memoria allocata per i dati delle \textit{capabilities}..}
-}
-
-{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 permette di liberare la memoria allocata dalle altre funzioni
-della libreria sia per un \textit{capability state}, nel qual caso l'argomento
-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 è:
-
-\begin{funcproto}{
-\fhead{sys/capability.h}
-\fdecl{cap\_t cap\_dup(cap\_t cap\_p)}
-\fdesc{Duplica un \textit{capability state} restituendone una copia.}
-}
-
-{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}
-
-
-La funzione crea una copia del \textit{capability state} posto all'indirizzo
-\param{cap\_p} che si è passato come argomento, restituendo il puntatore alla
-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, 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
- state}; la prima di queste è \funcd{cap\_clear}, il cui prototipo è:
-
-\begin{funcproto}{
-\fhead{sys/capability.h}
-\fdecl{int cap\_clear(cap\_t cap\_p)}
-\fdesc{Inizializza un \textit{capability state} cancellando tutte le
- \textit{capabilities}.}
-}
-
-{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 si limita ad azzerare tutte le \textit{capabilities} presenti nel
-\textit{capability state} all'indirizzo \param{cap\_p} passato come argomento,
-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 elencati a 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 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
- \headfile{sys/capability.h}.} uno dei valori illustrati in
-tab.~\ref{tab:cap_set_identifier}.
-
-\begin{table}[htb]
- \centering
- \footnotesize
- \begin{tabular}[c]{|l|l|}
- \hline
- \textbf{Valore} & \textbf{Significato} \\
- \hline
- \hline
- \constd{CAP\_EFFECTIVE} & Capacità dell'insieme \textsl{effettivo}.\\
- \constd{CAP\_PERMITTED} & Capacità dell'insieme \textsl{permesso}.\\
- \constd{CAP\_INHERITABLE}& Capacità dell'insieme \textsl{ereditabile}.\\
- \hline
- \end{tabular}
- \caption{Valori possibili per il tipo di dato \typed{cap\_flag\_t} che
- identifica gli insiemi delle \textit{capabilities}.}
- \label{tab:cap_set_identifier}
-\end{table}
-
-Si possono inoltre confrontare in maniera diretta due diversi
-\textit{capability state} con la funzione \funcd{cap\_compare}; il suo
-prototipo è:
-
-\begin{funcproto}{
-\fhead{sys/capability.h}
-\fdecl{int cap\_compare(cap\_t cap\_a, cap\_t cap\_b)}
-\fdesc{Confronta due \textit{capability state}.}
-}
-
-{La funzione ritorna $0$ se i \textit{capability state} sono identici
- ed un valore positivo se differiscono, non sono previsti errori.}
-\end{funcproto}
-
-
-La funzione esegue un confronto fra i due \textit{capability state} passati
-come argomenti e ritorna in un valore intero il risultato, questo è nullo se
-sono identici o positivo se vi sono delle differenze. Il valore di ritorno
-della funzione consente inoltre di per ottenere ulteriori informazioni su
-quali sono gli insiemi di \textit{capabilities} che risultano differenti. Per
-questo si può infatti usare la apposita macro \macro{CAP\_DIFFERS}:
-
-{\centering
-\vspace{3pt}
-\begin{funcbox}{
-\fhead{sys/capability.h}
-\fdecl{int \macrod{CAP\_DIFFERS}(value, flag)}
-\fdesc{Controlla lo stato di eventuali differenze delle \textit{capabilities}
- nell'insieme \texttt{flag}.}
-}
-\end{funcbox}
-}
-
-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
-\func{cap\_compare} sono presenti nell'insieme indicato.
-
-Per la gestione dei singoli valori delle \textit{capabilities} presenti in un
-\textit{capability state} l'interfaccia prevede due funzioni specifiche,
-\funcd{cap\_get\_flag} e \funcd{cap\_set\_flag}, che permettono
-rispettivamente di leggere o impostare il valore di una capacità all'interno
-in uno dei tre insiemi già citati; i rispettivi prototipi sono:
-
-\begin{funcproto}{
-\fhead{sys/capability.h}
-\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, \\
-\phantom{int cap\_set\_flag(}cap\_flag\_value\_t value)}
-\fdesc{Imposta il valore di una \textit{capability}.}
-}
-
-{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}
-
-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
-\typed{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}.}
-
-Infine lo stato di una capacità è descritto ad una variabile di tipo
-\type{cap\_flag\_value\_t}, che a sua volta può assumere soltanto
-uno\footnote{anche questo è un tipo enumerato.} dei valori di
-tab.~\ref{tab:cap_value_type}.
-
-\begin{table}[htb]
- \centering
- \footnotesize
- \begin{tabular}[c]{|l|l|}
- \hline
- \textbf{Valore} & \textbf{Significato} \\
- \hline
- \hline
- \constd{CAP\_CLEAR}& La capacità non è impostata.\\
- \constd{CAP\_SET} & La capacità è impostata.\\
- \hline
- \end{tabular}
- \caption{Valori possibili per il tipo di dato \typed{cap\_flag\_value\_t} che
- indica lo stato di una capacità.}
- \label{tab:cap_value_type}
-\end{table}
-
-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 come \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
-lo stato di una capacità alla volta.
-
-La funzione \func{cap\_set\_flag} può invece impostare in una sola chiamata
-più \textit{capabilities}, anche se solo all'interno dello stesso insieme ed
-allo stesso valore. Per questo motivo essa prende un vettore di valori di tipo
-\type{cap\_value\_t} nell'argomento \param{caps}, la cui dimensione viene
-specificata dall'argomento \param{ncap}. Il tipo di impostazione da eseguire
-(cancellazione o 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}.
-
-Per semplificare la gestione delle \textit{capabilities} l'interfaccia prevede
-che sia possibile utilizzare anche una rappresentazione testuale del contenuto
-di un \textit{capability state} e fornisce le opportune funzioni di
-gestione;\footnote{entrambe erano previste dalla bozza dello standard
- POSIX.1e.} la prima di queste, che consente di ottenere la rappresentazione
-testuale, è \funcd{cap\_to\_text}, il cui prototipo è:
-
-\begin{funcproto}{
-\fhead{sys/capability.h}
-\fdecl{char *cap\_to\_text(cap\_t caps, ssize\_t *length\_p)}
-\fdesc{Genera una visualizzazione testuale delle \textit{capabilities}.}
-}
-
-{La funzione ritorna un puntatore alla stringa con la descrizione delle
- \textit{capabilities} 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}
-
-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 come \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 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
-rappresentazione si fa sempre conto di partire da uno stato in cui tutti gli
-insiemi sono vuoti e si provvede a impostarne i contenuti.
-
-Ciascuna proposizione è nella forma di un elenco di capacità, espresso con i
-nomi di tab.~\ref{tab:proc_capabilities} separati da virgole, seguito da un
-operatore, e dall'indicazione degli insiemi a cui l'operazione si applica. I
-nomi delle capacità possono essere scritti sia maiuscoli che minuscoli, viene
-inoltre riconosciuto il nome speciale \texttt{all} che è equivalente a
-scrivere la lista completa. Gli insiemi sono identificati dalle tre lettere
-iniziali: ``\texttt{p}'' per il \textit{permitted}, ``\texttt{i}'' per
-l'\textit{inheritable} ed ``\texttt{e}'' per l'\textit{effective} che devono
-essere sempre minuscole, e se ne può indicare più di uno.
-
-Gli operatori possibili sono solo tre: ``\texttt{+}'' che aggiunge le capacità
-elencate agli insiemi indicati, ``\texttt{-}'' che le toglie e ``\texttt{=}''
-che le assegna esattamente. I primi due richiedono che sia sempre indicato sia
-un elenco di capacità che gli insiemi a cui esse devono applicarsi, e
-rispettivamente attiveranno o disattiveranno le capacità elencate nell'insieme
-o negli insiemi specificati, ignorando tutto il resto. I due operatori possono
-anche essere combinati nella stessa proposizione, per aggiungere e togliere le
-capacità dell'elenco da insiemi diversi.
-
-L'assegnazione si applica invece su tutti gli insiemi allo stesso tempo,
-pertanto l'uso di ``\texttt{=}'' è equivalente alla cancellazione preventiva
-di tutte le capacità ed alla impostazione di quelle elencate negli insiemi
-specificati, questo significa che in genere lo si usa una sola volta
-all'inizio della stringa. In tal caso l'elenco delle capacità può non essere
-indicato e viene assunto che si stia facendo riferimento a tutte quante senza
-doverlo scrivere esplicitamente.
-
-Come esempi avremo allora che un processo non privilegiato di un utente, che
-non ha nessuna capacità attiva, avrà una rappresentazione nella forma
-``\texttt{=}'' che corrisponde al fatto che nessuna capacità viene assegnata a
-nessun insieme (vale la cancellazione preventiva), mentre un processo con
-privilegi di amministratore avrà una rappresentazione nella forma
-``\texttt{=ep}'' in cui tutte le capacità vengono assegnate agli insiemi
-\textit{permitted} ed \textit{effective} (e l'\textit{inheritable} è ignorato
-in quanto per le regole viste a pag.~\ref{sec:capability-uid-transition} le
-capacità verranno comunque attivate attraverso una \func{exec}). Infine, come
-esempio meno banale dei precedenti, otterremo per \texttt{init} una
-rappresentazione nella forma ``\texttt{=ep cap\_setpcap-e}'' dato che come
-accennato tradizionalmente \const{CAP\_SETPCAP} è sempre stata rimossa da
-detto processo.
-
-Viceversa per 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}
-\fdecl{cap\_t cap\_from\_text(const char *string)}
-\fdesc{Crea un \textit{capability state} dalla sua rappresentazione testuale.}
-}
-
-{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}
-
-
-La funzione restituisce il puntatore ad un \textit{capability state}
-inizializzato con i valori indicati nella stringa \param{string} che ne
-contiene la rappresentazione testuale. La memoria per il \textit{capability
- state} viene allocata automaticamente dalla funzione e dovrà essere liberata
-con \func{cap\_free}.
-
-Alle due funzioni citate se ne aggiungono altre due che consentono di
-convertire i valori delle costanti di tab.~\ref{tab:proc_capabilities} nelle
-stringhe usate nelle rispettive rappresentazioni e viceversa. Le due funzioni,
-\funcd{cap\_to\_name} e \funcd{cap\_from\_name}, sono estensioni specifiche di
-Linux ed i rispettivi prototipi sono:
-
-\begin{funcproto}{
-\fhead{sys/capability.h}
-\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{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$ 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}, come \textit{value result argument}, il valore della
-capacità rappresentata dalla stringa \param{name}.
-
-Fin quei abbiamo trattato solo le funzioni di servizio relative alla
-manipolazione dei \textit{capability state} come strutture di dati;
-l'interfaccia di gestione prevede però anche le funzioni per trattare le
-\textit{capabilities} presenti nei processi. La prima di queste funzioni è
-\funcd{cap\_get\_proc} che consente la lettura delle \textit{capabilities} del
-processo corrente, il suo prototipo è:
-
-\begin{funcproto}{
-\fhead{sys/capability.h}
-\fdecl{cap\_t cap\_get\_proc(void)}
-\fdesc{Legge le \textit{capabilities} del processo corrente.}
-}
-
-{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.}
-\end{funcproto}
-
-La funzione legge il valore delle \textit{capabilities} associate al processo
-da cui viene invocata, restituendo il risultato tramite il puntatore ad un
-\textit{capability state} contenente tutti i dati che provvede ad allocare
-autonomamente e che di nuovo occorrerà liberare con \func{cap\_free} quando
-non sarà più utilizzato.
-
-Se invece si vogliono leggere le \textit{capabilities} di un processo
-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
- dichiarazione della stessa in \headfile{sys/capability.h}.} è:
-
-\begin{funcproto}{
-\fhead{sys/capability.h}
-\fdecl{cap\_t cap\_get\_pid(pid\_t pid)}
-\fdesc{Legge le \textit{capabilities} di un processo.}
-}
-
-{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. }
-\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 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
-\texttt{init} si otterrà qualcosa del tipo:
-\begin{Console}
-piccardi@hain:~/gapil$ \textbf{cat /proc/1/status}
-...
-CapInh: 0000000000000000
-CapPrm: 00000000fffffeff
-CapEff: 00000000fffffeff
-...
-\end{Console}
-%$
-
-\itindend{capability~state}
-
-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}
-\fdecl{int cap\_set\_proc(cap\_t cap\_p)}
-\fdesc{Imposta le \textit{capabilities} del processo corrente.}
-}
-
-{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
- 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).
-
-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
-\textit{capabilities} del processo corrente\footnote{vale a dire di sé stesso,
- 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 \ids{PID} viene passato come parametro dell'opzione.
-
-\begin{figure}[!htbp]
- \footnotesize \centering
- \begin{minipage}[c]{\codesamplewidth}
- \includecodesample{listati/getcap.c}
- \end{minipage}
- \normalsize
- \caption{Corpo principale del programma \texttt{getcap.c}.}
- \label{fig:proc_getcap}
-\end{figure}
-
-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 \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
- 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.
-
-\itindend{capabilities}
-
-% TODO vedi http://lwn.net/Articles/198557/ e
-% http://www.madore.org/~david/linux/newcaps/
-
-
-
\subsection{La gestione dei {chroot}}
\label{sec:file_chroot}
% 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 mygetfacl
+% LocalWords: faccessat grpid lacl AppArmor capsetp mygetfacl table Tb MSK
+% LocalWords: LAZYTIME submount peer protected hardlink symlinks silly
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "gapil"
%%% End:
+% LocalWords: renames
projects / gapil.git / blobdiff