Revisione unlink e analoghe, trattata exit_group.

diff --git a/filedir.tex b/filedir.tex
index 0c4f94d578866dbaede4cb701c64c33466eba133..ec7ad75218655b5f223b2452dfd51ad3c0a662e2 100644 (file)
--- a/filedir.tex
+++ b/filedir.tex
@@ -1620,7 +1620,30 @@ ma si limita ad inserire il \textit{pathname} nel collegamento
 simbolico. Pertanto un collegamento simbolico può anche riferirsi ad un file
 che non esiste ed in questo caso si ha quello che viene chiamato un
 \itindex{dangling~link} \textit{dangling link}, letteralmente un
 simbolico. Pertanto un collegamento simbolico può anche riferirsi ad un file
 che non esiste ed in questo caso si ha quello che viene chiamato un
 \itindex{dangling~link} \textit{dangling link}, letteralmente un

-\index{collegamento!ciondolante} ``\textsl{collegamento ciondolante}''.
+\index{collegamento!ciondolante} ``\textsl{collegamento ciondolante}''. Ad
+esempio possiamo usare il comando \cmd{ln} per creare un collegamento
+simbolico nella nostra directory con:
+\begin{Console}
+piccardi@hain:~/gapil$ \textbf{ln -s /tmp/tmp_file symlink}
+\end{Console}
+%$
+e questo avrà successo anche se \file{/tmp/tmp\_file} non esiste:
+\begin{Console}
+piccardi@hain:~/gapil$ \textbf{ls symlink}
+symlink
+\end{Console}
+%$
+ma questo può generare confusione, perché accedendo in lettura a
+\file{symlink}, ad esempio con \cmd{cat}, otterremmo:
+\begin{Console}
+piccardi@hain:~/gapil$ \textbf{cat symlink}
+cat: symlink: No such file or directory
+\end{Console}
+%$
+con un errore che può sembrare sbagliato, dato che \cmd{ls} ci ha mostrato in
+prcedenza l'esistenza di \file{symlink}. Se invece andassimo a scrivere su
+\file{symlink}, l'effetto sarebbe quello di ottenere la creazione di
+\file{/tmp/tmp\_file} (che a quel punto verrebbe creato) senza errori.

 
 Come accennato i collegamenti simbolici sono risolti automaticamente dal
 kernel all'invocazione delle varie \textit{system call}. In
 
 Come accennato i collegamenti simbolici sono risolti automaticamente dal
 kernel all'invocazione delle varie \textit{system call}. In


@@ -1673,6 +1696,13 @@ funzione che restituisce il file descriptor (normalmente la \func{open}, vedi
 sez.~\ref{sec:file_open_close}) e tutte le operazioni seguenti fanno
 riferimento solo a quest'ultimo.
 
 sez.~\ref{sec:file_open_close}) e tutte le operazioni seguenti fanno
 riferimento solo a quest'ultimo.
 

+Si tenga anche presente che a partire dal kernel 3.16, se si abilita la
+funzionalità dei \textit{protected symlinks} (attiva di default in tutte le
+distribuzioni più recenti) la risoluzione dei nomi attraverso un collegamento
+simbolico può fallire per una serie di restrizione di sicurezza agguntive
+imposte dal meccanismo (si consulti sez.~\ref{sec:procadv_security_misc} per i
+dettagli del meccanismo).
+

 Dato che, come indicato in tab.~\ref{tab:file_symb_effect}, funzioni come la
 \func{open} seguono i collegamenti simbolici, occorrono funzioni apposite per
 accedere alle informazioni del collegamento invece che a quelle del file a cui
 Dato che, come indicato in tab.~\ref{tab:file_symb_effect}, funzioni come la
 \func{open} seguono i collegamenti simbolici, occorrono funzioni apposite per
 accedere alle informazioni del collegamento invece che a quelle del file a cui


@@ -1681,30 +1711,32 @@ simbolico si usa la funzione di sistema \funcd{readlink}, il cui prototipo è:
 
 \begin{funcproto}{
 \fhead{unistd.h}
 
 \begin{funcproto}{
 \fhead{unistd.h}

-\fdecl{int readlink(const char *path, char *buff, size\_t size)}
+\fdecl{int readlink(const char *pathname, char *buff, size\_t size)}

 \fdesc{Legge il contenuto di un collegamento simbolico.} 
 }
 {La funzione ritorna il numero di caratteri letti dentro \param{buff} in caso
   di successo e $-1$ per un errore,  nel qual caso \var{errno} assumerà uno
   dei valori:
   \begin{errlist}
 \fdesc{Legge il contenuto di un collegamento simbolico.} 
 }
 {La funzione ritorna il numero di caratteri letti dentro \param{buff} in caso
   di successo e $-1$ per un errore,  nel qual caso \var{errno} assumerà uno
   dei valori:
   \begin{errlist}

-  \item[\errcode{EINVAL}] \param{path} non è un collegamento simbolico
+  \item[\errcode{EACCES}] non si hanno i permessi di attraversamento di una
+    delle directory del pathname
+  \item[\errcode{EINVAL}] \param{pathname} non è un collegamento simbolico

     o \param{size} non è positiva.
     o \param{size} non è positiva.

-  \end{errlist} ed inoltre \errval{EACCES}, \errval{EFAULT}, \errval{EIO},
-  \errval{ELOOP}, \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM} e
-  \errval{ENOTDIR} nel loro significato generico.}
+  \end{errlist} ed inoltre \errval{EFAULT}, \errval{EIO}, \errval{ELOOP},
+  \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM} e \errval{ENOTDIR}
+  nel loro significato generico.}

 \end{funcproto}
 
 La funzione legge il \textit{pathname} a cui fa riferimento il collegamento
 \end{funcproto}
 
 La funzione legge il \textit{pathname} a cui fa riferimento il collegamento

-simbolico indicato dall'argomento \param{path} scrivendolo sul
-buffer \param{buff} di dimensione \param{size}. Si tenga presente che la
-funzione non termina la stringa con un carattere nullo e che se questa è
-troppo lunga la tronca alla dimensione specificata da \param{size} per evitare
-di sovrascrivere oltre le dimensioni del buffer.
+simbolico indicato dall'argomento \param{pathname} scrivendolo sul buffer
+\param{buff} di dimensione \param{size}. Si tenga presente che la funzione non
+termina la stringa con un carattere nullo e che se questa è troppo lunga la
+tronca alla dimensione specificata da \param{size} per evitare di scrivere
+dati oltre le dimensioni del buffer.

 
 \begin{figure}[htb]
   \centering
 
 \begin{figure}[htb]
   \centering

-  \includegraphics[width=7.0cm]{img/link_loop}
+  \includegraphics[width=8cm]{img/link_loop}

   \caption{Esempio di loop nel filesystem creato con un collegamento
     simbolico.}
   \label{fig:file_link_loop}
   \caption{Esempio di loop nel filesystem creato con un collegamento
     simbolico.}
   \label{fig:file_link_loop}


@@ -1715,57 +1747,30 @@ alle directory è che questi possono creare dei \textit{loop} nella risoluzione
 dei nomi che non possono essere eliminati facilmente. Invece è sempre
 possibile, ed in genere anche molto utile, creare un collegamento simbolico ad
 una directory, anche se in questo caso si potranno ottenere anche dei
 dei nomi che non possono essere eliminati facilmente. Invece è sempre
 possibile, ed in genere anche molto utile, creare un collegamento simbolico ad
 una directory, anche se in questo caso si potranno ottenere anche dei

-\textit{loop}. La situazione è illustrata in fig.~\ref{fig:file_link_loop},
-che riporta la struttura della directory \file{/boot}. Come si vede si è
-creato al suo interno un collegamento simbolico che punta di nuovo a
+\textit{loop}.
+
+La situazione è illustrata in fig.~\ref{fig:file_link_loop}, che riporta la
+struttura della directory \file{/boot}. Come si vede si è creato al suo
+interno un collegamento simbolico che punta di nuovo a

 \file{/boot}.\footnote{il \textit{loop} mostrato in
 \file{/boot}.\footnote{il \textit{loop} mostrato in

-  fig.~\ref{fig:file_link_loop} è stato usato per poter permettere a
-  \cmd{grub} (un bootloader in grado di leggere direttamente da vari
-  filesystem il file da lanciare come sistema operativo) di vedere i file
-  contenuti nella directory \file{/boot} con lo stesso \textit{pathname} con
-  cui verrebbero visti dal sistema operativo, anche se essi si trovano, come
-  accade spesso, su una partizione separata (che \cmd{grub} all'avvio vedrebbe 
-  come \file{/}).}
-
-Questo però può causare problemi per tutti quei programmi che effettuano la
-scansione di una directory senza tener conto dei collegamenti simbolici, ad
-esempio se lanciassimo un comando del tipo \code{grep -r linux *}, il loop
-nella directory porterebbe il comando ad esaminare \file{/boot},
-\file{/boot/boot}, \file{/boot/boot/boot} e così via.
+  fig.~\ref{fig:file_link_loop} è stato usato per poter permettere a al
+  \textit{bootloader} \cmd{grub} di vedere i file contenuti nella directory
+  \file{/boot} con lo stesso \textit{pathname} con cui verrebbero visti dal
+  sistema operativo, anche quando si trovano, come accade spesso, su una
+  partizione separata (che \cmd{grub} all'avvio vedrebbe come \file{/}).} Un
+\textit{loop} di di questo tipo però può causare problemi per tutti i
+programmi che effettuano la scansione di una directory, e ad esempio se
+lanciassimo un comando come \code{grep -r linux *}, il \textit{loop} nella
+directory porterebbe ad esaminare \file{/boot}, \file{/boot/boot},
+\file{/boot/boot/boot} e così via.

 
 Per questo motivo il kernel e le librerie prevedono che nella risoluzione di
 un \textit{pathname} possano essere seguiti fino ad un certo numero massimo di
 collegamenti simbolici, il cui valore limite è specificato dalla costante
 
 Per questo motivo il kernel e le librerie prevedono che nella risoluzione di
 un \textit{pathname} possano essere seguiti fino ad un certo numero massimo di
 collegamenti simbolici, il cui valore limite è specificato dalla costante

-\constd{MAXSYMLINKS}. Qualora questo limite venga superato viene generato un
-errore ed \var{errno} viene impostata al valore \errcode{ELOOP}, che nella
-quasi totalità dei casi indica appunto che si è creato un collegamento
-simbolico che fa riferimento ad una directory del suo stesso
-\textit{pathname}.
-
-Un altro punto da tenere sempre presente è che, come abbiamo accennato, un
-collegamento simbolico può fare riferimento anche ad un file che non esiste;
-ad esempio possiamo usare il comando \cmd{ln} per creare un collegamento
-simbolico nella nostra directory con:
-\begin{Console}
-piccardi@hain:~/gapil$ \textbf{ln -s /tmp/tmp_file symlink}
-\end{Console}
-%$
-e questo avrà successo anche se \file{/tmp/tmp\_file} non esiste:
-\begin{Console}
-piccardi@hain:~/gapil$ \textbf{ls symlink}
-symlink
-\end{Console}
-%$
-ma questo può generare confusione, perché accedendo in sola lettura a
-\file{symlink}, ad esempio con \cmd{cat}, otterremmo un errore:
-\begin{Console}
-piccardi@hain:~/gapil$ \textbf{cat symlink}
-cat: symlink: No such file or directory
-\end{Console}
-%$
-con un errore che può sembrare sbagliato, dato che \cmd{ls} ci ha mostrato
-l'esistenza di \file{symlink}. Se invece scrivessimo su \file{symlink}
-otterremmo la creazione di \file{/tmp/tmp\_file} senza errori.
+\constd{MAXSYMLINKS}. Se il limite viene superato si ha un errore ed
+\var{errno} viene impostata al valore \errcode{ELOOP}, che nella quasi
+totalità dei casi indica appunto che si è creato un collegamento simbolico che
+fa riferimento ad una directory del suo stesso \textit{pathname}.

 
 
 \itindend{symbolic~link}
 
 
 \itindend{symbolic~link}


@@ -1792,13 +1797,16 @@ nome come si può notare ha poco a che fare con il concetto di rimozione, è
   nel qual caso \var{errno} assumerà uno dei valori:\footnotemark  
   \begin{errlist}
   \item[\errcode{EACCES}] non si ha il permesso di scrittura sulla directory
   nel qual caso \var{errno} assumerà uno dei valori:\footnotemark  
   \begin{errlist}
   \item[\errcode{EACCES}] non si ha il permesso di scrittura sulla directory

-    che contiene \param{pathname} o di attraversamento di una delle directory
-    superiori. 
+    che contiene \param{pathname} o quello di attraversamento per una delle
+    directory superiori.
+  \item[\errcode{EBUSY}] \param{pathname} non può essere rimosso perché è in
+    uso da parte del sistema (in particolare per i cosidetti \textit{silly
+      renames} di NFS).

   \item[\errcode{EISDIR}] \param{pathname} si riferisce ad una
     directory.
   \item[\errcode{EPERM}] il filesystem non consente l'operazione, o la
     directory che contiene \param{pathname} ha lo \textit{sticky bit} e non si
   \item[\errcode{EISDIR}] \param{pathname} si riferisce ad una
     directory.
   \item[\errcode{EPERM}] il filesystem non consente l'operazione, o la
     directory che contiene \param{pathname} ha lo \textit{sticky bit} e non si

-    è il proprietario o non si hanno privilegi amministrativi. 
+    è il proprietario del file o non si hanno privilegi amministrativi. 

   \end{errlist} ed inoltre \errval{EFAULT}, \errval{EIO}, \errval{ELOOP},
   \errval{ENOENT}, \errval{ENOMEM}, \errval{ENOTDIR}, \errval{EROFS} nel loro
   significato generico.}
   \end{errlist} ed inoltre \errval{EFAULT}, \errval{EIO}, \errval{ELOOP},
   \errval{ENOENT}, \errval{ENOMEM}, \errval{ENOTDIR}, \errval{EROFS} nel loro
   significato generico.}


@@ -1815,55 +1823,60 @@ nome come si può notare ha poco a che fare con il concetto di rimozione, è
 
 La funzione elimina il nome specificato dall'argomento \param{pathname} nella
 directory che lo contiene e decrementa il numero di riferimenti nel relativo
 
 La funzione elimina il nome specificato dall'argomento \param{pathname} nella
 directory che lo contiene e decrementa il numero di riferimenti nel relativo

-\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, \textit{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.
+\textit{inode}; come per \func{link} queste due operazioni sono effettuate
+all'interno della \textit{system call} in maniera atomica rispetto ai
+processi.
+
+Si ricordi che, anche se se ne è rimosso il nome, un file viene realmente
+cancellato soltanto quando il numero di collegamenti mantenuto
+nell'\textit{inode} diventa nullo; solo allora l'\textit{inode} viene
+disallocato e lo spazio che il file occupava sul disco viene liberato.
+
+Si tenga presente comunque che a questo si aggiunge sempre un'ulteriore
+condizione e cioè che non ci siano processi che stiano ancora lavorando sul il
+file. Come vedremo in sez.~\ref{sec:file_unix_interface} il kernel una tabella
+di tutti file aperti da ciascun processo, che a sua volta contiene i
+riferimenti agli \textit{inode} ad essi relativi. Prima di procedere alla
+cancellazione dello spazio occupato su disco dal contenuto di un file il
+kernel controlla anche questa tabella, per verificare che anche in essa non ci
+sia più nessun riferimento all'\textit{inode} in questione, assicurandosi con
+questo che nessun processo stia ancora usando il file.
+
+Nel caso di socket, \textit{fifo} o file di dispositivo la funzione rimuove il
+nome, e come per i file normali i processi che hanno aperto uno di questi
+oggetti possono continuare ad utilizzarli.  Nel caso di cancellazione di un
+\textit{link} simbolico, che consiste solo nel rimando ad un altro file,
+questo viene immediatamente eliminato e non sarà più utilizzabile. 

 
 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
 il diritto di esecuzione/attraversamento sulla directory che la contiene
 (affronteremo in dettaglio l'argomento dei permessi di file e directory in
 
 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
 il diritto di esecuzione/attraversamento sulla directory che la contiene
 (affronteremo in dettaglio l'argomento dei permessi di file e directory in

-sez.~\ref{sec:file_access_control}). Se inoltre lo \textit{sticky bit} (vedi
-sez.~\ref{sec:file_special_perm}) è impostato occorrerà anche essere
-proprietari del file o proprietari della directory o avere i privilegi di
-amministratore.
-
-Si ricordi inoltre che anche se se ne è rimosso il nome da una directory, un
-file non viene eliminato dal disco fintanto che tutti i riferimenti ad esso
-sono stati cancellati: solo quando il numero di collegamenti mantenuto
-nell'\textit{inode} diventa nullo, questo viene disallocato e lo spazio
-occupato su disco viene liberato. Si tenga presente comunque che a questo si
-aggiunge sempre un'ulteriore condizione e cioè che non ci siano processi che
-abbiano il suddetto file aperto.\footnote{come vedremo in
-  sez.~\ref{sec:file_unix_interface} il kernel mantiene anche una tabella dei
-  file aperti nei vari processi, che a sua volta contiene i riferimenti agli
-  \textit{inode} ad essi relativi; prima di procedere alla cancellazione dello
-  spazio occupato su disco dal contenuto di un file il kernel controlla anche
-  questa tabella, per verificare che anche in essa non ci sia più nessun
-  riferimento all'\textit{inode} in questione.}
-
-Questa caratteristica del sistema può essere usata per essere sicuri di non
-lasciare file temporanei su disco in caso di crash di un programma. La tecnica
-è quella di aprire un nuovo file e chiamare \func{unlink} su di esso subito
+sez.~\ref{sec:file_access_control}). Se inoltre per la directory è impostato
+lo \textit{sticky bit} (vedi sez.~\ref{sec:file_special_perm}), occorrerà
+anche essere proprietari del file o proprietari della directory o avere i
+privilegi di amministratore.
+
+Questa caratteristica del sistema, che consente di usare un file anche se lo
+si è ``cancellato'', può essere usata per essere sicuri di non lasciare file
+temporanei su disco in caso di uscita imprevista di un programma. La tecnica è
+quella di aprire un nuovo file e chiamare \func{unlink} su di esso subito

 dopo, in questo modo il contenuto del file sarà sempre disponibile all'interno
 del processo attraverso il suo file descriptor (vedi sez.~\ref{sec:file_fd}),
 dopo, in questo modo il contenuto del file sarà sempre disponibile all'interno
 del processo attraverso il suo file descriptor (vedi sez.~\ref{sec:file_fd}),

-ma non ne resta traccia in nessuna directory, e lo spazio occupato su disco
-viene immediatamente rilasciato alla conclusione del processo, quando tutti i
-file vengono chiusi.
+ma non ne resterà traccia in nessuna directory, inoltre lo spazio occupato su
+disco verrà immediatamente rilasciato alla conclusione del processo, quando
+tutti i file vengono chiusi.

 
 Al contrario di quanto avviene con altri Unix, in Linux non è possibile usare
 
 Al contrario di quanto avviene con altri Unix, in Linux non è possibile usare

-la funzione \func{unlink} sulle directory, nel qual caso si otterrebbe un
+la funzione \func{unlink} sulle directory, che in tal caso fallisce con un

 errore di \errcode{EISDIR}. Per cancellare una directory si deve usare la
 apposita funzione di sistema \func{rmdir} (che vedremo in
 sez.~\ref{sec:file_dir_creat_rem}), oppure la funzione \func{remove}.
 errore di \errcode{EISDIR}. Per cancellare una directory si deve usare la
 apposita funzione di sistema \func{rmdir} (che vedremo in
 sez.~\ref{sec:file_dir_creat_rem}), oppure la funzione \func{remove}.

+

 Quest'ultima è la funzione prevista dallo standard ANSI C per effettuare una
 Quest'ultima è la funzione prevista dallo standard ANSI C per effettuare una

-cancellazione generica di un file o di una directory e funziona anche per i
-sistemi operativo che non supportano gli \textit{hard link}. Nei sistemi
-unix-like \funcd{remove} è equivalente ad usare in maniera trasparente
+cancellazione generica di un file o di una directory e viene usata in generale
+anche per i sistemi operativi che non supportano gli \textit{hard link}. Nei
+sistemi unix-like \funcd{remove} è equivalente ad usare in maniera trasparente

 \func{unlink} per i file ed \func{rmdir} per le directory; il suo prototipo è:
 
 \begin{funcproto}{
 \func{unlink} per i file ed \func{rmdir} per le directory; il suo prototipo è:
 
 \begin{funcproto}{


@@ -1877,13 +1890,15 @@ unix-like \funcd{remove} è equivalente ad usare in maniera trasparente
   \func{unlink} e \func{rmdir}.}
 \end{funcproto}
 
   \func{unlink} e \func{rmdir}.}
 \end{funcproto}
 

-La funzione utilizza la funzione \func{unlink} per cancellare i file e la
-funzione \func{rmdir} (vedi sez.~\ref{sec:file_dir_creat_rem}) per cancellare
-le directory.\footnote{questo vale usando la \acr{glibc}; nella \acr{libc4} e
-  nella \acr{libc5} la funzione \func{remove} era un semplice alias alla
-  funzione \func{unlink} e quindi non poteva essere usata per le directory.}
-Si tenga presente che per alcune implementazioni del protocollo NFS utilizzare
-questa funzione può comportare la scomparsa di file ancora in uso.
+La funzione utilizza la funzione \func{unlink} per cancellare i file (e si
+applica anche a link simbolici, socket, \textit{fifo} e file di dispostivo) e
+la funzione \func{rmdir} (vedi sez.~\ref{sec:file_dir_creat_rem}) per
+cancellare le directory.\footnote{questo vale usando la \acr{glibc}; nella
+  \acr{libc4} e nella \acr{libc5} la funzione \func{remove} era un semplice
+  alias alla funzione \func{unlink} e quindi non poteva essere usata per le
+  directory.}  Si tenga presente che per alcune limitazioni del protocollo
+NFS, utilizzare questa funzione su file che usano questo filesystem di rete
+può comportare la scomparsa di file ancora in uso.

 
 Infine per cambiare nome ad un file o a una directory si usa la funzione di
 sistema \funcd{rename},\footnote{la funzione è definita dallo standard ANSI C,
 
 Infine per cambiare nome ad un file o a una directory si usa la funzione di
 sistema \funcd{rename},\footnote{la funzione è definita dallo standard ANSI C,


@@ -1898,9 +1913,9 @@ sistema \funcd{rename},\footnote{la funzione è definita dallo standard ANSI C,
 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
   nel qual caso \var{errno} assumerà uno dei valori: 
   \begin{errlist}
 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
   nel qual caso \var{errno} assumerà uno dei valori: 
   \begin{errlist}

-  \item[\errcode{EACCESS}] non c'è permesso di scrivere nelle directory
+  \item[\errcode{EACCESS}] manca il permesso di scrittura sulle directory

     contenenti \param{oldpath} e \param{newpath} o di attraversare 
     contenenti \param{oldpath} e \param{newpath} o di attraversare 

-    quelle dei loro \textit{pathname} o di scrivere su \param{newpath}
+    il 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 directory di lavoro o come radice) o del
     se questa è una directory.
   \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

diff --git a/procadv.tex b/procadv.tex
index 2859e8b0f6529864d8c424edae9e385e6e23874a..0b9dd0aadcebf48606433535c58cff1c67e8db78 100644 (file)
--- a/procadv.tex
+++ b/procadv.tex
@@ -2013,26 +2013,37 @@ funzione.
 
 Il \textit{secure computing mode} è un meccanismo ideato per fornire un
 supporto per l'esecuzione di codice esterno non fidato e non verificabile a
 
 Il \textit{secure computing mode} è un meccanismo ideato per fornire un
 supporto per l'esecuzione di codice esterno non fidato e non verificabile a

-scopo di calcolo. L'idea era quello di poter vendere la capacità di calcolo
-della propria macchina ad un qualche servizio di calcolo distribuito, senza
-comprometterne la sicurezza eseguendo codice non sotto il proprio controllo.
-
-Nella prima versione del meccanismo, introdotto con il kernel 2.6.23 e
-disponibile solo avendo è abilitato il supporto nel kernel con
-\texttt{CONFIG\_SECCOMP}, questo veniva attivato con \func{prctl} indicando
-l'opzione \const{PR\_SET\_SECCOMP}, che all'epoca supportava soltanto l'uso
-del valore \const{SECCOMP\_MODE\_STRICT} per \param{arg2}.
-
-Una volta abilitato il \textit{secure computing mode} in questa modalità (in
-seguito denominata \textit{strict mode}) il processo o il \textit{thread}
-chiamante potrà utilizzare soltanto un insieme estremamente limitato di
-\textit{system call}: \func{read}, \func{write}, \func{\_exit} e
-\funcm{sigreturn}. Ogni altra \textit{system call} porterà all'emissione di un
-\signal{SIGKILL} (vedi sez.~\ref{sec:sig_termination}). In questa modalità di
-utilizzo i dati vengono letti o scritti grazie ad un socket o una
-\textit{pipe}, creati prima di lanciare il processo che eseguirà il codice non
-fidato, e per evitare problemi di sicurezza non saranno possibili altre
-operazioni se non quelle citate.
+scopo di calcolo. L'idea era quella di disporre di una modalità di esecuzione
+dei programmi che permettesse di vendere la capacità di calcolo della propria
+macchina ad un qualche servizio di calcolo distribuito, senza comprometterne
+la sicurezza eseguendo codice non sotto il proprio controllo.
+
+La prima versione del meccanismo è stata introdotta con il kernel
+2.6.23,\footnote{e disponibile solo avendo abilitato il supporto nel kernel
+  con l'opzione di configurazione \texttt{CONFIG\_SECCOMP}.} è molto semplice,
+il \textit{secure computing mode} viene attivato con \func{prctl} usando
+l'opzione \const{PR\_SET\_SECCOMP}, ed indicando \const{SECCOMP\_MODE\_STRICT}
+come valore per \param{arg2} (all'epoca unico valore possibile).  Una volta
+abilitato in questa modalità (in seguito denominata \textit{strict mode}) il
+processo o il \textit{thread} chiamante potrà utilizzare soltanto un insieme
+estremamente limitato di \textit{system call}: \func{read}, \func{write},
+\func{\_exit} e \funcm{sigreturn}; l'esecuzione di qualsiasi altra
+\textit{system call} comporta l'emissione di un \signal{SIGKILL} e conseguente
+terminazione immediata del processo.
+
+Si tenga presente che in questo caso, con versioni recenti della \acr{glibc}
+(il comportamento è stato introdotto con la 2.3), diventa impossibile usare
+anche \func{\_exit} in \textit{strict mode}, in quanto questa funzione viene
+intercettata ed al suo posto viene chiamata \func{exit\_group} (vedi
+sez.~\ref{sec:pthread_management}) che non è consentita e comporta un
+\signal{SIGKILL}.
+
+Si tenga presente che, non essendo \func{execve} fra le funzioni permesse, per
+poter eseguire un programma terzo essendo in \textit{strict mode} questo dovrà
+essere fornito in una forma di codice interpretabile fornito attraverso un
+socket o una \textit{pipe}, creati prima di lanciare il processo che eseguirà
+il codice non fidato. 
+

 
 
 % TODO a partire dal kernel 3.5 è stato introdotto la possibilità di usare un
 
 
 % TODO a partire dal kernel 3.5 è stato introdotto la possibilità di usare un

diff --git a/thread.tex b/thread.tex
index 6dce4cc19587a106d79e5cab679e8237f6ebc3c8..d5634775cd3a51a75702e54ffd845946960a20df 100644 (file)
--- a/thread.tex
+++ b/thread.tex
@@ -116,6 +116,24 @@ della \acr{glibc}.
 \label{sec:pthread_management}
 
 
 \label{sec:pthread_management}
 
 

+Benché la funzione sia utilizzabile anche con i processi, tanto che a partire
+dalla versione 2.3 della \acr{glibc} viene a sostituire \func{\_exit} (tramite
+un \textit{wrapper} che la utilizza al suo posto) per la terminazione di tutti
+i \textit{thread} di un processo si deve usare la funzione di sistema
+\func{exit\_group}, il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{linux/unistd.h}
+\fdecl{void exit\_group(int status)}
+\fdesc{Termina tutti i \textit{thread} di un processo.} 
+}
+{La funzione non ha errori e pertanto non ritorna.}
+\end{funcproto}
+
+La funzione è sostanzialmente identica alla \textit{system call} \func{\_exit}
+ma a differenza di quest'ultima, che termina solo il \textit{thread}
+chiamante, termina tutti \textit{thread} del processo. 
+

 
 \section{La sincronizzazione dei \textit{thread}}
 \label{sec:pthread_sync}
 
 \section{La sincronizzazione dei \textit{thread}}
 \label{sec:pthread_sync}