- \errval{EROFS} e \errval{EIO}.}
-\end{prototype}
-\noindent in questo modo la directory radice del processo diventerà
-\param{path} (che ovviamente deve esistere) ed ogni
-\itindsub{pathname}{assoluto}\textit{pathname} assoluto usato dalle funzioni
-chiamate nel processo sarà risolto a partire da essa, rendendo impossibile
-accedere alla parte di albero sovrastante. Si ha così quella che viene
-chiamata una \textit{chroot jail}, in quanto il processo non può più accedere
-a file al di fuori della sezione di albero in cui è stato
-\textsl{imprigionato}.
-
-Solo un processo con i privilegi di amministratore può usare questa funzione,
-e la nuova radice, per quanto detto in sez.~\ref{sec:proc_fork}, sarà ereditata
-da tutti i suoi processi figli. Si tenga presente però che la funzione non
-cambia la directory di lavoro, che potrebbe restare fuori dalla \textit{chroot
- jail}.
-
-Questo è il motivo per cui la funzione è efficace solo se dopo averla eseguita
-si cedono i privilegi di root. Infatti se per un qualche motivo il processo
-resta con \index{directory~di~lavoro} la directory di lavoro fuori dalla
-\textit{chroot jail}, potrà comunque accedere a tutto il resto del filesystem
-usando \itindsub{pathname}{relativo}\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 \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
-trasferire, per cui in genere si esegue una \func{chroot} sulla directory che
-contiene i file. Si tenga presente però che in questo caso occorrerà
-replicare all'interno della \textit{chroot jail} tutti i file (in genere
-programmi e librerie) di cui il server potrebbe avere bisogno.
-
-
-
-% TODO: trattare la funzione setns e i namespace file descriptors (vedi
-% http://lwn.net/Articles/407495/) introdotti con il kernel 3.0
+ \errval{EROFS} e \errval{EIO} nel loro significato generico.}
+\end{funcproto}
+
+La funzione imposta la directory radice del processo a quella specificata da
+\param{path} (che ovviamente deve esistere) ed ogni \textit{pathname} assoluto
+usato dalle funzioni chiamate nel processo sarà risolto a partire da essa,
+rendendo impossibile accedere alla parte di albero sovrastante. Si ha così
+quella che viene chiamata una \textit{chroot jail}, in quanto il processo non
+può più accedere a file al di fuori della sezione di albero in cui è stato
+\textsl{imprigionato}.
+
+Solo un processo con i privilegi di amministratore può usare questa
+funzione,\footnote{più precisamente se possiede la capacità
+ \const{CAP\_SYS\_CHROOT}.} e la nuova radice, per quanto detto in
+sez.~\ref{sec:proc_fork}, sarà ereditata da tutti i suoi processi figli. Si
+tenga presente però che la funzione non cambia la directory di lavoro del
+processo, che potrebbe restare fuori dalla \textit{chroot jail}.
+
+Questo è il motivo per cui la funzione è efficace nel restringere un processo
+ad un ramo di albero solo se dopo averla eseguita si cedono i privilegi di
+amministratore. Infatti se per un qualunque motivo il processo resta con la
+sua directory di lavoro al di fuori dalla \textit{chroot jail}, potrà accedere
+a tutto il resto del filesystem usando 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
+directory di lavoro fuori dalla \textit{chroot jail} in cui si trova. Basterà
+infatti eseguire di nuovo \func{chroot} su una qualunque directory contenuta
+nell'attuale directory di lavoro perché quest'ultima risulti al di fuori della
+nuova \textit{chroot jail}. Per questo motivo l'uso di questa funzione non ha
+molto senso quando un processo di cui si vuole limitare l'accesso necessita
+comunque dei privilegi di amministratore per le sue normali operazioni.
+
+Nonostante queste limitazioni la funzione risulta utile qualora la si possa
+applicare correttamente cedendo completamente i privilegi di amministratore
+una volta eseguita. Ed esempio caso tipico di uso di \func{chroot} è quello
+di un server FTP anonimo in si vuole che il server veda solo i file che deve
+trasferire. In tal caso si esegue una \func{chroot} sulla directory che
+contiene i file, che il server dovrà in grado di leggere come utente
+ordinario, e poi si cedono tutti i privilegi di amministratore. Si tenga
+presente però che in casi come questo occorrerà fornire all'interno della
+\textit{chroot jail} un accesso anche a tutti i file (in genere programmi e
+librerie) di cui il server potrebbe avere bisogno.