X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=prochand.tex;h=4c16fe24584e65fc4321a5a33012e3a4adcc603d;hp=69bdb16e4224a89cfe216fca14896f760804029b;hb=607aae2f62d086e9c71d6a571bbbb6908631207c;hpb=c6bb1ae340cad082718e43163b9595608ed123e1 diff --git a/prochand.tex b/prochand.tex index 69bdb16..4c16fe2 100644 --- a/prochand.tex +++ b/prochand.tex @@ -1,90 +1,173 @@ \chapter{La gestione dei processi} \label{cha:process_handling} -Come accennato nell'introduzione in un sistema unix ogni attività del sistema -viene svolta tramite i processi. In sostanza i processi costituiscono l'unità -base per l'allocazione e l'uso delle risorse del sistema. +Come accennato nell'introduzione in un sistema Unix tutte le operazioni +vengono svolte tramite opportuni processi. In sostanza questi ultimi vengono +a costituire l'unità base per l'allocazione e l'uso delle risorse del sistema. + +Nel precedente capitolo abbiamo esaminato il funzionamento di un processo come +unità a se stante, in questo esamineremo il funzionamento dei processi +all'interno del sistema. Saranno cioè affrontati i dettagli della creazione e +della terminazione dei processi, della gestione dei loro attributi e +privilegi, e di tutte le funzioni a questo connesse. Infine nella sezione +finale introdurremo alcune problematiche generiche della programmazione in +ambiente multitasking. -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. \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. +Inizieremo con una introduzione generale ai concetti che stanno alla base +della gestione dei processi in un sistema unix-like. Introdurremo in questa +sezione l'architettura della gestione dei processi e le sue principali +caratteristiche, dando una panoramica sull'uso delle principali funzioni di +gestione. + -\subsection{La gerarchia dei processi} +\subsection{L'architettura della gestione dei processi} \label{sec:proc_hierarchy} A differenza di quanto avviene in altri sistemi (ad esempio nel VMS la generazione di nuovi processi è un'operazione privilegiata) una delle -caratteristiche di unix (che esamineremo in dettaglio più avanti) è che +caratteristiche di Unix (che esamineremo in dettaglio più avanti) è che qualunque processo può a sua volta generarne altri, detti processi figli (\textit{child process}). Ogni processo è identificato presso il sistema da un -numero unico, il \acr{pid} (da \textit{process identifier}). - -Una seconda caratteristica è che la generazione di un processo è una -operazione separata rispetto al lancio di un programma. In genere la sequenza -è sempre quella di creare un nuovo processo, il quale si eseguirà, in un passo -successivo, il programma voluto: questo è ad esempio quello che fa la shell -quando mette in esecuzione il programma che gli indichiamo nella linea di -comando. - -Una terza caratteristica è che ogni processo viene sempre generato da un altro -che viene chiamato processo genitore (\textit{parent process}). Questo vale -per tutti i processi, con una eccezione (dato che ci deve essere un punto di -partenza), esiste sempre infatti un processo speciale, che normalmente è -\cmd{/sbin/init}, che viene lanciato dal kernel quando questo ha finito la -fase di avvio, esso essendo il primo processo lanciato ha sempre il \acr{pid} -uguale a 1 e non è figlio di nessuno. - -Questo è ovviamente un processo speciale, che in genere si occupa di far -partire tutti gli processi altri necessari al funzionamento del sistema, +numero unico, il cosiddetto \textit{process identifier} o, più brevemente, +\acr{pid}. + +Una seconda caratteristica di un sistema Unix è che la generazione di un +processo è una operazione separata rispetto al lancio di un programma. In +genere la sequenza è sempre quella di creare un nuovo processo, il quale +eseguirà, in un passo successivo, il programma voluto: questo è ad esempio +quello che fa la shell quando mette in esecuzione il programma che gli +indichiamo nella linea di comando. + +Una terza caratteristica è che ogni processo è sempre stato generato da un +altro, che viene chiamato processo padre (\textit{parent process}). Questo +vale per tutti i processi, con una sola eccezione: dato che ci deve essere un +punto di partenza esiste un processo speciale (che normalmente è +\cmd{/sbin/init}), che viene lanciato dal kernel alla conclusione della fase +di avvio; essendo questo il primo processo lanciato dal sistema ha sempre il +\acr{pid} uguale a 1 e non è figlio di nessun altro processo. + +Ovviamente \cmd{init} è un processo speciale che in genere si occupa di far +partire tutti gli altri processi necessari al funzionamento del sistema, inoltre \cmd{init} è essenziale per svolgere una serie di compiti -amministrativi nelle operazioni ordinarie del sistema (torneremo si alcuni di -essi in \secref{}) e non può mai essere terminato. La struttura del sistema -comunque consente di lanciare al posto di \cmd{init} qualunque altro programma -(e in casi di emergenza, ad esempio se il file di \cmd{init} si fosse -corrotto, è possibile farlo ad esempio passando la riga \cmd{init=/bin/sh} -all'avvio). - -Dato che tutti i processi successivi sono comunque generati da \cmd{init} o da -suoi figli tutto ciò comporta che, i processi sono organizzati gerarchicamente -dalla relazione fra genitori e figli, in maniera analoga a come i file sono -organizzati in un albero di directory con alla base \file{/} (si veda -\secref{sec:file_file_struct}); in questo caso alla base dell'albero c'è il -processo \cmd{init} che è progenitore di ogni altro processo\footnote{in - realtà questo non è del tutto vero, in Linux ci sono alcuni processi che pur - comparendo come figli di init (ad esempio in \cmd{pstree}) sono generati - direttamente dal kernel, come \cmd{keventd}, \cmd{kswapd}, etc.}. - - -\subsection{Una panoramica sulle funzioni di gestione} +amministrativi nelle operazioni ordinarie del sistema (torneremo su alcuni di +essi in \secref{sec:proc_termination}) e non può mai essere terminato. La +struttura del sistema comunque consente di lanciare al posto di \cmd{init} +qualunque altro programma, e in casi di emergenza (ad esempio se il file di +\cmd{init} si fosse corrotto) è ad esempio possibile lanciare una shell al suo +posto, passando la riga \cmd{init=/bin/sh} come parametro di avvio. + +\begin{figure}[!htb] + \footnotesize +\begin{verbatim} +[piccardi@gont piccardi]$ pstree -n +init-+-keventd + |-kapm-idled + |-kreiserfsd + |-portmap + |-syslogd + |-klogd + |-named + |-rpc.statd + |-gpm + |-inetd + |-junkbuster + |-master-+-qmgr + | `-pickup + |-sshd + |-xfs + |-cron + |-bash---startx---xinit-+-XFree86 + | `-WindowMaker-+-ssh-agent + | |-wmtime + | |-wmmon + | |-wmmount + | |-wmppp + | |-wmcube + | |-wmmixer + | |-wmgtemp + | |-wterm---bash---pstree + | `-wterm---bash-+-emacs + | `-man---pager + |-5*[getty] + |-snort + `-wwwoffled +\end{verbatim} %$ + \caption{L'albero dei processi, così come riportato dal comando + \cmd{pstree}.} + \label{fig:proc_tree} +\end{figure} + +Dato che tutti i processi attivi nel sistema sono comunque generati da +\cmd{init} o da uno dei suoi figli\footnote{in realtà questo non è del tutto + vero, in Linux ci sono alcuni processi che pur comparendo come figli di + init, o con \acr{pid} successivi, sono in realtà generati direttamente dal + kernel, (come \cmd{keventd}, \cmd{kswapd}, etc.)} si possono classificare i +processi con la relazione padre/figlio in una organizzazione gerarchica ad +albero, in maniera analoga a come i file sono organizzati in un albero di +directory (si veda \secref{sec:file_organization}); in \curfig\ si è mostrato +il risultato del comando \cmd{pstree} che permette di mostrare questa +struttura, alla cui base c'è \cmd{init} che è progenitore di tutti gli altri +processi. + + +Il kernel mantiene una tabella dei processi attivi, la cosiddetta +\textit{process table}; per ciascun processo viene mantenuta una voce nella +tabella dei processi costituita da una struttura \type{task\_struct}, che +contiene tutte le informazioni rilevanti per quel processo. Tutte le strutture +usate a questo scopo sono dichiarate nell'header file \file{linux/sched.h}, ed +uno schema semplificato che riporta la struttura delle principali informazioni +contenute nella \type{task\_struct} (che in seguito incontreremo a più +riprese), è mostrato in \nfig. + +\begin{figure}[htb] + \centering + \includegraphics[width=13cm]{img/task_struct} + \caption{Schema semplificato dell'architettura delle strutture usate dal + kernel nella gestione dei processi.} + \label{fig:proc_task_struct} +\end{figure} + + +Come accennato in \secref{sec:intro_unix_struct} è lo \textit{scheduler} che +decide quale processo mettere in esecuzione; esso viene eseguito ad ogni +system call ed ad ogni interrupt, (ma può essere anche attivato +esplicitamente). Il timer di sistema provvede comunque a che esso sia invocato +periodicamente, generando un interrupt periodico secondo la frequenza +specificata dalla costante \macro{HZ}, definita in \file{asm/param.h} Il +valore usuale è 100 (è espresso in Hertz), si ha cioè un interrupt dal timer +ogni centesimo di secondo. + +Ogni volta che viene eseguito, lo \textit{scheduler} effettua il calcolo delle +priorità dei vari processi attivi (torneremo su questo in +\secref{sec:proc_priority}) e stabilisce quale di essi debba essere posto in +esecuzione fino alla successiva invocazione. + + +\subsection{Una panoramica sulle funzioni fondamentali} \label{sec:proc_handling_intro} I processi vengono creati dalla funzione \func{fork}; in molti unix questa è -una system call, Linux però usa un'altra nomenclatura, e la funzione fork è -basata a sua volta sulla system call \func{\_\_clone}, che viene usata anche -per generare i \textit{thread}. Il processo figlio creato dalla \func{fork} è -una copia identica del processo processo padre, ma ha nuovo \acr{pid} e viene -eseguito in maniera indipendente (le differenze fra padre e figlio sono -affrontate in dettaglio in \secref{sec:proc_fork}). +una system call, Linux però usa un'altra nomenclatura, e la funzione +\func{fork} è basata a sua volta sulla system call \func{\_\_clone}, che viene +usata anche per generare i \textit{thread}. Il processo figlio creato dalla +\func{fork} è una copia identica del processo processo padre, ma ha nuovo +\acr{pid} e viene eseguito in maniera indipendente (le differenze fra padre e +figlio sono affrontate in dettaglio in \secref{sec:proc_fork}). Se si vuole che il processo padre si fermi fino alla conclusione del processo figlio questo deve essere specificato subito dopo la \func{fork} chiamando la -funzione \func{wait} o la funzione \func{waitpid}; queste funzioni -restituiscono anche una informazione abbastanza limitata (il codice di uscita) -sulle cause della terminazione del processo. +funzione \func{wait} o la funzione \func{waitpid} (si veda +\secref{sec:proc_wait}); queste funzioni restituiscono anche una informazione +abbastanza limitata sulle cause della terminazione del processo figlio. Quando un processo ha concluso il suo compito o ha incontrato un errore non risolvibile esso può essere terminato con la funzione \func{exit} (si veda -quanto discusso in \secref{sec:proc_termination}). La vita del processo però +quanto discusso in \secref{sec:proc_conclusion}). La vita del processo però termina solo quando la notifica della sua conclusione viene ricevuta dal processo padre, a quel punto tutte le risorse allocate nel sistema ad esso associate vengono rilasciate. @@ -110,13 +193,14 @@ non ritorna mai (in quanto con essa viene eseguito un altro programma). -\section{La gestione dei processi} +\section{Le funzioni di base}% della gestione dei processi} \label{sec:proc_handling} -In questa sezione tratteremo le funzioni per la gestione dei processi, a -partire dalle funzioni elementari che permettono di leggerne gli -identificatori, alle varie funzioni di manipolazione dei processi, che -riguardano la loro creazione, terminazione, e la messa in esecuzione di altri +In questa sezione tratteremo le problematiche della gestione dei processi +all'interno del sistema, illustrandone tutti i dettagli. Inizieremo con le +funzioni elementari che permettono di leggerne gli identificatori, per poi +passare alla spiegazione delle funzioni base che si usano per la creazione e +la terminazione dei processi, e per la messa in esecuzione degli altri programmi. @@ -126,97 +210,105 @@ programmi. Come accennato nell'introduzione ogni processo viene identificato dal sistema da un numero identificativo unico, il \textit{process id} o \acr{pid}; quest'ultimo è un tipo di dato standard, il \type{pid\_t} che in genere è un -intero con segno (nel caso di Linux e delle glibc il tipo usato è \type{int}). +intero con segno (nel caso di Linux e delle \acr{glibc} il tipo usato è \type{int}). Il \acr{pid} viene assegnato in forma progressiva ogni volta che un nuovo processo viene creato, fino ad un limite massimo (in genere essendo detto numero memorizzato in un intero a 16 bit si arriva a 32767) oltre il quale si -riparte dal numero più basso disponibile (FIXME: verificare, non sono sicuro). -Per questo motivo processo il processo di avvio (\cmd{init}) ha sempre il -\acr{pid} uguale a uno. +riparte dal numero più basso disponibile\footnote{FIXME: verificare, non sono + sicuro}. Per questo motivo processo il processo di avvio (\cmd{init}) ha +sempre il \acr{pid} uguale a uno. 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}) ed è normalmente utilizzato per il controllo di -sessione. Questi due identificativi possono essere ottenuti da programma -usando le funzioni: +\textit{parent process id}). Questi due identificativi possono essere +ottenuti da programma usando le funzioni: \begin{functions} \headdecl{sys/types.h} \headdecl{unistd.h} -\funcdecl{pid\_t getpid(void)} restituisce il pid del processo corrente. -\funcdecl{pid\_t getppid(void)} restituisce il pid del padre del processo +\funcdecl{pid\_t getpid(void)} Restituisce il pid del processo corrente. +\funcdecl{pid\_t getppid(void)} Restituisce il pid del padre del processo corrente. -Entrambe le funzioni non riportano condizioni di errore. +\bodydesc{Entrambe le funzioni non riportano condizioni di errore.} \end{functions} +\noindent esempi dell'uso di queste funzioni sono riportati in +\figref{fig:proc_fork_code}, nel programma di esempio \file{ForkTest.c}. -Il fatto che il \acr{pid} sia un numero univoco per il sistema lo rende il -candidato ideale per generare ulteriori indicatori associati al processo di -cui diventa possibile garantire l'unicità: ad esempio la funzione -\func{tmpname} (si veda \secref{sec:file_temp_file}) usa il \acr{pid} per -generare un pathname univoco, che non potrà essere replicato da un'altro -processo che usi la stessa funzione. +Il fatto che il \acr{pid} sia un numero univoco per il sistema lo rende un +candidato per generare ulteriori indicatori associati al processo di cui +diventa possibile garantire l'unicità: ad esempio in alcune implementazioni la +funzione \func{tmpname} (si veda \secref{sec:file_temp_file}) usa il \acr{pid} +per generare un pathname univoco, che non potrà essere replicato da un'altro +processo che usi la stessa funzione. Tutti i processi figli dello stesso processo padre sono detti -\textit{sibling}, questa è un'altra delle relazioni usate nel controllo di -sessione, in cui si raggruppano tutti i processi creati su uno stesso -terminale una volta che si è effettuato il login. Torneremo su questo -argomento in \secref{cap:terminal}, dove esamineremo tutti gli altri -identificativi associati ad un processo relativi al controllo di sessione. +\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{cha:session}, dove esamineremo gli altri identificativi associati ad +un processo e le varie relazioni fra processi utilizzate per definire una +sessione. + +Oltre al \acr{pid} e al \acr{ppid}, (e a quelli che vedremo in +\secref{sec:sess_xxx}, relativi al controllo di sessione), ad ogni processo +vengono associati degli altri identificatori che vengono usati per il +controllo di accesso. Questi servono per determinare se un processo può +eseguire o meno le operazioni richieste, a seconda dei privilegi e +dell'identità di chi lo ha posto in esecuzione; l'argomento è complesso e sarà +affrontato in dettaglio in \secref{sec:proc_perms}. \subsection{La funzione \func{fork}} \label{sec:proc_fork} -La funzione \func{fork} è la funzione fondamentale della gestione dei processi -in unix; come si è detto l'unico modo di creare un nuovo processo è attraverso -l'uso di questa funzione, che è quindi la base per il multitasking. Il prototipo -della funzione è: - +La funzione \func{fork} è la funzione fondamentale della gestione dei +processi: come si è detto l'unico modo di creare un nuovo processo è +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} \funcdecl{pid\_t fork(void)} - Restituisce zero al padre e il \acr{pid} al figlio in caso di successo, - ritorna -1 al padre (senza creare il figlio) in caso di errore; - \texttt{errno} può assumere i valori: + Crea un nuovo processo. + + \bodydesc{Restituisce zero al padre e il \acr{pid} al figlio in caso di + successo, ritorna -1 al padre (senza creare il figlio) in caso di errore; + \var{errno} può assumere i valori: \begin{errlist} - \item \macro{EAGAIN} non ci sono risorse sufficienti per creare un'altro + \item[\macro{EAGAIN}] non ci sono risorse sufficienti per creare un'altro processo (per allocare la tabella delle pagine e le strutture del task) o si è esaurito il numero di processi disponibili. - \item \macro{ENOMEM} non è stato possibile allocare la memoria per le + \item[\macro{ENOMEM}] non è stato possibile allocare la memoria per le strutture necessarie al kernel per creare il nuovo processo. - \end{errlist} + \end{errlist}} \end{functions} -Dopo l'esecuzione di una \func{fork} sia il processo padre che il processo -figlio continuano ad essere eseguiti normalmente alla istruzione seguente la -\func{fork}; il processo figlio è però una copia del padre, e riceve una copia -dei segmenti di testo, stack e dati (vedi \secref{sec:proc_mem_layout}), ed -esegue esattamente lo stesso codice del padre, ma la memoria è copiata, non -condivisa\footnote{In generale il segmento di testo, che è identico, è - condiviso e tenuto in read-only, Linux poi utilizza la tecnica del - \textit{copy-on-write}, per cui la memoria degli altri segmenti viene - copiata dal kernel per il nuovo processo solo in caso di scrittura, rendendo - molto più efficiente il meccanismo} pertanto padre e figlio vedono variabili -diverse. +Dopo il successo dell'esecuzione di una \func{fork} sia il processo padre che +il processo figlio continuano ad essere eseguiti normalmente alla istruzione +seguente la \func{fork}; il processo figlio è però una copia del padre, e +riceve una copia dei segmenti di testo, stack e dati (vedi +\secref{sec:proc_mem_layout}), ed esegue esattamente lo stesso codice del +padre, ma la memoria è copiata, non condivisa,\footnote{In generale il segmento + di testo, che è identico, è condiviso e tenuto in read-only, Linux poi + utilizza la tecnica del \textit{copy-on-write}, per cui la memoria degli + altri segmenti viene copiata dal kernel per il nuovo processo solo in caso + di scrittura, rendendo molto più efficiente il meccanismo della creazione di + un nuovo processo.} pertanto padre e figlio vedono variabili diverse. La differenza che si ha nei due processi è che nel processo padre il valore di -ritorno della funzione fork è il \acr{pid} del processo figlio, mentre nel -figlio è zero; in questo modo il programma può identificare se viene eseguito -dal padre o dal figlio. -Si noti come la funzione \func{fork} ritorni \textbf{due} volte: una nel padre -e una nel figlio. La sola differenza che si ha nei due processi è il valore di -ritorno restituito dalla funzione, che nel padre è il \acr{pid} del figlio -mentre nel figlio è zero; in questo modo il programma può identificare se -viene eseguito dal padre o dal figlio. - -La scelta di questi valori non è casuale, un processo infatti può avere più -figli, ed il valore di ritorno di \func{fork} è l'unico modo che permette di -identificare quello appena creato; al contrario un figlio ha sempre un solo -padre (il cui \acr{pid} può sempre essere ottenuto con \func{getppid}, vista -in \secref{sec:proc_pid}) e si usa il valore nullo, che non può essere il -\acr{pid} di nessun processo. +ritorno della funzione \func{fork} è il \acr{pid} del processo figlio, mentre +nel figlio è zero; in questo modo il programma può identificare se viene +eseguito dal padre o dal figlio. Si noti come la funzione \func{fork} ritorni +\textbf{due} volte: una nel padre e una nel figlio. + +La scelta di questi valori di ritorno non è casuale, un processo infatti può +avere più figli, ed il valore di ritorno di \func{fork} è l'unico modo che gli +permette di identificare quello appena creato; al contrario un figlio ha +sempre un solo padre (il cui \acr{pid} può sempre essere ottenuto con +\func{getppid}, vedi \secref{sec:proc_pid}) per cui si usa il valore nullo, +che non è il \acr{pid} di nessun processo. \begin{figure}[!htb] \footnotesize @@ -237,26 +329,23 @@ int main(int argc, char *argv[]) */ int nchild, i; pid_t pid; - int wait_child=0; - int wait_parent=0; - + int wait_child = 0; + int wait_parent = 0; + int wait_end = 0; ... /* handling options */ - - /* There must be remaing parameters */ - if (optind == argc) { - usage(); - } nchild = atoi(argv[optind]); printf("Test for forking %d child\n", nchild); /* loop to fork children */ for (i=0; i output [piccardi@selidor sources]$ cat output -Test for forking 3 child +Process 1967: forking 3 child Child 1 successfully executing -Child 1 exiting +Child 1, parent 1967, exiting Test for forking 3 child -Spawned 1 child, pid 836 +Spawned 1 child, pid 1968 Go to next child Child 2 successfully executing -Child 2 exiting +Child 2, parent 1967, exiting Test for forking 3 child -Spawned 1 child, pid 836 +Spawned 1 child, pid 1968 Go to next child -Spawned 2 child, pid 837 +Spawned 2 child, pid 1969 Go to next child Child 3 successfully executing -Child 3 exiting +Child 3, parent 1967, exiting Test for forking 3 child -Spawned 1 child, pid 836 +Spawned 1 child, pid 1968 Go to next child -Spawned 2 child, pid 837 +Spawned 2 child, pid 1969 Go to next child -Spawned 3 child, pid 838 +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 in gran dettaglio in \capref{cha:file_unix_interface} e in \secref{cha:files_std_interface}. Qui basta accennare che si sono usate le funzioni standard della libreria del C che prevedono l'output bufferizzato; e -questa bufferizzazione varia a seconda che si tratti di un file su disco (in -cui il buffer viene scaricato su disco solo quando necessario) o di un -terminale (nel qual caso il buffer viene scaricato ad ogni a capo). +questa bufferizzazione (trattata in dettaglio in \secref{sec:file_buffering}) +varia a seconda che si tratti di un file su disco (in cui il buffer viene +scaricato su disco solo quando necessario) o di un terminale (nel qual caso il +buffer viene scaricato ad ogni carattere di a capo). Nel primo esempio allora avevamo che ad ogni chiamata a \func{printf} il buffer veniva scaricato, e le singole righe erano stampate a video subito dopo l'esecuzione della \func{printf}. Ma con la redirezione su file la scrittura -non avviene più alla fine di ogni riga e l'output resta nel buffer, per questo -motivo, dato che ogni figlio riceve una copia della memoria del padre, esso -riceverà anche quanto c'è nel buffer delle funzioni di I/O, comprese le linee -scritte dal padre fino allora. Così quando all'uscita del figlio il buffer -viene scritto su disco, troveremo nel file anche tutto quello che il processo -padre aveva scritto prima della sua creazione. E alla fine del file, dato che -in questo caso il padre esce per ultimo, troviamo anche l'output del padre. - -Ma l'esempio ci mostra un'altro aspetto fondamentale dell'interazione con i -file, che era valido anche per l'esempio precedente, ma meno evidente; il -fatto cioè che non solo processi diversi possono scrivere in contemporanea -sullo stesso file (l'argomento della condivisione dei file in unix è trattato -in dettaglio in \secref{sec:file_sharing}), ma anche che, a differenza di -quanto avviene per le variabili, la posizione corrente sul file è condivisa -fra il padre e tutti i processi figli. +non avviene più alla fine di ogni riga e l'output resta nel buffer. Dato che +ogni figlio riceve una copia della memoria del padre, esso riceverà anche +quanto c'è nel buffer delle funzioni di I/O, comprese le linee scritte dal +padre fino allora. Così quando il buffer viene scritto su disco all'uscita del +figlio, troveremo nel file anche tutto quello che il processo padre aveva +scritto prima della sua creazione. E alla fine del file (dato che in questo +caso il padre esce per ultimo) troveremo anche l'output completo del padre. + +L'esempio ci mostra un'altro aspetto fondamentale dell'interazione con i file, +valido anche per l'esempio precedente, ma meno evidente: il fatto cioè che non +solo processi diversi possono scrivere in contemporanea sullo stesso file +(l'argomento della condivisione dei file è trattato in dettaglio in +\secref{sec:file_sharing}), ma anche che, a differenza di quanto avviene per +le variabili, la posizione corrente sul file è condivisa fra il padre e tutti +i processi figli. Quello che succede è che quando lo standard output del padre viene rediretto, 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. - -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 -nuovo valore; in questo modo si evita, in casi come quello appena mostrato in -cui diversi processi scrivono sullo stesso file, che l'output successivo di un -processo vada a sovrapporsi a quello dei precedenti (l'output potrà risultare -mescolato, ma non ci saranno parti perdute per via di una sovrascrittura). +descriptor aperti nel padre, il che comporta che padre e figli condividono le +stesse voci della \textit{file table} (per la spiegazione di questi termini si +veda \secref{sec:file_sharing}) e fra cui c'è anche la posizione corrente nel +file. + +In questo modo se un processo scrive sul file aggiornerà la posizione corrente +sulla \textit{file table}, e tutti gli altri processi, che vedono la stessa +\textit{file table}, vedranno il nuovo valore. In questo modo si evita, in +casi come quello appena mostrato in cui diversi processi scrivono sullo stesso +file, che l'output successivo di un processo vada a sovrapporsi a quello dei +precedenti: l'output potrà risultare mescolato, ma non ci saranno parti +perdute per via di una sovrascrittura. Questo tipo di comportamento è essenziale in tutti quei casi in cui il padre -crea un figlio ed attende la sua conclusione per proseguire, ed entrambi -scrivono sullo stesso file, ad esempio lo standard output (un caso tipico è la -shell). Se l'output viene rediretto con questo comportamento avremo che il -padre potrà continuare a scrivere automaticamente in coda a quanto scritto dal -figlio; se così non fosse ottenere questo comportamento sarebbe estremamente -complesso necessitando di una qualche forma di comunicazione fra i due -processi. +crea un figlio e attende la sua conclusione per proseguire, ed entrambi +scrivono sullo stesso file (un caso tipico è la shell quando lancia un +programma, il cui output va sullo standard output). + +In questo modo, anche se l'output viene rediretto, il padre potrà sempre +continuare a scrivere in coda a quanto scritto dal figlio in maniera +automatica; se così non fosse ottenere questo comportamento sarebbe +estremamente complesso necessitando di una qualche forma di comunicazione fra +i due processi per far riprendere al padre la scrittura al punto giusto. In generale comunque non è buona norma far scrivere più processi sullo stesso -file senza una qualche forma di sincronizzazione in quanto, come visto con il -nostro esempio, le varie scritture risulteranno mescolate fra loro in una -sequenza impredicibile. Le modalità con cui in genere si usano i file dopo una -\func{fork} sono sostanzialmente due: +file senza una qualche forma di sincronizzazione in quanto, come visto anche +con il nostro esempio, le varie scritture risulteranno mescolate fra loro in +una sequenza impredicibile. Per questo le modalità con cui in genere si usano +i file dopo una \func{fork} sono sostanzialmente due: \begin{enumerate} \item Il processo padre aspetta la conclusione del figlio. In questo caso non è necessaria nessuna azione riguardo ai file, in quanto la sincronizzazione - degli offset dopo eventuali operazioni di lettura e scrittura effettuate dal - figlio è automatica. + della posizione corrente dopo eventuali operazioni di lettura e scrittura + effettuate dal figlio è automatica. \item L'esecuzione di padre e figlio procede indipendentemente. In questo caso - ciascuno dei due deve chiudere i file che non gli servono una volta che la - \func{fork} è stata eseguita, per evitare ogni forma di interferenza. + ciascuno dei due processi deve chiudere i file che non gli servono una volta + che la \func{fork} è stata eseguita, per evitare ogni forma di interferenza. \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: -\begin{itemize} -\item i file aperti (e gli eventuali flag di \textit{close-on-exec} se - settati). +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} settati + (vedi \secref{sec:proc_exec} e \secref{sec:file_fcntl}). \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 - \secref{tab:proc_uid_gid}). + l'\textit{effective group id} ed i \textit{supplementary group id} (vedi + \secref{sec:proc_access_id}). \item gli identificatori per il controllo di sessione: il \textit{process - group id} e il \textit{session id} e il terminale di controllo. -\item i flag \acr{suid} e \acr{suid} (vedi \secref{sec:file_suid_sgid}). + group id} e il \textit{session id} ed il terminale di controllo (vedi + \secref{sec:sess_xxx} e \secref{sec:sess_xxx}). \item la directory di lavoro e la directory radice (vedi - \secref{sec:file_work_dir}). + \secref{sec:file_work_dir} e \secref{sec:file_chroot}). \item la maschera dei permessi di creazione (vedi \secref{sec:file_umask}). -\item la maschera dei segnali. -\item i segmenti di memoria condivisa agganciati al processo. -\item i limiti sulle risorse +\item la maschera dei segnali bloccati e le azioni installate (vedi +\secref{sec:sig_xxx}). +\item i segmenti di memoria condivisa agganciati al processo (vedi +\secref{sec:ipc_xxx}). +\item i limiti sulle risorse (vedi \secref{sec:sys_xxx}). \item le variabili di ambiente (vedi \secref{sec:proc_environ}). -\end{itemize} -le differenze invece sono: -\begin{itemize} +\end{itemize*} +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}. \item il \textit{parent process id} (quello del figlio viene settato al \acr{pid} del padre). -\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. -\end{itemize} +\item i valori dei tempi di esecuzione (vedi \secref{sec:sys_xxx}) che + nel figlio sono posti a zero. +\item i \textit{file lock} (vedi \secref{sec:file_locking}), che non + vengono ereditati dal figlio. +\item gli allarmi ed i segnali pendenti (vedi \secref{sec:sig_xxx}), che per il figlio vengono cancellati. +\end{itemize*} \subsection{La funzione \func{vfork}} @@ -518,25 +626,31 @@ ritornare o uscire con \func{exit} ma usare esplicitamente \func{\_exit}. Questa funzione è un rimasuglio dei vecchi tempi in cui eseguire una \func{fork} comportava anche la copia completa del segmento dati del processo padre, che costituiva un inutile appesantimento in tutti quei casi in cui la -\func{fork} veniva fatto solo per poi eseguire una \func{exec}. La funzione +\func{fork} veniva fatta solo per poi eseguire una \func{exec}. La funzione venne introdotta in BSD per migliorare le prestazioni. Dato che Linux supporta il \textit{copy on write} la perdita di prestazioni è assolutamente trascurabile, e l'uso di questa funzione (che resta un caso -speciale della funzione \func{clone}), è deprecato, per questo eviteremo di +speciale della funzione \func{clone}), è deprecato; per questo eviteremo di trattarla ulteriormente. \subsection{La conclusione di un processo.} \label{sec:proc_termination} -In \secref{sec:proc_conclusion} abbiamo già affrontato le tre modalità con cui -si conclude un programma in maniera normale: la chiamata di \func{exit} (che -esegue le funzioni registrate e chiude gli stream), il ritorno dalla funzione -\func{main} (equivalente alla chiamata di \func{exit}), e la chiamata ad -\func{\_exit} (che esegue direttamente la terminazione del processo). +In \secref{sec:proc_conclusion} abbiamo già affrontato le modalità con cui +chiudere un programma, ma dall'interno del programma stesso; avendo a che fare +con un sistema multitasking resta da affrontare l'argomento dal punto di vista +di come il sistema gestisce la conclusione dei processi. -Ma oltre alla conclusione normale abbiamo accennato che esistono anche delle +Abbiamo visto in \secref{sec:proc_conclusion} le tre modalità con cui un +programma viene terminato in maniera normale: la chiamata di \func{exit} (che +esegue le funzioni registrate per l'uscita e chiude gli stream), il ritorno +dalla funzione \func{main} (equivalente alla chiamata di \func{exit}), e la +chiamata ad \func{\_exit} (che passa direttamente alle operazioni di +terminazione del processo da parte del kernel). + +Ma abbiamo accennato che oltre alla conclusione normale esistono anche delle modalità di conclusione anomala; queste sono in sostanza due: il programma può chiamare la funzione \func{abort} per invocare una chiusura anomala, o essere terminato da un segnale. In realtà anche la prima modalità si riconduce alla @@ -545,114 +659,1375 @@ seconda, dato che \func{abort} si limita a generare il segnale Qualunque sia la modalità di conclusione di un processo, il kernel esegue comunque una serie di operazioni: chiude tutti i file aperti, rilascia la -memoria che stava usando, e così via. Ma per ciascuna delle varie modalità -di chiusura al padre deve essere riportato come il figlio è terminato. +memoria che stava usando, e così via; l'elenco completo delle operazioni +eseguite alla chiusura di un processo è il seguente: +\begin{itemize*} +\item tutti i file descriptor sono chiusi. +\item viene memorizzato lo stato di terminazione del processo. +\item ad ogni processo figlio viene assegnato un nuovo padre (in genere + \cmd{init}). +\item viene inviato il segnale \macro{SIGCHLD} al processo padre (vedi + \secref{sec:sig_xxx}). +\item se il processo è un leader di sessione viene mandato un segnale di + \macro{SIGHUP} a tutti i processi in background e il terminale di + controllo viene disconnesso (vedi \secref{sec:sess_xxx}). +\item se la conclusione di un processo rende orfano un \textit{process + group} ciascun membro del gruppo viene bloccato, e poi gli vengono + inviati in successione i segnali \macro{SIGHUP} e \macro{SIGCONT} + (vedi \secref{sec:sess_xxx}). +\end{itemize*} + +Oltre queste operazioni è però necessario poter disporre di un meccanismo +ulteriore che consenta di sapere come la terminazione è avvenuta: dato che in +un sistema unix-like tutto viene gestito attraverso i processi il meccanismo +scelto consiste nel riportare lo stato di terminazione (il cosiddetto +\textit{termination status}) al processo padre. + +Nel caso di conclusione normale, abbiamo visto in \secref{sec:proc_conclusion} +che lo stato di uscita del processo viene caratterizzato tramite il valore del +cosiddetto \textit{exit status}, cioè il valore passato alle funzioni +\func{exit} o \func{\_exit} (o dal valore di ritorno per \func{main}). Ma se +il processo viene concluso in maniera anomala il programma non può specificare +nessun \textit{exit status}, ed è il kernel che deve generare autonomamente il +\textit{termination status} per indicare le ragioni della conclusione anomala. + +Si noti la distinzione fra \textit{exit status} e \textit{termination status}: +quello che contraddistingue lo stato di chiusura del processo e viene +riportato attraverso le funzioni \func{wait} o \func{waitpid} (vedi +\secref{sec:proc_wait}) è sempre quest'ultimo; in caso di conclusione normale +il kernel usa il primo (nel codice eseguito da \func{\_exit}) per produrre il +secondo. + +La scelta di riportare al padre lo stato di terminazione dei figli, pur +essendo l'unica possibile, comporta comunque alcune complicazioni: infatti se +alla sua creazione è scontato che ogni nuovo processo ha un padre, non è detto +che sia così alla sua conclusione, dato che il padre potrebbe essere già +terminato (si potrebbe avere cioè quello che si chiama un processo +\textsl{orfano}). + +Questa complicazione viene superata facendo in modo che il processo orfano +venga \textsl{adottato} da \cmd{init}. Come già accennato quando un processo +termina il kernel controlla se è il padre di altri processi in esecuzione: in +caso positivo allora il \acr{ppid} di tutti questi processi viene sostituito +con il \acr{pid} di \cmd{init} (e cioè con 1); in questo modo ogni processo +avrà sempre un padre (nel caso possiamo parlare di un padre \textsl{adottivo}) +cui riportare il suo stato di terminazione. Come verifica di questo +comportamento possiamo eseguire il nostro programma \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 +Spawned 1 child, pid 1973 +Child 1 successfully executing +Go to next child +Spawned 2 child, pid 1974 +Child 2 successfully executing +Go to next child +Child 3 successfully executing +Spawned 3 child, pid 1975 +Go to next child +[piccardi@selidor sources]$ Child 3, parent 1, exiting +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 +terminano, e come si può notare in questo caso, al contrario di quanto visto +in precedenza, essi riportano 1 come \acr{ppid}. + +Altrettanto rilevante è il caso in cui il figlio termina prima del padre, +perché non è detto che il padre possa ricevere immediatamente lo stato di +terminazione, quindi il kernel deve comunque conservare una certa quantità di +informazioni riguardo ai processi che sta terminando. + +Questo viene fatto mantenendo attiva la voce nella tabella dei processi, e +memorizzando alcuni dati essenziali, come il \acr{pid}, i tempi di CPU usati +dal processo (vedi \secref{sec:sys_unix_time}) e lo stato di +terminazione\footnote{NdA verificare esattamente cosa c'è!}, mentre la memoria +in uso ed i file aperti vengono rilasciati immediatamente. I processi che sono +terminati, ma il cui stato di terminazione non è stato ancora ricevuto dal +padre sono chiamati \textit{zombie}, essi restano presenti nella tabella dei +processi ed in genere possono essere identificati dall'output di \cmd{ps} per +la presenza di una \texttt{Z} nella colonna che ne indica lo stato. Quando il +padre effettuerà la lettura dello stato di uscita anche questa informazione, +non più necessaria, verrà scartata e la terminazione potrà dirsi completamente +conclusa. + +Possiamo utilizzare il nostro programma di prova per analizzare anche questa +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 + 419 pts/0 S 0:00 bash + 568 pts/0 S 0:00 ./forktest -e10 3 + 569 pts/0 Z 0:00 [forktest ] + 570 pts/0 Z 0:00 [forktest ] + 571 pts/0 Z 0:00 [forktest ] + 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. + +La possibilità di avere degli zombie deve essere tenuta sempre presente quando +si scrive un programma che deve essere mantenuto in esecuzione a lungo e +creare molti figli. In questo caso si deve sempre avere cura di far leggere +l'eventuale stato di uscita di tutti i figli (in genere questo si fa +attraverso un apposito \textit{signal handler}, che chiama la funzione +\func{wait}, vedi \secref{sec:sig_xxx} e \secref{sec:proc_wait}). Questa +operazione è necessaria perché anche se gli \textit{zombie} non consumano +risorse di memoria o processore, occupano comunque una voce nella tabella dei +processi, che a lungo andare potrebbe esaurirsi. + +Si noti che quando un processo adottato da \cmd{init} termina, esso non +diviene uno \textit{zombie}; questo perché una delle funzioni di \cmd{init} è +appunto quella di chiamare la funzione \func{wait} per i processi cui fa da +padre, completandone la terminazione. Questo è quanto avviene anche quando, +come nel caso del precedente esempio con \cmd{forktest}, il padre termina con +dei figli in stato di zombie: alla sua terminazione infatti tutti i suoi figli +(compresi gli zombie) verranno adottati da \cmd{init}, il quale provvederà a +completarne la terminazione. + +Si tenga presente infine che siccome gli zombie sono processi già usciti, non +c'è modo di eliminarli con il comando \cmd{kill}; l'unica possibilità di +cancellarli dalla tabella dei processi è quella di terminare il processo che +li ha generati, in modo che \cmd{init} possa adottarli e provvedere a +concluderne la terminazione. + + +\subsection{Le funzioni \func{wait} e \func{waitpid}} +\label{sec:proc_wait} -Nel caso di conclusione normale per riportare lo stato di uscita del processo -viene usato l'\textit{exit status} specificato dal valore passato alle -funzioni \func{exit} o \func{\_exit} (o dal valore di ritorno per -\func{main}). Ma se il processo viene concluso in maniera anomala è il kernel -che deve generare un \textit{termination status} per indicare le ragioni della -conclusione anomala. Si noti che si è distinto fra \textit{exit status} e -\textit{termination status} in quanto anche in caso di conclusione normale, il -kernel usa il primo per produrre il secondo. +Uno degli usi più comuni delle capacità multitasking di un sistema unix-like +consiste nella creazione di programmi di tipo server, in cui un processo +principale attende le richieste che vengono poi soddisfatte da una serie di +processi figli. Si è già sottolineato al paragrafo precedente come in questo +caso diventi necessario gestire esplicitamente la conclusione dei 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} +\funcdecl{pid\_t wait(int *status)} -In ogni caso il valore dello stato di conclusione del processo può essere -letto attraverso le funzioni \func{wait} o \func{waitpid}. +Sospende il processo corrente finché un figlio non è uscito, o finché un +segnale termina il processo o chiama una funzione di gestione. +\bodydesc{La funzione restituisce il \acr{pid} del figlio in caso di successo + e -1 in caso di errore; \var{errno} può assumere i valori: + \begin{errlist} + \item[\macro{EINTR}] la funzione è stata interrotta da un segnale. + \end{errlist}} +\end{functions} +\noindent +è presente fin dalle prime versioni di Unix; la funzione ritorna non appena un +processo figlio termina. Se un figlio è già terminato la funzione ritorna +immediatamente. + +Al ritorno lo stato di termininazione del processo viene salvato nella +variabile puntata da \var{status} e tutte le informazioni relative al +processo (vedi \secref{sec:proc_termination}) vengono rilasciate. Nel +caso un processo abbia più figli il valore di ritorno permette di +identificare qual'è quello che è uscito. + +Questa funzione ha il difetto di essere poco flessibile, in quanto +ritorna all'uscita di un figlio qualunque. Nelle occasioni in cui è +necessario attendere la conclusione di un processo specifico occorre +predisporre un meccanismo che tenga conto dei processi già terminati, e +provveda a ripetere la chiamata alla funzione nel caso il processo +cercato sia ancora attivo. + +Per questo motivo lo standard POSIX.1 ha introdotto la funzione \func{waitpid} +che effettua lo stesso servizio, ma dispone di una serie di funzionalità più +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 cui prototipo è: +\begin{functions} +\headdecl{sys/types.h} +\headdecl{sys/wait.h} +\funcdecl{pid\_t waitpid(pid\_t pid, int *status, int options)} +Attende la conclusione di un processo figlio. -\subsection{Le funzioni \texttt{wait} e \texttt{waitpid}} -\label{sec:proc_wait} +\bodydesc{La funzione restituisce il \acr{pid} del processo che è uscito, 0 se + è stata specificata l'opzione \macro{WNOHANG} e il processo non è uscito e + -1 per un errore, nel qual caso \var{errno} assumerà i valori: + \begin{errlist} + \item[\macro{EINTR}] se non è stata specificata l'opzione \macro{WNOHANG} e + la funzione è stata interrotta da un segnale. + \item[\macro{ECHILD}] il processo specificato da \param{pid} non esiste o + non è figlio del processo chiamante. + \end{errlist}} +\end{functions} +Le differenze principali fra le due funzioni sono che \func{wait} si blocca +sempre fino a che un processo figlio non termina, mentre \func{waitpid} ha la +possibilità si specificare un'opzione \macro{WNOHANG} che ne previene il +blocco; inoltre \func{waitpid} può specificare quale processo attendere sulla +base del valore fornito dall'argomento \param{pid}, secondo lo +specchietto riportato in \ntab: +\begin{table}[!htb] + \centering + \footnotesize + \begin{tabular}[c]{|c|p{10cm}|} + \hline + \textbf{Valore} & \textbf{Significato}\\ + \hline + \hline + $<-1$& attende per un figlio il cui \textit{process group} è uguale al + valore assoluto di \var{pid}. \\ + $-1$ & attende per un figlio qualsiasi, usata in questa maniera è + equivalente a \func{wait}.\\ + $0$ & attende per un figlio il cui \textit{process group} è uguale a + quello del processo chiamante. \\ + $>0$ & attende per un figlio il cui \acr{pid} è uguale al + valore di \var{pid}.\\ + \hline + \end{tabular} + \caption{Significato dei valori del parametro \var{pid} della funzione + \func{waitpid}.} + \label{tab:proc_waidpid_pid} +\end{table} +Il comportamento di \func{waitpid} può inoltre essere modificato passando +delle opportune opzioni tramite l'argomento \param{option}. I valori possibili +sono il già citato \macro{WNOHANG}, che previene il blocco della funzione +quando il processo figlio non è terminato, e \macro{WUNTRACED} (usata per il +controllo di sessione, trattato in \capref{cha:session}) che fa ritornare la +funzione anche per i processi figli che sono bloccati ed il cui stato non è +stato ancora riportato al padre. Il valore dell'opzione deve essere +specificato come maschera binaria ottenuta con l'OR delle suddette costanti +con zero. + +La terminazione di un processo figlio è chiaramente un evento asincrono +rispetto all'esecuzione di un programma e può avvenire in un qualunque +momento. Per questo motivo, come accennato nella sezione precedente, una delle +azioni prese dal kernel alla conclusione di un processo è quella di mandare un +segnale di \macro{SIGCHLD} al padre. L'azione di default (si veda +\secref{sec:sig_base}) per questo segnale è di essere ignorato, ma la sua +generazione costituisce il meccanismo di comunicazione asincrona con cui il +kernel avverte il processo padre che uno dei suoi figli è terminato. + +In genere in un programma non si vuole essere forzati ad attendere la +conclusione di un processo per proseguire, specie se tutto questo serve solo +per leggerne lo stato di chiusura (ed evitare la presenza di \textit{zombie}), +per questo la modalità più usata per chiamare queste funzioni è quella di +utilizzarle all'interno di un \textit{signal handler} (torneremo sui segnali e +su come gestire \macro{SIGCHLD} in \secref{sec:sig_sigwait_xxx}). In questo +caso infatti, dato che il segnale è generato dalla terminazione un figlio, +avremo la certezza che la chiamata a \func{wait} non si bloccherà. + +\begin{table}[!htb] + \centering + \footnotesize + \begin{tabular}[c]{|c|p{10cm}|} + \hline + \textbf{Macro} & \textbf{Descrizione}\\ + \hline + \hline + \macro{WIFEXITED(s)} & Condizione vera (valore non nullo) per un processo + figlio che sia terminato normalmente. \\ + \macro{WEXITSTATUS(s)} & Restituisce gli otto bit meno significativi dello + stato di uscita del processo (passato attraverso \func{\_exit}, \func{exit} + o come valore di ritorno di \func{main}). Può essere valutata solo se + \macro{WIFEXITED} ha restituito un valore non nullo.\\ + \macro{WIFSIGNALED(s)} & Vera se il processo figlio è terminato + in maniera anomala a causa di un segnale che non è stato catturato (vedi + \secref{sec:sig_notification}).\\ + \macro{WTERMSIG(s)} & restituisce il numero del segnale che ha causato + la terminazione anomala del processo. Può essere valutata solo se + \macro{WIFSIGNALED} ha restituito un valore non nullo.\\ + \macro{WCOREDUMP(s)} & Vera se il processo terminato ha generato un + file si \textit{core dump}. Può essere valutata solo se + \macro{WIFSIGNALED} ha restituito un valore non nullo\footnote{questa + macro non è definita dallo standard POSIX.1, ma è presente come estensione + sia in Linux che in altri unix}.\\ + \macro{WIFSTOPPED(s)} & Vera se il processo che ha causato il ritorno di + \func{waitpid} è bloccato. L'uso è possibile solo avendo specificato + l'opzione \macro{WUNTRACED}. \\ + \macro{WSTOPSIG(s)} & restituisce il numero del segnale che ha bloccato + il processo, Può essere valutata solo se \macro{WIFSTOPPED} ha + restituito un valore non nullo. \\ + \hline + \end{tabular} + \caption{Descrizione delle varie macro di preprocessore utilizzabili per + verificare lo stato di terminazione \var{s} di un processo.} + \label{tab:proc_status_macro} +\end{table} -\subsection{Le funzioni \texttt{exec}} +Entrambe le funzioni di attesa restituiscono lo stato di terminazione del +processo tramite il puntatore \param{status} (se non interessa memorizzare lo +stato si può passare un puntatore nullo). Il valore restituito da entrambe le +funzioni dipende dall'implementazione, e tradizionalmente alcuni bit (in +genere 8) sono riservati per memorizzare lo stato di uscita, e altri per +indicare il segnale che ha causato la terminazione (in caso di conclusione +anomala), uno per indicare se è stato generato un core file, ecc.\footnote{le + definizioni esatte si possono trovare in \file{} ma + questo file non deve mai essere usato direttamente, esso viene incluso + attraverso \file{}.} + +Lo standard POSIX.1 definisce una serie di macro di preprocessore da usare per +analizzare lo stato di uscita. Esse sono definite sempre in +\file{} ed elencate in \curtab\ (si tenga presente che queste +macro prendono come parametro la variabile di tipo \type{int} puntata da +\var{status}). + +Si tenga conto che nel caso di conclusione anomala il valore restituito da +\macro{WTERMSIG} può essere controllato contro le costanti definite in +\file{signal.h} ed elencate in \tabref{tab:sig_signal_list}, e stampato usando +le apposite funzioni trattate in \secref{sec:sig_strsignal}. + + +\subsection{Le funzioni \func{wait3} e \func{wait4}} +\label{sec:proc_wait4} + +Linux, seguendo una estensione di BSD, supporta altre due funzioni per la +lettura dello stato di terminazione di un processo \func{wait3} e +\func{wait4}, analoghe alle precedenti ma che prevedono un ulteriore +parametro attraverso il quale il kernel può restituire al padre informazioni +sulle risorse usate dal processo terminato e dai vari figli. I prototipi di +queste funzioni, che diventano accessibili definendo la costante +\macro{\_USE\_BSD}, 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 dei parametri, ma restituisce in \param{rusage} un sommario delle + risorse usate dal processo (per i dettagli vedi \secref{sec:sys_xxx}) + + \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 \type{rusage} è definita in \file{sys/resource.h}, e viene +utilizzata anche dalla funzione \func{getrusage} (vedi \secref{sec:sys_xxx}) +per ottenere le risorse di sistema usate da un processo; la sua definizione è +riportata in \figref{fig:sys_rusage_struct}. + +In genere includere esplicitamente \file{} non è più +necessario, ma aumenta la portabilità, e serve in caso si debba accedere +ai campi di \var{rusage} definiti come \type{struct timeval}. La +struttura è ripresa da BSD 4.3, attualmente (con il kernel 2.4.x) i soli +campi che sono mantenuti sono: \var{ru\_utime}, \var{ru\_stime}, +\var{ru\_minflt}, \var{ru\_majflt}, e \var{ru\_nswap}. + + +\subsection{Le funzioni \func{exec}} \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 stack, lo +heap, i dati ed il 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 \figref{fig:proc_exec_relat}), sono tutte 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[])} + Esegue il programma contenuto nel file \param{filename}. + + \bodydesc{La funzione ritorna -1 solo in caso di errore, nel qual caso + caso la \var{errno} può assumere i valori: + \begin{errlist} + \item[\macro{EACCES}] il file non è eseguibile, oppure il filesystem è + montato in \cmd{noexec}, oppure non è un file normale o un interprete. + \item[\macro{EPERM}] il file ha i bit \acr{suid} o \acr{sgid}, l'utente non + è root, e o il processo viene tracciato, o il filesystem è montato con + l'opzione \cmd{nosuid}. + \item[\macro{ENOEXEC}] il file è in un formato non eseguibile o non + riconosciuto come tale, o compilato per un'altra architettura. + \item[\macro{ENOENT}] il file o una delle librerie dinamiche o l'interprete + necessari per eseguirlo non esistono. + \item[\macro{ETXTBSY}] L'eseguibile è aperto in scrittura da uno o più + processi. + \item[\macro{EINVAL}] L'eseguibile ELF ha più di un segmento + \macro{PF\_INTERP}, cioè chiede di essere eseguito da più di un + interprete. + \item[\macro{ELIBBAD}] Un interprete ELF non è in un formato + riconoscibile. + \end{errlist} + ed inoltre anche \macro{EFAULT}, \macro{ENOMEM}, \macro{EIO}, + \macro{ENAMETOOLONG}, \macro{E2BIG}, \macro{ELOOP}, \macro{ENOTDIR}, + \macro{ENFILE}, \macro{EMFILE}.} +\end{prototype} + +La funzione \func{exec} esegue il file o lo script indicato da +\var{filename}, passandogli la lista di argomenti indicata da \var{argv} +e come ambiente la lista di stringhe indicata da \var{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 +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, ...)} +\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. I parametri 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} andrà ad assumere 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 \ntab. La prima differenza riguarda +le modalità di passaggio dei parametri che poi andranno a costituire gli +argomenti a linea di comando (cioè i valori di \var{argv} e \var{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: +\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{} + char *arg0, char *arg1, ..., char *argn, NULL +\end{lstlisting} +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\ }&\func{execlp}&\func{execle} + &\func{execv\ }& \func{execvp}& \func{execve} \\ + \hline + \hline + argomenti a lista &$\bullet$&$\bullet$&$\bullet$&&& \\ + argomenti a vettore &&&&$\bullet$&$\bullet$&$\bullet$\\ + \hline + filename completo &&$\bullet$&&&$\bullet$& \\ + ricerca su \var{PATH}&$\bullet$&&$\bullet$&$\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 il parametro \var{file} non +contiene una \file{/} 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 di +permessi negati (cioè l'esecuzione della sottostante \func{execve} ritorna un +\macro{EACCESS}), la ricerca viene proseguita nelle eventuali ulteriori +directory indicate nel \var{PATH}, solo se non viene trovato nessun altro file +viene finalmente restituito \macro{EACCESS}. + +Le altre quattro funzioni si limitano invece a cercare di eseguire il file +indicato dal parametro \var{path}, che viene interpretato come il +\textit{pathname} del programma. + +\begin{figure}[htb] + \centering + \includegraphics[width=13cm]{img/exec_rel} + \caption{La interrelazione fra le sei funzioni della famiglia \func{exec}} + \label{fig:proc_exec_relat} +\end{figure} -\section{Il controllo di accesso} -\label{sec:proc_perms} +La terza differenza è come viene passata la lista delle variabili di ambiente. +Con lo mnemonico \code{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 \macro{NULL}), le altre usano il +valore della variabile \var{environ} (vedi \secref{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 il \textit{real user id} ed il \textit{real group id} (vedi + \secref{sec:proc_access_id}). +\item i \textit{supplementary group id} (vedi \secref{sec:proc_access_id}). +\item il \textit{session id} ed il \textit{process group id} (vedi + \secref{sec:sess_xxx}). +\item il terminale di controllo (vedi \secref{sec:sess_xxx}). +\item il tempo restante ad un allarme (vedi \secref{sec:sig_xxx}). +\item la directory radice e la directory di lavoro corrente (vedi + \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_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:sys_limits}). +\item i valori delle variabili \var{tms\_utime}, \var{tms\_stime}, + \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 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 che ha il flag di +\textit{close-on-exec} (trattato in \secref{sec:file_fcntl}) per ciascun file +descriptor. 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. + +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 \secref{sec:file_dir_read}) che effettua da sola il +settaggio del flag di \textit{close-on-exec} sulle directory che apre, in +maniera trasparente all'utente. + +Abbiamo detto che il \textit{real user id} ed il \textit{real group id} +restano gli stessi all'esecuzione di \func{exec}; lo stesso vale per +l'\textit{effective user id} ed l'\textit{effective group id}, tranne quando +il file che si va ad eseguire abbia o il \acr{suid} bit o lo \acr{sgid} bit +settato, in questo caso l'\textit{effective user id} e l'\textit{effective + group id} vengono settati rispettivamente all'utente o al gruppo cui il file +appartiene (per i dettagli vedi \secref{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{ld.so} prima del +programma per caricare le librerie necessarie ed effettuare il link +dell'eseguibile. Se il programma è in formato ELF per caricare le librerie +dinamiche viene usato l'interprete indicato nel segmento \macro{PT\_INTERP}, +in genere questo è \file{/lib/ld-linux.so.1} per programmi linkati con le +\emph{libc5}, e \file{/lib/ld-linux.so.2} per programmi linkati con le +\emph{glibc}. Infine nel caso il file sia uno script esso deve iniziare con +una linea nella forma \cmd{\#!/path/to/interpreter} dove l'interprete indicato +deve esse un valido programma (binario, non un altro script) che verrà +chiamato come se si fosse eseguito il comando \cmd{interpreter [arg] + filename}. + +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 avvia un nuovo programma, con \func{exit} e +\func{wait} si effettua e verifica la conclusione dei programmi. Tutte le +altre funzioni sono ausiliarie e servono la lettura e il settaggio dei vari +parametri connessi ai processi. -In questa sezione esamineremo le problematiche relative al controllo di -accesso dal punto di vista del processi; gli identificativi usati, come questi -vengono modificati nella creazione e nel lancio di nuovi processi, e le varie -funzioni per la loro manipolazione diretta. -\subsection{Utente e gruppo di un processo} -\label{sec:proc_user_group} +\section{Il controllo di accesso} +\label{sec:proc_perms} -Abbiamo già accennato in \secref{sec:intro_multiuser} ad ogni utente ed gruppo -sono associati due identificatori univoci, lo \acr{uid} e il \acr{gid} che li -contraddistinguono nei confronti del kernel. Questi identificatori stanno alla -base del sistema di permessi e protezioni di un sistema unix, e vengono usati -anche nella gestione dei privilegi di accesso dei processi. +In questa sezione esamineremo le problematiche relative al controllo di +accesso dal punto di vista del 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 \secref{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 \textit{capabilities}, le ACL per i file + o il \textit{Mandatory Access Control} di SELinux} 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. + +%Benché il sistema sia piuttosto semplice (è basato su un solo livello di +% separazione) il sistema permette una +%notevole flessibilità, + +Abbiamo già accennato come il sistema associ ad ogni utente e gruppo due +identificatori univoci, lo \acr{uid} e il \acr{gid}; 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 \secref{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 è associato un utente e a 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}. -In realtà ad ogni processo è associato un certo numero di identificatori, il -cui elenco è riportato \ntab, in genere questi derivano direttamente -dall'utente che ha lanciato il processo (attraverso i valori di \acr{uid} e -\acr{gid}), e vengono usati sia per il controllo di accesso ai file che per la -gestione dei privilegi associati ai processi stessi. \begin{table}[htb] + \footnotesize \centering - \begin{tabular}[c]{|c|l|l|} + \begin{tabular}[c]{|c|l|p{6.5cm}|} \hline - Sigla & Significato & Utilizzo \\ + \textbf{Suffisso} & \textbf{Significato} & \textbf{Utilizzo} \\ \hline \hline - \acr{ruid} & \textit{real user id} & indica l'utente reale che ha lanciato + \acr{uid} & \textit{real user id} & indica l'utente che ha lanciato il programma\\ - \acr{rgid} & \textit{real group id} & indica il gruppo reale dell'utente + \acr{gid} & \textit{real group id} & indica il gruppo dell'utente che ha lanciato il programma \\ - \acr{euid} & \textit{effective user id} & indica l'utente effettivo usato - dal programma \\ - \acr{egid} & \textit{effective group id} & indica il gruppo effettivo usato - dal programma \\ - & \textit{supplementary group id} & indica i gruppi cui + \hline + \acr{euid} & \textit{effective user id} & indica l'utente usato + dal programma nel controllo di accesso \\ + \acr{egid} & \textit{effective group id} & indica il gruppo + usato dal programma nel controllo di accesso \\ + -- & \textit{supplementary group id} & indica i gruppi cui l'utente appartiene \\ - \acr{suid} & \textit{saved user id} & indica l'utente \\ - \acr{sgid} & \textit{daved group id} & indica il gruppo \\ + \hline + -- & \textit{saved user id} & copia dell'\acr{euid} iniziale\\ + -- & \textit{saved group id} & copia dell'\acr{egid} iniziale \\ + \hline \acr{fsuid} & \textit{filesystem user id} & indica l'utente effettivo per il filesystem \\ \acr{fsgid} & \textit{filesystem group id} & indica il gruppo effettivo per il filesystem \\ \hline \end{tabular} - \caption{Identificatori di utente e gruppo associati a ciascun processo.} + \caption{Identificatori di utente e gruppo associati a ciascun processo con + indicazione dei suffissi usate dalle varie funzioni di manipolazione.} \label{tab:proc_uid_gid} \end{table} -Il \textit{real user id} e il \textit{real group id} indicano l'utente che ha -lanciato il processo, e vengono settati al login al valore standard di -\acr{uid} e \acr{gid} dell'utente letti direttamente da \file{/etc/passwd}. -Questi non vengono mai cambiati nella creazione di nuovi processi e restano -sempre gli stessi per tutti i processi avviati in una sessione. In realtà è -possibile modificarli (vedi \secref{sec:proc_setuid}), ma solo per un processo -che abbia i privilegi di amministratore (ed è così infatti che \cmd{login}, -che gira con i privilegi di amministratore, li setta ai valori corrispondenti -all'utente che entra nel sistema). - -L'\textit{effective user id}, l'\textit{effective group id} e gli eventuali -\textit{supplementary group id} sono gli identificativi usati per il controllo -di accesso ai file secondo quanto descritto in dettaglio in -\secref{sec:file_perm_overview}. Normalmente sono uguali al \textit{real user - id} e al \textit{real group id}, a meno che il file posto in esecuzione non -abbia i bit \acr{suid} o \acr{sgid} settati, nel qual caso vengono settati -rispettivamente all'\acr{uid} e \acr{gid} del file. +Al primo gruppo appartengono il \textit{real user id} e il \textit{real group + id}: questi vengono settati al login ai valori corrispondenti all'utente con +cui si accede al sistema (e relativo gruppo di default). Servono per +l'identificazione dell'utente e normalmente non vengono mai cambiati. In +realtà vedremo (in \secref{sec:proc_setuid}) che è possibile modificarli, ma +solo ad un processo che abbia i privilegi di amministratore; questa +possibilità è usata ad esempio da \cmd{login} che, una volta completata la +procedura di autenticazione, lancia una shell per la quale setta questi +identificatori ai valori corrispondenti all'utente che entra nel sistema. + +Al secondo gruppo appartengono l'\textit{effective user id} e +l'\textit{effective group id} (a cui si aggiungono gli eventuali +\textit{supplementary group id} dei gruppi dei quale l'utente fa parte). +Questi sono invece gli identificatori usati nella verifiche dei permessi del +processo e per il controllo di accesso ai file (argomento affrontato in +dettaglio in \secref{sec:file_perm_overview}). + +Questi identificatori normalmente sono identici ai corrispondenti del gruppo +\textsl{reale} tranne nel caso in cui, come accennato in +\secref{sec:proc_exec}, il programma che si è posto in esecuzione abbia i bit +\acr{suid} o \acr{sgid} 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 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. + + \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}, analoghi ai precedenti. 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. 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 -processo padre, e vengono settati all'avvio del processo, prima che -\textit{effective user id} e \textit{effective group id} vengano modificati -per tener conto di eventuali \acr{suid} o \acr{sgid}. +processo padre, e vengono settati dalla funzione \func{exec} all'avvio del +processo, come copie dell'\textit{effective user id} e dell'\textit{effective + group id} dopo che questo sono stati settati tenendo conto di eventuali +\acr{suid} o \acr{sgid}. Essi quindi consentono di tenere traccia di quale +fossero utente e gruppo effettivi all'inizio dell'esecuzione di un nuovo +programma. + +Il \textit{filesystem user id} e il \textit{filesystem group id} sono una +estensione introdotta in Linux per rendere più sicuro l'uso di NFS (torneremo +sull'argomento in \secref{sec:proc_setfsuid}). Essi sono una replica dei +corrispondenti \textit{effective id}, ai quali si sostituiscono per tutte le +operazioni di verifica dei permessi relativi ai file (trattate in +\secref{sec:file_perm_overview}). Ogni cambiamento effettuato sugli +\textit{effective id} viene automaticamente riportato su di essi, per cui in +condizioni normali se ne può tranquillamente ignorare l'esistenza, in quanto +saranno del tutto equivalenti ai precedenti. + +Uno specchietto riassuntivo, contenente l'elenco completo degli identificatori +di utente e gruppo associati dal kernel ad ogni processo, è riportato in +\tabref{tab:proc_uid_gid}. + + +\subsection{Le funzioni \func{setuid} e \func{setgid}} +\label{sec:proc_setuid} +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_access_id} in Linux esse +seguono la semantica POSIX che prevede l'esistenza del \textit{saved user id} +e del \textit{saved group id}; i loro prototipi sono: +\begin{functions} +\headdecl{unistd.h} +\headdecl{sys/types.h} -\subsection{Le funzioni \texttt{setuid} e \texttt{setgid}} -\label{sec:proc_setuid} +\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. +\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso + di fallimento: l'unico errore possibile è \macro{EPERM}.} +\end{functions} -\subsection{Le funzioni \texttt{seteuid} e \texttt{setegid}} +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. + + +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 prendiamo 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 \code{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 +\code{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, FIXME verificare e aggiornare la nota.} i +\textit{saved id}, le usava per poter scambiare fra di loro \textit{effective} +e \textit{real id}. I loro 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}. + +\bodydesc{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 in Linux tutte le volte che vengono usata per modificare uno degli +identificatori ad un valore diverso dal \textit{real id} precedente, il +\textit{saved id} viene sempre settato al valore dell'\textit{effective id}. + + + +\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}. + +\bodydesc{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{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}. + +\bodydesc{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. + +Per queste funzioni esistono anche due controparti che permettono di leggere +in blocco i vari identificatori: \func{getresuid} e \func{getresgid}; i loro +prototipi sono: +\begin{functions} +\headdecl{unistd.h} +\headdecl{sys/types.h} + +\funcdecl{int getresuid(uid\_t *ruid, uid\_t *euid, uid\_t *suid)} Legge il +\textit{real user id}, l'\textit{effective user id} e il \textit{saved user + id} del processo corrente. + +\funcdecl{int getresgid(gid\_t *rgid, gid\_t *egid, gid\_t *sgid)} Legge il +\textit{real group id}, l'\textit{effective group id} e il \textit{saved group + id} del processo corrente. + +\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso di + fallimento: l'unico errore possibile è \macro{EFAULT} se gli indirizzi delle + variabili di ritorno non sono validi.} +\end{functions} + +Anche queste funzioni sono una estensione specifica di Linux, e non richiedono +nessun privilegio. I valori sono restituiti negli argomenti, che vanno +specificati come puntatori (è un'altro esempio di \textit{value result + argument}). Si noti che queste funzioni sono le uniche in grado di leggere i +\textit{saved id}. + + +\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_access_id} 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, +così che l'utente non possa inviare segnali al server NFS. + +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}. + +\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso + di fallimento: l'unico errore possibile è \macro{EPERM}.} +\end{functions} +\noindent 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}. + + +\subsection{Le funzioni \func{setgroups} e \func{getgroups}} +\label{sec:proc_setgroups} + +Le ultime funzioni che esamineremo sono quelle sono quelle che permettono di +operare sui gruppi supplementari. Ogni processo può avere fino a +\macro{NGROUPS\_MAX} gruppi supplementari in aggiunta al gruppo primario, +questi vengono ereditati dal processo padre e possono essere cambiati con +queste funzioni. + +La funzione che permette di leggere i gruppi supplementari è \func{getgroups}; +questa funzione è definita nello standard POSIX ed il suo prototipo è: +\begin{functions} + \headdecl{sys/types.h} + \headdecl{unistd.h} + + \funcdecl{int getgroups(int size, gid\_t list[])} Legge gli identificatori + dei gruppi supplementari del processo sul vettore \param{list} di dimensione + \param{size}. + + \bodydesc{La funzione restituisce il numero di gruppi letti in caso di + successo e -1 in caso di fallimento, nel qual caso \var{errno} viene + settata a: + \begin{errlist} + \item[\macro{EFAULT}] \param{list} non ha un indirizzo valido. + \item[\macro{EINVAL}] il valore di \param{size} è diverso da zero ma + minore del numero di gruppi supplementari del processo. + \end{errlist}} +\end{functions} +\noindent non è specificato se la funzione inserisca o meno nella lista +l'\textit{effective user id} del processo. Se si specifica un valore di +\param{size} uguale a 0 \param{list} non viene modificato, ma si ottiene il +numero di gruppi supplementari. + +Una seconda funzione, \func{getgrouplist}, può invece essere usata per +ottenere tutti i gruppi a cui appartiene un utente; il suo prototipo è: +\begin{functions} + \headdecl{sys/types.h} + \headdecl{grp.h} + + \funcdecl{int getgrouplist(const char *user, gid\_t group, gid\_t *groups, + int *ngroups)} Legge i gruppi supplementari dell'utente \param{user}. + + \bodydesc{La funzione legge fino ad un massimo di \param{ngroups} valori, + restituisce 0 in caso di successo e -1 in caso di fallimento.} +\end{functions} +\noindent la funzione esegue una scansione del database dei gruppi (si veda +\secref{sec:sys_user_group}) e ritorna in \param{groups} la lista di quelli a +cui l'utente appartiene. Si noti che \param{ngroups} è passato come puntatore +perché qualora il valore specificato sia troppo piccolo la funzione ritorna -1 +e passando indietro il numero dei gruppi trovati. + +Per settare i gruppi supplementari di un processo ci sono due funzioni, che +possono essere usate solo se si hanno i privilegi di amministratore. La prima +delle due è \func{setgroups}, ed il suo prototipo è: +\begin{functions} + \headdecl{sys/types.h} + \headdecl{grp.h} + + \funcdecl{int setgroups(size\_t size, gid\_t *list)} Setta i gruppi + supplementari del processo ai valori specificati in \param{list}. + + \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di + fallimento, nel qual caso \var{errno} viene settata a: + \begin{errlist} + \item[\macro{EFAULT}] \param{list} non ha un indirizzo valido. + \item[\macro{EPERM}] il processo non ha i privilegi di amministratore. + \item[\macro{EINVAL}] il valore di \param{size} è maggiore del valore + massimo (\macro{NGROUPS}, che per Linux è 32). + \end{errlist}} +\end{functions} + +Se invece si vogliono settare i gruppi supplementari del processo a quelli di +un utente specifico si può usare \func{initgroups} il cui prototipo è: +\begin{functions} + \headdecl{sys/types.h} + \headdecl{grp.h} + + \funcdecl{int initgroups(const char *user, gid\_t group)} Setta i gruppi + supplementari del processo a quelli di cui è membro l'utente \param{user}, + aggiungendo il gruppo addizionale \param{group}. + + \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di + fallimento, nel qual caso \var{errno} viene settata agli stessi valori di + \func{setgroups} più \macro{ENOMEM} quando non c'è memoria sufficiente per + allocare lo spazio per informazioni dei gruppi.} +\end{functions} + +La funzione esegue la scansione del database dei gruppi (usualmente +\file{/etc/groups}) cercando i gruppi di cui è membro \param{user} costruendo +una lista di gruppi supplementari a cui aggiunge \param{group}, che poi setta +usando \func{setgroups}. + +Si tenga presente che sia \func{setgroups} che \func{initgroups} non sono +definite nello standard POSIX.1 e che pertanto non è possibile utilizzarle +quando si definisce \macro{\_POSIX\_SOURCE} o si compila con il flag +\cmd{-ansi}. + + +\section{La gestione della priorità di esecuzione} +\label{sec:proc_priority} + +In questa sezione tratteremo più approfonditamente i meccanismi con il quale +lo \textit{scheduler}\footnote{che è la parte del kernel che si occupa di + stabilire quale processo dovrà essere posto in esecuzione.} assegna la CPU +ai vari processi attivi. In particolare prendremo in esame i vari meccanismi +con cui viene gestita l'assgnazione del tempo di CPU, ed illustreremo le varie +funzioni di gestione. + + +\subsection{I meccanismi di \textit{scheduling}} +\label{sec:proc_sched} + +La scelta di un meccanismo che sia in grado di distribuire in maniera efficace +il tempo di CPU per l'esecuzione dei processi è sempre una questione delicata, +ed oggetto di numerose ricerche; in ogni caso essa dipende in maniera +essenziale anche dal tipo di utilizzo che deve essere fatto del sistema. + +La cosa è resa ancora più complicata dal fatto che con sistemi +multi-processore si introduce anche la complessità dovuta alla scelta di quale +sia la CPU più opportuna da utilizzare.\footnote{nei processori moderni la + presenza di ampie cache può rendere poco efficiente trasferire l'esecuzione + di un processo da una CPU ad un'altra, per cui occorrono meccanismi per + determininare quale è la migliore scelta fra le diverse CPU.} Tutto questo +comunque appartiene alle sottigliezze dell'implementazione del kernel, e dal +punto di vista dei programmi che girano in user space di può pensare sempre +alla risorsa tempo di esecuzione, governata dagli stessi mecca, che nel caso +di più processori sarà a disposizione di più di un processo alla volta. + +Si tenga presente inoltre che l'utilizzo della CPU è soltanto una delle +risorse (insieme alla memoria e all'accesso alle periferiche) che sono +necessarie per l'esecuzione di un programma, e spesso non è neanche la più +importante. Per questo non è affatto detto che dare ad un programma la massima +priorità di esecuzione abbia risultati significativi in termini di +prestazioni. + +La politica tradizionale di scheduling di Unix (che tratteremo in +\secref{sec:proc_sched_stand}) è sempre stata basata su delle priorità +dinamiche, che assicurassaro che tutti i processi, anche i meno importanti, +potessero ricevere un po' di tempo di CPU. + +Lo standard POSIX però per tenere conto dei sistemi real-time,\footnote{per + sistema real-time si intende un sistema in grado di eseguire operazioni in + tempo reale; in genere si tende a distinguere fra l'\textit{hard real-time} + in cui è necessario che i tempi di esecuzione di un programma siano + determinabili con certezza assoluta, come nel caso di meccanismi di + controllo di macchine, dove uno sforamento dei tempi avrebbe conseguenze + disastrose, e \textit{soft-real-time} in cui un occasionale sforamento è + ritenuto accettabile.} in cui è vitale che i processi in che devono essere +eseguiti in un determinato momento non debbano aspettare la conclusione di un +altri processi che non hanno questa necessità, ha introdotto il concetto di +\textsl{priorità assoluta}, chimata anche \textsl{priorità statica}, in +contrapposizione con la normale priorità dinamica. + +Il concetto di prorità assoluta dice che quando due processi si contendono +l'esecuzione, vince sempre quello con la priorità assoluta più alta, anche, +grazie al \textit{prehemptive scheduling}, se l'altro è in esecuzione. +Ovviamente questo avviene solo per i processi che sono pronti per essere +eseguiti (cioè nello stato \textit{runnable}\footnote{lo stato di un processo + è riportato nel campo \texttt{STAT} dell'output del comando \cmd{ps}, + abbiamo già visto che lo stato di \textit{zombie} è indicato con \texttt{Z}, + gli stati \textit{runnable}, \textit{sleep} e di I/O (\textit{uninteruttible + sleep}) sono invece indicati con \texttt{R}, \texttt{S} e \texttt{D}.}), +la priorità assoluta viene invece ignorata per quelli che sono bloccati su una +richiesta di I/O o in stato di \textit{sleep}. + +Questa viene in genere indicata con un numero + + + + +\subsection{Il meccanismo di \textit{scheduling} standard} +\label{sec:proc_sched_stand} + +In Linux tutti i processi hanno sostanzialmente la stessa priorità; benché sia +possibile specificare una priorità assoluta secondo lo standard POSIX +(argomento che tratteremo più avanti) l'uso comune segue quello che è il +meccanismo tradizionale con cui i sistemi + + + + +\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 multitasking +occorre tenere conto di 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 essendo questo argomento di carattere generale, ci è parso opportuno +introdurre sinteticamente queste problematiche, che ritroveremo a più riprese +in capitoli successivi, in questa sezione conclusiva del capitolo in cui +abbiamo affrontato la gestione dei processi. + + +\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 nelle 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 +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}, 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 tutti 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 definiscono \textit{race condition} tutte quelle situazioni in cui processi +diversi operano su una risorsa comune, ed in cui il risultato viene a +dipendere dall'ordine in cui essi effettuano le loro operazioni. Il caso +tipico è quello di una operazione che viene eseguita da un processo in più +passi, e può essere compromessa dall'intervento di un altro processo che +accede alla stessa risorsa quando ancora non tutti i passi sono stati +completati. + +Dato che in un sistema multitasking ogni processo può essere interrotto in +qualunque momento per farne subentrare un'altro in esecuzione, niente può +assicurare un preciso ordine di esecuzione fra processi diversi o che una +sezione di un programma possa essere eseguita senza interruzioni da parte di +altri. Queste situazioni comportano pertanto errori estremamente subdoli e +difficili da tracciare, in quanto nella maggior parte dei casi tutto +funzionerà regolarmente, e solo occasionalmente si avranno degli errori. + +Per questo occorre essere ben consapevoli di queste problematiche, e del fatto +che l'unico modo per evitarle è quello di riconoscerle come tali e prendere +gli adeguati provvedimenti per far si che non si verifichino. 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 quelle parti di codice in +cui si compiono le operazioni sulle risorse condivise (le cosiddette +\textsl{sezioni critiche}) del programma, 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}, particolarmente gravi in quanto comportano spesso il blocco +completo di un servizio, e non il fallimento di una singola operazione. +L'esempio tipico di una situazione che può condurre ad un \textit{deadlock} è +quello in cui un flag di ``occupazione'' viene rilasciato da un evento +asincrono (come un segnale o un altro processo) fra il momento in cui lo si è +controllato (trovandolo occupato) e la successiva operazione di attesa per lo +sblocco. In questo caso, dato che l'evento di sblocco del flag è avvenuto +senza che ce ne accorgessimo proprio fra il controllo e la messa in attesa, +quest'ultima diventerà perpetua (da cui il nome di \textit{deadlock}). + +In tutti questi casi è di fondamentale importanza il concetto di atomicità +visto in \secref{sec:proc_atom_oper}; questi problemi infatti possono essere +risolti soltanto assicurandosi, quando essa sia richiesta, che sia possibile +eseguire in maniera atomica le operazioni necessarie. + + +\subsection{Le funzioni rientranti} +\label{sec:proc_reentrant} + +Si dice \textsl{rientrante} una funzione che può essere interrotta in +qualunque punto della sua esecuzione ed essere chiamata una seconda volta da +un altro thread di esecuzione senza che questo comporti nessun problema nella +esecuzione della stessa. La problematica è comune nella programmazione +multi-thread, ma si hanno gli stessi problemi quando si vogliono chiamare +delle funzioni all'interno dei manipolatori dei segnali. + +Fintanto che una funzione opera soltanto con le variabili locali è rientrante; +queste infatti vengono tutte le volte allocate nello stack, e un'altra +invocazione non fa altro che allocarne un'altra copia. Una funzione può non +essere rientrante quando opera su memoria che non è nello stack. Ad esempio +una funzione non è mai rientrante se usa una variabile globale o statica. + +Nel caso invece la funzione operi su un oggetto allocato dinamicamente la cosa +viene a dipendere da come avvengono le operazioni; se l'oggetto è creato ogni +volta e ritornato indietro la funzione può essere rientrante, se invece esso +viene individuato dalla funzione stessa due chiamate alla stessa funzione +potranno interferire quando entrambe faranno riferimento allo stesso oggetto. +Allo stesso modo 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; in tutti questi casi occorre molta cura da +parte del programmatore. + +In genere le funzioni di libreria non sono rientranti, molte di esse ad +esempio utilizzano variabili statiche, le \acr{glibc} però mettono a +disposizione due macro di compilatore, \macro{\_REENTRANT} e +\macro{\_THREAD\_SAFE}, la cui definizione attiva le versioni rientranti di +varie funzioni di libreria, che sono identificate aggiungendo il suffisso +\code{\_r} al nome della versione normale. + + + +%%% Local Variables: +%%% mode: latex +%%% TeX-master: "gapil" +%%% End: