X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=prochand.tex;h=6e99c3cd56cd21ca618899c856e23edb9c77df06;hp=ef6c064a0552dcbfa657378321a7ce663b38fbfb;hb=0ab3f419ed7721862f3a3bc012d681fbefdf0cfa;hpb=682ed599d14547e67301b35fba26c3a1cf9a39f7

diff --git a/prochand.tex b/prochand.tex
index ef6c064..6e99c3c 100644
--- a/prochand.tex
+++ b/prochand.tex
@@ -8,16 +8,20 @@ base per l'allocazione e l'uso delle risorse del sistema.
 Nel precedente capitolo abbiamo visto come funziona un singolo processo, in
 questo capitolo affronteremo i dettagli della creazione e della distruzione
 dei processi, della gestione dei loro attributi e privilegi, e di tutte le
-funzioni a questo connesse.
+funzioni a questo connesse. Infine nella sezione finale affronteremo alcune
+problematiche generiche della programmazione in ambiente multitasking.
+
 
 
 \section{Introduzione}
 \label{sec:proc_gen}
 
 Partiremo con una introduzione generale ai concetti che stanno alla base della
-gestione dei processi in unix. Introdurremo in questa sezione l'architettura
-della gestione dei processi e le sue principali caratteristiche, e daremo una
-panoramica sull'uso delle principali funzioni per la gestione dei processi.
+gestione dei processi in un sistema unix-like. Introdurremo in questa sezione
+l'architettura della gestione dei processi e le sue principali
+caratteristiche, e daremo una panoramica sull'uso delle principali funzioni
+per la gestione dei processi.
+
 
 \subsection{La gerarchia dei processi}
 \label{sec:proc_hierarchy}
@@ -183,7 +187,6 @@ Tutti i processi inoltre memorizzano anche il \acr{pid} del genitore da cui
 sono stati creati, questo viene chiamato in genere \acr{ppid} (da
 \textit{parent process id}).  Questi due identificativi possono essere
 ottenuti da programma usando le funzioni:
-
 \begin{functions}
 \headdecl{sys/types.h}
 \headdecl{unistd.h}
@@ -207,7 +210,7 @@ Tutti i processi figli dello stesso processo padre sono detti
 \textit{sibling}, questa è una delle relazioni usate nel \textsl{controllo di
   sessione}, in cui si raggruppano i processi creati su uno stesso terminale,
 o relativi allo stesso login. Torneremo su questo argomento in dettaglio in
-\secref{cap:session}, dove esamineremo gli altri identificativi associati ad
+\secref{cha:session}, dove esamineremo gli altri identificativi associati ad
 un processo e le varie relazioni fra processi utilizzate per definire una
 sessione.
 
@@ -215,8 +218,8 @@ Oltre al \acr{pid} e al \acr{ppid}, e a quelli usati per il controllo di
 sessione, ad ogni processo sono associati altri identificatori, usati per il
 controllo di accesso, che servono per determinare se il processo può o meno
 eseguire le operazioni richieste, a seconda dei privilegi e dell'identità di
-chi lo ha posto in esecuzione; su questi torneremo in dettaglii più avanti in
-\secref{sec:proc_perm}.
+chi lo ha posto in esecuzione; su questi torneremo in dettagli più avanti in
+\secref{sec:proc_perms}.
 
 
 \subsection{La funzione \func{fork}}
@@ -227,7 +230,6 @@ processi: come si 
 attraverso l'uso di questa funzione, essa quindi riveste un ruolo centrale
 tutte le volte che si devono scrivere programmi che usano il multitasking.  Il
 prototipo della funzione è:
-
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{unistd.h} 
@@ -377,6 +379,8 @@ periodo di attesa.
 Se eseguiamo il comando senza specificare attese (come si può notare in
 \texttt{\small 17--19} i valori di default specificano di non attendere),
 otterremo come output sul terminale:
+
+\footnotesize
 \begin{verbatim}
 [piccardi@selidor sources]$ ./forktest 3
 Process 1963: forking 3 child
@@ -393,6 +397,7 @@ Child 3, parent 1963, exiting
 Spawned 3 child, pid 1966 
 Go to next child 
 \end{verbatim} %$
+\normalsize
 
 Esaminiamo questo risultato: una prima conclusione che si può trarre è non si
 può dire quale processo fra il padre ed il figlio venga eseguito per
@@ -431,6 +436,8 @@ Un secondo aspetto molto importante nella creazione dei processi figli 
 quello dell'interazione dei vari processi con i file; per illustrarlo meglio
 proviamo a redirigere su un file l'output del nostro programma di test, quello
 che otterremo è:
+
+\footnotesize
 \begin{verbatim}
 [piccardi@selidor sources]$ ./forktest 3 > output
 [piccardi@selidor sources]$ cat output
@@ -457,6 +464,7 @@ Go to next child
 Spawned 3 child, pid 1970 
 Go to next child 
 \end{verbatim}
+\normalsize
 che come si vede è completamente diverso da quanto ottenevamo sul terminale.
 
 Il comportamento delle varie funzioni di interfaccia con i file è analizzato
@@ -490,10 +498,9 @@ Quello che succede 
 lo stesso avviene anche per tutti i figli; la funzione \func{fork} infatti ha
 la caratteristica di duplicare (allo stesso modo in cui lo fa la funzione
 \func{dup}, trattata in \secref{sec:file_dup}) nei figli tutti i file
-descriptor aperti nel padre, il che comporta che padre e figli condividono
-le stesse voci della file table (per la spiegazione di questi termini si veda
-\secref{sec:file_sharing} e referenza a figura da fare) e quindi anche
-l'offset corrente nel file.
+descriptor aperti nel padre, il che comporta che padre e figli condividono le
+stesse voci della file table (per la spiegazione di questi termini si veda
+\secref{sec:file_sharing}) e quindi anche l'offset corrente nel file.
 
 In questo modo se un processo scrive sul file aggiornerà l'offset sulla file
 table, e tutti gli altri processi che condividono la file table vedranno il
@@ -527,11 +534,10 @@ sequenza impredicibile. Le modalit
 \end{enumerate}
 
 Oltre ai file aperti i processi figli ereditano dal padre una serie di altre
-proprietà comuni; in dettaglio avremo che dopo l'esecuzione di una \func{fork}
-padre e figlio avranno in comune:
+proprietà; la lista dettagliata delle proprietà che padre e figlio hanno in
+comune dopo l'esecuzione di una \func{fork} è la seguente:
 \begin{itemize*}
-\item i file aperti (e gli eventuali flag di \textit{close-on-exec} se
-  settati).
+\item i file aperti e gli eventuali flag di \textit{close-on-exec} se settati.
 \item gli identificatori per il controllo di accesso: il \textit{real user
     id}, il \textit{real group id}, l'\textit{effective user id},
   l'\textit{effective group id} e i \textit{supplementary group id} (vedi
@@ -543,12 +549,12 @@ padre e figlio avranno in comune:
 \item la directory di lavoro e la directory radice (vedi
   \secref{sec:file_work_dir}).
 \item la maschera dei permessi di creazione (vedi \secref{sec:file_umask}).
-\item la maschera dei segnali.
+\item la maschera dei segnali bloccati e le azioni installate.
 \item i segmenti di memoria condivisa agganciati al processo. 
-\item i limiti sulle risorse
+\item i limiti sulle risorse.
 \item le variabili di ambiente (vedi \secref{sec:proc_environ}).
 \end{itemize*}
-le differenze invece sono:
+le differenze fra padre e figlio dopo la \func{fork} invece sono:
 \begin{itemize*}
 \item il valore di ritorno di \func{fork}.
 \item il \textit{process id}. 
@@ -557,7 +563,7 @@ le differenze invece sono:
 \item i valori dei tempi di esecuzione (\var{tms\_utime}, \var{tms\_stime},
   \var{tms\_cutime}, \var{tms\_uetime}) che nel figlio sono posti a zero.
 \item i \textit{file lock}, che non vengono ereditati dal figlio.
-\item gli allarmi pendenti, che per il figlio vengono cancellati.
+\item gli allarmi ed i segnali pendenti, che per il figlio vengono cancellati.
 \end{itemize*}
 
 
@@ -660,6 +666,8 @@ avr
 di terminazione.  Come verifica di questo comportamento possiamo eseguire il
 comando \cmd{forktest} imponendo a ciascun processo figlio due
 secondi di attesa prima di uscire, il risultato è:
+
+\footnotesize
 \begin{verbatim}
 [piccardi@selidor sources]$ ./forktest -c2 3
 Process 1972: forking 3 child
@@ -676,6 +684,7 @@ Go to next child
 Child 2, parent 1, exiting
 Child 1, parent 1, exiting
 \end{verbatim}
+\normalsize
 come si può notare in questo caso il processo padre si conclude prima dei
 figli, tornando alla shell, che stampa il prompt sul terminale: circa due
 secondi dopo viene stampato a video anche l'output dei tre figli che
@@ -705,6 +714,8 @@ condizione: lanciamo il comando \cmd{forktest} in background, indicando al
 processo padre di aspettare 10 secondi prima di uscire; in questo caso, usando
 \cmd{ps} sullo stesso terminale (prima dello scadere dei 10 secondi)
 otterremo:
+
+\footnotesize
 \begin{verbatim}
 [piccardi@selidor sources]$ ps T
   PID TTY      STAT   TIME COMMAND
@@ -715,6 +726,7 @@ otterremo:
   571 pts/0    Z      0:00 [forktest <defunct>]
   572 pts/0    R      0:00 ps T
 \end{verbatim} %$
+\normalsize 
 e come si vede, dato che non si è fatto nulla per riceverne lo stato di
 terminazione, i tre processi figli sono ancora presenti pur essendosi
 conclusi, con lo stato di zombie e l'indicazione che sono stati terminati.
@@ -744,7 +756,7 @@ di terminare il processo che li ha generati, in modo che \cmd{init} possa
 adottarli e provvedere a concludere la terminazione.
 
 
-\subsection{Le funzioni \texttt{wait} e  \texttt{waitpid}}
+\subsection{Le funzioni \func{wait} e  \func{waitpid}}
 \label{sec:proc_wait}
 
 Abbiamo già accennato come uno degli usi possibili delle capacità multitasking
@@ -756,7 +768,6 @@ conclusione dei vari processi figli onde evitare di riempire di
 \textit{zombie} la tabella dei processi; le funzioni deputate a questo compito
 sono sostanzialmente due, \func{wait} e \func{waitpid}. La prima, il cui
 prototipo è:
