\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}.
-
-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 nell'elenco seguente:
-
-\begin{basedescript}{\desclabelstyle{\pushlabel}}
-
-\item[\const{MS\_BIND}] Effettua un cosiddetto \textit{bind mount}, in
- sostanza .
+Oltre alle opzioni specifiche di ciascun filesystem, che si passano nella
+forma delle opzioni 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}.} oggi invece sono
+ignorati mentre i 16 meno significativi sono usati per specificare le opzioni
+come maschera binaria e vanno impostati con un OR aritmetico dei valori
+riportati 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. In
+ questo caso verranno presi in considerazione solo gli argomenti
+ \texttt{source}, che stavolta indicherà la directory che si vuole montare (e
+ non un file di dispositivo) e \texttt{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 \texttt{target} viene montato l'\textit{inode}
+ di \texttt{source}, così che la porzione di albero dei file presente sotto
+ \texttt{source} diventi visibile allo stesso modo sotto
+ \texttt{target}. Trattandosi esattamente di 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 \texttt{target} comparirà il
+ contenuto che è presente sotto \texttt{source} all'interno del filesystem in
+ cui quest'ultima è contenuta. Questo potrebbe non corrispondere alla
+ porzione di albero che sta sotto \texttt{source} qualora in una
+ sottodirectory di quest'ultima si fosse effettuato un altro montaggio. In
+ tal caso infatti nella porzione di albero sotto \texttt{source} si
+ troverebbe il contenuto del nuovo filesystem (o di un altro \textit{bind
+ mount}) mentre sotto \texttt{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 \texttt{target} una directory in cui essa è contenuta, il
+ cerchio non potrebbe chiudersi perché ritornati a \texttt{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 può far sì che l'accesso ai file sotto
+ \texttt{target} possa avvenire soltanto 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}) e di poter far comparire una qualunque porzione
+ dell'albero dei file all'interno di una qualunque directory, anche se questa
+ sta su un filesystem diverso, fornendo 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}] .
-\item[\const{MS\_MANDLOCK}] Consente il \textit{mandatory locking}
- \itindex{mandatory~locking} (vedi
- sez.~\ref{sec:file_mand_locking}).
+\item[\const{MS\_MANDLOCK}] Consente il \textit{mandatory locking}
+ \itindex{mandatory~locking} (vedi sez.~\ref{sec:file_mand_locking}).
-\item[\const{MS\_MOVE}] Sposta atomicamente il punto di montaggio.
+\item[\const{MS\_MOVE}] Sposta atomicamente il punto di montaggio.
-\item[\const{MS\_NOATIME}] Non aggiorna gli \textit{access time} (vedi
- sez.~\ref{sec:file_file_times}).
+\item[\const{MS\_NOATIME}] Non aggiorna gli \textit{access time} (vedi
+ sez.~\ref{sec:file_file_times}).
-\item[\const{MS\_NODEV}] Impedisce l'accesso ai file di dispositivo.
+\item[\const{MS\_NODEV}] Impedisce l'accesso ai file di dispositivo.
-\item[\const{MS\_NODIRATIME}] Non aggiorna gli \textit{access time} delle
- directory.
-\item[\const{MS\_NOEXEC}] Impedisce di eseguire programmi.
+\item[\const{MS\_NODIRATIME}] Non aggiorna gli \textit{access time} delle
+ directory.
+\item[\const{MS\_NOEXEC}] Impedisce di eseguire programmi.
-\item[\const{MS\_NOSUID}] Ignora i bit \itindex{suid~bit} \acr{suid} e
- \itindex{sgid~bit} \acr{sgid}.
+\item[\const{MS\_NOSUID}] Ignora i bit \itindex{suid~bit} \acr{suid} e
+ \itindex{sgid~bit} \acr{sgid}.
-\item[\const{MS\_RDONLY}] Monta in sola lettura.
+\item[\const{MS\_RDONLY}] Monta in sola lettura.
-\item[\const{MS\_RELATIME}] .
+\item[\const{MS\_RELATIME}] .
-\item[\const{MS\_REMOUNT}] Rimonta il filesystem cambiando le opzioni.
+\item[\const{MS\_REMOUNT}] Rimonta il filesystem cambiando le opzioni.
-\item[\const{MS\_SILENT}] .
+\item[\const{MS\_SILENT}] .
\item[\const{MS\_STRICTATIME}] .
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
-\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
projects / gapil.git / commitdiff