% NOTE articolo interessante:
% http://www.ibm.com/developerworks/linux/library/l-virtual-filesystem-switch/index.html?ca=dgr-lnxw97Linux-VFSdth-LXdW&S_TACT=105AGX59&S_CMP=GRlnxw97
-\itindbeg{Virtual~File~System}
+\itindbeg{Virtual~File~System~(VFS)}
Come illustrato brevemente in sez.~\ref{sec:file_arch_overview} in Linux il
concetto di \textit{everything is a file} è stato implementato attraverso il
sez.~\ref{sec:file_dir_creat_rem}).\\
\textsl{\code{rmdir}} & Rimuove una directory (vedi
sez.~\ref{sec:file_dir_creat_rem}).\\
- \textsl{\code{mknod}} & Crea un \index{file!speciali} file speciale (vedi
+ \textsl{\code{mknod}} & Crea un file speciale (vedi
sez.~\ref{sec:file_mknod}).\\
\textsl{\code{rename}} & Cambia il nome di un file (vedi
sez.~\ref{sec:link_symlink_rename}).\\
possono esserci negli oggetti a cui si applicano.
-\itindend{Virtual~File~System}
+\itindend{Virtual~File~System~(VFS)}
% NOTE: documentazione interessante:
% * sorgenti del kernel: Documentation/filesystems/vfs.txt
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
-\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.}
+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.}
Il tipo di filesystem che si vuole montare è specificato
dall'argomento \param{filesystemtype}, che deve essere una delle stringhe
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 che lo compongono, detti anche \textit{mount flags}, devono
-essere impostati con un OR aritmetico dei valori dalle costanti riportate
-nell'elenco seguente:
+ \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
+che lo compongono, detti anche \textit{mount flags}, devono essere impostati
+con un OR aritmetico dei valori dalle costanti riportate nell'elenco seguente:
\begin{basedescript}{\desclabelwidth{2.cm}\desclabelstyle{\nextlinelabel}}
\itindbeg{bind~mount}
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 corrispondenza della \textit{dentry} di \texttt{target}
- un diverso \itindex{inode} \textit{inode}, che stavolta, invece di essere
- quello della radice del filesystem indicato da un file di dispositivo, è
- quello di una directory già montata.
+ 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
+ \itindex{inode} \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
sullo stesso \itindex{mount~point} \textit{mount point} viene smontato quello
che è stato montato per ultimo. Si tenga presente che la funzione fallisce se
il filesystem è ``\textsl{occupato}'', cioè quando ci sono ancora dei file
-aperti sul filesystem, se questo contiene la \index{directory~di~lavoro}
-directory di lavoro di un qualunque processo o il \itindex{mount~point}
-\textit{mount point} di un altro filesystem.
+aperti sul filesystem, se questo contiene la directory di lavoro (vedi
+sez.~\ref{sec:file_work_dir}) di un qualunque processo o il
+\itindex{mount~point} \textit{mount point} di un altro filesystem.
Linux provvede inoltre una seconda funzione di sistema, \funcd{umount2}, che
consente un maggior controllo delle operazioni, come forzare lo smontaggio di
\begin{errlist}
\item[\errcode{EAGAIN}] si è chiamata la funzione con \const{MNT\_EXPIRE}
ed il filesystem non era occupato.
- \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.
- \item[\errcode{EINVAL}] \param{target} non è un \itindex{mount~point}
- \textit{mount point} o si è usato \const{MNT\_EXPIRE} con
- \const{MNT\_FORCE} o \const{MNT\_DETACH} o si è specificato un flag non
- esistente.
+ \item[\errcode{EBUSY}] \param{target} è la directory di lavoro di qualche
+ processo, o contiene dei file aperti, o un altro \textit{mount point}.
+ \item[\errcode{EINVAL}] \param{target} non è un \textit{mount point} o si
+ è usato \const{MNT\_EXPIRE} con \const{MNT\_FORCE} o
+ \const{MNT\_DETACH} o si è specificato un flag non esistente.
\end{errlist}
e tutti gli altri valori visti per \func{umount} con lo stesso significato.}
\end{funcproto}
introdotta per evitare, per quei filesystem per il quale è prevista una
gestione diretta da parte degli utenti, come quelli basati su
FUSE,\footnote{il \textit{Filesystem in USEr space} (FUSE) è una delle più
- interessanti applicazioni del \itindex{Virtual~File~System} VFS che
- consente, tramite un opportuno modulo, di implementarne le funzioni in
- \textit{user space}, così da rendere possibile l'implementazione di un
- qualunque filesystem (con applicazioni di grande interesse come il
- filesystem cifrato \textit{encfs} o il filesystem di rete \textit{sshfs})
- che possa essere usato direttamente per conto degli utenti.} che si possano
-passare ai programmi che effettuano lo smontaggio dei filesystem, che in
-genere sono privilegiati ma consentono di agire solo sui propri \textit{mount
- point}, dei collegamenti simbolici che puntano ad altri \textit{mount
- point}, ottenendo così la possibilità di smontare qualunque filesystem.
+ interessanti applicazioni del VFS che consente, tramite un opportuno modulo,
+ di implementarne le funzioni in \textit{user space}, così da rendere
+ possibile l'implementazione di un qualunque filesystem (con applicazioni di
+ grande interesse come il filesystem cifrato \textit{encfs} o il filesystem
+ di rete \textit{sshfs}) che possa essere usato direttamente per conto degli
+ utenti.} che si possano passare ai programmi che effettuano lo smontaggio
+dei filesystem, che in genere sono privilegiati ma consentono di agire solo
+sui propri \textit{mount point}, dei collegamenti simbolici che puntano ad
+altri \textit{mount point}, ottenendo così la possibilità di smontare
+qualunque filesystem.
Altre due funzioni di sistema specifiche di Linux,\footnote{esse si trovano
directory che lo contiene e decrementa il numero di riferimenti nel relativo
\itindex{inode} \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, fifo o file di dispositivo
-\index{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.
+ atomica.} Nel caso di socket, 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.
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
quelle dei 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 \index{directory~di~lavoro} directory di
- lavoro o come radice) o del sistema (come \itindex{mount~point}
- \textit{mount point}) ed il sistema non riesce a risolvere la situazione.
+ parte di qualche processo (come directory di lavoro o come radice) o del
+ sistema (come \textit{mount point}) ed il sistema non riesce a risolvere
+ la situazione.
\item[\errcode{EEXIST}] \param{newpath} è una directory già esistente e
non è vuota (anche \errcode{ENOTEMPTY}).
\item[\errcode{EINVAL}] \param{newpath} contiene un prefisso di
non è possibile trattarle come file ordinari e devono essere create
direttamente dal kernel attraverso una opportuna \textit{system
call}.\footnote{questo è quello che permette anche, attraverso l'uso del
- \itindex{Virtual~File~System} VFS, l'utilizzo di diversi formati per la
- gestione dei suddetti elenchi, dalle semplici liste a strutture complesse
- come alberi binari, hash, ecc. che consentono una ricerca veloce quando il
- numero di file è molto grande.} La funzione di sistema usata per creare una
-directory è \funcd{mkdir}, ed il suo prototipo è:
+ VFS, l'utilizzo di diversi formati per la gestione dei suddetti elenchi,
+ dalle semplici liste a strutture complesse come alberi binari, hash,
+ ecc. che consentono una ricerca veloce quando il numero di file è molto
+ grande.} La funzione di sistema usata per creare una directory è
+\funcd{mkdir}, ed il suo prototipo è:
\begin{funcproto}{
\fhead{sys/stat.h}
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
- \index{directory~di~lavoro} directory di lavoro o la radice di qualche
- processo o un \itindex{mount~point} \textit{mount point}.
+ \item[\errcode{EBUSY}] la directory specificata è la directory di lavoro o
+ la radice di qualche processo o un \textit{mount point}.
\item[\errcode{EINVAL}] si è usato ``\texttt{.}'' come ultimo componente
di \param{dirname}.
\item[\errcode{EPERM}] il filesystem non supporta la cancellazione di
in sez.~\ref{sec:file_open_close} che è possibile aprire una directory come se
fosse un file, anche se solo in sola lettura) in generale il formato con cui
esse sono scritte può dipendere dal tipo di filesystem, tanto che, come
-riportato in tab.~\ref{tab:file_file_operations}, il
-\itindex{Virtual~File~System} VFS prevede una apposita funzione per la lettura
-delle directory.
+riportato in tab.~\ref{tab:file_file_operations}, il VFS prevede una apposita
+funzione per la lettura delle directory.
\itindbeg{directory~stream}
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 \index{directory~di~lavoro} directory di lavoro (vedi
+spostare su di essa la directory di lavoro (vedi
sez.~\ref{sec:file_work_dir}).
Viceversa se si è aperto un file descriptor corrispondente ad una directory è
una struttura allocata staticamente, che viene sovrascritta tutte le volte che
si ripete la lettura di una voce sullo stesso \textit{directory stream}.
-Di questa funzione esiste anche una versione \index{funzioni!rientranti}
-rientrante, \funcd{readdir\_r},\footnote{per usarla è necessario definire una
- qualunque delle macro \texttt{\macro{\_POSIX\_C\_SOURCE} >= 1},
+Di questa funzione esiste anche una versione rientrante,
+\funcd{readdir\_r},\footnote{per usarla è necessario definire una qualunque
+ delle macro \texttt{\macro{\_POSIX\_C\_SOURCE} >= 1},
\macro{\_XOPEN\_SOURCE}, \macro{\_BSD\_SOURCE}, \macro{\_SVID\_SOURCE},
\macro{\_POSIX\_SOURCE}.} che non usa una struttura allocata staticamente, e
può essere utilizzata anche con i \itindex{thread} \textit{thread}, il suo
18-22}) uno \textit{stream} sulla directory passata come primo argomento,
stampando un messaggio in caso di errore.
-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 \textit{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 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 \textit{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
\const{L\_tmpnam}, \const{P\_tmpdir} e \const{TMP\_MAX} sono definite in
\headfile{stdio.h}.}
-Di questa funzione esiste una versione \index{funzioni!rientranti} rientrante,
+Di questa funzione esiste una versione \ rientrante,
\funcm{tmpnam\_r}, che non fa nulla quando si passa \val{NULL} come argomento.
Una funzione simile, \funcd{tempnam}, permette di specificare un prefisso per
il file esplicitamente, il suo prototipo è:
\end{funcproto}
La funzione alloca con \code{malloc} la stringa in cui restituisce il nome,
-per cui è sempre \index{funzioni!rientranti} rientrante, occorre però
+per cui è sempre \ rientrante, occorre però
ricordarsi di disallocare con \code{free} il puntatore che restituisce.
L'argomento \param{pfx} specifica un prefisso di massimo 5 caratteri per il
nome provvisorio. La funzione assegna come directory per il file temporaneo,
che viene automaticamente cancellato alla sua chiusura o all'uscita dal
programma. Lo standard non specifica in quale directory verrà aperto il file,
ma la \acr{glibc} prima tenta con \const{P\_tmpdir} e poi con
-\file{/tmp}. Questa funzione è \index{funzioni!rientranti} rientrante e non
-soffre di problemi di \itindex{race~condition} \textit{race condition}.
+\file{/tmp}. Questa funzione è rientrante e non soffre di problemi di
+\itindex{race~condition} \textit{race condition}.
Alcune versioni meno recenti di Unix non supportano queste funzioni; in questo
caso si possono usare le vecchie funzioni \funcd{mktemp} e \func{mkstemp} che
anche alla chiamata di \func{utime}. Questo serve anche come misura di
sicurezza per evitare che si possa modificare un file nascondendo
completamente le proprie tracce. In realtà la cosa resta possibile se si è in
-grado di accedere al \index{file!di~dispositivo} file di dispositivo,
-scrivendo direttamente sul disco senza passare attraverso il filesystem, ma
-ovviamente in questo modo la cosa è più complicata da
-realizzare.\footnote{esistono comunque molti programmi che consentono di farlo
- con relativa semplicità per cui non si dia per scontato che il valore sia
- credibile in caso di macchina compromessa.}
+grado di accedere al file di dispositivo, scrivendo direttamente sul disco
+senza passare attraverso il filesystem, ma ovviamente in questo modo la cosa è
+più complicata da realizzare.\footnote{esistono comunque molti programmi che
+ consentono di farlo con relativa semplicità per cui non si dia per scontato
+ che il valore sia credibile in caso di macchina compromessa.}
A partire dal kernel 2.6 la risoluzione dei tempi dei file, che nei campi di
tab.~\ref{tab:file_file_times} è espressa in secondi, è stata portata ai
notazione illustrata in fig.~\ref{fig:file_perm_bit}.
Si ricordi infine che i permessi non hanno alcun significato per i
-collegamenti simbolici, mentre per i \index{file!di~dispositivo} file di
-dispositivo hanno senso soltanto i permessi di lettura e scrittura, che si
-riflettono sulla possibilità di compiere dette operazioni sul dispositivo
-stesso.
+collegamenti simbolici, mentre per i file di dispositivo hanno senso soltanto
+i permessi di lettura e scrittura, che si riflettono sulla possibilità di
+compiere dette operazioni sul dispositivo stesso.
Nella tabella si è indicato con il carattere ``-'' il fatto che il valore del
bit in questione non è influente rispetto a quanto indicato nella riga della
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
- utenti, come i collegamenti simbolici, o alcuni \index{file!di~dispositivo}
- 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 piacere.\footnote{la cosa è stata notata su XFS, dove
- questo comportamento permetteva, non essendovi limiti sullo spazio
- occupabile dagli \textit{Extended Attributes}, di bloccare il sistema
- riempiendo il disco.}
+ 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
+ piacere.\footnote{la cosa è stata notata su XFS, dove questo comportamento
+ permetteva, non essendovi limiti sullo spazio occupabile dagli
+ \textit{Extended Attributes}, di bloccare il sistema riempiendo il disco.}
La semantica del controllo di accesso indicata inoltre non avrebbe alcun
senso al di fuori di file e directory: i permessi di lettura e scrittura per
- un \index{file!di~dispositivo} file di dispositivo attengono alle capacità
- di accesso al dispositivo sottostante,\footnote{motivo per cui si può
- formattare un disco anche se \texttt{/dev} è su un filesystem in sola
- lettura.} mentre per i collegamenti simbolici questi vengono semplicemente
- ignorati: in nessuno dei due casi hanno a che fare con il contenuto del
- file, e nella discussione relativa all'uso degli \textit{extended user
- attributes} nessuno è mai stato capace di indicare una qualche forma
- sensata di utilizzo degli stessi per collegamenti simbolici o
- \index{file!di~dispositivo} file di dispositivo, e neanche per le fifo o i
+ un file di dispositivo attengono alle capacità di accesso al dispositivo
+ sottostante,\footnote{motivo per cui si può formattare un disco anche se
+ \texttt{/dev} è su un filesystem in sola lettura.} mentre per i
+ collegamenti simbolici questi vengono semplicemente ignorati: in nessuno dei
+ due casi hanno a che fare con il contenuto del file, e nella discussione
+ relativa all'uso degli \textit{extended user attributes} nessuno è mai stato
+ capace di indicare una qualche forma sensata di utilizzo degli stessi per
+ collegamenti simbolici o file di dispositivo, e neanche per le fifo o i
socket. Per questo motivo essi sono stati completamente disabilitati per
tutto ciò che non sia un file regolare o una directory.\footnote{si può
verificare la semantica adottata consultando il file \texttt{fs/xattr.c}
\textit{immutable} e \textit{append-only} (vedi
sez.~\ref{sec:file_perm_overview}) se
supportati.\\
- \const{CAP\_MKNOD} & Creare \index{file!di~dispositivo} file di
- dispositivo con \func{mknod} (vedi
+ \const{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.\\
questa sezione.
Come accennato in sez.~\ref{sec:proc_fork} ogni processo oltre ad una
-\index{directory~di~lavoro} directory di lavoro, ha anche una directory
-\textsl{radice}\footnote{entrambe sono contenute in due campi (rispettivamente
- \var{pwd} e \var{root}) di \kstruct{fs\_struct}; vedi
- fig.~\ref{fig:proc_task_struct}.} che, pur essendo di norma corrispondente
-alla radice dell'albero dei file dell'intero sistema, ha per il processo il
-significato specifico di directory rispetto alla quale vengono risolti i
-\itindsub{pathname}{assoluto}\textit{pathname} assoluti.\footnote{cioè quando
- un processo chiede la risoluzione di un \textit{pathname}, il kernel usa
- sempre questa directory come punto di partenza.} Il fatto che questo valore
-sia specificato per ogni processo apre allora la possibilità di modificare le
-modalità di risoluzione dei \itindsub{pathname}{assoluto} \textit{pathname}
-assoluti da parte di un processo cambiando questa directory, così come si fa
-coi \itindsub{pathname}{relativo} \textit{pathname} relativi cambiando la
-\index{directory~di~lavoro} directory di lavoro.
+directory di lavoro, ha anche una directory \textsl{radice}\footnote{entrambe
+ sono contenute in due campi (rispettivamente \var{pwd} e \var{root}) di
+ \kstruct{fs\_struct}; vedi fig.~\ref{fig:proc_task_struct}.} che, pur
+essendo di norma corrispondente alla radice dell'albero dei file dell'intero
+sistema, ha per il processo il significato specifico di directory rispetto
+alla quale vengono risolti i \itindsub{pathname}{assoluto}\textit{pathname}
+assoluti.\footnote{cioè quando un processo chiede la risoluzione di un
+ \textit{pathname}, il kernel usa sempre questa directory come punto di
+ partenza.} Il fatto che questo valore sia specificato per ogni processo apre
+allora la possibilità di modificare le modalità di risoluzione dei
+\itindsub{pathname}{assoluto} \textit{pathname} assoluti da parte di un
+processo cambiando questa directory, così come si fa coi
+\itindsub{pathname}{relativo} \textit{pathname} relativi cambiando la
+directory di lavoro.
Normalmente la directory radice di un processo coincide con la radice generica
dell'albero dei file, che è la directory che viene montata direttamente dal
Questo è il motivo per cui la funzione è efficace nel restringere un processo
ad un ramo di albero solo se dopo averla eseguita si cedono i privilegi di
amministratore. Infatti se per un qualunque motivo il processo resta con la
-sua \index{directory~di~lavoro} directory di lavoro al di fuori dalla
-\textit{chroot jail}, potrà accedere a tutto il resto del filesystem usando
-\itindsub{pathname}{relativo} dei \textit{pathname} relativi, dato che in tal
-caso è possibile, grazie all'uso di ``\texttt{..}'', risalire all'indietro
-fino alla radice effettiva dell'albero dei file.
+sua directory di lavoro al di fuori dalla \textit{chroot jail}, potrà accedere
+a tutto il resto del filesystem usando \itindsub{pathname}{relativo} dei
+\textit{pathname} relativi, dato che in tal caso è possibile, grazie all'uso
+di ``\texttt{..}'', risalire all'indietro fino alla radice effettiva
+dell'albero dei file.
Potrebbe sembrare che per risolvere il problema sia sufficiente ricordarsi di
eseguire preventivamente anche una \func{chdir} sulla directory su cui si
andrà ad eseguire \func{chroot}, così da assicurarsi che le directory di
lavoro sia all'interno della \textit{chroot jail}. Ma se ad un processo
restano i privilegi di amministratore esso potrà comunque portare la sua
-\index{directory~di~lavoro} directory di lavoro fuori dalla \textit{chroot
- jail} in cui si trova. Basterà infatti eseguire di nuovo \func{chroot} su
-una qualunque directory contenuta nell'attuale directory di lavoro perché
-quest'ultima risulti al di fuori della nuova \textit{chroot jail}. Per questo
-motivo l'uso di questa funzione non ha molto senso quando un processo di cui
-si vuole limitare l'accesso necessita comunque dei privilegi di amministratore
-per le sue normali operazioni.
+directory di lavoro fuori dalla \textit{chroot jail} in cui si trova. Basterà
+infatti eseguire di nuovo \func{chroot} su una qualunque directory contenuta
+nell'attuale directory di lavoro perché quest'ultima risulti al di fuori della
+nuova \textit{chroot jail}. Per questo motivo l'uso di questa funzione non ha
+molto senso quando un processo di cui si vuole limitare l'accesso necessita
+comunque dei privilegi di amministratore per le sue normali operazioni.
Nonostante queste limitazioni la funzione risulta utile qualora la si possa
applicare correttamente cedendo completamente i privilegi di amministratore
projects / gapil.git / blobdiff