-
 \begin{functions}
 \headdecl{sys/types.h}
 \headdecl{sys/wait.h}
@@ -775,6 +786,7 @@ caso di errore; \var{errno} pu
   \item \macro{EINTR} la funzione è stata interrotta da un segnale.
   \end{errlist}
 \end{functions}
+
 è presente fin dalle prime versioni di unix; la funzione ritorna alla
 conclusione del primo figlio (o immediatamente se un figlio è già uscito). Nel
 caso un processo abbia più figli il valore di ritorno permette di identificare
@@ -791,7 +803,6 @@ che effettua lo stesso servizio, ma dispone di una serie di funzionalit
 ampie, legate anche al controllo di sessione.  Dato che è possibile ottenere
 lo stesso comportamento di \func{wait} si consiglia di utilizzare sempre
 questa funzione; il suo prototipo è:
-
 \begin{functions}
 \headdecl{sys/types.h}
 \headdecl{sys/wait.h}
@@ -816,6 +827,7 @@ base del valore specificato tramite la variabile \var{pid}, secondo lo
 specchietto riportato in \ntab:
 \begin{table}[!htb]
   \centering
+  \footnotesize
   \begin{tabular}[c]{|c|p{10cm}|}
     \hline
     \textbf{Valore} & \textbf{Significato}\\
@@ -900,7 +912,6 @@ certezza che la chiamata a \func{wait} non si bloccher
   \label{tab:proc_status_macro}
 \end{table}
 
-
 Entrambe le funzioni restituiscono lo stato di terminazione del processo
 tramite il puntatore \var{status} (se non interessa memorizzare lo stato si
 può passare un puntatore nullo). Il valore restituito da entrambe le funzioni
@@ -931,7 +942,6 @@ lettura dello stato di terminazione di un processo, analoghe a \func{wait} e
 kernel può restituire al processo padre ulteriori informazioni sulle risorse
 usate dal processo terminato e dai vari figli.  Queste funzioni, che diventano
 accessibili definendo la costante \macro{\_USE\_BSD}, sono:
-
 \begin{functions}
   \headdecl{sys/times.h} 
   \headdecl{sys/types.h} 
@@ -946,6 +956,7 @@ accessibili definendo la costante \macro{\_USE\_BSD}, sono:
   Prima versione, equivalente a \func{wait4(-1, \&status, opt, rusage)} è
   ormai deprecata in favore di \func{wait4}.
 \end{functions}
+\noindent 
 la struttura \type{rusage} è definita in \file{sys/resource.h}, e viene
 utilizzata anche dalla funzione \func{getrusage} per ottenere le risorse di
 sistema usate dal processo; in Linux è definita come:
@@ -975,7 +986,7 @@ struct rusage {
     \end{lstlisting}
   \end{minipage} 
   \normalsize 
-  \caption{La struttura \texttt{rusage} per la lettura delle informazioni dei 
+  \caption{La struttura \var{rusage} per la lettura delle informazioni dei 
     delle risorse usate da un processo.}
   \label{fig:proc_rusage_struct}
 \end{figure}
@@ -987,7 +998,7 @@ sono mantenuti sono: \var{ru\_utime}, \var{ru\_stime}, \var{ru\_minflt},
 \var{ru\_majflt}, e \var{ru\_nswap}.
 
 
-\subsection{Le funzioni \texttt{exec}}
+\subsection{Le funzioni \func{exec}}
 \label{sec:proc_exec}
 
 Abbiamo già detto che una delle modalità principali con cui si utilizzano i
@@ -1003,7 +1014,6 @@ Ci sono sei diverse versioni di \func{exec} (per questo la si 
 famiglia di funzioni) che possono essere usate per questo compito, che in
 realtà (come mostrato in \figref{fig:proc_exec_relat}), costituiscono un
 front-end a \func{execve}. Il prototipo  di quest'ultima è:
-
 \begin{prototype}{unistd.h}
 {int execve(const char * filename, char * const argv [], char * const envp[])}
   
@@ -1040,7 +1050,6 @@ front-end a \func{execve}. Il prototipo  di quest'ultima 
 Le altre funzioni della famiglia servono per fornire all'utente una serie
 possibile di diverse interfacce per la creazione di un nuovo processo. I loro
 prototipi sono:
-
 \begin{functions}
 \headdecl{unistd.h}
 \funcdecl{int execl(const char *path, const char *arg, ...)} 
@@ -1126,7 +1135,7 @@ indicato dal parametro \var{path}, che viene interpretato come il
 
 \begin{figure}[htb]
   \centering
-  \includegraphics[width=13cm]{img/exec_rel.eps}
+  \includegraphics[width=13cm]{img/exec_rel}
   \caption{La interrelazione fra le sei funzioni della famiglia \func{exec}}
   \label{fig:proc_exec_relat}
 \end{figure}
@@ -1155,24 +1164,24 @@ la lista completa 
   \secref{sec:file_work_dir}).
 \item la maschera di creazione dei file (\var{umask}, vedi
   \secref{sec:file_umask}) ed i \textit{lock} sui file (vedi
-  \secref{sec:file_xxx}).
+  \secref{sec:file_locking}).
 \item i segnali sospesi (\textit{pending}) e la maschera dei segnali (si veda
   \secref{sec:sig_xxx}).
