+\val{WTERMSIG} può essere confrontato con le costanti definite in
+\file{signal.h} ed elencate in tab.~\ref{tab:sig_signal_list}, e stampato
+usando le apposite funzioni trattate in sez.~\ref{sec:sig_strsignal}.
+
+A partire dal kernel 2.6.9, sempre in conformità allo standard POSIX.1-2001, è
+stata introdotta una nuova funzione di attesa che consente di avere un
+controllo molto più preciso sui possibili cambiamenti di stato dei processi
+figli e più dettagli sullo stato di uscita; la funzione è \funcd{waitid} ed il
+suo prototipo è:
+\begin{functions}
+ \headdecl{sys/types.h}
+
+ \headdecl{sys/wait.h}
+
+ \funcdecl{int waitid(idtype\_t idtype, id\_t id, siginfo\_t *infop, int
+ options)}
+
+ Attende la conclusione di un processo figlio.
+
+ \bodydesc{La funzione restituisce 0 in caso di successo e -1 per un errore,
+ nel qual caso \var{errno} assumerà i valori:
+ \begin{errlist}
+ \item[\errcode{EINTR}] se non è stata specificata l'opzione \const{WNOHANG} e
+ la funzione è stata interrotta da un segnale.
+ \item[\errcode{ECHILD}] il processo specificato da \param{pid} non esiste o
+ non è figlio del processo chiamante.
+ \item[\errcode{EINVAL}] si è specificato un valore non valido per
+ l'argomento \param{options}.
+ \end{errlist}}
+\end{functions}
+
+La funzione prevede che si specifichi quali processi si intendono osservare
+usando i due argomenti \param{idtype} ed \param{id}; il primo indica se si
+vuole porsi in attesa su un singolo processo, un gruppo di processi o un
+processo qualsiasi, e deve essere specificato secondo uno dei valori di
+tab.~\ref{tab:proc_waitid_idtype}; il secondo indica, a seconda del valore del
+primo, quale processo o quale gruppo di processi selezionare.
+
+
+\begin{table}[!htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|p{8cm}|}
+ \hline
+ \textbf{Macro} & \textbf{Descrizione}\\
+ \hline
+ \hline
+ \const{P\_PID} & Indica la richiesta di attendere per un processo figlio
+ il cui \acr{pid} corrisponda al valore dell'argomento
+ \param{id}.\\
+ \const{P\_PGID}& Indica la richiesta di attendere per un processo figlio
+ appartenente al \textit{process group} (vedi
+ sez.~\ref{sec:sess_proc_group}) il cui \acr{pgid}
+ corrisponda al valore dell'argomento \param{id}.\\
+ \const{P\_ALL} & Indica la richiesta di attendere per un processo figlio
+ generico, il valore dell'argomento \param{id} viene
+ ignorato.\\
+ \hline
+ \end{tabular}
+ \caption{Costanti per i valori dell'argomento \param{idtype} della funzione
+ \func{waitid}.}
+ \label{tab:proc_waitid_idtype}
+\end{table}
+
+Come per \func{waitpid} anche il comportamento di \func{waitid} viene
+controllato dall'argomento \param{options}, da specificare come maschera
+binaria dei valori riportati in tab.~\ref{tab:proc_waitid_options}. Benché
+alcuni di questi siano identici come significato ed effetto ai precedenti di
+tab.~\ref{tab:proc_waitpid_options}, ci sono delle differenze significative:
+in questo caso si dovrà specificare esplicitamente l'attesa della terminazione
+di un processo impostando l'opzione \const{WEXITED}, mentre il precedente
+\const{WUNTRACED} è sostituito da \const{WSTOPPED}. Infine è stata aggiunta
+l'opzione \const{WNOWAIT} che consente una lettura dello stato mantenendo il
+processo in attesa di ricezione, così che una successiva chiamata possa di
+nuovo riceverne lo stato.
+
+\begin{table}[!htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|p{8cm}|}
+ \hline
+ \textbf{Macro} & \textbf{Descrizione}\\
+ \hline
+ \hline
+ \const{WEXITED} & Ritorna quando un processo figlio è terminato.\\
+ \const{WNOHANG} & Ritorna immediatamente anche se non c'è niente da
+ notificare.\\
+ \const{WSTOPPED} & Ritorna quando un processo figlio è stato fermato.\\
+ \const{WCONTINUED}& Ritorna quando un processo figlio che era stato
+ fermato ha ripreso l'esecuzione.\\
+ \const{WNOWAIT} & Lascia il processo ancora in attesa di ricezione, così
+ che una successiva chiamata possa di nuovo riceverne
+ lo stato.\\
+ \hline
+ \end{tabular}
+ \caption{Costanti che identificano i bit dell'argomento \param{options}
+ della funzione \func{waitid}.}
+ \label{tab:proc_waitid_options}
+\end{table}
+
+La funzione \func{waitid} restituisce un valore nullo in caso di successo, e
+$-1$ in caso di errore; viene restituito un valore nullo anche se è stata
+specificata l'opzione \const{WNOHANG} e la funzione è ritornata immediatamente
+senza che nessun figlio sia terminato. Pertanto per verificare il motivo del
+ritorno della funzione occorre analizzare le informazioni che essa
+restituisce; queste, al contrario delle precedenti \func{wait} e
+\func{waitpid} che usavano un semplice valore numerico, sono ritornate in una
+struttura di tipo \struct{siginfo\_t} (vedi fig.~\ref{fig:sig_siginfo_t})
+all'indirizzo puntato dall'argomento \param{infop}.
+
+Tratteremo nei dettagli la struttura \struct{siginfo\_t} ed il significato dei
+suoi vari campi in sez.~\ref{sec:sig_sigaction}, per quanto ci interessa qui
+basta dire che al ritorno di \func{waitid} verranno avvalorati i seguenti
+campi:
+\begin{basedescript}{\desclabelwidth{2.0cm}}
+\item[\var{si\_pid}] con il \acr{pid} del figlio.
+\item[\var{si\_uid}] con l'user-ID reale (vedi sez.~\ref{sec:proc_perms}) del
+ figlio.
+\item[\var{si\_signo}] con \const{SIGCHLD}.
+\item[\var{si\_status}] con lo stato di uscita del figlio o con il segnale che
+ lo ha terminato, fermato o riavviato.
+\item[\var{si\_code}] con uno fra \const{CLD\_EXITED}, \const{CLD\_KILLED},
+ \const{CLD\_STOPPED}, \const{CLD\_CONTINUED} (vedi tab.~\ref{xxx_si_code}).
+\end{basedescript}
+
+%TODO mettere riferimento alla tabella giusta (vedere man credentials e man
+% waitid)
+
+Infine Linux, seguendo un'estensione di BSD, supporta altre due funzioni per
+la lettura dello stato di terminazione di un processo, analoghe alle
+precedenti ma che prevedono un ulteriore argomento attraverso il quale il
+kernel può restituire al padre informazioni sulle risorse (vedi
+sez.~\ref{sec:sys_res_limits}) usate dal processo terminato e dai vari figli.
+Le due funzioni sono \funcd{wait3} e \funcd{wait4}, che diventano accessibili
+definendo la macro \macro{\_USE\_BSD}; i loro prototipi sono:
+\begin{functions}
+ \headdecl{sys/times.h} \headdecl{sys/types.h} \headdecl{sys/wait.h}
+ \headdecl{sys/resource.h}
+
+ \funcdecl{pid\_t wait4(pid\_t pid, int *status, int options, struct rusage
+ *rusage)}
+ È identica a \func{waitpid} sia per comportamento che per i valori degli
+ argomenti, ma restituisce in \param{rusage} un sommario delle risorse usate
+ dal processo.
+
+ \funcdecl{pid\_t wait3(int *status, int options, struct rusage *rusage)}
+ Prima versione, equivalente a \code{wait4(-1, \&status, opt, rusage)} è
+ ormai deprecata in favore di \func{wait4}.
+\end{functions}
+\noindent
+la struttura \struct{rusage} è definita in \file{sys/resource.h}, e viene
+utilizzata anche dalla funzione \func{getrusage} (vedi
+sez.~\ref{sec:sys_resource_use}) per ottenere le risorse di sistema usate da un
+processo; la sua definizione è riportata in fig.~\ref{fig:sys_rusage_struct}.
+
+\subsection{La funzione \func{exec} e le funzioni di esecuzione dei programmi}
+\label{sec:proc_exec}
+
+Abbiamo già detto che una delle modalità principali con cui si utilizzano i
+processi in Unix è quella di usarli per lanciare nuovi programmi: questo viene
+fatto attraverso una delle funzioni della famiglia \func{exec}. Quando un
+processo chiama una di queste funzioni esso viene completamente sostituito dal
+nuovo programma; il \acr{pid} del processo non cambia, dato che non viene
+creato un nuovo processo, la funzione semplicemente rimpiazza lo
+\itindex{stack} \textit{stack}, lo \itindex{heap} \textit{heap}, i
+\index{segmento!dati} dati ed il \index{segmento!testo} testo del processo
+corrente con un nuovo programma letto da disco.
+
+Ci sono sei diverse versioni di \func{exec} (per questo la si è chiamata
+famiglia di funzioni) che possono essere usate per questo compito, in realtà
+(come mostrato in fig.~\ref{fig:proc_exec_relat}), sono tutte un front-end a
+\funcd{execve}. Il prototipo di quest'ultima è:
+\begin{prototype}{unistd.h}
+{int execve(const char *filename, char *const argv[], char *const envp[])}
+ Esegue il programma contenuto nel file \param{filename}.
+
+ \bodydesc{La funzione ritorna solo in caso di errore, restituendo -1; nel
+ qual caso \var{errno} può assumere i valori:
+ \begin{errlist}
+ \item[\errcode{EACCES}] il file non è eseguibile, oppure il filesystem è
+ montato in \cmd{noexec}, oppure non è un file regolare o un interprete.
+ \item[\errcode{EPERM}] il file ha i bit \itindex{suid~bit} \acr{suid} o
+ \itindex{sgid~bit} \acr{sgid}, l'utente non è root, il processo viene
+ tracciato, o il filesystem è montato con l'opzione \cmd{nosuid}.
+ \item[\errcode{ENOEXEC}] il file è in un formato non eseguibile o non
+ riconosciuto come tale, o compilato per un'altra architettura.
+ \item[\errcode{ENOENT}] il file o una delle librerie dinamiche o l'interprete
+ necessari per eseguirlo non esistono.
+ \item[\errcode{ETXTBSY}] l'eseguibile è aperto in scrittura da uno o più
+ processi.
+ \item[\errcode{EINVAL}] l'eseguibile ELF ha più di un segmento
+ \const{PF\_INTERP}, cioè chiede di essere eseguito da più di un
+ interprete.
+ \item[\errcode{ELIBBAD}] un interprete ELF non è in un formato
+ riconoscibile.
+ \item[\errcode{E2BIG}] la lista degli argomenti è troppo grande.
+ \end{errlist}
+ ed inoltre anche \errval{EFAULT}, \errval{ENOMEM}, \errval{EIO},
+ \errval{ENAMETOOLONG}, \errval{ELOOP}, \errval{ENOTDIR}, \errval{ENFILE},
+ \errval{EMFILE}.}
+\end{prototype}
+
+La funzione \func{exec} esegue il file o lo script indicato da
+\param{filename}, passandogli la lista di argomenti indicata da \param{argv}
+e come ambiente la lista di stringhe indicata da \param{envp}; entrambe le
+liste devono essere terminate da un puntatore nullo. I vettori degli
+argomenti e dell'ambiente possono essere acceduti dal nuovo programma
+quando la sua funzione \func{main} è dichiarata nella forma
+\code{main(int argc, char *argv[], char *envp[])}.
+
+Le altre funzioni della famiglia servono per fornire all'utente una serie di
+possibili 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, ...)}
+\funcdecl{int execv(const char *path, char *const argv[])}
+\funcdecl{int execle(const char *path, const char *arg, ..., char
+* const envp[])}
+\funcdecl{int execlp(const char *file, const char *arg, ...)}
+\funcdecl{int execvp(const char *file, char *const argv[])}
+
+Sostituiscono l'immagine corrente del processo con quella indicata nel primo
+argomento. Gli argomenti successivi consentono di specificare gli argomenti a
+linea di comando e l'ambiente ricevuti dal nuovo processo.
+
+\bodydesc{Queste funzioni ritornano solo in caso di errore, restituendo -1;
+ nel qual caso \var{errno} assumerà i valori visti in precedenza per
+ \func{execve}.}
+\end{functions}
+
+Per capire meglio le differenze fra le funzioni della famiglia si può fare
+riferimento allo specchietto riportato in tab.~\ref{tab:proc_exec_scheme}. La
+prima differenza riguarda le modalità di passaggio dei valori che poi andranno
+a costituire gli argomenti a linea di comando (cioè i valori di
+\param{argv} e \param{argc} visti dalla funzione \func{main} del programma
+chiamato).
+
+Queste modalità sono due e sono riassunte dagli mnemonici \code{v} e \code{l}
+che stanno rispettivamente per \textit{vector} e \textit{list}. Nel primo caso
+gli argomenti sono passati tramite il vettore di puntatori \var{argv[]} a
+stringhe terminate con zero che costituiranno gli argomenti a riga di comando,
+questo vettore \emph{deve} essere terminato da un puntatore nullo.
+
+Nel secondo caso le stringhe degli argomenti sono passate alla funzione come
+lista di puntatori, nella forma:
+\includecodesnip{listati/char_list.c}
+che deve essere terminata da un puntatore nullo. In entrambi i casi vale la
+convenzione che il primo argomento (\var{arg0} o \var{argv[0]}) viene usato
+per indicare il nome del file che contiene il programma che verrà eseguito.
+
+\begin{table}[!htb]
+ \footnotesize
+ \centering
+ \begin{tabular}[c]{|l|c|c|c||c|c|c|}
+ \hline
+ \multicolumn{1}{|c|}{\textbf{Caratteristiche}} &
+ \multicolumn{6}{|c|}{\textbf{Funzioni}} \\
+ \hline
+ &\func{execl}\texttt{ }&\func{execlp}&\func{execle}
+ &\func{execv}\texttt{ }& \func{execvp}& \func{execve} \\
+ \hline
+ \hline
+ argomenti a lista &$\bullet$&$\bullet$&$\bullet$&&& \\
+ argomenti a vettore &&&&$\bullet$&$\bullet$&$\bullet$\\
+ \hline
+ filename completo &$\bullet$&&$\bullet$&$\bullet$&&$\bullet$\\
+ ricerca su \var{PATH} &&$\bullet$&&&$\bullet$& \\
+ \hline
+ ambiente a vettore &&&$\bullet$&&&$\bullet$ \\
+ uso di \var{environ} &$\bullet$&$\bullet$&&$\bullet$&$\bullet$& \\
+ \hline
+ \end{tabular}
+ \caption{Confronto delle caratteristiche delle varie funzioni della
+ famiglia \func{exec}.}
+ \label{tab:proc_exec_scheme}
+\end{table}
+
+La seconda differenza fra le funzioni riguarda le modalità con cui si
+specifica il programma che si vuole eseguire. Con lo mnemonico \code{p} si
+indicano le due funzioni che replicano il comportamento della shell nello
+specificare il comando da eseguire; quando l'argomento \param{file} non
+contiene una ``\texttt{/}'' esso viene considerato come un nome di programma,
+e viene eseguita automaticamente una ricerca fra i file presenti nella lista
+di directory specificate dalla variabile di ambiente \var{PATH}. Il file che
+viene posto in esecuzione è il primo che viene trovato. Se si ha un errore
+relativo a permessi di accesso insufficienti (cioè l'esecuzione della
+sottostante \func{execve} ritorna un \errcode{EACCES}), la ricerca viene
+proseguita nelle eventuali ulteriori directory indicate in \var{PATH}; solo se
+non viene trovato nessun altro file viene finalmente restituito
+\errcode{EACCES}.
+
+Le altre quattro funzioni si limitano invece a cercare di eseguire il file
+indicato dall'argomento \param{path}, che viene interpretato come il
+\itindex{pathname} \textit{pathname} del programma.
+
+\begin{figure}[htb]
+ \centering
+ \includegraphics[width=15cm]{img/exec_rel}
+ \caption{La interrelazione fra le sei funzioni della famiglia \func{exec}.}
+ \label{fig:proc_exec_relat}
+\end{figure}
+
+La terza differenza è come viene passata la lista delle variabili di ambiente.
+Con lo mnemonico \texttt{e} vengono indicate quelle funzioni che necessitano
+di un vettore di parametri \var{envp[]} analogo a quello usato per gli
+argomenti a riga di comando (terminato quindi da un \val{NULL}), le altre
+usano il valore della variabile \var{environ} (vedi
+sez.~\ref{sec:proc_environ}) del processo di partenza per costruire
+l'ambiente.
+
+Oltre a mantenere lo stesso \acr{pid}, il nuovo programma fatto partire da
+\func{exec} assume anche una serie di altre proprietà del processo chiamante;
+la lista completa è la seguente:
+\begin{itemize}
+\item il \textit{process id} (\acr{pid}) ed il \textit{parent process id}
+ (\acr{ppid});
+\item l'\textsl{user-ID reale}, il \textit{group-ID reale} ed i
+ \textsl{group-ID supplementari} (vedi sez.~\ref{sec:proc_access_id});
+\item il \textit{session ID} (\acr{sid}) ed il \itindex{process~group}
+ \textit{process group ID} (\acr{pgid}), vedi sez.~\ref{sec:sess_proc_group};
+\item il terminale di controllo (vedi sez.~\ref{sec:sess_ctrl_term});
+\item il tempo restante ad un allarme (vedi sez.~\ref{sec:sig_alarm_abort});
+\item la directory radice e la directory di lavoro corrente (vedi
+ sez.~\ref{sec:file_work_dir});
+\item la maschera di creazione dei file \itindex{umask} (\textit{umask}, vedi
+ sez.~\ref{sec:file_perm_management}) ed i \textit{lock} sui file (vedi
+ sez.~\ref{sec:file_locking});
+\item i segnali sospesi (\textit{pending}) e la maschera dei segnali (si veda
+ sez.~\ref{sec:sig_sigmask});
+\item i limiti sulle risorse (vedi sez.~\ref{sec:sys_resource_limit});
+\item i valori delle variabili \var{tms\_utime}, \var{tms\_stime},
+ \var{tms\_cutime}, \var{tms\_ustime} (vedi sez.~\ref{sec:sys_cpu_times}).
+\end{itemize}
+
+Inoltre i segnali che sono stati impostati per essere ignorati nel processo
+chiamante mantengono la stessa impostazione pure nel nuovo programma, tutti
+gli altri segnali vengono impostati alla loro azione predefinita. Un caso
+speciale è il segnale \const{SIGCHLD} che, quando impostato a
+\const{SIG\_IGN}, può anche non essere reimpostato a \const{SIG\_DFL} (si veda
+sez.~\ref{sec:sig_gen_beha}).
+
+La gestione dei file aperti dipende dal valore che ha il flag di
+\itindex{close-on-exec} \textit{close-on-exec} (vedi anche
+sez.~\ref{sec:file_fcntl}) per ciascun file descriptor. I file per cui è
+impostato vengono chiusi, tutti gli altri file restano aperti. Questo
+significa che il comportamento predefinito è che i file restano aperti
+attraverso una \func{exec}, a meno di una chiamata esplicita a \func{fcntl}
+che imposti il suddetto flag. Per le directory, lo standard POSIX.1 richiede
+che esse vengano chiuse attraverso una \func{exec}, in genere questo è fatto
+dalla funzione \func{opendir} (vedi sez.~\ref{sec:file_dir_read}) che effettua
+da sola l'impostazione del flag di \itindex{close-on-exec}
+\textit{close-on-exec} sulle directory che apre, in maniera trasparente
+all'utente.
+
+Abbiamo detto che l'\textsl{user-ID reale} ed il \textsl{group-ID reale}
+restano gli stessi all'esecuzione di \func{exec}; normalmente vale lo stesso
+anche per l'\textsl{user-ID effettivo} ed il \textsl{group-ID effettivo} (il
+significato di questi identificatori è trattato in
+sez.~\ref{sec:proc_access_id}), tranne quando il file di cui viene chiesta
+l'esecuzione ha o il \itindex{suid~bit} \acr{suid} bit o lo \itindex{sgid~bit}
+\acr{sgid} bit impostato, in questo caso l'\textsl{user-ID effettivo} ed il
+\textsl{group-ID effettivo} vengono impostati rispettivamente all'utente o al
+gruppo cui il file appartiene (per i dettagli di questo comportamento si veda
+sez.~\ref{sec:proc_perms}).
+
+Se il file da eseguire è in formato \emph{a.out} e necessita di librerie
+condivise, viene lanciato il \textit{linker} dinamico \cmd{/lib/ld.so} prima
+del programma per caricare le librerie necessarie ed effettuare il link
+dell'eseguibile.\footnote{il formato è ormai in completo disuso, per cui è
+ molto probabile che non il relativo supporto non sia disponibile.} Se il
+programma è in formato ELF per caricare le librerie dinamiche viene usato
+l'interprete indicato nel segmento \const{PT\_INTERP} previsto dal formato
+stesso, in genere questo è \sysfile{/lib/ld-linux.so.1} per programmi
+collegati con le \acr{libc5}, e \sysfile{/lib/ld-linux.so.2} per programmi
+collegati con le \acr{glibc}.
+
+Infine nel caso il file sia uno script esso deve iniziare con una linea nella
+forma \cmd{\#!/path/to/interpreter [argomenti]} dove l'interprete indicato
+deve essere un programma valido (binario, non un altro script) che verrà
+chiamato come se si fosse eseguito il comando \cmd{interpreter [argomenti]
+ filename}.\footnote{si tenga presente che con Linux quanto viene scritto
+ come \texttt{argomenti} viene passato all'interprete come un unico argomento
+ con una unica stringa di lunghezza massima di 127 caratteri e se questa
+ dimensione viene ecceduta la stringa viene troncata; altri Unix hanno
+ dimensioni massime diverse, e diversi comportamenti, ad esempio FreeBSD
+ esegue la scansione della riga e la divide nei vari argomenti e se è troppo
+ lunga restituisce un errore di \const{ENAMETOOLONG}, una comparazione dei
+ vari comportamenti si trova su
+ \href{http://www.in-ulm.de/~mascheck/various/shebang/}
+ {\textsf{http://www.in-ulm.de/\tild mascheck/various/shebang/}}.}
+
+Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è
+basata la gestione dei processi in Unix: con \func{fork} si crea un nuovo
+processo, con \func{exec} si lancia un nuovo programma, con \func{exit} e
+\func{wait} si effettua e verifica la conclusione dei processi. Tutte le
+altre funzioni sono ausiliarie e servono per la lettura e l'impostazione dei
+vari parametri connessi ai processi.
+
+
+
+\section{Il controllo di accesso}
+\label{sec:proc_perms}
+
+In questa sezione esamineremo le problematiche relative al controllo di
+accesso dal punto di vista dei processi; vedremo quali sono gli identificatori
+usati, come questi possono essere modificati nella creazione e nel lancio di
+nuovi processi, le varie funzioni per la loro manipolazione diretta e tutte le
+problematiche connesse ad una gestione accorta dei privilegi.
+
+
+\subsection{Gli identificatori del controllo di accesso}
+\label{sec:proc_access_id}
+
+Come accennato in sez.~\ref{sec:intro_multiuser} il modello base\footnote{in
+ realtà già esistono estensioni di questo modello base, che lo rendono più
+ flessibile e controllabile, come le \itindex{capabilities}
+ \textit{capabilities} illustrate in sez.~\ref{sec:proc_capabilities}, le ACL
+ per i file (vedi sez.~\ref{sec:file_ACL}) o il
+ \itindex{Mandatory~Access~Control~(MAC)} \textit{Mandatory Access Control}
+ di \index{SELinux} SELinux; inoltre basandosi sul lavoro effettuato con
+ SELinux, a partire dal kernel 2.5.x, è iniziato lo sviluppo di una
+ infrastruttura di sicurezza, i \itindex{Linux~Security~Modules}
+ \textit{Linux Security Modules}, o LSM, in grado di fornire diversi agganci
+ a livello del kernel per modularizzare tutti i possibili controlli di
+ accesso.} di sicurezza di un sistema unix-like è fondato sui concetti di
+utente e gruppo, e sulla separazione fra l'amministratore (\textsl{root},
+detto spesso anche \textit{superuser}) che non è sottoposto a restrizioni, ed
+il resto degli utenti, per i quali invece vengono effettuati i vari controlli
+di accesso.
+
+Abbiamo già accennato come il sistema associ ad ogni utente e gruppo due
+identificatori univoci, lo user-ID ed il group-ID; questi servono al kernel per
+identificare uno specifico utente o un gruppo di utenti, per poi poter
+controllare che essi siano autorizzati a compiere le operazioni richieste. Ad
+esempio in sez.~\ref{sec:file_access_control} vedremo come ad ogni file vengano
+associati un utente ed un gruppo (i suoi \textsl{proprietari}, indicati
+appunto tramite un \acr{uid} ed un \acr{gid}) che vengono controllati dal
+kernel nella gestione dei permessi di accesso.
+
+Dato che tutte le operazioni del sistema vengono compiute dai processi, è
+evidente che per poter implementare un controllo sulle operazioni occorre
+anche poter identificare chi è che ha lanciato un certo programma, e pertanto
+anche a ciascun processo dovrà essere associato un utente e un gruppo.
+
+Un semplice controllo di una corrispondenza fra identificativi non garantisce
+però sufficiente flessibilità per tutti quei casi in cui è necessario poter
+disporre di privilegi diversi, o dover impersonare un altro 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} (cioè \textsl{reali} ed
+\textsl{effettivi}). Nel caso di Linux si aggiungono poi altri due gruppi, il
+\textit{saved} (\textsl{salvati}) ed il \textit{filesystem} (\textsl{di
+ filesystem}), secondo la situazione illustrata in
+tab.~\ref{tab:proc_uid_gid}.
+
+\begin{table}[htb]
+ \footnotesize
+ \centering
+ \begin{tabular}[c]{|c|c|l|p{7.3cm}|}
+ \hline
+ \textbf{Suffisso} & \textbf{Gruppo} & \textbf{Denominazione}
+ & \textbf{Significato} \\
+ \hline
+ \hline
+ \acr{uid} & \textit{real} & \textsl{user-ID reale}
+ & Indica l'utente che ha lanciato il programma.\\
+ \acr{gid} & '' &\textsl{group-ID reale}
+ & Indica il gruppo principale dell'utente che ha lanciato
+ il programma.\\
+ \hline
+ \acr{euid} & \textit{effective} &\textsl{user-ID effettivo}
+ & Indica l'utente usato nel controllo di accesso.\\
+ \acr{egid} & '' & \textsl{group-ID effettivo}
+ & Indica il gruppo usato nel controllo di accesso.\\
+ -- & -- & \textsl{group-ID supplementari}
+ & Indicano gli ulteriori gruppi cui l'utente appartiene.\\
+ \hline
+ -- & \textit{saved} & \textsl{user-ID salvato}
+ & È una copia dell'\acr{euid} iniziale.\\
+ -- & '' & \textsl{group-ID salvato}
+ & È una copia dell'\acr{egid} iniziale.\\
+ \hline
+ \acr{fsuid} & \textit{filesystem} &\textsl{user-ID di filesystem}
+ & Indica l'utente effettivo per l'accesso al filesystem. \\
+ \acr{fsgid} & '' & \textsl{group-ID di filesystem}
+ & Indica il gruppo effettivo per l'accesso al filesystem.\\
+ \hline
+ \end{tabular}
+ \caption{Identificatori di utente e gruppo associati a ciascun processo con
+ indicazione dei suffissi usati dalle varie funzioni di manipolazione.}
+ \label{tab:proc_uid_gid}
+\end{table}
+
+Al primo gruppo appartengono l'\textsl{user-ID reale} ed il \textsl{group-ID
+ reale}: questi vengono impostati al login ai valori corrispondenti
+all'utente con cui si accede al sistema (e relativo gruppo principale).
+Servono per l'identificazione dell'utente e normalmente non vengono mai
+cambiati. In realtà vedremo (in sez.~\ref{sec:proc_setuid}) che è possibile
+modificarli, ma solo ad un processo che abbia i privilegi di amministratore;
+questa possibilità è usata proprio dal programma \cmd{login} che, una volta
+completata la procedura di autenticazione, lancia una shell per la quale
+imposta questi identificatori ai valori corrispondenti all'utente che entra
+nel sistema.
+
+Al secondo gruppo appartengono lo \textsl{user-ID effettivo} ed il
+\textsl{group-ID effettivo} (a cui si aggiungono gli eventuali \textsl{group-ID
+ supplementari} dei gruppi dei quali l'utente fa parte). Questi sono invece
+gli identificatori usati nelle verifiche dei permessi del processo e per il
+controllo di accesso ai file (argomento affrontato in dettaglio in
+sez.~\ref{sec:file_perm_overview}).
+
+Questi identificatori normalmente sono identici ai corrispondenti del gruppo
+\textit{real} tranne nel caso in cui, come accennato in
+sez.~\ref{sec:proc_exec}, il programma che si è posto in esecuzione abbia i
+bit \itindex{suid~bit} \acr{suid} o \itindex{sgid~bit} \acr{sgid} impostati
+(il significato di questi bit è affrontato in dettaglio in
+sez.~\ref{sec:file_special_perm}). In questo caso essi saranno impostati
+all'utente e al gruppo proprietari del file. Questo consente, per programmi in
+cui ci sia 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}, anche tutti questi
+identificatori possono essere letti attraverso le rispettive funzioni:
+\funcd{getuid}, \funcd{geteuid}, \funcd{getgid} e \funcd{getegid}, i loro
+prototipi sono:
+\begin{functions}
+ \headdecl{unistd.h}
+ \headdecl{sys/types.h}
+ \funcdecl{uid\_t getuid(void)} Restituisce l'\textsl{user-ID reale} del
+ processo corrente.
+
+ \funcdecl{uid\_t geteuid(void)} Restituisce l'\textsl{user-ID effettivo} del
+ processo corrente.
+
+ \funcdecl{gid\_t getgid(void)} Restituisce il \textsl{group-ID reale} del
+ processo corrente.
+
+ \funcdecl{gid\_t getegid(void)} Restituisce il \textsl{group-ID effettivo}
+ del processo corrente.
+
+ \bodydesc{Queste funzioni non riportano condizioni di errore.}
+\end{functions}
+
+In generale l'uso di privilegi superiori deve essere limitato il più
+possibile, per evitare abusi e problemi di sicurezza, per questo occorre anche
+un meccanismo che consenta ad un programma di rilasciare gli eventuali
+maggiori privilegi necessari, una volta che si siano effettuate le operazioni
+per i quali erano richiesti, e a poterli eventualmente recuperare in caso
+servano di nuovo.
+
+Questo in Linux viene fatto usando altri due gruppi di identificatori, il
+\textit{saved} ed il \textit{filesystem}. Il primo gruppo è lo stesso usato in
+SVr4, e previsto dallo standard POSIX quando è 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.
+
+L'\textsl{user-ID salvato} ed il \textsl{group-ID salvato} sono copie
+dell'\textsl{user-ID effettivo} e del \textsl{group-ID effettivo} del processo
+padre, e vengono impostati dalla funzione \func{exec} all'avvio del processo,
+come copie dell'\textsl{user-ID effettivo} e del \textsl{group-ID effettivo}
+dopo che questi sono stati impostati tenendo conto di eventuali
+\itindex{suid~bit} \acr{suid} o \itindex{sgid~bit} \acr{sgid}. Essi quindi
+consentono di tenere traccia di quale fossero utente e gruppo effettivi
+all'inizio dell'esecuzione di un nuovo programma.
+
+L'\textsl{user-ID di filesystem} e il \textsl{group-ID di filesystem} sono
+un'estensione introdotta in Linux per rendere più sicuro l'uso di NFS
+(torneremo sull'argomento in sez.~\ref{sec:proc_setuid}). Essi sono una
+replica dei corrispondenti identificatori del gruppo \textit{effective}, ai
+quali si sostituiscono per tutte le operazioni di verifica dei permessi
+relativi ai file (trattate in sez.~\ref{sec:file_perm_overview}). Ogni
+cambiamento effettuato sugli identificatori effettivi viene automaticamente
+riportato su di essi, per cui in condizioni normali si può tranquillamente
+ignorarne l'esistenza, in quanto saranno del tutto equivalenti ai precedenti.
+
+
+\subsection{Le funzioni di gestione degli identificatori dei processi}
+\label{sec:proc_setuid}
+
+Le due funzioni più comuni che vengono usate per cambiare identità (cioè
+utente e gruppo di appartenenza) ad un processo sono rispettivamente
+\funcd{setuid} e \funcd{setgid}; come accennato in
+sez.~\ref{sec:proc_access_id} in Linux esse seguono la semantica POSIX che
+prevede l'esistenza dell'\textit{user-ID salvato} e del \textit{group-ID
+ salvato}; i loro prototipi sono:
+\begin{functions}
+\headdecl{unistd.h}
+\headdecl{sys/types.h}
+
+\funcdecl{int setuid(uid\_t uid)} Imposta l'\textsl{user-ID} del processo
+corrente.
+
+\funcdecl{int setgid(gid\_t gid)} Imposta il \textsl{group-ID} del processo
+corrente.
+
+\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
+ di fallimento: l'unico errore possibile è \errval{EPERM}.}
+\end{functions}
+
+Il funzionamento di queste due funzioni è analogo, per cui considereremo solo
+la prima; la seconda si comporta esattamente allo stesso modo facendo
+riferimento al \textsl{group-ID} invece che all'\textsl{user-ID}. Gli
+eventuali \textsl{group-ID supplementari} non vengono modificati.
+
+L'effetto della chiamata è diverso a seconda dei privilegi del processo; se
+l'\textsl{user-ID effettivo} è zero (cioè è quello dell'amministratore di
+sistema) allora tutti gli identificatori (\textit{real}, \textit{effective} e
+\textit{saved}) vengono impostati al valore specificato da \param{uid},
+altrimenti viene impostato solo l'\textsl{user-ID effettivo}, e soltanto se il
+valore specificato corrisponde o all'\textsl{user-ID reale} o
+all'\textsl{user-ID salvato}. Negli altri casi viene segnalato un errore (con
+\errcode{EPERM}).
+
+Come accennato l'uso principale di queste funzioni è quello di poter
+consentire ad un programma con i bit \itindex{suid~bit} \acr{suid} o
+\itindex{sgid~bit} \acr{sgid} impostati (vedi sez.~\ref{sec:file_special_perm})
+di riportare l'\textsl{user-ID effettivo} a quello dell'utente che ha lanciato
+il programma, effettuare il lavoro che non necessita di privilegi aggiuntivi,
+ed eventualmente tornare indietro.
+
+Come esempio per chiarire l'uso di queste funzioni prendiamo quello con cui
+viene gestito l'accesso al file \sysfile{/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 potrebbe
+falsificare la registrazione. Per questo motivo questo file (e l'analogo
+\sysfile{/var/log/wtmp} su cui vengono registrati login e logout) appartengono
+ad un gruppo dedicato (\acr{utmp}) ed i programmi che devono accedervi (ad
+esempio tutti i programmi di terminale in X, o il programma \cmd{screen} che
+crea terminali multipli su una console) appartengono a questo gruppo ed hanno
+il bit \acr{sgid} impostato.
+
+Quando uno di questi programmi (ad esempio \cmd{xterm}) viene lanciato, la
+situazione degli identificatori è la seguente:
+\begin{eqnarray*}
+ \label{eq:1}
+ \textsl{group-ID reale} &=& \textrm{\acr{gid} (del chiamante)} \\
+ \textsl{group-ID effettivo} &=& \textrm{\acr{utmp}} \\
+ \textsl{group-ID salvato} &=& \textrm{\acr{utmp}}
+\end{eqnarray*}
+in questo modo, dato che il \textsl{group-ID effettivo} è quello giusto, il
+programma può accedere a \sysfile{/var/log/utmp} in scrittura ed aggiornarlo.
+A questo punto il programma può eseguire una \code{setgid(getgid())} per
+impostare il \textsl{group-ID effettivo} a quello dell'utente (e dato che il
+\textsl{group-ID reale} 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}
+ \textsl{group-ID reale} &=& \textrm{\acr{gid} (invariato)} \\
+ \textsl{group-ID effettivo} &=& \textrm{\acr{gid}} \\
+ \textsl{group-ID salvato} &=& \textrm{\acr{utmp} (invariato)}
+\end{eqnarray*}
+e ogni processo lanciato dal terminale avrebbe comunque \acr{gid} come
+\textsl{group-ID effettivo}. All'uscita dal terminale, per poter di nuovo
+aggiornare lo stato di \sysfile{/var/log/utmp} il programma eseguirà una
+\code{setgid(utmp)} (dove \var{utmp} è il valore numerico associato al gruppo
+\acr{utmp}, ottenuto ad esempio con una precedente \func{getegid}), dato che
+in questo caso il valore richiesto corrisponde al \textsl{group-ID salvato} la
+funzione avrà successo e riporterà la situazione a:
+\begin{eqnarray*}
+ \label{eq:3}
+ \textsl{group-ID reale} &=& \textrm{\acr{gid} (invariato)} \\
+ \textsl{group-ID effettivo} &=& \textrm{\acr{utmp}} \\
+ \textsl{group-ID salvato} &=& \textrm{\acr{utmp} (invariato)}
+\end{eqnarray*}
+consentendo l'accesso a \sysfile{/var/log/utmp}.
+
+Occorre però tenere conto che tutto questo non è possibile con un processo con
+i privilegi di amministratore, in tal caso infatti l'esecuzione di 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'\textsl{user-ID effettivo} del processo per cedere i privilegi occorre
+ricorrere ad altre funzioni.
+
+Le due funzioni \funcd{setreuid} e \funcd{setregid} derivano da BSD che, non
+supportando\footnote{almeno fino alla versione 4.3+BSD.} gli identificatori
+del gruppo \textit{saved}, le usa per poter scambiare fra di loro
+\textit{effective} e \textit{real}. I rispettivi prototipi sono:
+\begin{functions}
+\headdecl{unistd.h}
+\headdecl{sys/types.h}
+
+\funcdecl{int setreuid(uid\_t ruid, uid\_t euid)} Imposta l'\textsl{user-ID
+ reale} e l'\textsl{user-ID effettivo} del processo corrente ai valori
+specificati da \param{ruid} e \param{euid}.
+
+\funcdecl{int setregid(gid\_t rgid, gid\_t egid)} Imposta il \textsl{group-ID
+ reale} ed il \textsl{group-ID effettivo} del processo corrente ai valori
+specificati da \param{rgid} e \param{egid}.