permettono di fare riferimento allo stesso file chiamandolo con nomi diversi
o accedendovi da directory diverse.
-Questo è possibile anche in ambiente unix, dove tali collegamenti sono
+Questo è possibile anche in ambiente Unix, dove tali collegamenti sono
usualmente chiamati \textit{link}; ma data la struttura del sistema di
gestione dei file (ed in particolare quanto trattato in
-\secref{sec:file_architecture}) ci sono due metodi sostanzialmente diversi per
+\secref{sec:file_arch_func}) ci sono due metodi sostanzialmente diversi per
fare questa operazione.
-Come spiegato in \secref{sec:file_filesystem} l'accesso al contenuto di
-un file su disco avviene attraverso il suo inode, e il nome che si trova in
-una directory è solo una etichetta associata ad un puntatore a che fa
+Come spiegato in \secref{sec:file_filesystem} l'accesso al contenuto di un
+file su disco avviene attraverso il suo inode\index{inode}, e il nome che si
+trova in una directory è solo una etichetta associata ad un puntatore a che fa
riferimento al suddetto inode.
Questo significa che la realizzazione di un link è immediata in quanto uno
\bodydesc{La funzione restituisce zero in caso di successo e -1 per un
errore, nel qual caso la variabile \var{errno} restituisce i valori:
\begin{errlist}
- \item[\macro{EPERM}] il filesystem che contiene \param{newpath} non supporta i
- link simbolici.
+ \item[\macro{EPERM}] il filesystem che contiene \param{newpath} non supporta
+ i link simbolici.
\item[\macro{ENOENT}] una componente di \param{newpath} non esiste o
\param{oldpath} è una stringa vuota.
\item[\macro{EEXIST}] esiste già un file \param{newpath}.
specificati dalle variabili \var{owner} e \var{group}.
\bodydesc{Le funzioni restituiscono zero in caso di successo e -1 per
- un errore, in caso di errore \texttt{errno} viene settato ai valori:
+ un errore, in caso di errore \var{errno} viene settato ai valori:
\begin{errlist}
\item[\macro{EPERM}] L'\textit{effective user id} non corrisponde a quello
del proprietario del file o non è zero, o utente e gruppo non sono validi
di lavoro corrente, ha anche una directory radice, che è la directory che per
il processo costituisce la radice dell'albero dei file e rispetto alla quale
vengono risolti i pathname assoluti (si ricordi quanto detto in
-\secref{sec:file_file_struct})
-
+\secref{sec:file_organization}).
La radice viene eredidata dal padre per ogni processo figlio; come si può
vedere da \figref{fig:proc_task_struct} è tenuta nella struttura
\type{fs\_struct} insieme alla directory di lavoro corrente e alla
\var{umask}, e quindi di norma coincide con la \file{/} del sistema.
-
-
In certe situazioni però per motivi di sicurezza non si vuole che un processo
possa accedere a tutto il filesystem; per questo si può cambiare la directory
radice con la funzione \func{chroot}, il cui prototipo è:
\begin{prototype}{unistd.h}{int chroot(const char *path)}
Cambia la directory radice del processo a quella specificata da
- \param{path}..
+ \param{path}.
\bodydesc{La funzione restituisce zero in caso di successo e -1 per
- un errore, in caso di errore \texttt{errno} viene settato ai valori:
+ un errore, in caso di errore \var{errno} viene settato ai valori:
\begin{errlist}
\item[\macro{EPERM}] L'\textit{effective user id} non è zero.
\end{errlist}
\macro{ENOMEM}, \macro{ENOTDIR}, \macro{EACCES}, \macro{ELOOP};
\macro{EROFS} e \macro{EIO}.}
\end{prototype}
-
-
-
-
-
-un caso tipico è quello di un server
-ftp che dovrebbe limitarsi
-
-
-Il sistema però consente di cambiare questa directory con la funzione
-\func{chroot}
+\noindent in questo modo la directory radice del processo diventerà
+\param{path} (che ovviamente deve esistere) ed ogni pathname assoluto sarà
+risolto a partire da essa, rendendo impossibile accedere alla parte di albero
+sovrastante; si ha cioè quella che viene chiamata una \textit{chroot jail}.
+
+Solo l'amministratore può usare questa funzione, e la nuova radice, per quanto
+detto in \secref{sec:proc_fork}, sarà ereditata da tutti i processi figli. Si
+tenga presente che la funzione non cambia la directory di lavoro corrente, che
+potrebbe restare fuori dalla \textit{chroot jail}.
+
+Un caso tipico di uso di \func{chroot} è quello di un server ftp, in questo
+caso infatti si vuole che il server veda solo i file che deve trasferire, per
+cui in genere si una \textit{chroot jail} alla 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.
%%% Local Variables:
projects / gapil.git / blobdiff