-\item i limiti sulle risorse (vedi \secref{sec:limits_xxx})..
+\item i limiti sulle risorse (vedi \secref{sec:sys_limits})..
 \item i valori delle variabili \var{tms\_utime}, \var{tms\_stime},
-  \var{tms\_cutime}, \var{tms\_ustime} (vedi \secref{sec:xxx_xxx})..
+  \var{tms\_cutime}, \var{tms\_ustime} (vedi \secref{sec:xxx_xxx}).
 \end{itemize*}
 
 Oltre a questo i segnali che sono stati settati per essere ignorati nel
-processo chiamante mantengono lo stesso settaggio pure nuovo programma, tutti
-gli altri segnali vengono settati alla loro azione di default. Un caso
-speciale è il segnale \macro{SIGCHLD} che, quando settato a \macro{SIG\_IGN}
+processo chiamante mantengono lo stesso settaggio pure nel nuovo programma,
+tutti gli altri segnali vengono settati alla loro azione di default. Un caso
+speciale è il segnale \macro{SIGCHLD} che, quando settato a \macro{SIG\_IGN},
 può anche non essere resettato a \macro{SIG\_DFL} (si veda
 \secref{sec:sig_xxx}).
 
 La gestione dei file aperti dipende dal valore del flag di
 \textit{close-on-exec} per ciascun file descriptor (si veda
-\secref{sec:file_xxx}); i file per cui è settato vengono chiusi, tutti gli
+\secref{sec:file_fcntl}); i file per cui è settato vengono chiusi, tutti gli
 altri file restano aperti. Questo significa che il comportamento di default è
 che i file restano aperti attraverso una \func{exec}, a meno di una chiamata
 esplicita a \func{fcntl} che setti il suddetto flag.
@@ -1260,7 +1269,6 @@ utente per un limitato insieme di operazioni. Per questo motivo in generale
 tutti gli unix prevedono che i processi abbiano almeno due gruppi di
 identificatori, chiamati rispettivamente \textit{real} ed \textit{effective}.
 
-
 \begin{table}[htb]
   \footnotesize
   \centering
@@ -1315,26 +1323,29 @@ il programma che si 
 settati (il significato di questi bit è affrontato in dettaglio in
 \secref{sec:file_suid_sgid}). In questo caso essi saranno settati all'utente e
 al gruppo proprietari del file; questo consente, per programmi in cui ci sia
-necessità, di dare a qualunquee utente normale privilegi o permessi di
+necessità, di dare a qualunque utente normale privilegi o permessi di
 un'altro (o dell'amministratore).
 
 Come nel caso del \acr{pid} e del \acr{ppid} tutti questi identificatori
 possono essere letti dal processo attraverso delle opportune funzioni, i cui
 prototipi sono i seguenti:
-
 \begin{functions}
-\headdecl{unistd.h}
-\headdecl{sys/types.h}
-\funcdecl{uid\_t getuid(void)} restituisce il \textit{real user ID} del
-processo corrente.
-\funcdecl{uid\_t geteuid(void)} restituisce l'\textit{effective user ID} del
-processo corrente.
-\funcdecl{gid\_t getgid(void)} restituisce il \textit{real group ID} del
-processo corrente.
-\funcdecl{gid\_t getegid(void)} restituisce l'\textit{effective group ID} del
-processo corrente.
-
-Queste funzioni non riportano condizioni di errore. 
+  \headdecl{unistd.h}
+  \headdecl{sys/types.h}
+  
+  \funcdecl{uid\_t getuid(void)} restituisce il \textit{real user ID} del
+  processo corrente.
+
+  \funcdecl{uid\_t geteuid(void)} restituisce l'\textit{effective user ID} del
+  processo corrente.
+
+  \funcdecl{gid\_t getgid(void)} restituisce il \textit{real group ID} del
+  processo corrente.
+
+  \funcdecl{gid\_t getegid(void)} restituisce l'\textit{effective group ID} del
+  processo corrente.
+  
+  Queste funzioni non riportano condizioni di errore. 
 \end{functions}
 
 In generale l'uso di privilegi superiori deve essere limitato il più
@@ -1347,8 +1358,11 @@ servano di nuovo.
 Questo in Linux viene fatto usando altri due gruppi di identificatori, il
 \textit{saved} ed il \textit{filesystem}, analoghi ai precedenti. Il primo
 gruppo è lo stesso usato in SVr4, e previsto dallo standard POSIX quando è
-definita la costante \macro{\_POSIX\_SAVED\_IDS}, il secondo gruppo è
-specifico di Linux e viene usato per migliorare la sicurezza con NFS. 
+definita la costante \macro{\_POSIX\_SAVED\_IDS}\footnote{in caso si abbia a
+  cuore la portabilità del programma su altri unix è buona norma controllare
+  sempre la disponibilità di queste funzioni controllando se questa costante è
+  definita}, il secondo gruppo è specifico di Linux e viene usato per
+migliorare la sicurezza con NFS.
 
 Il \textit{saved user id} e il \textit{saved group id} sono copie
 dell'\textit{effective user id} e dell'\textit{effective group id} del
