+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 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 setgid(gid\_t gid)} setta il \textit{group ID} del processo
+corrente.
+
+Le funzioni restituiscono 0 in caso di successo e -1 in caso di fallimento:
+l'unico errore possibile è \macro{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 \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 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 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
+riportare l'\textit{effective user id} 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 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 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
+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} settato.
+
+Quando uno di questi programmi (ad esempio \cmd{xterm}) viene lanciato la
+situazione degli identificatori è la seguente:
+\begin{eqnarray*}
+ \label{eq:1}
+ \textit{real group id} &=& \textrm{\acr{gid} (del chiamante)} \\
+ \textit{effective group id} &=& \textrm{\acr{utmp}} \\
+ \textit{saved group id} &=& \textrm{\acr{utmp}}
+\end{eqnarray*}
+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 (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)} \\
+ \textit{effective group id} &=& \textrm{\acr{gid}} \\
+ \textit{saved group id} &=& \textrm{\acr{utmp} (invariato)}
+\end{eqnarray*}
+e ogni processo lanciato dal terminale avrebbe comunque \acr{gid} come
+\textit{effective group id}. All'uscita dal terminale, per poter di nuovo
+aggiornare lo stato di \file{/var/log/utmp} il programma eseguirà una
+\func{setgid(utmp)} (dove \var{utmp} è il valore numerico associato al gruppo
+\acr{utmp}, ottenuto ad esempio con una \func{getegid}), dato che in questo
+caso il valore richiesto corrisponde al \textit{saved group id} la funzione
+avrà successo e riporterà la situazione a:
+\begin{eqnarray*}
+ \label{eq:3}
+ \textit{real group id} &=& \textrm{\acr{gid} (invariato)} \\
+ \textit{effective group id} &=& \textrm{\acr{utmp}} \\
+ \textit{saved group id} &=& \textrm{\acr{utmp} (invariato)}
+\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}
+
+\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}.
+
+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 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.