%% filedir.tex
%%
-%% Copyright (C) 2000-2011 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2012 Simone Piccardi. Permission is granted to
%% copy, distribute and/or modify this document under the terms of the GNU Free
%% Documentation License, Version 1.1 or any later version published by the
%% Free Software Foundation; with the Invariant Sections being "Un preambolo",
partizioni. In essa per semplicità si è fatto riferimento alla struttura del
filesystem \acr{ext2}, che prevede una suddivisione dei dati in \textit{block
group}. All'interno di ciascun \textit{block group} viene anzitutto
-replicato il cosiddetto \textit{superblock}, (la struttura che contiene
-l'indice iniziale del filesystem e che consente di accedere a tutti i dati
-sottostanti) e creata una opportuna suddivisione dei dati e delle informazioni
-per accedere agli stessi. Sulle caratteristiche di \acr{ext2} e derivati
-torneremo in sez.~\ref{sec:file_ext2}.
+replicato il cosiddetto \itindex{superblock} \textit{superblock}, (la
+struttura che contiene l'indice iniziale del filesystem e che consente di
+accedere a tutti i dati sottostanti) e creata una opportuna suddivisione dei
+dati e delle informazioni per accedere agli stessi. Sulle caratteristiche di
+\acr{ext2} e derivati torneremo in sez.~\ref{sec:file_ext2}.
\itindbeg{inode}
Se si va ad esaminare con maggiore dettaglio la strutturazione
dell'informazione all'interno del filesystem \textsl{ext2}, tralasciando i
dettagli relativi al funzionamento del filesystem stesso come la
-strutturazione in gruppi dei blocchi, il \textit{superblock} e tutti i dati di
-gestione possiamo esemplificare la situazione con uno schema come quello
-esposto in fig.~\ref{fig:file_filesys_detail}.
+strutturazione in gruppi dei blocchi, il \itindex{superblock}
+\textit{superblock} e tutti i dati di gestione possiamo esemplificare la
+situazione con uno schema come quello esposto in
+fig.~\ref{fig:file_filesys_detail}.
\begin{figure}[!htb]
\centering
gruppo primario del processo, eccetto il caso in cui la directory ha il bit
di \acr{sgid} impostato (per una descrizione dettagliata del significato di
questi termini si veda sez.~\ref{sec:file_access_control}), nel qual caso
- file e subdirectory ereditano sia il \acr{gid} che lo \acr{sgid}.
+ file e subdirectory ereditano sia il \ids{GID} che lo \acr{sgid}.
\item l'amministratore può scegliere la dimensione dei blocchi del filesystem
in fase di creazione, a seconda delle sue esigenze: blocchi più grandi
permettono un accesso più veloce, ma sprecano più spazio disco.
in gruppi di blocchi.
Ciascun gruppo di blocchi contiene una copia delle informazioni essenziali del
-filesystem (i \textit{superblock} sono quindi ridondati) per una maggiore
-affidabilità e possibilità di recupero in caso di corruzione del
-\textit{superblock} principale. L'utilizzo di raggruppamenti di blocchi ha
-inoltre degli effetti positivi nelle prestazioni dato che viene ridotta la
-distanza fra i dati e la tabella degli \itindex{inode} inode.
+filesystem (i \itindex{superblock} \textit{superblock} sono quindi ridondati)
+per una maggiore affidabilità e possibilità di recupero in caso di corruzione
+del \itindex{superblock} \textit{superblock} principale. L'utilizzo di
+raggruppamenti di blocchi ha inoltre degli effetti positivi nelle prestazioni
+dato che viene ridotta la distanza fra i dati e la tabella degli
+\itindex{inode} inode.
\begin{figure}[!htb]
\centering
o non può essere montato su \param{target} perché la directory è ancora in
uso.
\item[\errcode{EINVAL}] il dispositivo \param{source} presenta un
- \textit{superblock} non valido, o si è cercato di rimontare un filesystem
- non ancora montato, o di montarlo senza che \param{target} sia un
- \itindex{mount~point} \textit{mount point} o di spostarlo
- quando \param{target} non è un \itindex{mount~point} \textit{mount point}
- o è la radice.
- \item[\errcode{EMFILE}] la tabella dei device \textit{dummy} è piena.
+ \itindex{superblock} \textit{superblock} non valido, o si è cercato di
+ rimontare un filesystem non ancora montato, o di montarlo senza
+ che \param{target} sia un \itindex{mount~point} \textit{mount point} o di
+ spostarlo quando \param{target} non è un \itindex{mount~point}
+ \textit{mount point} o è la radice.
+ \item[\errcode{ELOOP}] si è cercato di spostare un \itindex{mount~point}
+ \textit{mount point} su una sottodirectory di \param{source} o si sono
+ incontrati troppi link simolici nella risoluzione di un nome.
+ \item[\errcode{EMFILE}] in caso di filesystem virtuale, la tabella dei
+ dispositivi fittizi (chiamati \textit{dummy} nella documentazione inglese)
+ è piena.
\item[\errcode{ENODEV}] il tipo \param{filesystemtype} non esiste o non è
configurato nel kernel.
\item[\errcode{ENOTBLK}] non si è usato un \textit{block device} per
dispositivo \param{source} è sbagliato.
\item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
\end{errlist}
- ed inoltre \errval{EFAULT}, \errval{ELOOP}, \errval{ENOMEM},
- \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOTDIR} nel loro
- significato generico.}
+ ed inoltre \errval{EFAULT}, \errval{ENOMEM}, \errval{ENAMETOOLONG},
+ \errval{ENOENT}, \errval{ENOTDIR} nel loro significato generico.}
\end{funcproto}
-La funzione monta sulla directory indicata \param{target}, detta
+La funzione monta sulla directory indicata da \param{target}, detta
\itindex{mount~point} \textit{mount point}, il filesystem contenuto nel file
-di dispositivo indicato \param{source}. In entrambi i casi, come daremo per
+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 \itindex{pathname}
\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
- File System} è estremamente flessibile e può essere usata anche per oggetti
-diversi da un disco. Ad esempio usando il \textit{loop device} si può montare
-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.}
+illustrato in sez.~\ref{sec:file_vfs_work} la struttura del
+\itindex{Virtual~File~System} \textit{Virtual File System} è estremamente
+flessibile e può essere usata anche per oggetti diversi da un disco. Ad
+esempio usando il \textit{loop device} si può montare 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.}
Il tipo di filesystem che si vuole montare è specificato
dall'argomento \param{filesystemtype}, che deve essere una delle stringhe
L'argomento \param{data} viene usato per passare le impostazioni relative alle
caratteristiche specifiche di ciascun filesystem. Si tratta di una stringa di
parole chiave (separate da virgole e senza spazi) che indicano le cosiddette
-opzioni del filesystem che devono essere impostate, in sostanza viene usato il
-contenuto del parametro dell'opzione \texttt{-o} del comando \texttt{mount}. I
-valori utilizzabili dipendono dal tipo di filesystem e ciascuno ha i suoi,
-pertanto si rimanda alla documentazione della pagina di manuale di questo
-comando.
+``\textsl{opzioni}'' del filesystem che devono essere impostate; in genere
+viene usato direttamente il contenuto del parametro dell'opzione \texttt{-o}
+del comando \texttt{mount}. I valori utilizzabili dipendono dal tipo di
+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 \itindex{mount~point}
\textit{mount point}, il precedente contenuto di detta directory viene
-mascherato dal contenuto della directory radice del filesystem montato.
-
-Dal kernel 2.4.x inoltre è divenuto possibile sia spostare atomicamente un
-\itindex{mount~point} \textit{mount point} da una directory ad un'altra, sia
-montare in diversi \itindex{mount~point} \textit{mount point} lo stesso
-filesystem, sia montare più filesystem sullo stesso \itindex{mount~point}
-\textit{mount point}, nel qual caso vale quanto appena detto, e solo il
+mascherato dal contenuto della directory radice del filesystem montato. Fino
+ai kernel della serie 2.2.x non era possibile montare un filesytem se un
+\textit{mount point} era già in uso.
+
+A partire dal kernel 2.4.x inoltre è divenuto possibile sia spostare
+atomicamente un \itindex{mount~point} \textit{mount point} da una directory ad
+un'altra, sia montare lo stesso filesystem in diversi \itindex{mount~point}
+\textit{mount point}, sia montare più filesystem sullo stesso
+\itindex{mount~point} \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.
-Ciascun filesystem è dotato di caratteristiche specifiche che possono essere
-attivate o meno, alcune di queste sono generali (anche se non è detto siano
-disponibili in ogni filesystem), e vengono specificate come opzioni di
-montaggio con l'argomento \param{mountflags}.
+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, 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
+ \itindex{magic~number} \textit{magic number} \code{0xC0ED}, si può usare la
+ costante \const{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 \const{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 devono essere impostati con un OR aritmetico dei rispettivi flag,
+identificati dalle costanti riportate nell'elenco seguente:
+
+\begin{basedescript}{\desclabelwidth{2.cm}\desclabelstyle{\nextlinelabel}}
+\itindbeg{bind~mount}
+\item[\const{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 \index{pathname}
+ \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 \itindex{Virtual~File~System} VFS l'operazione è
+ analoga al montaggio di un filesystem proprio nel fatto che anche in questo
+ caso si inserisce in corripondenza 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 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:file_link}) ottenendo un qualcosa di analogo in cui si può
+ 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 link simbolici (di cui parleremo in
+ sez.~\ref{sec:file_symlink}) che funziona correttamente anche all'intero di
+ un \textit{chroot} (argomento su cui torneremo in
+ sez.~\ref{sec:file_chroot}.
+\itindend{bind~mount}
+
+\item[\const{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
+ con il comando \cmd{lsattr}.\footnote{questo avviene tramite delle opportune
+ \texttt{ioctl} (vedi sez.~\ref{sec:file_ioctl}).}
+
+ Questo consente di ridurre al minimo il rischio di perdita dei dati delle
+ directory in caso di crollo improvviso del sistema, al costo di una certa
+ perdita di prestazioni dato che le funzioni di scrittura relative ad
+ operazioni sulle directory non saranno più bufferizzate e si bloccheranno
+ fino all'arrivo dei dati sul disco prima che un programma possa proseguire.
+
+\item[\const{MS\_MANDLOCK}] Consente l'uso del \textit{mandatory locking}
+ \itindex{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[\const{MS\_MOVE}] Effettua uno del spostamento del \itindex{mount~point}
+ \textit{mount point} di un filesystem. La directory del
+ \itindex{mount~point} \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à immediatamante 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[\const{MS\_NOATIME}] Viene disabilitato sul filesystem l'aggiornamento
+ degli \textit{access time} (vedi sez.~\ref{sec:file_file_times}) per
+ qualunque tipo di file. Dato che l'aggiornamento degli \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.
+
+\item[\const{MS\_NODEV}] Viene disabilitato sul filesystem l'accesso ai file
+ di dispositivo eventualmente presenti su di esso. L'opzione viene usata come
+ misura di precauzione per rendere inutile la presenza di eventuali file di
+ dispositivo su filesystem che non dovrebbero contenerne.\footnote{si ricordi
+ che le convenzioni del \itindex{Filesystem~Hierarchy~Standard~(FHS)}
+ \textit{Linux Filesystem Hierarchy Standard} richiedono che questi siano
+ mantenuti esclusivamente sotto \texttt{/dev}.}
+
+ Viene utilizzata, assieme a \const{MS\_NOEXEC} e \const{MS\_NOSUID}, per
+ fornire un accesso più controllato a quei filesystem di cui gli utenti hanno
+ il controllo dei contenuti, in particolar modo quelli posti su dispositivi
+ rimuovibili. In questo modo si evitano alla radice possibili situazioni in
+ cui un utente malizioso inserisce su uno di questi filesystem dei file di
+ dispositivo con permessi ``opportunamente'' ampliati che gli consentano di
+ accedere anche a risorse cui non dovrebbe.
+
+\item[\const{MS\_NODIRATIME}] Viene disabilitato sul filesystem
+ l'aggiornamento degli \textit{access time} (vedi
+ sez.~\ref{sec:file_file_times}), ma soltanto per le directory. Costituisce
+ una alternativa per \const{MS\_NOATIME}, che elimina l'informazione per le
+ directory, che in pratica che non viene mai utilizzata, mantenendola per i
+ file in cui invece ha un impiego, sia pur limitato.
+
+\item[\const{MS\_NOEXEC}] Viene disabilitata sul filesystem l'esecuzione di un
+ qualunque file eseguibile eventualmente presente su di esso. L'opzione viene
+ usata come misura di precauzione per rendere impossibile l'uso di programmi
+ posti su filesystem che non dovrebbero contenerne.
+
+ Anche in questo caso viene utilizzata per fornire un accesso più controllato
+ a quei filesystem di cui gli utenti hanno il controllo dei contenuti. Da
+ questo punto di vista l'opzione è meno importante delle analoghe
+ \const{MS\_NODEV} e \const{MS\_NOSUID} in quanto l'esecuzione di un
+ programma creato dall'utente pone un livello di rischio nettamente
+ inferiore, ed è in genere consentita per i file contenuti nella sua home
+ directory.\footnote{cosa che renderebbe superfluo l'attivazione di questa
+ opzione, il cui uso ha senso solo per ambienti molto controllati in cui si
+ vuole che gli utenti eseguano solo i programmi forniti
+ dall'amministratore.}
+
+\item[\const{MS\_NOSUID}] Viene disabilitato sul filesystem l'effetto dei bit
+ dei permessi \itindex{suid~bit} \acr{suid} e \itindex{sgid~bit} \acr{sgid}
+ (vedi sez.~\ref{sec:file_special_perm}) eventualmente presenti sui file in
+ esso contenuti. L'opzione viene usata come misura di precauzione per rendere
+ inefficace l'effetto di questi bit per filesystem in cui non ci dovrebbero
+ essere file dotati di questi permessi.
+
+ Di nuovo viene utilizzata, analogamente a \const{MS\_NOEXEC} e
+ \const{MS\_NODEV}, per fornire un accesso più controllato a quei filesystem
+ di cui gli utenti hanno il controllo dei contenuti. In questo caso si evita
+ che un utente malizioso possa inserire su uno di questi filesystem un
+ eseguibile con il bit \itindex{suid~bit} \acr{suid} attivo e di proprietà
+ dell'amministratore o di un altro utente, che gli consentirebbe di eseguirlo
+ per conto di quest'ultimo.
+
+\item[\const{MS\_PRIVATE}] Marca un \itindex{mount~point} \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 \itindex{shared~subtree} \textit{shared
+ subtree} introdotta a partire dal kernel 2.6.15, che estendono le
+ funzionalità dei \itindex{bind~mount} \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 \itindex{shared~subtree} \textit{shared subtree}, ogni
+ \textit{mount point} è privato. Ogni \textit{bind mount} ottenuto da un
+ \itindex{mount~point} \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[\const{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à.
+
+\item[\const{MS\_REC}] Applica ricorsivamente a tutti i \itindex{mount~point}
+ \textit{mount point} presenti al di sotto del \textit{mount point} indicato
+ gli effetti della opzione degli \itindex{shared~subtree} \textit{shared
+ subtree} associata. Anche questo caso l'argomento \param{target} deve fare
+ riferimento ad un \itindex{mount~point} \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}.
+
+\item[\const{MS\_RELATIME}] Indica di effettuare l'aggiornamento degli
+ \textit{access time} sul filesystem soltanto quando questo risulti
+ antecendente il valore corrente del \textit{modification time} o del
+ \textit{change time} (per i tempi dei file si veda
+ sez.~\ref{sec:file_file_times}). L'opzione è disponibile a partire dal
+ kernel 2.6.20, mentre dal 2.6.30 questo è diventato il comportamento di
+ default del sistema, che può essere riportato a quello tradizionale con
+ l'uso di \const{MS\_STRICTATIME}. Sempre dal 2.6.30 il comportamento è stato
+ anche modificato e l'\textit{access time} viene comunque aggiornato se è più
+ vecchio di un giorno.
+
+ L'opzione consente di evitare i problemi di prestazioni relativi
+ all'aggiornamento dell'\textit{access time} senza avere impatti negativi
+ riguardo le funzionalità, il comportamento adottato infatti consente di
+ rendere evidente che vi è stato un accesso dopo la scrittura, ed evitando al
+ contempo ulteriori operazioni su disco negli accessi successivi. In questo
+ modo l'informazione relativa al fatto che un file sia stato letto resta
+ disponibile, ed i programmi che ne fanno uso continuano a funzionare. Con
+ l'introduzione di questo comportamento l'uso delle alternative
+ \const{MS\_NOATIME} e \const{MS\_NODIRATIME} è sostanzialmente inutile.
+
+\item[\const{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 \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}.
+
+\item[\const{MS\_SHARED}] Marca un \itindex{mount~point} \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 degli \itindex{shared~subtree} \textit{shared
+ subtree} introdotta a partire dal kernel 2.6.15, che estendono le
+ funzionalità dei \itindex{bind~mount} \textit{bind mount}. In questo caso
+ \param{target} dovrà fare riferimento al \itindex{mount~point} \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 cioè vengono ``\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.
+
+\item[\const{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[\const{MS\_SLAVE}] Marca un \itindex{mount~point} \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 \itindex{shared~subtree} \textit{shared
+ subtree} introdotta a partire dal kernel 2.6.15, che estendono le
+ funzionalità dei \itindex{bind~mount} \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 \itindex{mount~point} \textit{mount point}
+ originale.
+
+\item[\const{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
+ comportamento di default del kernel è diventato quello fornito da
+ \const{MS\_RELATIME}.
+
+\item[\const{MS\_SYNCHRONOUS}] Abilita la scrittura sincrona richiedendo che
+ ogni modifica al contenuto del filesystem venga immediatamente registrata su
+ disco. Lo stesso comportamento può essere ottenuto con il flag
+ \const{O\_SYNC} di \func{open} (vedi sez.~\ref{sec:file_open}).
+
+ Questa opzione consente di ridurre al minimo il rischio di perdita dei dati
+ in caso di crollo improvviso del sistema, al costo di una pesante perdita di
+ prestazioni dato che tutte le funzioni di scrittura non saranno più
+ bufferizzate e si bloccheranno fino all'arrivo dei dati sul disco. Per un
+ compromesso in cui questo comportamento avviene solo per le directory, ed ha
+ quindi una incidenza nettamente minore, si può usare \const{MS\_DIRSYNC}.
+
+\item[\const{MS\_UNBINDABLE}] Marca un \itindex{mount~point} \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
+ \itindex{shared~subtree} \textit{shared subtree} introdotta a partire dal
+ kernel 2.6.15, che estendono le funzionalità dei \itindex{bind~mount}
+ \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 disabilità la capacità di
+ eseguire dei \itindex{bind~mount} \textit{bind mount}. Si comporta cioè come
+ allo stesso modo di un \itindex{mount~point} \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 \itindex{bind~mount} \textit{bind
+ mount}.
-In Linux \param{mountflags} deve essere un intero a 32 bit i cui 16 più
-significativi sono un \itindex{magic~number} \textit{magic
- number}\footnote{che nel caso è \code{0xC0ED}, si può usare la costante
- \const{MS\_MGC\_MSK} per ottenere la parte di \param{mountflags} riservata
- al \textit{magic number}.} mentre i 16 meno significativi sono usati per
-specificare le opzioni; essi sono usati come maschera binaria e vanno
-impostati con un OR aritmetico della costante \const{MS\_MGC\_VAL} con i
-valori riportati in tab.~\ref{tab:sys_mount_flags}.
+\end{basedescript}
-\begin{table}[htb]
- \footnotesize
- \centering
- \begin{tabular}[c]{|l|p{8cm}|}
- \hline
- \textbf{Parametro} & \textbf{Significato}\\
- \hline
- \hline
- \const{MS\_BIND} & Monta il filesystem altrove.\\
- \const{MS\_DIRSYNC} & .\\
- \const{MS\_MANDLOCK} & Consente il \textit{mandatory locking}
- \itindex{mandatory~locking} (vedi
- sez.~\ref{sec:file_mand_locking}).\\
- \const{MS\_MOVE} & Sposta atomicamente il punto di montaggio.\\
- \const{MS\_NOATIME} & Non aggiorna gli \textit{access time} (vedi
- sez.~\ref{sec:file_file_times}).\\
- \const{MS\_NODEV} & Impedisce l'accesso ai file di dispositivo.\\
- \const{MS\_NODIRATIME} & Non aggiorna gli \textit{access time} delle
- directory.\\
- \const{MS\_NOEXEC} & Impedisce di eseguire programmi.\\
- \const{MS\_NOSUID} & Ignora i bit \itindex{suid~bit} \acr{suid} e
- \itindex{sgid~bit} \acr{sgid}.\\
- \const{MS\_RDONLY} & Monta in sola lettura.\\
- \const{MS\_RELATIME} & .\\
- \const{MS\_REMOUNT} & Rimonta il filesystem cambiando le opzioni.\\
- \const{MS\_SILENT} & .\\
- \const{MS\_STRICTATIME}& .\\
- \const{MS\_SYNCHRONOUS}& Abilita la scrittura sincrona.\\
- % \const{S\_WRITE} & Scrive normalmente.\\
- % \const{S\_APPEND} & Consente la scrittura solo in
- % \itindex{append~mode} \textit{append mode}
- % (vedi sez.~\ref{sec:file_sharing}).\\
- % \const{S\_IMMUTABLE} & Impedisce che si possano modificare i file.\\
- \hline
- \end{tabular}
- \caption{Tabella dei codici dei flag di montaggio di un filesystem.}
- \label{tab:sys_mount_flags}
-\end{table}
+% 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
+% * Documentation/filesystems/sharedsubtree.txt
-% TODO aggiornare con i nuovi flag di man mount
-% verificare i readonly mount bind del 2.6.26
+% TODO: (bassa priorità) non documentati ma presenti in sys/mount.h:
+% * MS_POSIXACL
+% * MS_KERNMOUNT
+% * MS_I_VERSION
+% * MS_ACTIVE
+% * MS_NOUSER
-La funzione \func{mount} può essere utilizzata anche per effettuare il
-\textsl{rimontaggio} di un filesystem, cosa che permette di cambiarne al volo
-alcune delle caratteristiche di funzionamento (ad esempio passare da sola
-lettura a lettura/scrittura). Questa operazione è attivata attraverso uno dei
-bit di \param{mountflags}, \const{MS\_REMOUNT}, che se impostato specifica che
-deve essere effettuato il rimontaggio del filesystem (con le opzioni
-specificate dagli altri bit), anche in questo caso il valore di \param{source}
-viene ignorato.
Una volta che non si voglia più utilizzare un certo filesystem è possibile
\textsl{smontarlo} usando la funzione \funcd{umount}, il cui prototipo è:
nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
- \item[\errcode{EBUSY}] \param{target} è la directory di lavoro di qualche
- processo, o contiene dei file aperti, o un altro mount point.
+ \item[\errcode{EBUSY}] \param{target} è la \index{directory~di~lavoro}
+ directory di lavoro di qualche processo, o contiene dei file aperti, o un
+ altro mount point.
\end{errlist}ed inoltre \errval{ENOTDIR}, \errval{EFAULT}, \errval{ENOMEM},
\errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ELOOP} nel loro
significato generico.}
non il file o il dispositivo che è stato montato,\footnote{questo è vero a
partire dal kernel 2.3.99-pre7, prima esistevano due chiamate separate e la
funzione poteva essere usata anche specificando il file di dispositivo.} in
-quanto con il kernel 2.4.x è possibile montare lo stesso dispositivo in più
-punti. Nel caso più di un filesystem sia stato montato sullo stesso
-\itindex{mount~point} \textit{mount point} viene smontato quello che è stato
-montato per ultimo.
+quanto a partire dai kernel della serie 2.4.x è possibile montare lo stesso
+dispositivo in più punti. Nel caso più di un filesystem sia stato montato
+sullo stesso \itindex{mount~point} \textit{mount point} viene smontato quello
+che è stato montato per ultimo.
Si tenga presente che la funzione fallisce quando il filesystem è
-\textsl{occupato}, questo avviene quando ci sono ancora file aperti sul
-filesystem, se questo contiene la directory di lavoro corrente di un qualunque
-processo o il \itindex{mount~point} \textit{mount point} di un altro
-filesystem; in questo caso l'errore restituito è \errcode{EBUSY}.
+\textsl{occupato}, cioè quando ci sono ancora dei file aperti sul filesystem,
+se questo contiene la \index{directory~di~lavoro} directory di lavoro corrente
+di un qualunque processo o il \itindex{mount~point} \textit{mount point} di un
+altro filesystem; in questo caso l'errore restituito è \errcode{EBUSY}.
Linux provvede inoltre una seconda funzione, \funcd{umount2}, che in alcuni
casi permette di forzare lo smontaggio di un filesystem, anche quando questo
programma \cmd{fsck} per riparare il filesystem).
Data la pericolosità di questa operazione e la disponibilità dei link
-simbolici che possono fornire la stessa funzionalità senza questi problemi,
-nel caso di Linux questa capacità è stata completamente disabilitata, e al
-tentativo di creare un link diretto ad una directory la funzione \func{link}
-restituisce l'errore \errcode{EPERM}.
+simbolici (che vedremo in sez.~\ref{sec:file_symlink}) e dei
+\itindex{bind~mount} \textit{bind mount} (già visti in
+sez.~\ref{sec:sys_file_config}) che possono fornire la stessa funzionalità
+senza questi problemi, nel caso di Linux questa capacità è stata completamente
+disabilitata, e al tentativo di creare un link diretto ad una directory la
+funzione \func{link} restituisce l'errore \errcode{EPERM}.
Un ulteriore comportamento peculiare di Linux è quello in cui si crea un
\textit{hard link} ad un link simbolico. In questo caso lo standard POSIX
kernel di sviluppo 1.3.56, ed è stato temporaneamente ripristinato anche
durante lo sviluppo della serie 2.1.x, per poi tornare al comportamento
attuale fino ad oggi (per riferimento si veda
- \href{http://lwn.net/Articles/293902}
- {\texttt{http://lwn.net/Articles/293902}}).} è stato adottato un
-comportamento che non segue più lo standard per cui l'\textit{hard link} viene
-creato rispetto al link simbolico, e non al file cui questo punta.
+ \url{http://lwn.net/Articles/293902}).} è stato adottato un comportamento
+che non segue più lo standard per cui l'\textit{hard link} viene creato
+rispetto al link simbolico, e non al file cui questo punta.
La ragione di questa differenza rispetto allo standard, presente anche in
altri sistemi unix-like, sono dovute al fatto che un link simbolico può fare
\item[\errcode{ENOTEMPTY}] \param{newpath} è una directory già esistente e
non vuota.
\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
- sistema (come \itindex{mount~point} \textit{mount point}).
+ parte di qualche processo (come \index{directory~di~lavoro} directory di
+ lavoro o come radice) o del sistema (come \itindex{mount~point}
+ \textit{mount point}).
\item[\errcode{EINVAL}] \param{newpath} contiene un prefisso di
\param{oldpath} o più in generale si è cercato di creare una directory come
sotto-directory di se stessa.
\begin{errlist}
\item[\errcode{EPERM}] il filesystem non supporta la cancellazione di
directory, oppure la directory che contiene \param{dirname} ha lo
- \itindex{sticky~bit} \textit{sticky bit} impostato e l'\acr{uid} effettivo
+ \itindex{sticky~bit} \textit{sticky bit} impostato e l'\ids{UID} effettivo
del processo non corrisponde al proprietario della directory.
\item[\errcode{EACCES}] non c'è il permesso di scrittura per la directory
che contiene la directory che si vuole cancellare, o non c'è il permesso
di attraversare (esecuzione) una delle directory specificate in
\param{dirname}.
- \item[\errcode{EBUSY}] la directory specificata è la directory di lavoro o la
- radice di qualche processo.
+ \item[\errcode{EBUSY}] la directory specificata è la
+ \index{directory~di~lavoro} directory di lavoro o la radice di qualche
+ processo.
\item[\errcode{ENOTEMPTY}] la directory non è vuota.
\end{errlist}
ed inoltre anche \errval{EFAULT}, \errval{ENAMETOOLONG}, \errval{ENOENT},
necessità di specificare il numero tramite delle opportune macro, così da non
avere problemi di compatibilità con eventuali ulteriori estensioni.
-Le macro sono definite nel file \file{sys/sysmacros.h}, che viene
-automaticamente incluso quando si include \file{sys/types.h}; si possono
+Le macro sono definite nel file \headfile{sys/sysmacros.h}, che viene
+automaticamente incluso quando si include \headfile{sys/types.h}; si possono
pertanto ottenere i valori del \itindex{major~number} \textit{major number} e
\itindex{minor~number} \textit{minor number} di un dispositivo rispettivamente
con le macro \macro{major} e \macro{minor}:
stream} \param{dir}. Di solito si utilizza questa funzione in abbinamento a
funzioni che operano sui file descriptor, ad esempio si potrà usare
\func{fstat} per ottenere le proprietà della directory, o \func{fchdir} per
-spostare su di essa la directory di lavoro (vedi
+spostare su di essa la \index{directory~di~lavoro} directory di lavoro (vedi
sez.~\ref{sec:file_work_dir}).
Viceversa se si è aperto un file descriptor corrispondente ad una directory è
stream sulla directory passata come primo argomento, stampando un messaggio in
caso di errore.
-Il passo successivo (\texttt{\small 23--24}) è cambiare directory di lavoro
-(vedi sez.~\ref{sec:file_work_dir}), usando in sequenza le funzioni
-\func{dirfd} e \func{fchdir} (in realtà si sarebbe potuto usare direttamente
-\func{chdir} su \var{dirname}), in modo che durante il successivo ciclo
-(\texttt{\small 26--30}) sulle singole voci dello stream ci si trovi
-all'interno della directory.\footnote{questo è essenziale al funzionamento
- della funzione \code{do\_ls}, e ad ogni funzione che debba usare il campo
- \var{d\_name}, in quanto i nomi dei file memorizzati all'interno di una
- struttura \struct{dirent} sono sempre relativi alla directory in questione,
- e senza questo posizionamento non si sarebbe potuto usare \func{stat} per
- ottenere le dimensioni.}
+Il passo successivo (\texttt{\small 23--24}) è cambiare
+\index{directory~di~lavoro} directory di lavoro (vedi
+sez.~\ref{sec:file_work_dir}), usando in sequenza le funzioni \func{dirfd} e
+\func{fchdir} (in realtà si sarebbe potuto usare direttamente \func{chdir} su
+\var{dirname}), in modo che durante il successivo ciclo (\texttt{\small
+ 26--30}) sulle singole voci dello stream ci si trovi all'interno della
+directory.\footnote{questo è essenziale al funzionamento della funzione
+ \code{do\_ls}, e ad ogni funzione che debba usare il campo \var{d\_name}, in
+ quanto i nomi dei file memorizzati all'interno di una struttura
+ \struct{dirent} sono sempre relativi alla directory in questione, e senza
+ questo posizionamento non si sarebbe potuto usare \func{stat} per ottenere
+ le dimensioni.}
Avendo usato lo stratagemma di fare eseguire tutte le manipolazioni necessarie
alla funzione passata come secondo argomento, il ciclo di scansione della
\label{sec:file_work_dir}
\itindbeg{pathname}
-
+\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 \struct{task\_struct} (vedi fig.~\ref{fig:proc_task_struct}), più
Una seconda usata per ottenere la directory di lavoro è \code{char
*get\_current\_dir\_name(void)} che è sostanzialmente equivalente ad una
\code{getcwd(NULL, 0)}, con la sola differenza che essa ritorna il valore
-della variabile di ambiente \val{PWD}, che essendo costruita dalla shell può
-contenere un \textit{pathname} comprendente anche dei link simbolici. Usando
-\func{getcwd} infatti, essendo il \textit{pathname} ricavato risalendo
-all'indietro l'albero della directory, si perderebbe traccia di ogni passaggio
-attraverso eventuali link simbolici.
+della variabile di ambiente \envvar{PWD}, che essendo costruita dalla shell
+può contenere un \textit{pathname} comprendente anche dei link
+simbolici. Usando \func{getcwd} infatti, essendo il \textit{pathname} ricavato
+risalendo all'indietro l'albero della directory, si perderebbe traccia di ogni
+passaggio attraverso eventuali link simbolici.
Per cambiare la directory di lavoro si può usare la funzione \funcd{chdir}
(equivalente del comando di shell \cmd{cd}) il cui nome sta appunto per
specificata da \param{fd}.
\itindend{pathname}
-
+\index{directory~di~lavoro|)}
\subsection{I file temporanei}
indefinito. Al nome viene automaticamente aggiunto come prefisso la directory
specificata dalla costante \const{P\_tmpdir}.\footnote{le costanti
\const{L\_tmpnam}, \const{P\_tmpdir} e \const{TMP\_MAX} sono definite in
- \file{stdio.h}.}
+ \headfile{stdio.h}.}
Di questa funzione esiste una versione \index{funzioni!rientranti} rientrante,
\func{tmpnam\_r}, che non fa nulla quando si passa \val{NULL} come argomento.
nome provvisorio. La funzione assegna come directory per il file temporaneo,
verificando che esista e sia accessibile, la prima valida fra le seguenti:
\begin{itemize*}
-\item La variabile di ambiente \const{TMPDIR} (non ha effetto se non è
+\item La variabile di ambiente \envvar{TMPDIR} (non ha effetto se non è
definita o se il programma chiamante è \itindex{suid~bit} \acr{suid} o
\itindex{sgid~bit} \acr{sgid}, vedi sez.~\ref{sec:file_special_perm}).
\item il valore dell'argomento \param{dir} (se diverso da \val{NULL}).
funzione non si può usare una stringa costante. Tutte le avvertenze riguardo
alle possibili \itindex{race~condition} \textit{race condition} date per
\func{tmpnam} continuano a valere; inoltre in alcune vecchie implementazioni
-il valore usato per sostituire le \code{XXXXXX} viene formato con il \acr{pid}
+il valore usato per sostituire le \code{XXXXXX} viene formato con il \ids{PID}
del processo più una lettera, il che mette a disposizione solo 26 possibilità
diverse per il nome del file, e rende il nome temporaneo facile da indovinare.
Per tutti questi motivi la funzione è deprecata e non dovrebbe mai essere
questa funzione esiste una variante \funcd{mkostemp}, introdotta
specificamente dalla \acr{glibc},\footnote{la funzione è stata introdotta
nella versione 2.7 delle librerie e richiede che sia definita la macro
- \const{\_GNU\_SOURCE}.} il cui prototipo è:
+ \macro{\_GNU\_SOURCE}.} il cui prototipo è:
\begin{prototype}{stlib.h}{int mkostemp(char *template, int flags)}
Genera un file temporaneo.
aperto, specificato tramite il suo file descriptor \param{filedes}.
La struttura \struct{stat} usata da queste funzioni è definita nell'header
-\file{sys/stat.h} e in generale dipende dall'implementazione; la versione
+\headfile{sys/stat.h} e in generale dipende dall'implementazione; la versione
usata da Linux è mostrata in fig.~\ref{fig:file_stat_struct}, così come
riportata dalla pagina di manuale di \func{stat}; in realtà la definizione
effettivamente usata nel kernel dipende dall'architettura e ha altri campi
Si noti come i vari membri della struttura siano specificati come tipi
primitivi del sistema (di quelli definiti in
-tab.~\ref{tab:intro_primitive_types}, e dichiarati in \file{sys/types.h}).
+tab.~\ref{tab:intro_primitive_types}, e dichiarati in \headfile{sys/types.h}).
\subsection{I tipi di file}
\label{sec:file_types}
\macro{S\_ISSOCK}\texttt{(m)} & socket.\\
\hline
\end{tabular}
- \caption{Macro per i tipi di file (definite in \texttt{sys/stat.h}).}
+ \caption{Macro per i tipi di file (definite in \headfile{sys/stat.h}).}
\label{tab:file_type_macro}
\end{table}
Oltre alle macro di tab.~\ref{tab:file_type_macro} è possibile usare
direttamente il valore di \var{st\_mode} per ricavare il tipo di file
controllando direttamente i vari bit in esso memorizzati. Per questo sempre in
-\file{sys/stat.h} sono definite le costanti numeriche riportate in
+\headfile{sys/stat.h} sono definite le costanti numeriche riportate in
tab.~\ref{tab:file_mode_flags}.
Il primo valore dell'elenco di tab.~\ref{tab:file_mode_flags} è la maschera
\hline
\end{tabular}
\caption{Costanti per l'identificazione dei vari bit che compongono il campo
- \var{st\_mode} (definite in \file{sys/stat.h}).}
+ \var{st\_mode} (definite in \headfile{sys/stat.h}).}
\label{tab:file_mode_flags}
\end{table}
in termini di prestazioni, che di consumo di risorse come la batteria per i
portatili, o cicli di riscrittura per i dischi su memorie riscrivibili.
+% TODO aggiustare per il contenuto duplicato con le analoghe MS_*
+
Per questo motivo, onde evitare di mantenere una informazione che nella
maggior parte dei casi non interessa, è sempre stato possibile disabilitare
l'aggiornamento del tempo di ultimo accesso con l'opzione di montaggio
Ad ogni file Linux associa sempre l'utente che ne è proprietario (il
cosiddetto \textit{owner}) ed un gruppo di appartenenza, secondo il meccanismo
-degli identificatori di utente e gruppo (\acr{uid} e \acr{gid}). Questi valori
+degli identificatori di utente e gruppo (\ids{UID} e \ids{GID}). Questi valori
sono accessibili da programma tramite la funzione \func{stat}, e sono
mantenuti nei campi \var{st\_uid} e \var{st\_gid} della struttura
\struct{stat} (si veda sez.~\ref{sec:file_stat}).\footnote{questo è vero solo
La procedura con cui il kernel stabilisce se un processo possiede un certo
permesso (di lettura, scrittura o esecuzione) si basa sul confronto fra
l'utente e il gruppo a cui il file appartiene (i valori di \var{st\_uid} e
-\var{st\_gid} accennati in precedenza) e l'\acr{uid} effettivo, il \acr{gid}
-effettivo e gli eventuali \acr{gid} supplementari del processo.\footnote{in
+\var{st\_gid} accennati in precedenza) e l'\ids{UID} effettivo, il \ids{GID}
+effettivo e gli eventuali \ids{GID} supplementari del processo.\footnote{in
realtà Linux, per quanto riguarda l'accesso ai file, utilizza gli
identificatori del gruppo \textit{filesystem} (si ricordi quanto esposto in
sez.~\ref{sec:proc_perms}), ma essendo questi del tutto equivalenti ai primi,
Per una spiegazione dettagliata degli identificatori associati ai processi si
veda sez.~\ref{sec:proc_perms}; normalmente, a parte quanto vedremo in
-sez.~\ref{sec:file_special_perm}, l'\acr{uid} effettivo e il \acr{gid} effettivo
-corrispondono ai valori dell'\acr{uid} e del \acr{gid} dell'utente che ha
-lanciato il processo, mentre i \acr{gid} supplementari sono quelli dei gruppi
+sez.~\ref{sec:file_special_perm}, l'\ids{UID} effettivo e il \ids{GID} effettivo
+corrispondono ai valori dell'\ids{UID} e del \ids{GID} dell'utente che ha
+lanciato il processo, mentre i \ids{GID} supplementari sono quelli dei gruppi
cui l'utente appartiene.
I passi attraverso i quali viene stabilito se il processo possiede il diritto
di accesso sono i seguenti:
\begin{enumerate}
-\item Se l'\acr{uid} effettivo del processo è zero (corrispondente
+\item Se l'\ids{UID} effettivo del processo è zero (corrispondente
all'amministratore) l'accesso è sempre garantito senza nessun ulteriore
controllo. Per questo motivo \textsl{root} ha piena libertà di accesso a
tutti i file.
-\item Se l'\acr{uid} effettivo del processo è uguale all'\acr{uid} del
+\item Se l'\ids{UID} effettivo del processo è uguale all'\ids{UID} del
proprietario del file (nel qual caso si dice che il processo è proprietario
del file) allora:
\begin{itemize*}
impostato, l'accesso è consentito
\item altrimenti l'accesso è negato
\end{itemize*}
-\item Se il \acr{gid} effettivo del processo o uno dei \acr{gid} supplementari
- dei processi corrispondono al \acr{gid} del file allora:
+\item Se il \ids{GID} effettivo del processo o uno dei \ids{GID} supplementari
+ dei processi corrispondono al \ids{GID} del file allora:
\begin{itemize*}
\item se il bit dei permessi d'accesso del gruppo è impostato, l'accesso è
consentito,
Se però il file del programma (che ovviamente deve essere
eseguibile\footnote{per motivi di sicurezza il kernel ignora i bit \acr{suid}
e \acr{sgid} per gli script eseguibili.}) ha il bit \acr{suid} impostato, il
-kernel assegnerà come \acr{uid} effettivo al nuovo processo l'\acr{uid} del
-proprietario del file al posto dell'\acr{uid} del processo originario. Avere
-il bit \acr{sgid} impostato ha lo stesso effetto sul \acr{gid} effettivo del
+kernel assegnerà come \ids{UID} effettivo al nuovo processo l'\ids{UID} del
+proprietario del file al posto dell'\ids{UID} del processo originario. Avere
+il bit \acr{sgid} impostato ha lo stesso effetto sul \ids{GID} effettivo del
processo.
I bit \acr{suid} e \acr{sgid} vengono usati per permettere agli utenti normali
\label{sec:file_perm_management}
Come visto in sez.~\ref{sec:file_access_control} il controllo di accesso ad un
-file viene fatto utilizzando l'\acr{uid} ed il \acr{gid} effettivo del processo;
-ci sono casi però in cui si può voler effettuare il controllo con l'\acr{uid}
-reale ed il \acr{gid} reale, vale a dire usando i valori di \acr{uid} e
-\acr{gid} relativi all'utente che ha lanciato il programma, e che, come
+file viene fatto utilizzando l'\ids{UID} ed il \ids{GID} effettivo del processo;
+ci sono casi però in cui si può voler effettuare il controllo con l'\ids{UID}
+reale ed il \ids{GID} reale, vale a dire usando i valori di \ids{UID} e
+\ids{GID} relativi all'utente che ha lanciato il programma, e che, come
accennato in sez.~\ref{sec:file_special_perm} e spiegato in dettaglio in
sez.~\ref{sec:proc_perms}, non è detto siano uguali a quelli effettivi.
\bodydesc{Le funzioni restituiscono zero in caso di successo e -1 per
un errore, in caso di errore \var{errno} può assumere i valori:
\begin{errlist}
- \item[\errcode{EPERM}] l'\acr{uid} effettivo non corrisponde a quello del
+ \item[\errcode{EPERM}] l'\ids{UID} effettivo non corrisponde a quello del
proprietario del file o non è zero.
\item[\errcode{EROFS}] il file è su un filesystem in sola lettura.
\end{errlist}
Il cambiamento dei permessi di un file eseguito attraverso queste funzioni ha
comunque alcune limitazioni, previste per motivi di sicurezza. L'uso delle
-funzioni infatti è possibile solo se l'\acr{uid} effettivo del processo
+funzioni infatti è possibile solo se l'\ids{UID} effettivo del processo
corrisponde a quello del proprietario del file o dell'amministratore,
altrimenti esse falliranno con un errore di \errcode{EPERM}.
in particolare accade che:
\begin{enumerate}
\item siccome solo l'amministratore può impostare lo \itindex{sticky~bit}
- \textit{sticky bit}, se l'\acr{uid} effettivo del processo non è zero esso
+ \textit{sticky bit}, se l'\ids{UID} effettivo del processo non è zero esso
viene automaticamente cancellato (senza notifica di errore) qualora sia
stato indicato in \param{mode}.
\item per quanto detto in sez.~\ref{sec:file_ownership_management} riguardo la
un file appartenente ad un gruppo per cui non si hanno diritti, questo viene
automaticamente cancellato da \param{mode} (senza notifica di errore)
qualora il gruppo del file non corrisponda a quelli associati al processo
- (la cosa non avviene quando l'\acr{uid} effettivo del processo è zero).
+ (la cosa non avviene quando l'\ids{UID} effettivo del processo è zero).
\end{enumerate}
Per alcuni filesystem\footnote{i filesystem più comuni (\textsl{ext2},
per la creazione di nuove directory (procedimento descritto in
sez.~\ref{sec:file_dir_creat_rem}).
-Lo standard POSIX prescrive che l'\acr{uid} del nuovo file corrisponda
-all'\acr{uid} effettivo del processo che lo crea; per il \acr{gid} invece prevede
-due diverse possibilità:
+Lo standard POSIX prescrive che l'\ids{UID} del nuovo file corrisponda
+all'\ids{UID} effettivo del processo che lo crea; per il \ids{GID} invece
+prevede due diverse possibilità:
\begin{itemize*}
-\item il \acr{gid} del file corrisponde al \acr{gid} effettivo del processo.
-\item il \acr{gid} del file corrisponde al \acr{gid} della directory in cui
+\item il \ids{GID} del file corrisponde al \ids{GID} effettivo del processo.
+\item il \ids{GID} del file corrisponde al \ids{GID} della directory in cui
esso è creato.
\end{itemize*}
in genere BSD usa sempre la seconda possibilità, che viene per questo chiamata
semantica BSD. Linux invece segue quella che viene chiamata semantica SVr4; di
norma cioè il nuovo file viene creato, seguendo la prima opzione, con il
-\acr{gid} del processo, se però la directory in cui viene creato il file ha il
+\ids{GID} del processo, se però la directory in cui viene creato il file ha il
bit \acr{sgid} impostato allora viene usata la seconda opzione.
-Usare la semantica BSD ha il vantaggio che il \acr{gid} viene sempre
+Usare la semantica BSD ha il vantaggio che il \ids{GID} viene sempre
automaticamente propagato, restando coerente a quello della directory di
partenza, in tutte le sotto-directory.
directory venga anche propagato anche il bit \acr{sgid}. Questo è il
comportamento predefinito del comando \cmd{mkdir}, ed è in questo modo ad
esempio che le varie distribuzioni assicurano che le sotto-directory create
-nella home di un utente restino sempre con il \acr{gid} del gruppo primario
+nella home di un utente restino sempre con il \ids{GID} del gruppo primario
dello stesso.
La presenza del bit \acr{sgid} è inoltre molto comoda quando si hanno
\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 per un
errore, nel qual caso caso \var{errno} assumerà i valori:
\begin{errlist}
- \item[\errcode{EPERM}] l'\acr{uid} effettivo non corrisponde a quello del
+ \item[\errcode{EPERM}] l'\ids{UID} effettivo non corrisponde a quello del
proprietario del file o non è zero, o utente e gruppo non sono validi
\end{errlist}
Oltre a questi entrambe restituiscono gli errori \errval{EROFS} e
ACL i passi attraverso i quali viene stabilito se esso ha diritto di accesso
sono i seguenti:
\begin{enumerate*}
-\item Se l'\acr{uid} del processo è nullo l'accesso è sempre garantito senza
+\item Se l'\ids{UID} del processo è nullo l'accesso è sempre garantito senza
nessun controllo.
-\item Se l'\acr{uid} del processo corrisponde al proprietario del file allora:
+\item Se l'\ids{UID} del processo corrisponde al proprietario del file allora:
\begin{itemize*}
\item se la voce \const{ACL\_USER\_OBJ} contiene il permesso richiesto,
l'accesso è consentito;
\item altrimenti l'accesso è negato.
\end{itemize*}
-\item Se l'\acr{uid} del processo corrisponde ad un qualunque qualificatore
+\item Se l'\ids{UID} del processo corrisponde ad un qualunque qualificatore
presente in una voce \const{ACL\_USER} allora:
\begin{itemize*}
\item se la voce \const{ACL\_USER} corrispondente e la voce
consentito;
\item altrimenti l'accesso è negato.
\end{itemize*}
-\item Se è il \acr{gid} del processo o uno dei \acr{gid} supplementari
+\item Se è il \ids{GID} del processo o uno dei \ids{GID} supplementari
corrisponde al gruppo proprietario del file allora:
\begin{itemize*}
\item se la voce \const{ACL\_GROUP\_OBJ} e una eventuale voce
l'accesso è consentito;
\item altrimenti l'accesso è negato.
\end{itemize*}
-\item Se è il \acr{gid} del processo o uno dei \acr{gid} supplementari
+\item Se è il \ids{GID} del processo o uno dei \ids{GID} supplementari
corrisponde ad un qualunque qualificatore presente in una voce
\const{ACL\_GROUP} allora:
\begin{itemize*}
\hline
\const{TEXT\_ABBREVIATE} & stampa le voci in forma abbreviata.\\
\const{TEXT\_NUMERIC\_IDS} & non effettua la risoluzione numerica di
- \acr{uid} e \acr{gid}.\\
+ \ids{UID} e \ids{GID}.\\
\const{TEXT\_SOME\_EFFECTIVE}& per ciascuna voce che contiene permessi che
vengono eliminati dalla \const{ACL\_MASK}
viene generato un commento con i permessi
con il supporto delle quote abilitato; esso deve essere specificato con il
nome del file di dispositivo nell'argomento \param{dev}. Per le operazioni che
lo richiedono inoltre si dovrà indicare con l'argomento \param{id} l'utente o
-il gruppo (specificati rispettivamente per \acr{uid} e \acr{gid}) su cui si
+il gruppo (specificati rispettivamente per \ids{UID} e \ids{GID}) su cui si
vuole operare. Alcune operazioni usano l'argomento \param{addr} per indicare
un indirizzo ad un area di memoria il cui utilizzo dipende dall'operazione
stessa.
\hline
\const{QFMT\_VFS\_OLD}& il vecchio (ed obsoleto) formato delle quote.\\
\const{QFMT\_VFS\_V0} & la versione 0 usata dal VFS di Linux (supporta
- \acr{uid} e \acr{gid} a 32 bit e limiti fino a
+ \ids{UID} e \ids{GID} a 32 bit e limiti fino a
$2^{42}$ byte e $2^{32}$ file.\\
\const{QFMT\_VFS\_V1} & la versione 1 usata dal VFS di Linux (supporta
- \acr{uid} e \acr{GID} a 32 bit e limiti fino a
+ \ids{UID} e \ids{GID} a 32 bit e limiti fino a
$2^{64}$ byte e $2^{64}$ file.\\
\hline
\end{tabular}
privilegi originali dal processo.
Per questo motivo se un programma senza \textit{capabilities} assegnate viene
-eseguito da un processo con \acr{uid} reale 0, esso verrà trattato come
+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
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 \acr{uid}
-nullo a \acr{uid} non nullo o viceversa (corrispondenti rispettivamente a
+\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 \acr{uid} effettivo nullo a non nullo
+\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 \acr{uid} effettivo non nullo a nullo il
+ 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} \acr{uid} nullo a non nullo verranno
+\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},
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 \acr{uid} nullo. La maschera viene sempre mantenuta
+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}.
\hline
\const{SECURE\_KEEP\_CAPS}& Il processo non subisce la cancellazione delle
sue \textit{capabilities} quando tutti i suoi
- \acr{uid} passano ad un valore non
+ \ids{UID} passano ad un valore non
nullo (regola di compatibilità per il cambio
- di \acr{uid} n.~3 del precedente
+ di \ids{UID} n.~3 del precedente
elenco), sostituisce il precedente uso
dell'operazione \const{PR\_SET\_KEEPCAPS} di
\func{prctl}.\\
\const{SECURE\_NO\_SETUID\_FIXUP}&Il processo non subisce le modifiche
delle sue \textit{capabilities} nel passaggio
- da nullo a non nullo degli \acr{uid}
+ da nullo a non nullo degli \ids{UID}
dei gruppi \textit{effective} e
\textit{file system} (regole di compatibilità
- per il cambio di \acr{uid} nn.~1 e 2 del
+ per il cambio di \ids{UID} nn.~1 e 2 del
precedente elenco).\\
\const{SECURE\_NOROOT} & Il processo non assume nessuna capacità
aggiuntiva quando esegue un programma, anche
- se ha \acr{uid} nullo o il programma ha
+ 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
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{linux/capabilities.h}, è
- aggiornato al kernel 2.6.26.} 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.
+ capabilities}) e dalle definizioni in
+ \texttt{include/linux/capabilities.h}, è aggiornato al kernel 2.6.26.} 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
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'\acr{uid} effettivo del
- processo (o meglio l'\acr{uid} di filesystem, vedi
+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
sez.~\ref{sec:sys_file_config}), effettuare operazioni di controllo su
qualunque oggetto dell'IPC di SysV (vedi sez.~\ref{sec:ipc_sysv}), operare
sugli attributi estesi dei file di classe \texttt{security} o \texttt{trusted}
-(vedi sez.~\ref{sec:file_xattr}), specificare un \acr{uid} arbitrario
+(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
indicato che per poterle utilizzare fosse necessario che la macro
\macro{\_POSIX\_SOURCE} risultasse non definita (ed era richiesto di inserire
una istruzione \texttt{\#undef \_POSIX\_SOURCE} prima di includere
-\texttt{sys/capability.h}) requisito che non risulta più presente.\footnote{e
- non è chiaro neanche quanto sia mai stato davvero necessario.}
+\headfile{sys/capability.h}) requisito che non risulta più
+presente.\footnote{e non è chiaro neanche quanto sia mai stato davvero
+ necessario.}
Si tenga presente che le strutture di fig.~\ref{fig:cap_kernel_struct}, come i
prototipi delle due funzioni \func{capget} e \func{capset}, sono soggette ad
con l'argomento \param{flag}. Questo deve essere specificato con una variabile
di tipo \type{cap\_flag\_t} che può assumere esclusivamente\footnote{si tratta
in effetti di un tipo enumerato, come si può verificare dalla sua
- definizione che si trova in \texttt{/usr/include/sys/capability.h}.} uno dei
-valori illustrati in tab.~\ref{tab:cap_set_identifier}.
+ definizione che si trova in \headfile{sys/capability.h}.} uno dei valori
+illustrati in tab.~\ref{tab:cap_set_identifier}.
Si possono inoltre confrontare in maniera diretta due diversi
\textit{capability state} con la funzione \funcd{cap\_compare}; il suo
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
- \texttt{sys/capability.h} il tipo \type{cap\_value\_t} è definito come
+ \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}.}
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 \texttt{sys/capability.h}.} è:
+ dichiarazione della stessa in \headfile{sys/capability.h}.} è:
\begin{functions}
\headdecl{sys/capability.h}
-\subsection{La funzione \func{chroot}}
+\subsection{La gestione dei {chroot}}
\label{sec:file_chroot}
% TODO introdurre nuova sezione sulle funzionalità di sicurezza avanzate, con
programma ad una sezione limitata del filesystem, per cui ne parleremo in
questa sezione.
+% TODO riferimenti ai bind mount, link simbolici ecc.
+
Come accennato in sez.~\ref{sec:proc_fork} ogni processo oltre ad una
-directory di lavoro, ha anche una directory \textsl{radice}\footnote{entrambe
- sono contenute in due campi (rispettivamente \var{pwd} e \var{root}) di
- \struct{fs\_struct}; vedi fig.~\ref{fig:proc_task_struct}.} che, pur essendo
-di norma corrispondente alla radice dell'albero di file e directory come visto
-dal kernel (ed illustrato in sez.~\ref{sec:file_pathname}), ha per il processo
-il significato specifico di directory rispetto alla quale vengono risolti i
+\index{directory~di~lavoro} directory di lavoro, ha anche una directory
+\textsl{radice}\footnote{entrambe sono contenute in due campi (rispettivamente
+ \var{pwd} e \var{root}) di \struct{fs\_struct}; vedi
+ fig.~\ref{fig:proc_task_struct}.} che, pur essendo di norma corrispondente
+alla radice dell'albero di file e directory come visto dal kernel (ed
+illustrato in sez.~\ref{sec:file_pathname}), ha per il processo il significato
+specifico di directory rispetto alla quale vengono risolti i
\itindsub{pathname}{assoluto}\textit{pathname} assoluti.\footnote{cioè quando
un processo chiede la risoluzione di un \textit{pathname}, il kernel usa
sempre questa directory come punto di partenza.} Il fatto che questo valore
sia specificato per ogni processo apre allora la possibilità di modificare le
modalità di risoluzione dei \textit{pathname} assoluti da parte di un processo
cambiando questa directory, così come si fa coi
-\itindsub{pathname}{relativo}\textit{pathname} relativi cambiando la directory
+\itindsub{pathname}{relativo}\textit{pathname} relativi cambiando la \index{directory~di~lavoro} directory
di lavoro.
Normalmente la directory radice di un processo coincide anche con la radice
\bodydesc{La funzione restituisce zero in caso di successo e -1 per
un errore, in caso di errore \var{errno} può assumere i valori:
\begin{errlist}
- \item[\errcode{EPERM}] l'\acr{uid} effettivo del processo non è zero.
+ \item[\errcode{EPERM}] l'\ids{UID} effettivo del processo non è zero.
\end{errlist}
ed inoltre \errval{EFAULT}, \errval{ENAMETOOLONG}, \errval{ENOENT},
\errval{ENOMEM}, \errval{ENOTDIR}, \errval{EACCES}, \errval{ELOOP};
Questo è il motivo per cui la funzione è efficace solo se dopo averla eseguita
si cedono i privilegi di root. Infatti se per un qualche motivo il processo
-resta con la directory di lavoro fuori dalla \textit{chroot jail}, potrà
-comunque accedere a tutto il resto del filesystem usando
-\itindsub{pathname}{relativo}\textit{pathname} relativi, i quali, partendo
-dalla directory di lavoro che è fuori della \textit{chroot jail}, potranno
-(con l'uso di ``\texttt{..}'') risalire fino alla radice effettiva del
-filesystem.
+resta con \index{directory~di~lavoro} la directory di lavoro fuori dalla
+\textit{chroot jail}, potrà comunque accedere a tutto il resto del filesystem
+usando \itindsub{pathname}{relativo}\textit{pathname} relativi, i quali,
+partendo dalla directory di lavoro che è fuori della \textit{chroot jail},
+potranno (con l'uso di ``\texttt{..}'') risalire fino alla radice effettiva
+del filesystem.
Ma se ad un processo restano i privilegi di amministratore esso potrà comunque
-portare la sua directory di lavoro fuori dalla \textit{chroot jail} in cui si
-trova. Basta infatti creare una nuova \textit{chroot jail} con l'uso di
-\func{chroot} su una qualunque directory contenuta nell'attuale directory di
-lavoro. Per questo motivo l'uso di questa funzione non ha molto senso quando
-un processo necessita dei privilegi di root per le sue normali operazioni.
+portare la sua \index{directory~di~lavoro} directory di lavoro fuori dalla
+\textit{chroot jail} in cui si trova. Basta infatti creare una nuova
+\textit{chroot jail} con l'uso di \func{chroot} su una qualunque directory
+contenuta nell'attuale directory di lavoro. Per questo motivo l'uso di questa
+funzione non ha molto senso quando un processo necessita dei privilegi di root
+per le sue normali operazioni.
Un caso tipico di uso di \func{chroot} è quello di un server FTP anonimo, in
questo caso infatti si vuole che il server veda solo i file che deve
projects / gapil.git / blobdiff