@@ -1377,18 +1391,17 @@ di utente e gruppo associati dal kernel ad ogni processo, 
 \subsection{Le funzioni \func{setuid} e \func{setgid}}
 \label{sec:proc_setuid}
 
-Le due funzioni che venfono usate per cambiare identità (cioè utente e gruppo
+Le due funzioni che vengono usate per cambiare identità (cioè utente e gruppo
 di appartenenza) ad un processo sono rispettivamente \func{setuid} e
 \func{setgid}; come accennato in \secref{sec:proc_user_group} in Linux esse
-seguono la sematica POSIX che prevede l'esistenza di \textit{saved user id} e
+seguono la semantica POSIX che prevede l'esistenza di \textit{saved user id} e
 \textit{saved group id}; i loro prototipi sono:
-
 \begin{functions}
 \headdecl{unistd.h}
 \headdecl{sys/types.h}
 
-\funcdecl{int setuid(uid\_t uid)} setta l' \textit{user ID} del processo
-corrente.  
+\funcdecl{int setuid(uid\_t uid)} setta l'\textit{user ID} del processo
+corrente.
 
 \funcdecl{int setgid(gid\_t gid)} setta il \textit{group ID} del processo
 corrente.
@@ -1399,36 +1412,29 @@ l'unico errore possibile 
 
 Il funzionamento di queste due funzioni è analogo, per cui considereremo solo
 la prima; la seconda si comporta esattamente allo stesso modo facendo
-riferimento al \textit{group id} invece che all'\textit{user id}.  
+riferimento al \textit{group id} invece che all'\textit{user id}.  Gli
+eventuali \textit{supplementary group id} non vengono modificati da nessuna
+delle funzioni che tratteremo in questa sezione.
 
 
 L'effetto della chiamata è diverso a seconda dei privilegi del processo; se
 l'\textit{effective user id} è zero (cioè è quello dell'amministratore di
-sistema) allora tutti gli identificatatori (\textit{real}, \textit{effective}
+sistema) allora tutti gli identificatori (\textit{real}, \textit{effective}
 e \textit{saved}) vengono settati al valore specificato da \var{uid},
 altrimenti viene settato solo l'\textit{effective user id}, e soltanto se il
 valore specificato corrisponde o al \textit{real user id} o al \textit{saved
-  user id}. Negli altri casi segnalato un errore (con \macro{EPERM}).
+  user id}. Negli altri casi viene segnalato un errore (con \macro{EPERM}).
 
 Come accennato l'uso principale di queste funzioni è quello di poter
-consentire ad un programma con i bit \acr{suid} o \acr{sgid} settati, di
+consentire ad un programma con i bit \acr{suid} o \acr{sgid} settati di
 riportare l'\textit{effective user id} a quello dell'utente che ha lanciato il
-programma, per effettuare il lavoro che non necessita di privilegi aggiuntivi,
-ed eventualmente tornare indietro. 
-
-Occorre però tenere conto che tutto questo non è possibile nel caso di root,
-in tal caso infatti l'esecuzione una \func{setuid} con un \textit{effective
-  user id} uguale a zero comporta il cambiamento di tutti gli identificatori
-associati al processo rendendo impossibile riguadagnare i privilegi di
-amministratore. Questo è l'uso che ne fa \cmd{login} una volta che crea una
-nuova shell per l'utente, ma se si vuole cambiare soltanto l'\textit{effective
-  user id} occorre ricorrere ad altre funzioni (si veda ad esempio
-\secref{sec:proc_seteuid}).
+programma, effettuare il lavoro che non necessita di privilegi aggiuntivi, ed
+eventualmente tornare indietro.
 
 Come esempio per chiarire dell'uso di queste funzioni prediamo quello con cui
 viene gestito l'accesso al file \file{/var/log/utmp}.  In questo file viene
 registrato chi sta usando il sistema al momento corrente; chiaramente non può
-essere lasciato aperto in scrittura a qualunque utente, che protrebbe
+essere lasciato aperto in scrittura a qualunque utente, che potrebbe
 falsificare la registrazione. Per questo motivo questo file (e l'analogo
 \file{/var/log/wtmp} su cui vengono registrati login e logout) appartengono ad
 un gruppo dedicato (\acr{utmp}) ed i programmi che devono accedervi (ad
@@ -1447,10 +1453,10 @@ situazione degli identificatori 
 in questo modo, dato che l'\textit{effective group id} è quello giusto, il
 programma può accedere a \file{/var/log/utmp} in scrittura ed aggiornarlo, a
 questo punto il programma può eseguire una \func{setgid(getgid())} per settare
-l'\textit{effective group id} a quello dell'utente (ed usando il \textit{real
-  group id} la funzione avrà successo), in questo modo non sarà possibile
-lanciare dal terminale programmi che modificano detto file, in tal caso
-infatti la situazione degli identificatori sarebbe:
+l'\textit{effective group id} a quello dell'utente (e dato che il \textit{real
+  group id} corrisponde la funzione avrà successo), in questo modo non sarà
+possibile lanciare dal terminale programmi che modificano detto file, in tal
+caso infatti la situazione degli identificatori sarebbe:
 \begin{eqnarray*}
   \label{eq:2}
   \textit{real group id}      &=& \textrm{\acr{gid} (invariato)}  \\
@@ -1472,27 +1478,279 @@ avr
 \end{eqnarray*}
 consentendo l'accesso a \file{/var/log/utmp}.
 
+Occorre però tenere conto che tutto questo non è possibile con un processo con
+i privilegi di root, in tal caso infatti l'esecuzione una \func{setuid}
+comporta il cambiamento di tutti gli identificatori associati al processo,
+rendendo impossibile riguadagnare i privilegi di amministratore.  Questo
+comportamento è corretto per l'uso che ne fa \cmd{login} una volta che crea
+una nuova shell per l'utente; ma quando si vuole cambiare soltanto
+l'\textit{effective user id} del processo per cedere i privilegi occorre
+ricorrere ad altre funzioni (si veda ad esempio \secref{sec:proc_seteuid}).
+
+
+\subsection{Le funzioni \func{setreuid} e \func{setresuid}}
+\label{sec:proc_setreuid}
+
+Queste due funzioni derivano da BSD che non supportando\footnote{almeno fino
+  alla versione 4.3+BSD TODO, verificare e aggiornare la nota} i \textit{saved
+  id} le usava per poter scambiare fra di loro effective e real id. I
+prototipi sono:
+\begin{functions}
+\headdecl{unistd.h}
+\headdecl{sys/types.h}
+
+\funcdecl{int setreuid(uid\_t ruid, uid\_t euid)} setta il \textit{real user
+  ID} e l'\textit{effective user ID} del processo corrente ai valori
+specificati da \var{ruid} e \var{euid}.
+  
+\funcdecl{int setregid(gid\_t rgid, gid\_t egid)} setta il \textit{real group
+  ID} e l'\textit{effective group ID} del processo corrente ai valori
+specificati da \var{rgid} e \var{egid}.
+
+Le funzioni restituiscono 0 in caso di successo e -1 in caso di fallimento:
+l'unico errore possibile è \macro{EPERM}. 
+\end{functions}
+
+I processi non privilegiati possono settare i \textit{real id} soltanto ai
+valori dei loro \textit{effective id} o \textit{real id} e gli
+\textit{effective id} ai valori dei loro \textit{real id}, \textit{effective
+  id} o \textit{saved id}; valori diversi comportano il fallimento della
+chiamata; l'amministratore invece può specificare un valore qualunque.
+Specificando un valore di -1 l'identificatore corrispondente viene lasciato
+inalterato.
+
+Con queste funzione si possono scambiare fra loro \textit{real id} e
+\textit{effective id}, e pertanto è possibile implementare un comportamento
+simile a quello visto in precedenza per \func{setgid}, cedendo i privilegi con
+un primo scambio, e recuperandoli, eseguito il lavoro non privilegiato, con un
+secondo scambio.
+
+In questo caso però occorre porre molta attenzione quando si creano nuovi
+processi nella fase intermedia in cui si sono scambiati gli identificatori, in
+questo caso infatti essi avranno un \textit{real id} privilegiato, che dovrà
+essere esplicitamente eliminato prima di porre in esecuzione un nuovo
+programma (occorrerà cioè eseguire un'altra chiamata dopo la \func{fork}, e
+prima della \func{exec} per uniformare i \textit{real id} agli
+\textit{effective id}) in caso contrario quest'ultimo potrebbe a sua volta
+effettuare uno scambio e riottenere privilegi non previsti.
+
+Lo stesso problema di propagazione dei privilegi ad eventuali processi figli
+si porrebbe per i \textit{saved id}. Queste funzioni derivano da
+un'implementazione che non ne prevede la presenza, e quindi non è possibile
+usarle per correggere la situazione come nel caso precedente, per questo
+motivo tutte le volte che uno degli identificatori viene modificato ad un
+valore diverso dal precedente \textit{real id}, il \textit{saved id} viene
+sempre settato al valore dell'\textit{effective id}.
+
+
+\subsection{Le funzioni \func{setresuid} e \func{setresgid}}
+\label{sec:proc_setresuid}
+
+Queste due funzioni sono una estensione introdotta in Linux dal kernel 2.1.44,
+e permettono un completo controllo su tutti gli identificatori (\textit{real},
+\textit{effective} e \textit{saved}), i prototipi sono:
+\begin{functions}
+\headdecl{unistd.h}
+\headdecl{sys/types.h}
+
+\funcdecl{int setresuid(uid\_t ruid, uid\_t euid, uid\_t suid)} setta il
+\textit{real user ID}, l'\textit{effective user ID} e il \textit{saved user
+  ID} del processo corrente ai valori specificati rispettivamente da
+\var{ruid}, \var{euid} e \var{suid}.
+  
+\funcdecl{int setresgid(gid\_t rgid, gid\_t egid, gid\_t sgid)} setta il
+\textit{real group ID}, l'\textit{effective group ID} e il \textit{saved group
+  ID} del processo corrente ai valori specificati rispettivamente da
+\var{rgid}, \var{egid} e \var{sgid}.
+
+Le funzioni restituiscono 0 in caso di successo e -1 in caso di fallimento:
+l'unico errore possibile è \macro{EPERM}. 
+\end{functions}
+
+I processi non privilegiati possono cambiare uno qualunque degli
+identificatori usando uno qualunque dei valori correnti di \textit{real id},
+\textit{effective id} o \textit{saved id}, l'amministratore può specificare i
+valori che vuole; un valore di -1 per un qualunque parametro lascia inalterato
+l'identificatore corrispondente.
+
+
 
 \subsection{Le funzioni \func{seteuid} e \func{setegid}}
 \label{sec:proc_seteuid}
 
+Queste funzioni sono un'estensione allo standard POSIX.1 (ma sono comunque
+supportate dalla maggior parte degli unix) e usate per cambiare gli
+\textit{effective id}; i loro prototipi sono:
+\begin{functions}
+\headdecl{unistd.h}
+\headdecl{sys/types.h}
 
-\subsection{Le funzioni \func{setreuid} e \func{setresuid}}
-\label{sec:proc_setreuid}
+\funcdecl{int seteuid(uid\_t uid)} setta l'\textit{effective user ID} del
+processo corrente a \var{uid}.
+
+\funcdecl{int setegid(gid\_t gid)} setta l'\textit{effective group ID} del
+processo corrente a \var{gid}.
+
+Le funzioni restituiscono 0 in caso di successo e -1 in caso di fallimento:
+l'unico errore possibile è \macro{EPERM}. 
+\end{functions}
 
+Gli utenti normali possono settare l'\textit{effective id} solo al valore del
+\textit{real id} o del \textit{saved id}, l'amministratore può specificare
+qualunque valore. Queste funzioni sono usate per permettere a root di settare
+solo l'\textit{effective id}, dato che l'uso normale di \func{setuid} comporta
+il settaggio di tutti gli identificatori.
+ 
 
 \subsection{Le funzioni \func{setfsuid} e \func{setfsgid}}
 \label{sec:proc_setfsuid}
 
+Queste funzioni sono usate per settare gli identificatori usati da Linux per
+il controllo dell'accesso ai file. Come già accennato in
+\secref{sec:proc_user_group} in Linux è definito questo ulteriore gruppo di
+identificatori, che di norma sono assolutamente equivalenti agli
+\textit{effective id}, dato che ogni cambiamento di questi ultimi viene
+immediatamente riportato sui \textit{filesystem id}.
+
+C'è un solo caso in cui si ha necessità di introdurre una differenza fra
+\textit{effective id} e \textit{filesystem id}, ed è per ovviare ad un
+problema di sicurezza che si presenta quando si deve implementare un server
+NFS. Il server NFS infatti deve poter cambiare l'identificatore con cui accede
+ai file per assumere l'identità del singolo utente remoto, ma se questo viene
+fatto cambiando l'\textit{effective id} o il \textit{real id} il server si
+espone alla ricezione di eventuali segnali ostili da parte dell'utente di cui
+ha temporaneamente assunto l'identità.  Cambiando solo il \textit{filesystem
+  id} si ottengono i privilegi necessari per accedere ai file, mantenendo
+quelli originari per quanto riguarda tutti gli altri controlli di accesso.
+
+Le due funzioni usate per cambiare questi identificatori sono \func{setfsuid}
+e \func{setfsgid}, ovviamente sono specifiche di Linux e non devono essere
+usate se si intendono scrivere programmi portabili; i loro prototipi sono:
+\begin{functions}
+\headdecl{sys/fsuid.h}
+
+\funcdecl{int setfsuid(uid\_t fsuid)} setta il \textit{filesystem user ID} del
+processo corrente a \var{fsuid}.
 
+\funcdecl{int setfsgid(gid\_t fsgid)} setta l'\textit{filesystem group ID} del
+processo corrente a \var{fsgid}.
 
-\subsection{Le \textit{race condition}}
+Le funzioni restituiscono 0 in caso di successo e -1 in caso di fallimento:
+l'unico errore possibile è \macro{EPERM}. 
+\end{functions}
+
+Queste funzioni hanno successo solo se il processo chiamante ha i privilegi di
+amministratore o, per gli altri utenti, se il valore specificato coincide con
+uno dei \textit{real}, \textit{effective} o \textit{saved id}.
+
+
+\section{Problematiche di programmazione multitasking}
+\label{sec:proc_multi_prog}
+
+Benché i processi siano strutturati in modo da apparire il più possibile come
+indipendenti l'uno dall'altro, nella programmazione in un sistema multiutente
+occorre tenere conto di tutta una serie di problematiche che normalmente non
+esistono quando si ha a che fare con un sistema in cui viene eseguito un solo
+programma alla volta. 
+
+Pur non essendo tutto questo direttamente legato alla modalità specifica in
+cui il multitasking è implementato in un sistema unix-like, né al solo
+concetto di multitasking (le stesse problematiche si presentano ad esempio
+nella gestione degli interrupt hardware), in questa sezione conclusiva del
+capitolo in cui abbiamo affrontato la gestione dei processi, introdurremo
+sinteticamente queste problematiche, che ritroveremo a più riprese in capitoli
+successivi, con una breve definizione della terminologia e delle loro
+caratteristiche di fondo.
+
+
+\subsection{Le operazioni atomiche}
+\label{sec:proc_atom_oper}
+
+La nozione di \textsl{operazione atomica} deriva dal significato greco della
+parola atomo, cioè indivisibile; si dice infatti che una operazione è atomica
+quando si ha la certezza che, qualora essa venga effettuata, tutti i passaggi
+che devono essere compiuti per realizzarla verranno eseguiti senza possibilità
+di interruzione in una fase intermedia.
+
+In un ambiente multitasking il concetto è essenziale, dato che un processo può
+essere interrotto in qualunque momento dal kernel che mette in esecuzione un
+altro processo o dalla ricezione di un segnale; occorre pertanto essere
+accorti nei confronti delle possibili \textit{race condition} (vedi
+\secref{sec:proc_race_cond}) derivanti da operazioni interrotte in una fase in
+cui non erano ancora state completate.
+
+Nel caso dell'interazione fra processi la situazione è molto più semplice, ed
+occorre preoccuparsi della atomicità delle operazioni solo quando si ha a che
+fare con meccanismi di intercomunicazione (che esamineremo in dettaglio in
+\capref{cha:IPC}) o nella operazioni con i file (vedremo alcuni esempi in
+\secref{sec:file_atomic}). In questi casi in genere l'uso delle appropriate
+funzioni di libreria per compiere le operazioni necessarie è garanzia
+sufficiente di atomicità in quanto le system call con cui esse sono realizzate
+non possono essere interrotte (o subire interferenze pericolose) da altri
+processi.
+
+Nel caso dei segnali invece la situazione è molto più delicata, in quanto lo
+stesso processo, e pure alcune system call, possono essere interrotti in
+qualunque momento, e le operazioni di un eventuale \textit{signal handler}
+sono compiute nello stesso spazio di indirizzi del processo. Per questo anche
+solo il solo accesso o l'assegnazione di una variabile possono non essere più
+operazioni atomiche (torneremo su questi aspetti in \secref{sec:sign_xxx}).
+
+In questo caso il sistema provvede un tipo di dato, il \type{sig\_atomic\_t},
+il cui accesso è assicurato essere atomico.  In pratica comunque si può
+assumere che in ogni piattaforma su cui è implementato Linux il tipo
+\type{int} (e gli altri interi di dimensione inferiore) ed i puntatori sono
+atomici. Non è affatto detto che lo stesso valga per interi di dimensioni
+maggiori (in cui l'accesso può comportare più istruzioni in assembler) o per
+le strutture. In questi casi è anche opportuno marcare come \type{volatile} le
+variabili che possono essere interessate ad accesso condiviso, onde evitare
+problemi con le ottimizzazioni del codice.
+
+
+\subsection{Le \textit{race condition} e i \textit{deadlock}}
 \label{sec:proc_race_cond}
 
 Si definisce una \textit{race condition} il caso in cui diversi processi
 stanno cercando di fare qualcosa con una risorsa comune ed il risultato finale
 viene a dipendere dall'ordine di esecuzione dei medesimi. Ovviamente dato che
-l'ordine di esecuzione di un processo, senza appositi meccanismi di
-sincronizzazione, non è assolutamente prevedibile, queste situazioni sono
-fonti di errori molto subdoli, che possono verificarsi solo in condizioni
-particolari e quindi difficilmente riproducibili.
+l'ordine di esecuzione di un processo rispetto agli altri, senza appositi
+meccanismi di sincronizzazione, non è assolutamente prevedibile, queste
+situazioni sono fonti di errori molto subdoli, che possono verificarsi solo in
+condizioni particolari e quindi difficilmente riproducibili.
+
+Casi tipici di \textit{race condition} si hanno quando diversi processi
+accedono allo stesso file, o nell'accesso a meccanismi di intercomunicazione
+come la memoria condivisa. In questi casi, se non si dispone della possibilità
+di eseguire atomicamente le operazioni necessarie, occorre che le risorse
+condivise siano opportunamente protette da meccanismi di sincronizzazione
+(torneremo su queste problematiche di questo tipo in \secref{sec:ipc_semaph}).
+
+Un caso particolare di \textit{race condition} sono poi i cosiddetti
+\textit{deadlock}; l'esempio tipico è quello di un flag di ``occupazione'' che
+viene rilasciato da un evento asincrono fra il controllo (in cui viene trovato
+occupato) e la successiva messa in attesa, che a questo punto diventerà
+perpetua (da cui il nome di \textit{deadlock}) in quanto l'evento di sblocco
+del flag è stato perso fra il controllo e la messa in attesa.
+
+
+\subsection{Le funzioni rientranti}
+\label{sec:proc_reentrant}
+
+Si dice rientrante una funzione che può essere interrotta in qualunque momento
+ed essere chiamata da capo (da questo il nome) da un altro filone di
+esecuzione (thread e manipolatori di segnali sono i casi in cui occorre
+prestare attenzione a questa problematica) senza che questo comporti nessun
+problema.
+
+In genere una funzione non è rientrante se opera direttamente su memoria che
+non è nello stack. Ad esempio una funzione non è rientrante se usa una
+variabile globale o statica od un oggetto allocato dinamicamente che trova da
+sola: due chiamate alla stessa funzione interferiranno.  Una funzione può non
+essere rientrante se usa e modifica un oggetto che le viene fornito dal
+chiamante: due chiamate possono interferire se viene passato lo stesso
+oggetto. 
+
+Le glibc mettono a disposizione due macro di compilatore \macro{\_REENTRANT} e
+\macro{\_THREAD\_SAFE} per assicurare che siano usate delle versioni rientranti
+delle funzioni di libreria.
+