582831aa8eb6dc908ab4b8a56c526fcbb37594aa
[gapil.git] / prochand.tex
1 \chapter{La gestione dei processi}
2 \label{cha:process_handling}
3
4 Come accennato nell'introduzione in un sistema Unix tutte le operazioni
5 vengono svolte tramite opportuni processi.  In sostanza questi ultimi vengono
6 a costituire l'unità base per l'allocazione e l'uso delle risorse del sistema.
7
8 Nel precedente capitolo abbiamo esaminato il funzionamento di un processo come
9 unità a se stante, in questo esamineremo il funzionamento dei processi
10 all'interno del sistema. Saranno cioè affrontati i dettagli della creazione e
11 della terminazione dei processi, della gestione dei loro attributi e
12 privilegi, e di tutte le funzioni a questo connesse. Infine nella sezione
13 finale introdurremo alcune problematiche generiche della programmazione in
14 ambiente multitasking.
15
16
17 \section{Introduzione}
18 \label{sec:proc_gen}
19
20 Inizieremo con un'introduzione generale ai concetti che stanno alla base della
21 gestione dei processi in un sistema unix-like. Introdurremo in questa sezione
22 l'architettura della gestione dei processi e le sue principali
23 caratteristiche, dando una panoramica sull'uso delle principali funzioni di
24 gestione.
25
26
27 \subsection{L'architettura della gestione dei processi}
28 \label{sec:proc_hierarchy}
29
30 A differenza di quanto avviene in altri sistemi (ad esempio nel VMS la
31 generazione di nuovi processi è un'operazione privilegiata) una delle
32 caratteristiche di Unix (che esamineremo in dettaglio più avanti) è che
33 qualunque processo può a sua volta generarne altri, detti processi figli
34 (\textit{child process}). Ogni processo è identificato presso il sistema da un
35 numero unico, il cosiddetto \textit{process identifier} o, più brevemente, 
36 \acr{pid}.
37
38 Una seconda caratteristica di un sistema Unix è che la generazione di un
39 processo è un'operazione separata rispetto al lancio di un programma. In
40 genere la sequenza è sempre quella di creare un nuovo processo, il quale
41 eseguirà, in un passo successivo, il programma desiderato: questo è ad esempio
42 quello che fa la shell quando mette in esecuzione il programma che gli
43 indichiamo nella linea di comando.
44
45 Una terza caratteristica è che ogni processo è sempre stato generato da un
46 altro, che viene chiamato processo padre (\textit{parent process}). Questo
47 vale per tutti i processi, con una sola eccezione: dato che ci deve essere un
48 punto di partenza esiste un processo speciale (che normalmente è
49 \cmd{/sbin/init}), che viene lanciato dal kernel alla conclusione della fase
50 di avvio; essendo questo il primo processo lanciato dal sistema ha sempre il
51 \acr{pid} uguale a 1 e non è figlio di nessun altro processo.
52
53 Ovviamente \cmd{init} è un processo speciale che in genere si occupa di far
54 partire tutti gli altri processi necessari al funzionamento del sistema,
55 inoltre \cmd{init} è essenziale per svolgere una serie di compiti
56 amministrativi nelle operazioni ordinarie del sistema (torneremo su alcuni di
57 essi in \secref{sec:proc_termination}) e non può mai essere terminato. La
58 struttura del sistema comunque consente di lanciare al posto di \cmd{init}
59 qualunque altro programma, e in casi di emergenza (ad esempio se il file di
60 \cmd{init} si fosse corrotto) è ad esempio possibile lanciare una shell al suo
61 posto, passando la riga \cmd{init=/bin/sh} come parametro di avvio.
62
63 \begin{figure}[!htb]
64   \footnotesize
65 \begin{verbatim}
66 [piccardi@gont piccardi]$ pstree -n 
67 init-+-keventd
68      |-kapm-idled
69      |-kreiserfsd
70      |-portmap
71      |-syslogd
72      |-klogd
73      |-named
74      |-rpc.statd
75      |-gpm
76      |-inetd
77      |-junkbuster
78      |-master-+-qmgr
79      |        `-pickup
80      |-sshd
81      |-xfs
82      |-cron
83      |-bash---startx---xinit-+-XFree86
84      |                       `-WindowMaker-+-ssh-agent
85      |                                     |-wmtime
86      |                                     |-wmmon
87      |                                     |-wmmount
88      |                                     |-wmppp
89      |                                     |-wmcube
90      |                                     |-wmmixer
91      |                                     |-wmgtemp
92      |                                     |-wterm---bash---pstree
93      |                                     `-wterm---bash-+-emacs
94      |                                                    `-man---pager
95      |-5*[getty]
96      |-snort
97      `-wwwoffled
98 \end{verbatim} %$
99   \caption{L'albero dei processi, così come riportato dal comando
100     \cmd{pstree}.}
101   \label{fig:proc_tree}
102 \end{figure}
103
104 Dato che tutti i processi attivi nel sistema sono comunque generati da
105 \cmd{init} o da uno dei suoi figli\footnote{in realtà questo non è del tutto
106   vero, in Linux ci sono alcuni processi speciali che pur comparendo come
107   figli di \cmd{init}, o con \acr{pid} successivi, sono in realtà generati
108   direttamente dal kernel, (come \cmd{keventd}, \cmd{kswapd}, etc.).} si
109 possono classificare i processi con la relazione padre/figlio in
110 un'organizzazione gerarchica ad albero, in maniera analoga a come i file sono
111 organizzati in un albero di directory (si veda
112 \secref{sec:file_organization}); in \curfig\ si è mostrato il risultato del
113 comando \cmd{pstree} che permette di visualizzare questa struttura, alla cui
114 base c'è \cmd{init} che è progenitore di tutti gli altri processi.
115
116
117 Il kernel mantiene una tabella dei processi attivi, la cosiddetta
118 \textit{process table}; per ciascun processo viene mantenuta una voce nella
119 tabella dei processi costituita da una struttura \type{task\_struct}, che
120 contiene tutte le informazioni rilevanti per quel processo. Tutte le strutture
121 usate a questo scopo sono dichiarate nell'header file \file{linux/sched.h}, ed
122 uno schema semplificato che riporta la struttura delle principali informazioni
123 contenute nella \type{task\_struct} (che in seguito incontreremo a più
124 riprese), è mostrato in \nfig.
125
126 \begin{figure}[htb]
127   \centering
128   \includegraphics[width=13cm]{img/task_struct}
129   \caption{Schema semplificato dell'architettura delle strutture usate dal
130     kernel nella gestione dei processi.}
131   \label{fig:proc_task_struct}
132 \end{figure}
133
134
135 Come accennato in \secref{sec:intro_unix_struct} è lo \textit{scheduler} che
136 decide quale processo mettere in esecuzione; esso viene eseguito ad ogni
137 system call ed ad ogni interrupt, (ma può essere anche attivato
138 esplicitamente). Il timer di sistema provvede comunque a che esso sia invocato
139 periodicamente, generando un interrupt periodico secondo la frequenza
140 specificata dalla costante \macro{HZ}, definita in \file{asm/param.h} Il
141 valore usuale è 100\footnote{è così per tutte le archietetture eccetto
142   l'alpha, per la quale è 1000} (è espresso in Hertz), si ha cioè un interrupt
143 dal timer ogni centesimo di secondo.
144
145 Ogni volta che viene eseguito, lo \textit{scheduler} effettua il calcolo delle
146 priorità dei vari processi attivi (torneremo su questo in
147 \secref{sec:proc_priority}) e stabilisce quale di essi debba essere posto in
148 esecuzione fino alla successiva invocazione.
149
150
151 \subsection{Una panoramica sulle funzioni fondamentali}
152 \label{sec:proc_handling_intro}
153
154 I processi vengono creati dalla funzione \func{fork}; in molti unix questa è
155 una system call, Linux però usa un'altra nomenclatura, e la funzione
156 \func{fork} è basata a sua volta sulla system call \func{\_\_clone}, che viene
157 usata anche per generare i \textit{thread}.  Il processo figlio creato dalla
158 \func{fork} è una copia identica del processo processo padre, ma ha nuovo
159 \acr{pid} e viene eseguito in maniera indipendente (le differenze fra padre e
160 figlio sono affrontate in dettaglio in \secref{sec:proc_fork}).
161
162 Se si vuole che il processo padre si fermi fino alla conclusione del processo
163 figlio questo deve essere specificato subito dopo la \func{fork} chiamando la
164 funzione \func{wait} o la funzione \func{waitpid} (si veda
165 \secref{sec:proc_wait}); queste funzioni restituiscono anche un'informazione
166 abbastanza limitata sulle cause della terminazione del processo figlio.
167
168 Quando un processo ha concluso il suo compito o ha incontrato un errore non
169 risolvibile esso può essere terminato con la funzione \func{exit} (si veda
170 quanto discusso in \secref{sec:proc_conclusion}). La vita del processo però
171 termina solo quando la notifica della sua conclusione viene ricevuta dal
172 processo padre, a quel punto tutte le risorse allocate nel sistema ad esso
173 associate vengono rilasciate.
174
175 Avere due processi che eseguono esattamente lo stesso codice non è molto
176 utile, normalmente si genera un secondo processo per affidargli l'esecuzione
177 di un compito specifico (ad esempio gestire una connessione dopo che questa è
178 stata stabilita), o fargli eseguire (come fa la shell) un altro programma. Per
179 quest'ultimo caso si usa la seconda funzione fondamentale per programmazione
180 coi processi che è la \func{exec}.
181
182 Il programma che un processo sta eseguendo si chiama immagine del processo (o
183 \textit{process image}), le funzioni della famiglia \func{exec} permettono di
184 caricare un'altro programma da disco sostituendo quest'ultimo all'immagine
185 corrente; questo fa sì che l'immagine precedente venga completamente
186 cancellata. Questo significa che quando il nuovo programma esce, anche il
187 processo termina, e non si può tornare alla precedente immagine.
188
189 Per questo motivo la \func{fork} e la \func{exec} sono funzioni molto
190 particolari con caratteristiche uniche rispetto a tutte le altre, infatti la
191 prima ritorna due volte (nel processo padre e nel figlio) mentre la seconda
192 non ritorna mai (in quanto con essa viene eseguito un altro programma).
193
194
195
196 \section{Le funzioni di base}% della gestione dei processi}
197 \label{sec:proc_handling}
198
199 In questa sezione tratteremo le problematiche della gestione dei processi
200 all'interno del sistema, illustrandone tutti i dettagli.  Inizieremo con le
201 funzioni elementari che permettono di leggerne gli identificatori, per poi
202 passare alla spiegazione delle funzioni base che si usano per la creazione e
203 la terminazione dei processi, e per la messa in esecuzione degli altri
204 programmi.
205
206
207 \subsection{Gli identificatori dei processi}
208 \label{sec:proc_pid}
209
210 Come accennato nell'introduzione, ogni processo viene identificato dal sistema
211 da un numero identificativo unico, il \textit{process id} o \acr{pid};
212 quest'ultimo è un tipo di dato standard, il \type{pid\_t} che in genere è un
213 intero con segno (nel caso di Linux e delle \acr{glibc} il tipo usato è
214 \type{int}).
215
216 Il \acr{pid} viene assegnato in forma progressiva ogni volta che un nuovo
217 processo viene creato, fino ad un limite che, essendo il \acr{pid} un numero
218 positivo memorizzato in un intero a 16 bit, arriva ad un massimo di 32767.
219 Oltre questo valore l'assegnazione riparte dal numero più basso disponibile a
220 partire da un minimo di 300,\footnote{questi valori sono definiti dalla macro
221   \macro{PID\_MAX} in \file{threads.h} e direttamente in \file{fork.c} nei
222   sorgenti del kernel.} che serve a riservare i \acr{pid} più bassi ai processi
223 eseguiti dal direttamente dal kernel.  Per questo motivo, come visto in
224 \secref{sec:proc_hierarchy}, il processo di avvio (\cmd{init}) ha sempre il
225 \acr{pid} uguale a uno.
226
227 Tutti i processi inoltre memorizzano anche il \acr{pid} del genitore da cui
228 sono stati creati, questo viene chiamato in genere \acr{ppid} (da
229 \textit{parent process id}).  Questi due identificativi possono essere
230 ottenuti da programma usando le funzioni:
231 \begin{functions}
232 \headdecl{sys/types.h}
233 \headdecl{unistd.h}
234 \funcdecl{pid\_t getpid(void)} Restituisce il pid del processo corrente.
235 \funcdecl{pid\_t getppid(void)} Restituisce il pid del padre del processo
236     corrente.
237
238 \bodydesc{Entrambe le funzioni non riportano condizioni di errore.}
239 \end{functions}
240 \noindent esempi dell'uso di queste funzioni sono riportati in
241 \figref{fig:proc_fork_code}, nel programma di esempio \file{ForkTest.c}.
242
243 Il fatto che il \acr{pid} sia un numero univoco per il sistema lo rende un
244 candidato per generare ulteriori indicatori associati al processo di cui
245 diventa possibile garantire l'unicità: ad esempio in alcune implementazioni la
246 funzione \func{tmpname} (si veda \secref{sec:file_temp_file}) usa il \acr{pid}
247 per generare un pathname univoco, che non potrà essere replicato da un'altro
248 processo che usi la stessa funzione.
249
250 Tutti i processi figli dello stesso processo padre sono detti
251 \textit{sibling}, questa è una delle relazioni usate nel \textsl{controllo di
252   sessione}, in cui si raggruppano i processi creati su uno stesso terminale,
253 o relativi allo stesso login. Torneremo su questo argomento in dettaglio in
254 \secref{cha:session}, dove esamineremo gli altri identificativi associati ad
255 un processo e le varie relazioni fra processi utilizzate per definire una
256 sessione.
257
258 Oltre al \acr{pid} e al \acr{ppid}, (e a quelli che vedremo in
259 \secref{sec:sess_xxx}, relativi al controllo di sessione), ad ogni processo
260 vengono associati degli altri identificatori che vengono usati per il
261 controllo di accesso.  Questi servono per determinare se un processo può
262 eseguire o meno le operazioni richieste, a seconda dei privilegi e
263 dell'identità di chi lo ha posto in esecuzione; l'argomento è complesso e sarà
264 affrontato in dettaglio in \secref{sec:proc_perms}.
265
266
267 \subsection{La funzione \func{fork}}
268 \label{sec:proc_fork}
269
270 La funzione \func{fork} è la funzione fondamentale della gestione dei
271 processi: come si è detto l'unico modo di creare un nuovo processo è
272 attraverso l'uso di questa funzione, essa quindi riveste un ruolo centrale
273 tutte le volte che si devono scrivere programmi che usano il multitasking.  Il
274 prototipo della funzione è:
275 \begin{functions}
276   \headdecl{sys/types.h} 
277   \headdecl{unistd.h} 
278   \funcdecl{pid\_t fork(void)} 
279   Crea un nuovo processo.
280   
281   \bodydesc{In caso di successo restituisce il \acr{pid} del figlio al padre e
282     zero al figlio; ritorna -1 al padre (senza creare il figlio) in caso di
283     errore; \var{errno} può assumere i valori:
284   \begin{errlist}
285   \item[\macro{EAGAIN}] non ci sono risorse sufficienti per creare un'altro
286     processo (per allocare la tabella delle pagine e le strutture del task) o
287     si è esaurito il numero di processi disponibili.
288   \item[\macro{ENOMEM}] non è stato possibile allocare la memoria per le
289     strutture necessarie al kernel per creare il nuovo processo.
290   \end{errlist}}
291 \end{functions}
292
293 Dopo il successo dell'esecuzione di una \func{fork} sia il processo padre che
294 il processo figlio continuano ad essere eseguiti normalmente all'istruzione
295 seguente la \func{fork}; il processo figlio è però una copia del padre, e
296 riceve una copia dei segmenti di testo, stack e dati (vedi
297 \secref{sec:proc_mem_layout}), ed esegue esattamente lo stesso codice del
298 padre. Si tenga presente però che la memoria è copiata, non condivisa,
299 pertanto padre e figlio vedono variabili diverse.
300
301 Per quanto riguarda la gestione della memoria in generale il segmento di
302 testo, che è identico, è condiviso e tenuto in read-only per il padre e per i
303 figli. Per gli altri segmenti Linux utilizza la tecnica del \textit{copy on
304   write}\index{copy on write}; questa tecnica comporta che una pagina di
305 memoria viene effettivamente copiata per il nuovo processo solo quando ci
306 viene effettuata sopra una scrittura (e si ha quindi una reale differenza fra
307 padre e figlio). In questo modo si rende molto più efficiente il meccanismo
308 della creazione di un nuovo processo, non essendo più necessaria la copia di
309 tutto lo spazio degli indirizzi virtuali del padre, ma solo delle pagine di
310 memoria che sono state modificate, e solo al momento della modifica stessa.
311
312 La differenza che si ha nei due processi è che nel processo padre il valore di
313 ritorno della funzione \func{fork} è il \acr{pid} del processo figlio, mentre
314 nel figlio è zero; in questo modo il programma può identificare se viene
315 eseguito dal padre o dal figlio.  Si noti come la funzione \func{fork} ritorni
316 \textbf{due} volte: una nel padre e una nel figlio. 
317
318 La scelta di questi valori di ritorno non è casuale, un processo infatti può
319 avere più figli, ed il valore di ritorno di \func{fork} è l'unico modo che gli
320 permette di identificare quello appena creato; al contrario un figlio ha
321 sempre un solo padre (il cui \acr{pid} può sempre essere ottenuto con
322 \func{getppid}, vedi \secref{sec:proc_pid}) per cui si usa il valore nullo,
323 che non è il \acr{pid} di nessun processo.
324
325 \begin{figure}[!htb]
326   \footnotesize
327   \begin{lstlisting}{}
328 #include <errno.h>       /* error definitions and routines */ 
329 #include <stdlib.h>      /* C standard library */
330 #include <unistd.h>      /* unix standard library */
331 #include <stdio.h>       /* standard I/O library */
332 #include <string.h>      /* string functions */
333
334 /* Help printing routine */
335 void usage(void);
336
337 int main(int argc, char *argv[])
338 {
339 /* 
340  * Variables definition  
341  */
342     int nchild, i;
343     pid_t pid;
344     int wait_child  = 0;
345     int wait_parent = 0;
346     int wait_end    = 0;
347     ...        /* handling options */
348     nchild = atoi(argv[optind]);
349     printf("Test for forking %d child\n", nchild);
350     /* loop to fork children */
351     for (i=0; i<nchild; i++) {
352         if ( (pid = fork()) < 0) { 
353             /* on error exit */ 
354             printf("Error on %d child creation, %s\n", i+1, strerror(errno));
355             exit(-1); 
356         }
357         if (pid == 0) {   /* child */
358             printf("Child %d successfully executing\n", ++i);
359             if (wait_child) sleep(wait_child);
360             printf("Child %d, parent %d, exiting\n", i, getppid());
361             exit(0);
362         } else {          /* parent */
363             printf("Spawned %d child, pid %d \n", i+1, pid);
364             if (wait_parent) sleep(wait_parent);
365             printf("Go to next child \n");
366         }
367     }
368     /* normal exit */
369     if (wait_end) sleep(wait_end);
370     return 0;
371 }
372   \end{lstlisting}
373   \caption{Esempio di codice per la creazione di nuovi processi.}
374   \label{fig:proc_fork_code}
375 \end{figure}
376
377 Normalmente la chiamata a \func{fork} può fallire solo per due ragioni, o ci
378 sono già troppi processi nel sistema (il che di solito è sintomo che
379 qualcos'altro non sta andando per il verso giusto) o si è ecceduto il limite
380 sul numero totale di processi permessi all'utente (vedi \secref{sec:sys_xxx}).
381
382 L'uso di \func{fork} avviene secondo due modalità principali; la prima è
383 quella in cui all'interno di un programma si creano processi figli cui viene
384 affidata l'esecuzione di una certa sezione di codice, mentre il processo padre
385 ne esegue un'altra. È il caso tipico dei server di rete in cui il padre riceve
386 ed accetta le richieste da parte dei client, per ciascuna delle quali pone in
387 esecuzione un figlio che è incaricato di fornire il servizio.
388
389 La seconda modalità è quella in cui il processo vuole eseguire un altro
390 programma; questo è ad esempio il caso della shell. In questo caso il processo
391 crea un figlio la cui unica operazione è quella fare una \func{exec} (di cui
392 parleremo in \secref{sec:proc_exec}) subito dopo la \func{fork}.
393
394 Alcuni sistemi operativi (il VMS ad esempio) combinano le operazioni di questa
395 seconda modalità (una \func{fork} seguita da una \func{exec}) in un'unica
396 operazione che viene chiamata \textit{spawn}. Nei sistemi unix-like è stato
397 scelto di mantenere questa separazione, dato che, come per la prima modalità
398 d'uso, esistono numerosi scenari in cui si può usare una \func{fork} senza
399 aver bisogno di eseguire una \func{exec}. Inoltre, anche nel caso della
400 seconda modalità d'uso, avere le due funzioni separate permette al figlio di
401 cambiare gli attributi del processo (maschera dei segnali, redirezione
402 dell'output, \textit{user id}) prima della \func{exec}, rendendo così
403 relativamente facile intervenire sulle le modalità di esecuzione del nuovo
404 programma.
405
406 In \curfig\ si è riportato il corpo del codice del programma di esempio
407 \cmd{forktest}, che ci permette di illustrare molte caratteristiche dell'uso
408 della funzione \func{fork}. Il programma permette di creare un numero di figli
409 specificato da linea di comando, e prende anche alcune opzioni per indicare
410 degli eventuali tempi di attesa in secondi (eseguiti tramite la funzione
411 \func{sleep}) per il padre ed il figlio (con \cmd{forktest -h} si ottiene la
412 descrizione delle opzioni); il codice completo, compresa la parte che gestisce
413 le opzioni a riga di comando, è disponibile nel file \file{ForkTest.c},
414 distribuito insieme agli altri sorgenti degli esempi su
415 \href{http://firenze.linux.it/~piccardi/gapil_source.tgz}
416 {\texttt{http://firenze.linux.it/\~~\hspace{-2.0mm}piccardi/gapil\_source.tgz}}.
417
418 Decifrato il numero di figli da creare, il ciclo principale del programma
419 (\texttt{\small 24--40}) esegue in successione la creazione dei processi figli
420 controllando il successo della chiamata a \func{fork} (\texttt{\small
421   25--29}); ciascun figlio (\texttt{\small 31--34}) si limita a stampare il
422 suo numero di successione, eventualmente attendere il numero di secondi
423 specificato e scrivere un messaggio prima di uscire. Il processo padre invece
424 (\texttt{\small 36--38}) stampa un messaggio di creazione, eventualmente
425 attende il numero di secondi specificato, e procede nell'esecuzione del ciclo;
426 alla conclusione del ciclo, prima di uscire, può essere specificato un altro
427 periodo di attesa.
428
429 Se eseguiamo il comando senza specificare attese (come si può notare in
430 \texttt{\small 17--19} i valori di default specificano di non attendere),
431 otterremo come output sul terminale:
432
433 \footnotesize
434 \begin{verbatim}
435 [piccardi@selidor sources]$ ./forktest 3
436 Process 1963: forking 3 child
437 Spawned 1 child, pid 1964 
438 Child 1 successfully executing
439 Child 1, parent 1963, exiting
440 Go to next child 
441 Spawned 2 child, pid 1965 
442 Child 2 successfully executing
443 Child 2, parent 1963, exiting
444 Go to next child 
445 Child 3 successfully executing
446 Child 3, parent 1963, exiting
447 Spawned 3 child, pid 1966 
448 Go to next child 
449 \end{verbatim} %$
450 \normalsize
451
452 Esaminiamo questo risultato: una prima conclusione che si può trarre è che non
453 si può dire quale processo fra il padre ed il figlio venga eseguito per
454 primo\footnote{a partire dal kernel 2.5.2-pre10 è stato introdotto il nuovo
455   scheduler di Ingo Molnar che esegue sempre per primo il figlio; per
456   mantenere la portabilità è opportuno non fare comunque affidamento su questo
457   comportamento.} dopo la chiamata a \func{fork}; dall'esempio si può notare
458 infatti come nei primi due cicli sia stato eseguito per primo il padre (con la
459 stampa del \acr{pid} del nuovo processo) per poi passare all'esecuzione del
460 figlio (completata con i due avvisi di esecuzione ed uscita), e tornare
461 all'esecuzione del padre (con la stampa del passaggio al ciclo successivo),
462 mentre la terza volta è stato prima eseguito il figlio (fino alla conclusione)
463 e poi il padre.
464
465 In generale l'ordine di esecuzione dipenderà, oltre che dall'algoritmo di
466 scheduling usato dal kernel, dalla particolare situazione in si trova la
467 macchina al momento della chiamata, risultando del tutto impredicibile.
468 Eseguendo più volte il programma di prova e producendo un numero diverso di
469 figli, si sono ottenute situazioni completamente diverse, compreso il caso in
470 cui il processo padre ha eseguito più di una \func{fork} prima che uno dei
471 figli venisse messo in esecuzione.
472
473 Pertanto non si può fare nessuna assunzione sulla sequenza di esecuzione delle
474 istruzioni del codice fra padre e figli, né sull'ordine in cui questi potranno
475 essere messi in esecuzione. Se è necessaria una qualche forma di precedenza
476 occorrerà provvedere ad espliciti meccanismi di sincronizzazione, pena il
477 rischio di incorrere nelle cosiddette \textit{race condition} \index{race
478   condition} (vedi \secref{sec:proc_race_cond}.
479
480 Si noti inoltre che essendo i segmenti di memoria utilizzati dai singoli
481 processi completamente separati, le modifiche delle variabili nei processi
482 figli (come l'incremento di \var{i} in \texttt{\small 31}) sono visibili solo
483 a loro (ogni processo vede solo la propria copia della memoria), e non hanno
484 alcun effetto sul valore che le stesse variabili hanno nel processo padre (ed
485 in eventuali altri processi figli che eseguano lo stesso codice).
486
487 Un secondo aspetto molto importante nella creazione dei processi figli è
488 quello dell'interazione dei vari processi con i file; per illustrarlo meglio
489 proviamo a redirigere su un file l'output del nostro programma di test, quello
490 che otterremo è:
491
492 \footnotesize
493 \begin{verbatim}
494 [piccardi@selidor sources]$ ./forktest 3 > output
495 [piccardi@selidor sources]$ cat output
496 Process 1967: forking 3 child
497 Child 1 successfully executing
498 Child 1, parent 1967, exiting
499 Test for forking 3 child
500 Spawned 1 child, pid 1968 
501 Go to next child 
502 Child 2 successfully executing
503 Child 2, parent 1967, exiting
504 Test for forking 3 child
505 Spawned 1 child, pid 1968 
506 Go to next child 
507 Spawned 2 child, pid 1969 
508 Go to next child 
509 Child 3 successfully executing
510 Child 3, parent 1967, exiting
511 Test for forking 3 child
512 Spawned 1 child, pid 1968 
513 Go to next child 
514 Spawned 2 child, pid 1969 
515 Go to next child 
516 Spawned 3 child, pid 1970 
517 Go to next child 
518 \end{verbatim}
519 \normalsize
520 che come si vede è completamente diverso da quanto ottenevamo sul terminale.
521
522 Il comportamento delle varie funzioni di interfaccia con i file è analizzato
523 in gran dettaglio in \capref{cha:file_unix_interface} e in
524 \secref{cha:files_std_interface}. Qui basta accennare che si sono usate le
525 funzioni standard della libreria del C che prevedono l'output bufferizzato; e
526 questa bufferizzazione (trattata in dettaglio in \secref{sec:file_buffering})
527 varia a seconda che si tratti di un file su disco (in cui il buffer viene
528 scaricato su disco solo quando necessario) o di un terminale (nel qual caso il
529 buffer viene scaricato ad ogni carattere di a capo).
530
531 Nel primo esempio allora avevamo che ad ogni chiamata a \func{printf} il
532 buffer veniva scaricato, e le singole righe erano stampate a video subito dopo
533 l'esecuzione della \func{printf}. Ma con la redirezione su file la scrittura
534 non avviene più alla fine di ogni riga e l'output resta nel buffer. Dato che
535 ogni figlio riceve una copia della memoria del padre, esso riceverà anche
536 quanto c'è nel buffer delle funzioni di I/O, comprese le linee scritte dal
537 padre fino allora. Così quando il buffer viene scritto su disco all'uscita del
538 figlio, troveremo nel file anche tutto quello che il processo padre aveva
539 scritto prima della sua creazione.  E alla fine del file (dato che in questo
540 caso il padre esce per ultimo) troveremo anche l'output completo del padre.
541
542 L'esempio ci mostra un'altro aspetto fondamentale dell'interazione con i file,
543 valido anche per l'esempio precedente, ma meno evidente: il fatto cioè che non
544 solo processi diversi possono scrivere in contemporanea sullo stesso file
545 (l'argomento della condivisione dei file è trattato in dettaglio in
546 \secref{sec:file_sharing}), ma anche che, a differenza di quanto avviene per
547 le variabili, la posizione corrente sul file è condivisa fra il padre e tutti
548 i processi figli.
549
550 Quello che succede è che quando lo standard output del padre viene rediretto,
551 lo stesso avviene anche per tutti i figli; la funzione \func{fork} infatti ha
552 la caratteristica di duplicare (allo stesso modo in cui lo fa la funzione
553 \func{dup}, trattata in \secref{sec:file_dup}) nei figli tutti i file
554 descriptor aperti nel padre, il che comporta che padre e figli condividono le
555 stesse voci della \textit{file table} (per la spiegazione di questi termini si
556 veda \secref{sec:file_sharing}) e fra cui c'è anche la posizione corrente nel
557 file.
558
559 In questo modo se un processo scrive sul file aggiornerà la posizione corrente
560 sulla \textit{file table}, e tutti gli altri processi, che vedono la stessa
561 \textit{file table}, vedranno il nuovo valore. In questo modo si evita, in
562 casi come quello appena mostrato in cui diversi processi scrivono sullo stesso
563 file, che l'output successivo di un processo vada a sovrapporsi a quello dei
564 precedenti: l'output potrà risultare mescolato, ma non ci saranno parti
565 perdute per via di una sovrascrittura.
566
567 Questo tipo di comportamento è essenziale in tutti quei casi in cui il padre
568 crea un figlio e attende la sua conclusione per proseguire, ed entrambi
569 scrivono sullo stesso file (un caso tipico è la shell quando lancia un
570 programma, il cui output va sullo standard output). 
571
572 In questo modo, anche se l'output viene rediretto, il padre potrà sempre
573 continuare a scrivere in coda a quanto scritto dal figlio in maniera
574 automatica; se così non fosse ottenere questo comportamento sarebbe
575 estremamente complesso necessitando di una qualche forma di comunicazione fra
576 i due processi per far riprendere al padre la scrittura al punto giusto.
577
578 In generale comunque non è buona norma far scrivere più processi sullo stesso
579 file senza una qualche forma di sincronizzazione in quanto, come visto anche
580 con il nostro esempio, le varie scritture risulteranno mescolate fra loro in
581 una sequenza impredicibile. Per questo le modalità con cui in genere si usano
582 i file dopo una \func{fork} sono sostanzialmente due:
583 \begin{enumerate}
584 \item Il processo padre aspetta la conclusione del figlio. In questo caso non
585   è necessaria nessuna azione riguardo ai file, in quanto la sincronizzazione
586   della posizione corrente dopo eventuali operazioni di lettura e scrittura
587   effettuate dal figlio è automatica.
588 \item L'esecuzione di padre e figlio procede indipendentemente. In questo caso
589   ciascuno dei due processi deve chiudere i file che non gli servono una volta
590   che la \func{fork} è stata eseguita, per evitare ogni forma di interferenza.
591 \end{enumerate}
592
593 Oltre ai file aperti i processi figli ereditano dal padre una serie di altre
594 proprietà; la lista dettagliata delle proprietà che padre e figlio hanno in
595 comune dopo l'esecuzione di una \func{fork} è la seguente:
596 \begin{itemize*}
597 \item i file aperti e gli eventuali flag di \textit{close-on-exec} settati
598   (vedi \secref{sec:proc_exec} e \secref{sec:file_fcntl}).
599 \item gli identificatori per il controllo di accesso: il \textit{real user
600     id}, il \textit{real group id}, l'\textit{effective user id},
601   l'\textit{effective group id} ed i \textit{supplementary group id} (vedi
602   \secref{sec:proc_access_id}).
603 \item gli identificatori per il controllo di sessione: il \textit{process
604     group id} e il \textit{session id} ed il terminale di controllo (vedi
605   \secref{sec:sess_xxx} e \secref{sec:sess_xxx}).
606 \item la directory di lavoro e la directory radice (vedi
607   \secref{sec:file_work_dir} e \secref{sec:file_chroot}).
608 \item la maschera dei permessi di creazione (vedi \secref{sec:file_umask}).
609 \item la maschera dei segnali bloccati (vedi \secref{sec:sig_sigpending}) e le
610   azioni installate (vedi \secref{sec:sig_gen_beha}).
611 \item i segmenti di memoria condivisa agganciati al processo (vedi
612 \secref{sec:ipc_xxx}). 
613 \item i limiti sulle risorse (vedi \secref{sec:sys_xxx}).
614 \item le variabili di ambiente (vedi \secref{sec:proc_environ}).
615 \end{itemize*}
616 le differenze fra padre e figlio dopo la \func{fork} invece sono:
617 \begin{itemize*}
618 \item il valore di ritorno di \func{fork}.
619 \item il \textit{process id}. 
620 \item il \textit{parent process id} (quello del figlio viene settato al
621   \acr{pid} del padre).
622 \item i valori dei tempi di esecuzione (vedi \secref{sec:sys_xxx}) che
623   nel figlio sono posti a zero.
624 \item i \textit{file lock} (vedi \secref{sec:file_locking}), che non
625   vengono ereditati dal figlio.
626 \item gli allarmi ed i segnali pendenti (vedi \secref{sec:sig_gen_beha}), che
627   per il figlio vengono cancellati.
628 \end{itemize*}
629
630
631 \subsection{La funzione \func{vfork}}
632 \label{sec:proc_vfork}
633
634 La funzione \func{vfork} è esattamente identica a \func{fork} ed ha la stessa
635 semantica e gli stessi errori; la sola differenza è che non viene creata la
636 tabella delle pagine né la struttura dei task per il nuovo processo. Il
637 processo padre è posto in attesa fintanto che il figlio non ha eseguito una
638 \func{execve} o non è uscito con una \func{\_exit}. Il figlio condivide la
639 memoria del padre (e modifiche possono avere effetti imprevedibili) e non deve
640 ritornare o uscire con \func{exit} ma usare esplicitamente \func{\_exit}.
641
642 Questa funzione è un rimasuglio dei vecchi tempi in cui eseguire una
643 \func{fork} comportava anche la copia completa del segmento dati del processo
644 padre, che costituiva un inutile appesantimento in tutti quei casi in cui la
645 \func{fork} veniva fatta solo per poi eseguire una \func{exec}. La funzione
646 venne introdotta in BSD per migliorare le prestazioni.
647
648 Dato che Linux supporta il \textit{copy on write} la perdita di prestazioni è
649 assolutamente trascurabile, e l'uso di questa funzione (che resta un caso
650 speciale della funzione \func{clone}), è deprecato; per questo eviteremo di
651 trattarla ulteriormente.
652
653
654 \subsection{La conclusione di un processo.}
655 \label{sec:proc_termination}
656
657 In \secref{sec:proc_conclusion} abbiamo già affrontato le modalità con cui
658 chiudere un programma, ma dall'interno del programma stesso; avendo a che fare
659 con un sistema multitasking resta da affrontare l'argomento dal punto di vista
660 di come il sistema gestisce la conclusione dei processi.
661
662 Abbiamo visto in \secref{sec:proc_conclusion} le tre modalità con cui un
663 programma viene terminato in maniera normale: la chiamata di \func{exit} (che
664 esegue le funzioni registrate per l'uscita e chiude gli stream), il ritorno
665 dalla funzione \func{main} (equivalente alla chiamata di \func{exit}), e la
666 chiamata ad \func{\_exit} (che passa direttamente alle operazioni di
667 terminazione del processo da parte del kernel).
668
669 Ma abbiamo accennato che oltre alla conclusione normale esistono anche delle
670 modalità di conclusione anomala; queste sono in sostanza due: il programma può
671 chiamare la funzione \func{abort} per invocare una chiusura anomala, o essere
672 terminato da un segnale.  In realtà anche la prima modalità si riconduce alla
673 seconda, dato che \func{abort} si limita a generare il segnale
674 \macro{SIGABRT}.
675
676 Qualunque sia la modalità di conclusione di un processo, il kernel esegue
677 comunque una serie di operazioni: chiude tutti i file aperti, rilascia la
678 memoria che stava usando, e così via; l'elenco completo delle operazioni
679 eseguite alla chiusura di un processo è il seguente:
680 \begin{itemize*}
681 \item tutti i file descriptor sono chiusi.
682 \item viene memorizzato lo stato di terminazione del processo.
683 \item ad ogni processo figlio viene assegnato un nuovo padre (in genere
684   \cmd{init}).
685 \item viene inviato il segnale \macro{SIGCHLD} al processo padre (vedi
686   \secref{sec:sig_sigchld}).
687 \item se il processo è un leader di sessione viene mandato un segnale di
688   \macro{SIGHUP} a tutti i processi in background e il terminale di
689   controllo viene disconnesso (vedi \secref{sec:sess_xxx}).
690 \item se la conclusione di un processo rende orfano un \textit{process
691     group} ciascun membro del gruppo viene bloccato, e poi gli vengono
692   inviati in successione i segnali \macro{SIGHUP} e \macro{SIGCONT}
693   (vedi \secref{sec:sess_xxx}).
694 \end{itemize*}
695
696 Oltre queste operazioni è però necessario poter disporre di un meccanismo
697 ulteriore che consenta di sapere come la terminazione è avvenuta: dato che in
698 un sistema unix-like tutto viene gestito attraverso i processi, il meccanismo
699 scelto consiste nel riportare lo stato di terminazione (il cosiddetto
700 \textit{termination status}) al processo padre.
701
702 Nel caso di conclusione normale, abbiamo visto in \secref{sec:proc_conclusion}
703 che lo stato di uscita del processo viene caratterizzato tramite il valore del
704 cosiddetto \textit{exit status}, cioè il valore passato alle funzioni
705 \func{exit} o \func{\_exit} (o dal valore di ritorno per \func{main}).  Ma se
706 il processo viene concluso in maniera anomala il programma non può specificare
707 nessun \textit{exit status}, ed è il kernel che deve generare autonomamente il
708 \textit{termination status} per indicare le ragioni della conclusione anomala.
709
710 Si noti la distinzione fra \textit{exit status} e \textit{termination status}:
711 quello che contraddistingue lo stato di chiusura del processo e viene
712 riportato attraverso le funzioni \func{wait} o \func{waitpid} (vedi
713 \secref{sec:proc_wait}) è sempre quest'ultimo; in caso di conclusione normale
714 il kernel usa il primo (nel codice eseguito da \func{\_exit}) per produrre il
715 secondo.
716
717 La scelta di riportare al padre lo stato di terminazione dei figli, pur
718 essendo l'unica possibile, comporta comunque alcune complicazioni: infatti se
719 alla sua creazione è scontato che ogni nuovo processo ha un padre, non è detto
720 che sia così alla sua conclusione, dato che il padre potrebbe essere già
721 terminato (si potrebbe avere cioè quello che si chiama un processo
722 \textsl{orfano}). 
723
724 Questa complicazione viene superata facendo in modo che il processo orfano
725 venga \textsl{adottato} da \cmd{init}. Come già accennato quando un processo
726 termina, il kernel controlla se è il padre di altri processi in esecuzione: in
727 caso positivo allora il \acr{ppid} di tutti questi processi viene sostituito
728 con il \acr{pid} di \cmd{init} (e cioè con 1); in questo modo ogni processo
729 avrà sempre un padre (nel caso possiamo parlare di un padre \textsl{adottivo})
730 cui riportare il suo stato di terminazione.  Come verifica di questo
731 comportamento possiamo eseguire il nostro programma \cmd{forktest} imponendo a
732 ciascun processo figlio due secondi di attesa prima di uscire, il risultato è:
733
734 \footnotesize
735 \begin{verbatim}
736 [piccardi@selidor sources]$ ./forktest -c2 3
737 Process 1972: forking 3 child
738 Spawned 1 child, pid 1973 
739 Child 1 successfully executing
740 Go to next child 
741 Spawned 2 child, pid 1974 
742 Child 2 successfully executing
743 Go to next child 
744 Child 3 successfully executing
745 Spawned 3 child, pid 1975 
746 Go to next child 
747 [piccardi@selidor sources]$ Child 3, parent 1, exiting
748 Child 2, parent 1, exiting
749 Child 1, parent 1, exiting
750 \end{verbatim}
751 \normalsize
752 come si può notare in questo caso il processo padre si conclude prima dei
753 figli, tornando alla shell, che stampa il prompt sul terminale: circa due
754 secondi dopo viene stampato a video anche l'output dei tre figli che
755 terminano, e come si può notare in questo caso, al contrario di quanto visto
756 in precedenza, essi riportano 1 come \acr{ppid}.
757
758 Altrettanto rilevante è il caso in cui il figlio termina prima del padre,
759 perché non è detto che il padre possa ricevere immediatamente lo stato di
760 terminazione, quindi il kernel deve comunque conservare una certa quantità di
761 informazioni riguardo ai processi che sta terminando.
762
763 Questo viene fatto mantenendo attiva la voce nella tabella dei processi, e
764 memorizzando alcuni dati essenziali, come il \acr{pid}, i tempi di CPU usati
765 dal processo (vedi \secref{sec:sys_unix_time}) e lo stato di
766 terminazione\footnote{NdA verificare esattamente cosa c'è!}, mentre la memoria
767 in uso ed i file aperti vengono rilasciati immediatamente. I processi che sono
768 terminati, ma il cui stato di terminazione non è stato ancora ricevuto dal
769 padre sono chiamati \textit{zombie}, essi restano presenti nella tabella dei
770 processi ed in genere possono essere identificati dall'output di \cmd{ps} per
771 la presenza di una \texttt{Z} nella colonna che ne indica lo stato. Quando il
772 padre effettuerà la lettura dello stato di uscita anche questa informazione,
773 non più necessaria, verrà scartata e la terminazione potrà dirsi completamente
774 conclusa.
775
776 Possiamo utilizzare il nostro programma di prova per analizzare anche questa
777 condizione: lanciamo il comando \cmd{forktest} in background, indicando al
778 processo padre di aspettare 10 secondi prima di uscire; in questo caso, usando
779 \cmd{ps} sullo stesso terminale (prima dello scadere dei 10 secondi)
780 otterremo:
781
782 \footnotesize
783 \begin{verbatim}
784 [piccardi@selidor sources]$ ps T
785   PID TTY      STAT   TIME COMMAND
786   419 pts/0    S      0:00 bash
787   568 pts/0    S      0:00 ./forktest -e10 3
788   569 pts/0    Z      0:00 [forktest <defunct>]
789   570 pts/0    Z      0:00 [forktest <defunct>]
790   571 pts/0    Z      0:00 [forktest <defunct>]
791   572 pts/0    R      0:00 ps T
792 \end{verbatim} %$
793 \normalsize 
794 e come si vede, dato che non si è fatto nulla per riceverne lo stato di
795 terminazione, i tre processi figli sono ancora presenti pur essendosi
796 conclusi, con lo stato di zombie e l'indicazione che sono stati terminati.
797
798 La possibilità di avere degli zombie deve essere tenuta sempre presente quando
799 si scrive un programma che deve essere mantenuto in esecuzione a lungo e
800 creare molti figli. In questo caso si deve sempre avere cura di far leggere
801 l'eventuale stato di uscita di tutti i figli (in genere questo si fa
802 attraverso un apposito \textit{signal handler}, che chiama la funzione
803 \func{wait}, vedi \secref{sec:sig_sigchld} e \secref{sec:proc_wait}). Questa
804 operazione è necessaria perché anche se gli \textit{zombie} non consumano
805 risorse di memoria o processore, occupano comunque una voce nella tabella dei
806 processi, che a lungo andare potrebbe esaurirsi.
807
808 Si noti che quando un processo adottato da \cmd{init} termina, esso non
809 diviene uno \textit{zombie}; questo perché una delle funzioni di \cmd{init} è
810 appunto quella di chiamare la funzione \func{wait} per i processi cui fa da
811 padre, completandone la terminazione. Questo è quanto avviene anche quando,
812 come nel caso del precedente esempio con \cmd{forktest}, il padre termina con
813 dei figli in stato di zombie: alla sua terminazione infatti tutti i suoi figli
814 (compresi gli zombie) verranno adottati da \cmd{init}, il quale provvederà a
815 completarne la terminazione.
816
817 Si tenga presente infine che siccome gli zombie sono processi già usciti, non
818 c'è modo di eliminarli con il comando \cmd{kill}; l'unica possibilità di
819 cancellarli dalla tabella dei processi è quella di terminare il processo che
820 li ha generati, in modo che \cmd{init} possa adottarli e provvedere a
821 concluderne la terminazione.
822
823
824 \subsection{Le funzioni \func{wait} e  \func{waitpid}}
825 \label{sec:proc_wait}
826
827 Uno degli usi più comuni delle capacità multitasking di un sistema unix-like
828 consiste nella creazione di programmi di tipo server, in cui un processo
829 principale attende le richieste che vengono poi soddisfatte da una serie di
830 processi figli. Si è già sottolineato al paragrafo precedente come in questo
831 caso diventi necessario gestire esplicitamente la conclusione dei figli onde
832 evitare di riempire di \textit{zombie} la tabella dei processi; le funzioni
833 deputate a questo compito sono sostanzialmente due, \func{wait} e
834 \func{waitpid}. La prima, il cui prototipo è:
835 \begin{functions}
836 \headdecl{sys/types.h}
837 \headdecl{sys/wait.h}
838 \funcdecl{pid\_t wait(int *status)} 
839
840 Sospende il processo corrente finché un figlio non è uscito, o finché un
841 segnale termina il processo o chiama una funzione di gestione. 
842
843 \bodydesc{La funzione restituisce il \acr{pid} del figlio in caso di successo
844   e -1 in caso di errore; \var{errno} può assumere i valori:
845   \begin{errlist}
846   \item[\macro{EINTR}] la funzione è stata interrotta da un segnale.
847   \end{errlist}}
848 \end{functions}
849 \noindent
850 è presente fin dalle prime versioni di Unix; la funzione ritorna non appena un
851 processo figlio termina. Se un figlio è già terminato la funzione ritorna
852 immediatamente.
853
854 Al ritorno lo stato di terminazione del processo viene salvato nella
855 variabile puntata da \var{status} e tutte le informazioni relative al
856 processo (vedi \secref{sec:proc_termination}) vengono rilasciate.  Nel
857 caso un processo abbia più figli il valore di ritorno permette di
858 identificare qual'è quello che è uscito.
859
860 Questa funzione ha il difetto di essere poco flessibile, in quanto
861 ritorna all'uscita di un figlio qualunque. Nelle occasioni in cui è
862 necessario attendere la conclusione di un processo specifico occorre
863 predisporre un meccanismo che tenga conto dei processi già terminati, e
864 provveda a ripetere la chiamata alla funzione nel caso il processo
865 cercato sia ancora attivo.
866
867 Per questo motivo lo standard POSIX.1 ha introdotto la funzione \func{waitpid}
868 che effettua lo stesso servizio, ma dispone di una serie di funzionalità più
869 ampie, legate anche al controllo di sessione.  Dato che è possibile ottenere
870 lo stesso comportamento di \func{wait} si consiglia di utilizzare sempre
871 questa funzione, il cui prototipo è:
872 \begin{functions}
873 \headdecl{sys/types.h}
874 \headdecl{sys/wait.h}
875 \funcdecl{pid\_t waitpid(pid\_t pid, int *status, int options)} 
876 Attende la conclusione di un processo figlio.
877
878 \bodydesc{La funzione restituisce il \acr{pid} del processo che è uscito, 0 se
879   è stata specificata l'opzione \macro{WNOHANG} e il processo non è uscito e
880   -1 per un errore, nel qual caso \var{errno} assumerà i valori:
881   \begin{errlist}
882   \item[\macro{EINTR}] se non è stata specificata l'opzione \macro{WNOHANG} e
883     la funzione è stata interrotta da un segnale.
884   \item[\macro{ECHILD}] il processo specificato da \param{pid} non esiste o
885     non è figlio del processo chiamante.
886   \end{errlist}}
887 \end{functions}
888
889 Le differenze principali fra le due funzioni sono che \func{wait} si blocca
890 sempre fino a che un processo figlio non termina, mentre \func{waitpid} ha la
891 possibilità si specificare un'opzione \macro{WNOHANG} che ne previene il
892 blocco; inoltre \func{waitpid} può specificare quale processo attendere sulla
893 base del valore fornito dall'argomento \param{pid}, secondo lo
894 specchietto riportato in \ntab:
895 \begin{table}[!htb]
896   \centering
897   \footnotesize
898   \begin{tabular}[c]{|c|p{10cm}|}
899     \hline
900     \textbf{Valore} & \textbf{Significato}\\
901     \hline
902     \hline
903     $<-1$& attende per un figlio il cui \textit{process group} è uguale al
904     valore assoluto di \var{pid}. \\
905     $-1$ & attende per un figlio qualsiasi, usata in questa maniera è
906     equivalente a \func{wait}.\\ 
907     $0$  & attende per un figlio il cui \textit{process group} è uguale a
908     quello del processo chiamante. \\
909     $>0$ & attende per un figlio il cui \acr{pid} è uguale al
910     valore di \var{pid}.\\
911     \hline
912   \end{tabular}
913   \caption{Significato dei valori del parametro \var{pid} della funzione
914     \func{waitpid}.}
915   \label{tab:proc_waidpid_pid}
916 \end{table}
917
918 Il comportamento di \func{waitpid} può inoltre essere modificato passando
919 delle opportune opzioni tramite l'argomento \param{option}. I valori possibili
920 sono il già citato \macro{WNOHANG}, che previene il blocco della funzione
921 quando il processo figlio non è terminato, e \macro{WUNTRACED} (usata per il
922 controllo di sessione, trattato in \capref{cha:session}) che fa ritornare la
923 funzione anche per i processi figli che sono bloccati ed il cui stato non è
924 stato ancora riportato al padre. Il valore dell'opzione deve essere
925 specificato come maschera binaria ottenuta con l'OR delle suddette costanti
926 con zero.
927
928 La terminazione di un processo figlio è chiaramente un evento asincrono
929 rispetto all'esecuzione di un programma e può avvenire in un qualunque
930 momento. Per questo motivo, come accennato nella sezione precedente, una delle
931 azioni prese dal kernel alla conclusione di un processo è quella di mandare un
932 segnale di \macro{SIGCHLD} al padre. L'azione di default (si veda
933 \secref{sec:sig_base}) per questo segnale è di essere ignorato, ma la sua
934 generazione costituisce il meccanismo di comunicazione asincrona con cui il
935 kernel avverte il processo padre che uno dei suoi figli è terminato.
936
937 In genere in un programma non si vuole essere forzati ad attendere la
938 conclusione di un processo per proseguire, specie se tutto questo serve solo
939 per leggerne lo stato di chiusura (ed evitare la presenza di \textit{zombie}),
940 per questo la modalità più usata per chiamare queste funzioni è quella di
941 utilizzarle all'interno di un \textit{signal handler} (torneremo sui segnali e
942 su come gestire \macro{SIGCHLD} in \secref{sec:sig_sigwait_xxx}). In questo
943 caso infatti, dato che il segnale è generato dalla terminazione di un figlio,
944 avremo la certezza che la chiamata a \func{wait} non si bloccherà.
945
946 \begin{table}[!htb]
947   \centering
948   \footnotesize
949   \begin{tabular}[c]{|c|p{10cm}|}
950     \hline
951     \textbf{Macro} & \textbf{Descrizione}\\
952     \hline
953     \hline
954     \macro{WIFEXITED(s)}   & Condizione vera (valore non nullo) per un processo
955     figlio che sia terminato normalmente. \\
956     \macro{WEXITSTATUS(s)} & Restituisce gli otto bit meno significativi dello
957     stato di uscita del processo (passato attraverso \func{\_exit}, \func{exit}
958     o come valore di ritorno di \func{main}). Può essere valutata solo se
959     \macro{WIFEXITED} ha restituito un valore non nullo.\\
960     \macro{WIFSIGNALED(s)} & Vera se il processo figlio è terminato
961     in maniera anomala a causa di un segnale che non è stato catturato (vedi
962     \secref{sec:sig_notification}).\\
963     \macro{WTERMSIG(s)}    & restituisce il numero del segnale che ha causato
964     la terminazione anomala del processo.  Può essere valutata solo se
965     \macro{WIFSIGNALED} ha restituito un valore non nullo.\\
966     \macro{WCOREDUMP(s)}   & Vera se il processo terminato ha generato un
967     file si \textit{core dump}. Può essere valutata solo se
968     \macro{WIFSIGNALED} ha restituito un valore non nullo.\footnote{questa
969     macro non è definita dallo standard POSIX.1, ma è presente come estensione
970     sia in Linux che in altri Unix.}\\
971     \macro{WIFSTOPPED(s)}  & Vera se il processo che ha causato il ritorno di
972     \func{waitpid} è bloccato. L'uso è possibile solo avendo specificato
973     l'opzione \macro{WUNTRACED}. \\
974     \macro{WSTOPSIG(s)}    & restituisce il numero del segnale che ha bloccato
975     il processo, Può essere valutata solo se \macro{WIFSTOPPED} ha
976     restituito un valore non nullo. \\
977     \hline
978   \end{tabular}
979   \caption{Descrizione delle varie macro di preprocessore utilizzabili per 
980     verificare lo stato di terminazione \var{s} di un processo.}
981   \label{tab:proc_status_macro}
982 \end{table}
983
984 Entrambe le funzioni di attesa restituiscono lo stato di terminazione del
985 processo tramite il puntatore \param{status} (se non interessa memorizzare lo
986 stato si può passare un puntatore nullo). Il valore restituito da entrambe le
987 funzioni dipende dall'implementazione, e tradizionalmente alcuni bit (in
988 genere 8) sono riservati per memorizzare lo stato di uscita, e altri per
989 indicare il segnale che ha causato la terminazione (in caso di conclusione
990 anomala), uno per indicare se è stato generato un core file, ecc.\footnote{le
991   definizioni esatte si possono trovare in \file{<bits/waitstatus.h>} ma
992   questo file non deve mai essere usato direttamente, esso viene incluso
993   attraverso \file{<sys/wait.h>}.}
994
995 Lo standard POSIX.1 definisce una serie di macro di preprocessore da usare per
996 analizzare lo stato di uscita. Esse sono definite sempre in
997 \file{<sys/wait.h>} ed elencate in \tabref{tab:proc_status_macro} (si tenga
998 presente che queste macro prendono come parametro la variabile di tipo
999 \type{int} puntata da \var{status}).
1000
1001 Si tenga conto che nel caso di conclusione anomala il valore restituito da
1002 \macro{WTERMSIG} può essere confrontato con le costanti definite in
1003 \file{signal.h} ed elencate in \tabref{tab:sig_signal_list}, e stampato usando
1004 le apposite funzioni trattate in \secref{sec:sig_strsignal}.
1005
1006
1007 \subsection{Le funzioni \func{wait3} e \func{wait4}}
1008 \label{sec:proc_wait4}
1009
1010 Linux, seguendo un'estensione di BSD, supporta altre due funzioni per la
1011 lettura dello stato di terminazione di un processo \func{wait3} e
1012 \func{wait4}, analoghe alle precedenti ma che prevedono un ulteriore
1013 parametro attraverso il quale il kernel può restituire al padre informazioni
1014 sulle risorse usate dal processo terminato e dai vari figli.  I prototipi di
1015 queste funzioni, che diventano accessibili definendo la costante
1016 \macro{\_USE\_BSD}, sono:
1017 \begin{functions}
1018   \headdecl{sys/times.h} 
1019   \headdecl{sys/types.h} 
1020   \headdecl{sys/wait.h}        
1021   \headdecl{sys/resource.h}
1022   \funcdecl{pid\_t wait4(pid\_t pid, int * status, int options, struct rusage
1023     * rusage)} 
1024   È identica a \func{waitpid} sia per comportamento che per i
1025   valori dei parametri, ma restituisce in \param{rusage} un sommario delle
1026   risorse usate dal processo (per i dettagli vedi \secref{sec:sys_xxx})
1027
1028   \funcdecl{pid\_t wait3(int *status, int options, struct rusage *rusage)}
1029   Prima versione, equivalente a \code{wait4(-1, \&status, opt, rusage)} è
1030   ormai deprecata in favore di \func{wait4}.
1031 \end{functions}
1032 \noindent 
1033 la struttura \type{rusage} è definita in \file{sys/resource.h}, e viene
1034 utilizzata anche dalla funzione \func{getrusage} (vedi \secref{sec:sys_xxx})
1035 per ottenere le risorse di sistema usate da un processo; la sua definizione è
1036 riportata in \figref{fig:sys_rusage_struct}.
1037
1038 In genere includere esplicitamente \file{<sys/time.h>} non è più
1039 necessario, ma aumenta la portabilità, e serve in caso si debba accedere
1040 ai campi di \var{rusage} definiti come \type{struct timeval}. La
1041 struttura è ripresa da BSD 4.3, attualmente (con il kernel 2.4.x) i soli
1042 campi che sono mantenuti sono: \var{ru\_utime}, \var{ru\_stime},
1043 \var{ru\_minflt}, \var{ru\_majflt}, e \var{ru\_nswap}.
1044
1045
1046 \subsection{Le funzioni \func{exec}}
1047 \label{sec:proc_exec}
1048
1049 Abbiamo già detto che una delle modalità principali con cui si utilizzano i
1050 processi in Unix è quella di usarli per lanciare nuovi programmi: questo viene
1051 fatto attraverso una delle funzioni della famiglia \func{exec}. Quando un
1052 processo chiama una di queste funzioni esso viene completamente sostituito dal
1053 nuovo programma; il \acr{pid} del processo non cambia, dato che non viene
1054 creato un nuovo processo, la funzione semplicemente rimpiazza lo stack, lo
1055 heap, i dati ed il testo del processo corrente con un nuovo programma letto da
1056 disco. 
1057
1058 Ci sono sei diverse versioni di \func{exec} (per questo la si è chiamata
1059 famiglia di funzioni) che possono essere usate per questo compito, in realtà
1060 (come mostrato in \figref{fig:proc_exec_relat}), sono tutte un front-end a
1061 \func{execve}. Il prototipo di quest'ultima è:
1062 \begin{prototype}{unistd.h}
1063 {int execve(const char *filename, char *const argv[], char *const envp[])}
1064   Esegue il programma contenuto nel file \param{filename}.
1065   
1066   \bodydesc{La funzione ritorna -1 solo in caso di errore, nel qual caso
1067     caso la \var{errno} può assumere i valori:
1068   \begin{errlist}
1069   \item[\macro{EACCES}] il file non è eseguibile, oppure il filesystem è
1070     montato in \cmd{noexec}, oppure non è un file normale o un interprete.
1071   \item[\macro{EPERM}] il file ha i bit \acr{suid} o \acr{sgid}, l'utente non
1072     è root, e o il processo viene tracciato, o il filesystem è montato con
1073     l'opzione \cmd{nosuid}.
1074   \item[\macro{ENOEXEC}] il file è in un formato non eseguibile o non
1075     riconosciuto come tale, o compilato per un'altra architettura.
1076   \item[\macro{ENOENT}] il file o una delle librerie dinamiche o l'interprete
1077     necessari per eseguirlo non esistono.
1078   \item[\macro{ETXTBSY}] L'eseguibile è aperto in scrittura da uno o più
1079     processi. 
1080   \item[\macro{EINVAL}] L'eseguibile ELF ha più di un segmento
1081     \macro{PF\_INTERP}, cioè chiede di essere eseguito da più di un
1082     interprete.
1083   \item[\macro{ELIBBAD}] Un interprete ELF non è in un formato
1084     riconoscibile.
1085   \end{errlist}
1086   ed inoltre anche \macro{EFAULT}, \macro{ENOMEM}, \macro{EIO},
1087   \macro{ENAMETOOLONG}, \macro{E2BIG}, \macro{ELOOP}, \macro{ENOTDIR},
1088   \macro{ENFILE}, \macro{EMFILE}.}
1089 \end{prototype}
1090
1091 La funzione \func{exec} esegue il file o lo script indicato da
1092 \var{filename}, passandogli la lista di argomenti indicata da \var{argv}
1093 e come ambiente la lista di stringhe indicata da \var{envp}; entrambe le
1094 liste devono essere terminate da un puntatore nullo. I vettori degli
1095 argomenti e dell'ambiente possono essere acceduti dal nuovo programma
1096 quando la sua funzione \func{main} è dichiarata nella forma
1097 \code{main(int argc, char *argv[], char *envp[])}.
1098
1099 Le altre funzioni della famiglia servono per fornire all'utente una serie
1100 possibile di diverse interfacce per la creazione di un nuovo processo. I loro
1101 prototipi sono:
1102 \begin{functions}
1103 \headdecl{unistd.h}
1104 \funcdecl{int execl(const char *path, const char *arg, ...)} 
1105 \funcdecl{int execv(const char *path, char *const argv[])} 
1106 \funcdecl{int execle(const char *path, const char *arg, ..., char 
1107 * const envp[])} 
1108 \funcdecl{int execlp(const char *file, const char *arg, ...)} 
1109 \funcdecl{int execvp(const char *file, char *const argv[])} 
1110
1111 Sostituiscono l'immagine corrente del processo con quella indicata nel primo
1112 argomento. I parametri successivi consentono di specificare gli argomenti a
1113 linea di comando e l'ambiente ricevuti dal nuovo processo.
1114
1115 \bodydesc{Queste funzioni ritornano solo in caso di errore, restituendo
1116   -1; nel qual caso \var{errno} andrà ad assumere i valori visti in
1117   precedenza per \func{execve}.}
1118 \end{functions}
1119
1120 Per capire meglio le differenze fra le funzioni della famiglia si può fare
1121 riferimento allo specchietto riportato in \ntab. La prima differenza riguarda
1122 le modalità di passaggio dei parametri che poi andranno a costituire gli
1123 argomenti a linea di comando (cioè i valori di \var{argv} e \var{argc} visti
1124 dalla funzione \func{main} del programma chiamato). 
1125
1126 Queste modalità sono due e sono riassunte dagli mnemonici \code{v} e \code{l}
1127 che stanno rispettivamente per \textit{vector} e \textit{list}. Nel primo caso
1128 gli argomenti sono passati tramite il vettore di puntatori \var{argv[]} a
1129 stringhe terminate con zero che costituiranno gli argomenti a riga di comando,
1130 questo vettore \emph{deve} essere terminato da un puntatore nullo.
1131
1132 Nel secondo caso le stringhe degli argomenti sono passate alla funzione come
1133 lista di puntatori, nella forma:
1134 \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
1135   char *arg0, char *arg1,  ..., char *argn, NULL
1136 \end{lstlisting}
1137 che deve essere terminata da un puntatore nullo.  In entrambi i casi vale la
1138 convenzione che il primo argomento (\var{arg0} o \var{argv[0]}) viene usato
1139 per indicare il nome del file che contiene il programma che verrà eseguito.
1140
1141 \begin{table}[!htb]
1142   \footnotesize
1143   \centering
1144   \begin{tabular}[c]{|l|c|c|c||c|c|c|}
1145     \hline
1146     \multicolumn{1}{|c|}{\textbf{Caratteristiche}} & 
1147     \multicolumn{6}{|c|}{\textbf{Funzioni}} \\
1148     \hline
1149     &\func{execl\ }&\func{execlp}&\func{execle}
1150     &\func{execv\ }& \func{execvp}& \func{execve} \\
1151     \hline
1152     \hline
1153     argomenti a lista    &$\bullet$&$\bullet$&$\bullet$&&& \\
1154     argomenti a vettore  &&&&$\bullet$&$\bullet$&$\bullet$\\
1155     \hline
1156     filename completo    &&$\bullet$&&&$\bullet$& \\ 
1157     ricerca su \var{PATH}&$\bullet$&&$\bullet$&$\bullet$&&$\bullet$ \\
1158     \hline
1159     ambiente a vettore   &&&$\bullet$&&&$\bullet$ \\
1160     uso di \var{environ} &$\bullet$&$\bullet$&&$\bullet$&$\bullet$& \\
1161     \hline
1162   \end{tabular}
1163   \caption{Confronto delle caratteristiche delle varie funzioni della 
1164     famiglia \func{exec}.}
1165   \label{tab:proc_exec_scheme}
1166 \end{table}
1167
1168 La seconda differenza fra le funzioni riguarda le modalità con cui si
1169 specifica il programma che si vuole eseguire. Con lo mnemonico \code{p} si
1170 indicano le due funzioni che replicano il comportamento della shell nello
1171 specificare il comando da eseguire; quando il parametro \var{file} non
1172 contiene una \file{/} esso viene considerato come un nome di programma, e
1173 viene eseguita automaticamente una ricerca fra i file presenti nella lista di
1174 directory specificate dalla variabile di ambiente \var{PATH}. Il file che
1175 viene posto in esecuzione è il primo che viene trovato. Se si ha un errore
1176 relativo a permessi di accesso insufficienti (cioè l'esecuzione della
1177 sottostante \func{execve} ritorna un \macro{EACCESS}), la ricerca viene
1178 proseguita nelle eventuali ulteriori directory indicate in \var{PATH}; solo se
1179 non viene trovato nessun altro file viene finalmente restituito
1180 \macro{EACCESS}.
1181
1182 Le altre quattro funzioni si limitano invece a cercare di eseguire il file
1183 indicato dal parametro \var{path}, che viene interpretato come il
1184 \textit{pathname} del programma.
1185
1186 \begin{figure}[htb]
1187   \centering
1188   \includegraphics[width=13cm]{img/exec_rel}
1189   \caption{La interrelazione fra le sei funzioni della famiglia \func{exec}.}
1190   \label{fig:proc_exec_relat}
1191 \end{figure}
1192
1193 La terza differenza è come viene passata la lista delle variabili di ambiente.
1194 Con lo mnemonico \code{e} vengono indicate quelle funzioni che necessitano di
1195 un vettore di parametri \var{envp[]} analogo a quello usato per gli argomenti
1196 a riga di comando (terminato quindi da un \macro{NULL}), le altre usano il
1197 valore della variabile \var{environ} (vedi \secref{sec:proc_environ}) del
1198 processo di partenza per costruire l'ambiente.
1199
1200 Oltre a mantenere lo stesso \acr{pid}, il nuovo programma fatto partire da
1201 \func{exec} assume anche una serie di altre proprietà del processo chiamante;
1202 la lista completa è la seguente:
1203 \begin{itemize*}
1204 \item il \textit{process id} (\acr{pid}) ed il \textit{parent process id}
1205   (\acr{ppid}).
1206 \item il \textit{real user id} ed il \textit{real group id} (vedi
1207   \secref{sec:proc_access_id}).
1208 \item i \textit{supplementary group id} (vedi \secref{sec:proc_access_id}).
1209 \item il \textit{session id} ed il \textit{process group id} (vedi
1210   \secref{sec:sess_xxx}).
1211 \item il terminale di controllo (vedi \secref{sec:sess_xxx}).
1212 \item il tempo restante ad un allarme (vedi \secref{sec:sig_alarm_abort}).
1213 \item la directory radice e la directory di lavoro corrente (vedi
1214   \secref{sec:file_work_dir}).
1215 \item la maschera di creazione dei file (\var{umask}, vedi
1216   \secref{sec:file_umask}) ed i \textit{lock} sui file (vedi
1217   \secref{sec:file_locking}).
1218 \item i segnali sospesi (\textit{pending}) e la maschera dei segnali (si veda
1219   \secref{sec:sig_sigpending}).
1220 \item i limiti sulle risorse (vedi \secref{sec:sys_limits}).
1221 \item i valori delle variabili \var{tms\_utime}, \var{tms\_stime},
1222   \var{tms\_cutime}, \var{tms\_ustime} (vedi \secref{sec:xxx_xxx}).
1223 \end{itemize*}
1224
1225 Inoltre i segnali che sono stati settati per essere ignorati nel processo
1226 chiamante mantengono lo stesso settaggio pure nel nuovo programma, tutti gli
1227 altri segnali vengono settati alla loro azione di default. Un caso speciale è
1228 il segnale \macro{SIGCHLD} che, quando settato a \macro{SIG\_IGN}, può anche
1229 non essere resettato a \macro{SIG\_DFL} (si veda \secref{sec:sig_gen_beha}).
1230
1231 La gestione dei file aperti dipende dal valore che ha il flag di
1232 \textit{close-on-exec} (trattato in \secref{sec:file_fcntl}) per ciascun file
1233 descriptor. I file per cui è settato vengono chiusi, tutti gli altri file
1234 restano aperti. Questo significa che il comportamento di default è che i file
1235 restano aperti attraverso una \func{exec}, a meno di una chiamata esplicita a
1236 \func{fcntl} che setti il suddetto flag.
1237
1238 Per le directory, lo standard POSIX.1 richiede che esse vengano chiuse
1239 attraverso una \func{exec}, in genere questo è fatto dalla funzione
1240 \func{opendir} (vedi \secref{sec:file_dir_read}) che effettua da sola il
1241 settaggio del flag di \textit{close-on-exec} sulle directory che apre, in
1242 maniera trasparente all'utente.
1243
1244 Abbiamo detto che il \textit{real user id} ed il \textit{real group id}
1245 restano gli stessi all'esecuzione di \func{exec}; lo stesso vale per
1246 l'\textit{effective user id} ed l'\textit{effective group id}, tranne quando
1247 il file che si va ad eseguire abbia o il \acr{suid} bit o lo \acr{sgid} bit
1248 settato, in questo caso l'\textit{effective user id} e l'\textit{effective
1249   group id} vengono settati rispettivamente all'utente o al gruppo cui il file
1250 appartiene (per i dettagli vedi \secref{sec:proc_perms}).
1251
1252 Se il file da eseguire è in formato \emph{a.out} e necessita di librerie
1253 condivise, viene lanciato il \textit{linker} dinamico \cmd{ld.so} prima del
1254 programma per caricare le librerie necessarie ed effettuare il link
1255 dell'eseguibile. Se il programma è in formato ELF per caricare le librerie
1256 dinamiche viene usato l'interprete indicato nel segmento \macro{PT\_INTERP},
1257 in genere questo è \file{/lib/ld-linux.so.1} per programmi linkati con le
1258 \emph{libc5}, e \file{/lib/ld-linux.so.2} per programmi linkati con le
1259 \emph{glibc}. Infine nel caso il file sia uno script esso deve iniziare con
1260 una linea nella forma \cmd{\#!/path/to/interpreter} dove l'interprete indicato
1261 deve esse un valido programma (binario, non un altro script) che verrà
1262 chiamato come se si fosse eseguito il comando \cmd{interpreter [arg]
1263   filename}.
1264
1265 Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è
1266 basata la gestione dei processi in Unix: con \func{fork} si crea un nuovo
1267 processo, con \func{exec} si avvia un nuovo programma, con \func{exit} e
1268 \func{wait} si effettua e verifica la conclusione dei programmi. Tutte le
1269 altre funzioni sono ausiliarie e servono la lettura e il settaggio dei vari
1270 parametri connessi ai processi.
1271
1272
1273
1274 \section{Il controllo di accesso}
1275 \label{sec:proc_perms}
1276
1277 In questa sezione esamineremo le problematiche relative al controllo di
1278 accesso dal punto di vista del processi; vedremo quali sono gli identificatori
1279 usati, come questi possono essere modificati nella creazione e nel lancio di
1280 nuovi processi, le varie funzioni per la loro manipolazione diretta e tutte le
1281 problematiche connesse ad una gestione accorta dei privilegi.
1282
1283
1284 \subsection{Gli identificatori del controllo di accesso}
1285 \label{sec:proc_access_id}
1286
1287 Come accennato in \secref{sec:intro_multiuser} il modello base\footnote{in
1288   realtà già esistono estensioni di questo modello base, che lo rendono più
1289   flessibile e controllabile, come le \textit{capabilities}, le ACL per i file
1290   o il \textit{Mandatory Access Control} di SELinux.} di sicurezza di un
1291 sistema unix-like è fondato sui concetti di utente e gruppo, e sulla
1292 separazione fra l'amministratore (\textsl{root}, detto spesso anche
1293 \textit{superuser}) che non è sottoposto a restrizioni, ed il resto degli
1294 utenti, per i quali invece vengono effettuati i vari controlli di accesso.
1295
1296 %Benché il sistema sia piuttosto semplice (è basato su un solo livello di
1297 % separazione) il sistema permette una
1298 %notevole flessibilità, 
1299
1300 Abbiamo già accennato come il sistema associ ad ogni utente e gruppo due
1301 identificatori univoci, lo \acr{uid} e il \acr{gid}; questi servono al kernel
1302 per identificare uno specifico utente o un gruppo di utenti, per poi poter
1303 controllare che essi siano autorizzati a compiere le operazioni richieste.  Ad
1304 esempio in \secref{sec:file_access_control} vedremo come ad ogni file vengano
1305 associati un utente ed un gruppo (i suoi \textsl{proprietari}, indicati
1306 appunto tramite un \acr{uid} ed un \acr{gid}) che vengono controllati dal
1307 kernel nella gestione dei permessi di accesso.
1308
1309 Dato che tutte le operazioni del sistema vengono compiute dai processi, è
1310 evidente che per poter implementare un controllo sulle operazioni occorre
1311 anche poter identificare chi è che ha lanciato un certo programma, e pertanto
1312 anche a ciascun processo è associato un utente e a un gruppo.
1313
1314 Un semplice controllo di una corrispondenza fra identificativi non garantisce
1315 però sufficiente flessibilità per tutti quei casi in cui è necessario poter
1316 disporre di privilegi diversi, o dover impersonare un altro utente per un
1317 limitato insieme di operazioni. Per questo motivo in generale tutti gli Unix
1318 prevedono che i processi abbiano almeno due gruppi di identificatori, chiamati
1319 rispettivamente \textit{real} ed \textit{effective}.
1320
1321 \begin{table}[htb]
1322   \footnotesize
1323   \centering
1324   \begin{tabular}[c]{|c|l|p{6.5cm}|}
1325     \hline
1326     \textbf{Suffisso} & \textbf{Significato} & \textbf{Utilizzo} \\ 
1327     \hline
1328     \hline
1329     \acr{uid}   & \textit{real user id} & indica l'utente che ha lanciato
1330     il programma\\ 
1331     \acr{gid}   & \textit{real group id} & indica il gruppo dell'utente 
1332     che ha lanciato il programma \\ 
1333     \hline
1334     \acr{euid}  & \textit{effective user id} & indica l'utente usato
1335     dal programma nel controllo di accesso \\ 
1336     \acr{egid}  & \textit{effective group id} & indica il gruppo 
1337     usato dal programma  nel controllo di accesso \\ 
1338     --          & \textit{supplementary group id} & indica i gruppi cui
1339     l'utente appartiene  \\ 
1340     \hline
1341     --          & \textit{saved user id} &  copia dell'\acr{euid} iniziale\\ 
1342     --          & \textit{saved group id} &  copia dell'\acr{egid} iniziale \\ 
1343     \hline
1344     \acr{fsuid} & \textit{filesystem user id} & indica l'utente effettivo per
1345     il filesystem \\ 
1346     \acr{fsgid} & \textit{filesystem group id} & indica il gruppo effettivo
1347     per il filesystem  \\ 
1348     \hline
1349   \end{tabular}
1350   \caption{Identificatori di utente e gruppo associati a ciascun processo con
1351     indicazione dei suffissi usate dalle varie funzioni di manipolazione.}
1352   \label{tab:proc_uid_gid}
1353 \end{table}
1354
1355 Al primo gruppo appartengono il \textit{real user id} e il \textit{real group
1356   id}: questi vengono settati al login ai valori corrispondenti all'utente con
1357 cui si accede al sistema (e relativo gruppo di default). Servono per
1358 l'identificazione dell'utente e normalmente non vengono mai cambiati. In
1359 realtà vedremo (in \secref{sec:proc_setuid}) che è possibile modificarli, ma
1360 solo ad un processo che abbia i privilegi di amministratore; questa
1361 possibilità è usata ad esempio da \cmd{login} che, una volta completata la
1362 procedura di autenticazione, lancia una shell per la quale setta questi
1363 identificatori ai valori corrispondenti all'utente che entra nel sistema.
1364
1365 Al secondo gruppo appartengono l'\textit{effective user id} e
1366 l'\textit{effective group id} (a cui si aggiungono gli eventuali
1367 \textit{supplementary group id} dei gruppi dei quali l'utente fa parte).
1368 Questi sono invece gli identificatori usati nella verifiche dei permessi del
1369 processo e per il controllo di accesso ai file (argomento affrontato in
1370 dettaglio in \secref{sec:file_perm_overview}). 
1371
1372 Questi identificatori normalmente sono identici ai corrispondenti del gruppo
1373 \textit{real} tranne nel caso in cui, come accennato in
1374 \secref{sec:proc_exec}, il programma che si è posto in esecuzione abbia i bit
1375 \acr{suid} o \acr{sgid} settati (il significato di questi bit è affrontato in
1376 dettaglio in \secref{sec:file_suid_sgid}). In questo caso essi saranno settati
1377 all'utente e al gruppo proprietari del file. Questo consente, per programmi in
1378 cui ci sia necessità, di dare a qualunque utente normale privilegi o permessi
1379 di un'altro (o dell'amministratore).
1380
1381 Come nel caso del \acr{pid} e del \acr{ppid} tutti questi identificatori
1382 possono essere letti dal processo attraverso delle opportune funzioni, i cui
1383 prototipi sono i seguenti:
1384 \begin{functions}
1385   \headdecl{unistd.h}
1386   \headdecl{sys/types.h}  
1387   \funcdecl{uid\_t getuid(void)} Restituisce il \textit{real user id} del
1388   processo corrente.
1389
1390   \funcdecl{uid\_t geteuid(void)} Restituisce l'\textit{effective user id} del
1391   processo corrente.
1392
1393   \funcdecl{gid\_t getgid(void)} Restituisce il \textit{real group id} del
1394   processo corrente.
1395
1396   \funcdecl{gid\_t getegid(void)} Restituisce l'\textit{effective group id} del
1397   processo corrente.
1398   
1399   \bodydesc{Queste funzioni non riportano condizioni di errore.}
1400 \end{functions}
1401
1402 In generale l'uso di privilegi superiori deve essere limitato il più
1403 possibile, per evitare abusi e problemi di sicurezza, per questo occorre anche
1404 un meccanismo che consenta ad un programma di rilasciare gli eventuali
1405 maggiori privilegi necessari, una volta che si siano effettuate le operazioni
1406 per i quali erano richiesti, e a poterli eventualmente recuperare in caso
1407 servano di nuovo.
1408
1409 Questo in Linux viene fatto usando altri due gruppi di identificatori, il
1410 \textit{saved} ed il \textit{filesystem}, analoghi ai precedenti. Il primo
1411 gruppo è lo stesso usato in SVr4, e previsto dallo standard POSIX quando è
1412 definita la costante \macro{\_POSIX\_SAVED\_IDS},\footnote{in caso si abbia a
1413   cuore la portabilità del programma su altri Unix è buona norma controllare
1414   sempre la disponibilità di queste funzioni controllando se questa costante è
1415   definita.} il secondo gruppo è specifico di Linux e viene usato per
1416 migliorare la sicurezza con NFS.
1417
1418 Il \textit{saved user id} e il \textit{saved group id} sono copie
1419 dell'\textit{effective user id} e dell'\textit{effective group id} del
1420 processo padre, e vengono settati dalla funzione \func{exec} all'avvio del
1421 processo, come copie dell'\textit{effective user id} e dell'\textit{effective
1422   group id} dopo che questo sono stati settati tenendo conto di eventuali
1423 \acr{suid} o \acr{sgid}.  Essi quindi consentono di tenere traccia di quale
1424 fossero utente e gruppo effettivi all'inizio dell'esecuzione di un nuovo
1425 programma.
1426
1427 Il \textit{filesystem user id} e il \textit{filesystem group id} sono una
1428 estensione introdotta in Linux per rendere più sicuro l'uso di NFS (torneremo
1429 sull'argomento in \secref{sec:proc_setfsuid}). Essi sono una replica dei
1430 corrispondenti \textit{effective id}, ai quali si sostituiscono per tutte le
1431 operazioni di verifica dei permessi relativi ai file (trattate in
1432 \secref{sec:file_perm_overview}).  Ogni cambiamento effettuato sugli
1433 \textit{effective id} viene automaticamente riportato su di essi, per cui in
1434 condizioni normali se ne può tranquillamente ignorare l'esistenza, in quanto
1435 saranno del tutto equivalenti ai precedenti.
1436
1437 Uno specchietto riassuntivo, contenente l'elenco completo degli identificatori
1438 di utente e gruppo associati dal kernel ad ogni processo, è riportato in
1439 \tabref{tab:proc_uid_gid}.
1440
1441
1442 \subsection{Le funzioni \func{setuid} e \func{setgid}}
1443 \label{sec:proc_setuid}
1444
1445 Le due funzioni che vengono usate per cambiare identità (cioè utente e gruppo
1446 di appartenenza) ad un processo sono rispettivamente \func{setuid} e
1447 \func{setgid}; come accennato in \secref{sec:proc_access_id} in Linux esse
1448 seguono la semantica POSIX che prevede l'esistenza del \textit{saved user id}
1449 e del \textit{saved group id}; i loro prototipi sono:
1450 \begin{functions}
1451 \headdecl{unistd.h}
1452 \headdecl{sys/types.h}
1453
1454 \funcdecl{int setuid(uid\_t uid)} Setta l'\textit{user id} del processo
1455 corrente.
1456
1457 \funcdecl{int setgid(gid\_t gid)} Setta il \textit{group id} del processo
1458 corrente.
1459
1460 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1461   di fallimento: l'unico errore possibile è \macro{EPERM}.}
1462 \end{functions}
1463
1464 Il funzionamento di queste due funzioni è analogo, per cui considereremo solo
1465 la prima; la seconda si comporta esattamente allo stesso modo facendo
1466 riferimento al \textit{group id} invece che all'\textit{user id}.  Gli
1467 eventuali \textit{supplementary group id} non vengono modificati.
1468
1469
1470 L'effetto della chiamata è diverso a seconda dei privilegi del processo; se
1471 l'\textit{effective user id} è zero (cioè è quello dell'amministratore di
1472 sistema) allora tutti gli identificatori (\textit{real}, \textit{effective}
1473 e \textit{saved}) vengono settati al valore specificato da \var{uid},
1474 altrimenti viene settato solo l'\textit{effective user id}, e soltanto se il
1475 valore specificato corrisponde o al \textit{real user id} o al \textit{saved
1476   user id}. Negli altri casi viene segnalato un errore (con \macro{EPERM}).
1477
1478 Come accennato l'uso principale di queste funzioni è quello di poter
1479 consentire ad un programma con i bit \acr{suid} o \acr{sgid} settati di
1480 riportare l'\textit{effective user id} a quello dell'utente che ha lanciato il
1481 programma, effettuare il lavoro che non necessita di privilegi aggiuntivi, ed
1482 eventualmente tornare indietro.
1483
1484 Come esempio per chiarire l'uso di queste funzioni prendiamo quello con cui
1485 viene gestito l'accesso al file \file{/var/log/utmp}.  In questo file viene
1486 registrato chi sta usando il sistema al momento corrente; chiaramente non può
1487 essere lasciato aperto in scrittura a qualunque utente, che potrebbe
1488 falsificare la registrazione. Per questo motivo questo file (e l'analogo
1489 \file{/var/log/wtmp} su cui vengono registrati login e logout) appartengono ad
1490 un gruppo dedicato (\acr{utmp}) ed i programmi che devono accedervi (ad
1491 esempio tutti i programmi di terminale in X, o il programma \cmd{screen} che
1492 crea terminali multipli su una console) appartengono a questo gruppo ed hanno
1493 il bit \acr{sgid} settato.
1494
1495 Quando uno di questi programmi (ad esempio \cmd{xterm}) viene lanciato, la
1496 situazione degli identificatori è la seguente:
1497 \begin{eqnarray*}
1498   \label{eq:1}
1499   \textit{real group id}      &=& \textrm{\acr{gid} (del chiamante)} \\
1500   \textit{effective group id} &=& \textrm{\acr{utmp}} \\
1501   \textit{saved group id}     &=& \textrm{\acr{utmp}}
1502 \end{eqnarray*}
1503 in questo modo, dato che l'\textit{effective group id} è quello giusto, il
1504 programma può accedere a \file{/var/log/utmp} in scrittura ed aggiornarlo. A
1505 questo punto il programma può eseguire una \code{setgid(getgid())} per settare
1506 l'\textit{effective group id} a quello dell'utente (e dato che il \textit{real
1507   group id} corrisponde la funzione avrà successo), in questo modo non sarà
1508 possibile lanciare dal terminale programmi che modificano detto file, in tal
1509 caso infatti la situazione degli identificatori sarebbe:
1510 \begin{eqnarray*}
1511   \label{eq:2}
1512   \textit{real group id}      &=& \textrm{\acr{gid} (invariato)}  \\
1513   \textit{effective group id} &=& \textrm{\acr{gid}} \\
1514   \textit{saved group id}     &=& \textrm{\acr{utmp} (invariato)}
1515 \end{eqnarray*}
1516 e ogni processo lanciato dal terminale avrebbe comunque \acr{gid} come
1517 \textit{effective group id}. All'uscita dal terminale, per poter di nuovo
1518 aggiornare lo stato di \file{/var/log/utmp} il programma eseguirà una
1519 \code{setgid(utmp)} (dove \var{utmp} è il valore numerico associato al gruppo
1520 \acr{utmp}, ottenuto ad esempio con una precedente \func{getegid}), dato che
1521 in questo caso il valore richiesto corrisponde al \textit{saved group id} la
1522 funzione avrà successo e riporterà la situazione a:
1523 \begin{eqnarray*}
1524   \label{eq:3}
1525   \textit{real group id}      &=& \textrm{\acr{gid} (invariato)}  \\
1526   \textit{effective group id} &=& \textrm{\acr{utmp}} \\
1527   \textit{saved group id}     &=& \textrm{\acr{utmp} (invariato)}
1528 \end{eqnarray*}
1529 consentendo l'accesso a \file{/var/log/utmp}.
1530
1531 Occorre però tenere conto che tutto questo non è possibile con un processo con
1532 i privilegi di root, in tal caso infatti l'esecuzione una \func{setuid}
1533 comporta il cambiamento di tutti gli identificatori associati al processo,
1534 rendendo impossibile riguadagnare i privilegi di amministratore.  Questo
1535 comportamento è corretto per l'uso che ne fa \cmd{login} una volta che crea
1536 una nuova shell per l'utente; ma quando si vuole cambiare soltanto
1537 l'\textit{effective user id} del processo per cedere i privilegi occorre
1538 ricorrere ad altre funzioni (si veda ad esempio \secref{sec:proc_seteuid}).
1539
1540
1541 \subsection{Le funzioni \func{setreuid} e \func{setresuid}}
1542 \label{sec:proc_setreuid}
1543
1544 Queste due funzioni derivano da BSD che, non supportando\footnote{almeno fino
1545   alla versione 4.3+BSD TODO, FIXME verificare e aggiornare la nota.} i
1546 \textit{saved id}, le usava per poter scambiare fra di loro \textit{effective}
1547 e \textit{real id}. I loro prototipi sono:
1548 \begin{functions}
1549 \headdecl{unistd.h}
1550 \headdecl{sys/types.h}
1551
1552 \funcdecl{int setreuid(uid\_t ruid, uid\_t euid)} Setta il \textit{real user
1553   id} e l'\textit{effective user id} del processo corrente ai valori
1554 specificati da \var{ruid} e \var{euid}.
1555   
1556 \funcdecl{int setregid(gid\_t rgid, gid\_t egid)} Setta il \textit{real group
1557   id} e l'\textit{effective group id} del processo corrente ai valori
1558 specificati da \var{rgid} e \var{egid}.
1559
1560 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1561   di fallimento: l'unico errore possibile è \macro{EPERM}.}
1562 \end{functions}
1563
1564 I processi non privilegiati possono settare i \textit{real id} soltanto ai
1565 valori dei loro \textit{effective id} o \textit{real id} e gli
1566 \textit{effective id} ai valori dei loro \textit{real id}, \textit{effective
1567   id} o \textit{saved id}; valori diversi comportano il fallimento della
1568 chiamata; l'amministratore invece può specificare un valore qualunque.
1569 Specificando un valore di -1 l'identificatore corrispondente viene lasciato
1570 inalterato.
1571
1572 Con queste funzione si possono scambiare fra loro \textit{real id} e
1573 \textit{effective id}, e pertanto è possibile implementare un comportamento
1574 simile a quello visto in precedenza per \func{setgid}, cedendo i privilegi con
1575 un primo scambio, e recuperandoli, eseguito il lavoro non privilegiato, con un
1576 secondo scambio.
1577
1578 In questo caso però occorre porre molta attenzione quando si creano nuovi
1579 processi nella fase intermedia in cui si sono scambiati gli identificatori, in
1580 questo caso infatti essi avranno un \textit{real id} privilegiato, che dovrà
1581 essere esplicitamente eliminato prima di porre in esecuzione un nuovo
1582 programma (occorrerà cioè eseguire un'altra chiamata dopo la \func{fork}, e
1583 prima della \func{exec} per uniformare i \textit{real id} agli
1584 \textit{effective id}) in caso contrario quest'ultimo potrebbe a sua volta
1585 effettuare uno scambio e riottenere privilegi non previsti.
1586
1587 Lo stesso problema di propagazione dei privilegi ad eventuali processi figli
1588 si porrebbe per i \textit{saved id}: queste funzioni derivano da
1589 un'implementazione che non ne prevede la presenza, e quindi non è possibile
1590 usarle per correggere la situazione come nel caso precedente. Per questo
1591 motivo in Linux tutte le volte che vengono usate per modificare uno degli
1592 identificatori ad un valore diverso dal \textit{real id} precedente, il
1593 \textit{saved id} viene sempre settato al valore dell'\textit{effective id}.
1594
1595
1596
1597 \subsection{Le funzioni \func{seteuid} e \func{setegid}}
1598 \label{sec:proc_seteuid}
1599
1600 Queste funzioni sono un'estensione allo standard POSIX.1 (ma sono comunque
1601 supportate dalla maggior parte degli Unix) e usate per cambiare gli
1602 \textit{effective id}; i loro prototipi sono:
1603 \begin{functions}
1604 \headdecl{unistd.h}
1605 \headdecl{sys/types.h}
1606
1607 \funcdecl{int seteuid(uid\_t uid)} Setta l'\textit{effective user id} del
1608 processo corrente a \var{uid}.
1609
1610 \funcdecl{int setegid(gid\_t gid)} Setta l'\textit{effective group id} del
1611 processo corrente a \var{gid}.
1612
1613 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1614   di fallimento: l'unico errore possibile è \macro{EPERM}.}
1615 \end{functions}
1616
1617 Gli utenti normali possono settare l'\textit{effective id} solo al valore del
1618 \textit{real id} o del \textit{saved id}, l'amministratore può specificare
1619 qualunque valore. Queste funzioni sono usate per permettere a root di settare
1620 solo l'\textit{effective id}, dato che l'uso normale di \func{setuid} comporta
1621 il settaggio di tutti gli identificatori.
1622  
1623
1624 \subsection{Le funzioni \func{setresuid} e \func{setresgid}}
1625 \label{sec:proc_setresuid}
1626
1627 Queste due funzioni sono un'estensione introdotta in Linux dal kernel 2.1.44,
1628 e permettono un completo controllo su tutti gli identificatori (\textit{real},
1629 \textit{effective} e \textit{saved}), i prototipi sono:
1630 \begin{functions}
1631 \headdecl{unistd.h}
1632 \headdecl{sys/types.h}
1633
1634 \funcdecl{int setresuid(uid\_t ruid, uid\_t euid, uid\_t suid)} Setta il
1635 \textit{real user id}, l'\textit{effective user id} e il \textit{saved user
1636   id} del processo corrente ai valori specificati rispettivamente da
1637 \var{ruid}, \var{euid} e \var{suid}.
1638   
1639 \funcdecl{int setresgid(gid\_t rgid, gid\_t egid, gid\_t sgid)} Setta il
1640 \textit{real group id}, l'\textit{effective group id} e il \textit{saved group
1641   id} del processo corrente ai valori specificati rispettivamente da
1642 \var{rgid}, \var{egid} e \var{sgid}.
1643
1644 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1645   di fallimento: l'unico errore possibile è \macro{EPERM}.}
1646 \end{functions}
1647
1648 I processi non privilegiati possono cambiare uno qualunque degli
1649 identificatori usando uno qualunque dei valori correnti di \textit{real id},
1650 \textit{effective id} o \textit{saved id}, l'amministratore può specificare i
1651 valori che vuole; un valore di -1 per un qualunque parametro lascia inalterato
1652 l'identificatore corrispondente.
1653
1654 Per queste funzioni esistono anche due controparti che permettono di leggere
1655 in blocco i vari identificatori: \func{getresuid} e \func{getresgid}; i loro
1656 prototipi sono: 
1657 \begin{functions}
1658 \headdecl{unistd.h}
1659 \headdecl{sys/types.h}
1660
1661 \funcdecl{int getresuid(uid\_t *ruid, uid\_t *euid, uid\_t *suid)} Legge il
1662 \textit{real user id}, l'\textit{effective user id} e il \textit{saved user
1663   id} del processo corrente.
1664   
1665 \funcdecl{int getresgid(gid\_t *rgid, gid\_t *egid, gid\_t *sgid)} Legge il
1666 \textit{real group id}, l'\textit{effective group id} e il \textit{saved group
1667   id} del processo corrente.
1668
1669 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso di
1670   fallimento: l'unico errore possibile è \macro{EFAULT} se gli indirizzi delle
1671   variabili di ritorno non sono validi.}
1672 \end{functions}
1673
1674 Anche queste funzioni sono un'estensione specifica di Linux, e non richiedono
1675 nessun privilegio. I valori sono restituiti negli argomenti, che vanno
1676 specificati come puntatori (è un'altro esempio di \textit{value result
1677   argument}). Si noti che queste funzioni sono le uniche in grado di leggere i
1678 \textit{saved id}.
1679
1680
1681 \subsection{Le funzioni \func{setfsuid} e \func{setfsgid}}
1682 \label{sec:proc_setfsuid}
1683
1684 Queste funzioni sono usate per settare gli identificatori usati da Linux per
1685 il controllo dell'accesso ai file. Come già accennato in
1686 \secref{sec:proc_access_id} in Linux è definito questo ulteriore gruppo di
1687 identificatori, che di norma sono assolutamente equivalenti agli
1688 \textit{effective id}, dato che ogni cambiamento di questi ultimi viene
1689 immediatamente riportato sui \textit{filesystem id}.
1690
1691 C'è un solo caso in cui si ha necessità di introdurre una differenza fra
1692 \textit{effective id} e \textit{filesystem id}, ed è per ovviare ad un
1693 problema di sicurezza che si presenta quando si deve implementare un server
1694 NFS. Il server NFS infatti deve poter cambiare l'identificatore con cui accede
1695 ai file per assumere l'identità del singolo utente remoto, ma se questo viene
1696 fatto cambiando l'\textit{effective id} o il \textit{real id} il server si
1697 espone alla ricezione di eventuali segnali ostili da parte dell'utente di cui
1698 ha temporaneamente assunto l'identità.  Cambiando solo il \textit{filesystem
1699   id} si ottengono i privilegi necessari per accedere ai file, mantenendo
1700 quelli originari per quanto riguarda tutti gli altri controlli di accesso,
1701 così che l'utente non possa inviare segnali al server NFS.
1702
1703 Le due funzioni usate per cambiare questi identificatori sono \func{setfsuid}
1704 e \func{setfsgid}, ovviamente sono specifiche di Linux e non devono essere
1705 usate se si intendono scrivere programmi portabili; i loro prototipi sono:
1706 \begin{functions}
1707 \headdecl{sys/fsuid.h}
1708
1709 \funcdecl{int setfsuid(uid\_t fsuid)} Setta il \textit{filesystem user id} del
1710 processo corrente a \var{fsuid}.
1711
1712 \funcdecl{int setfsgid(gid\_t fsgid)} Setta l'\textit{filesystem group id} del
1713 processo corrente a \var{fsgid}.
1714
1715 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1716   di fallimento: l'unico errore possibile è \macro{EPERM}.}
1717 \end{functions}
1718 \noindent queste funzioni hanno successo solo se il processo chiamante ha i
1719 privilegi di amministratore o, per gli altri utenti, se il valore specificato
1720 coincide con uno dei \textit{real}, \textit{effective} o \textit{saved id}.
1721
1722
1723 \subsection{Le funzioni \func{setgroups} e \func{getgroups}}
1724 \label{sec:proc_setgroups}
1725
1726 Le ultime funzioni che esamineremo sono quelle che permettono di operare sui
1727 gruppi supplementari. Ogni processo può avere fino a \macro{NGROUPS\_MAX}
1728 gruppi supplementari in aggiunta al gruppo primario, questi vengono ereditati
1729 dal processo padre e possono essere cambiati con queste funzioni.
1730
1731 La funzione che permette di leggere i gruppi supplementari è \func{getgroups};
1732 questa funzione è definita nello standard POSIX ed il suo prototipo è:
1733 \begin{functions}
1734   \headdecl{sys/types.h}
1735   \headdecl{unistd.h}
1736   
1737   \funcdecl{int getgroups(int size, gid\_t list[])} Legge gli identificatori
1738   dei gruppi supplementari del processo sul vettore \param{list} di dimensione
1739   \param{size}.
1740   
1741   \bodydesc{La funzione restituisce il numero di gruppi letti in caso di
1742     successo e -1 in caso di fallimento, nel qual caso \var{errno} viene
1743     settata a: 
1744     \begin{errlist}
1745     \item[\macro{EFAULT}] \param{list} non ha un indirizzo valido.
1746     \item[\macro{EINVAL}] il valore di \param{size} è diverso da zero ma
1747       minore del numero di gruppi supplementari del processo.
1748     \end{errlist}}
1749 \end{functions}
1750 \noindent non è specificato se la funzione inserisca o meno nella lista
1751 l'\textit{effective user id} del processo. Se si specifica un valore di
1752 \param{size} uguale a 0 \param{list} non viene modificato, ma si ottiene il
1753 numero di gruppi supplementari.
1754
1755 Una seconda funzione, \func{getgrouplist}, può invece essere usata per
1756 ottenere tutti i gruppi a cui appartiene un utente; il suo prototipo è:
1757 \begin{functions}
1758   \headdecl{sys/types.h} 
1759   \headdecl{grp.h}
1760   
1761   \funcdecl{int getgrouplist(const char *user, gid\_t group, gid\_t *groups,
1762     int *ngroups)} Legge i gruppi supplementari dell'utente \param{user}.
1763   
1764   \bodydesc{La funzione legge fino ad un massimo di \param{ngroups} valori,
1765     restituisce 0 in caso di successo e -1 in caso di fallimento.}
1766 \end{functions}
1767 \noindent la funzione esegue una scansione del database dei gruppi (si veda
1768 \secref{sec:sys_user_group}) e ritorna in \param{groups} la lista di quelli a
1769 cui l'utente appartiene. Si noti che \param{ngroups} è passato come puntatore
1770 perché qualora il valore specificato sia troppo piccolo la funzione ritorna
1771 -1, passando indietro il numero dei gruppi trovati.
1772
1773 Per settare i gruppi supplementari di un processo ci sono due funzioni, che
1774 possono essere usate solo se si hanno i privilegi di amministratore. La prima
1775 delle due è \func{setgroups}, ed il suo prototipo è:
1776 \begin{functions}
1777   \headdecl{sys/types.h}
1778   \headdecl{grp.h}
1779   
1780   \funcdecl{int setgroups(size\_t size, gid\_t *list)} Setta i gruppi
1781   supplementari del processo ai valori specificati in \param{list}.
1782
1783   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1784     fallimento, nel qual caso \var{errno} viene settata a:
1785     \begin{errlist}
1786     \item[\macro{EFAULT}] \param{list} non ha un indirizzo valido.
1787     \item[\macro{EPERM}] il processo non ha i privilegi di amministratore.
1788     \item[\macro{EINVAL}] il valore di \param{size} è maggiore del valore
1789     massimo (\macro{NGROUPS}, che per Linux è 32).
1790     \end{errlist}}
1791 \end{functions}
1792
1793 Se invece si vogliono settare i gruppi supplementari del processo a quelli di
1794 un utente specifico, si può usare \func{initgroups} il cui prototipo è:
1795 \begin{functions}
1796   \headdecl{sys/types.h}
1797   \headdecl{grp.h}
1798
1799   \funcdecl{int initgroups(const char *user, gid\_t group)} Setta i gruppi
1800   supplementari del processo a quelli di cui è membro l'utente \param{user},
1801   aggiungendo il gruppo addizionale \param{group}.
1802   
1803   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1804     fallimento, nel qual caso \var{errno} viene settata agli stessi valori di
1805     \func{setgroups} più \macro{ENOMEM} quando non c'è memoria sufficiente per
1806     allocare lo spazio per informazioni dei gruppi.}
1807 \end{functions}
1808
1809 La funzione esegue la scansione del database dei gruppi (usualmente
1810 \file{/etc/groups}) cercando i gruppi di cui è membro \param{user} e
1811 costruendo una lista di gruppi supplementari a cui aggiunge \param{group}, che
1812 poi setta usando \func{setgroups}.
1813
1814 Si tenga presente che sia \func{setgroups} che \func{initgroups} non sono
1815 definite nello standard POSIX.1 e che pertanto non è possibile utilizzarle
1816 quando si definisce \macro{\_POSIX\_SOURCE} o si compila con il flag
1817 \cmd{-ansi}.
1818
1819
1820 \section{La gestione della priorità di esecuzione}
1821 \label{sec:proc_priority}
1822
1823 In questa sezione tratteremo più approfonditamente i meccanismi con il quale
1824 lo \textit{scheduler}\footnote{che è la parte del kernel che si occupa di
1825   stabilire quale processo dovrà essere posto in esecuzione.} assegna la CPU
1826 ai vari processi attivi. In particolare prenderemo in esame i vari meccanismi
1827 con cui viene gestita l'assegnazione del tempo di CPU, ed illustreremo le
1828 varie funzioni di gestione.
1829
1830
1831 \subsection{I meccanismi di \textit{scheduling}}
1832 \label{sec:proc_sched}
1833
1834 La scelta di un meccanismo che sia in grado di distribuire in maniera efficace
1835 il tempo di CPU per l'esecuzione dei processi è sempre una questione delicata,
1836 ed oggetto di numerose ricerche; in ogni caso essa dipende in maniera
1837 essenziale anche dal tipo di utilizzo che deve essere fatto del sistema.
1838
1839 La cosa è resa ancora più complicata dal fatto che con le architetture
1840 multi-processore si introduce anche la problematica dovuta alla scelta di
1841 quale sia la CPU più opportuna da utilizzare.\footnote{nei processori moderni
1842   la presenza di ampie cache può rendere poco efficiente trasferire
1843   l'esecuzione di un processo da una CPU ad un'altra, per cui occorrono
1844   meccanismi per determinare quale è la migliore scelta fra le diverse CPU.}
1845 Tutto questo comunque appartiene alle sottigliezze dell'implementazione del
1846 kernel, e dal punto di vista dei programmi che girano in user space, anche
1847 quando si hanno più processori (e dei processi che sono eseguiti davvero in
1848 contemporanea), si può pensare alle politiche di scheduling come concernenti
1849 la risorsa \textsl{tempo di esecuzione}, la cui assegnazione sarà governata
1850 dagli stessi meccanismi di scelta di priorità, solo che nel caso di più
1851 processori sarà a disposizione di più di un processo alla volta.
1852
1853 Si tenga presente inoltre che l'utilizzo della CPU è soltanto una delle
1854 risorse (insieme alla memoria e all'accesso alle periferiche) che sono
1855 necessarie per l'esecuzione di un programma, e spesso non è neanche la più
1856 importante. Per questo non è affatto detto che dare ad un programma la massima
1857 priorità di esecuzione abbia risultati significativi in termini di
1858 prestazioni.
1859
1860 Il meccanismo tradizionale di scheduling di Unix (che tratteremo in
1861 \secref{sec:proc_sched_stand}) è sempre stato basato su delle \textsl{priorità
1862   dinamiche}, in modo da assicurare che tutti i processi, anche i meno
1863 importanti, possano ricevere un po' di tempo di CPU. In sostanza quando un
1864 processo ottiene la CPU la sua priorità viene diminuita. In questo modo alla
1865 fine, anche un processo con priorità iniziale molto bassa, finisce per avere
1866 una priorità sufficiente per essere eseguito.
1867
1868 Lo standard POSIX.1b però ha introdotto il concetto di \textsl{priorità
1869   assoluta}, (chiamata anche \textsl{priorità statica}, in contrapposizione
1870 alla normale priorità dinamica), per tenere conto dei sistemi
1871 real-time,\footnote{per sistema real-time si intende un sistema in grado di
1872   eseguire operazioni in tempo reale; in genere si tende a distinguere fra
1873   l'\textit{hard real-time} in cui è necessario che i tempi di esecuzione di
1874   un programma siano determinabili con certezza assoluta, come nel caso di
1875   meccanismi di controllo di macchine, dove uno sforamento dei tempi avrebbe
1876   conseguenze disastrose, e \textit{soft-real-time} in cui un occasionale
1877   sforamento è ritenuto accettabile.} in cui è vitale che i processi che
1878 devono essere eseguiti in un determinato momento non debbano aspettare la
1879 conclusione di altri che non hanno questa necessità.
1880
1881 Il concetto di priorità assoluta dice che quando due processi si contendono
1882 l'esecuzione, vince sempre quello con la priorità assoluta più alta, anche
1883 quando l'altro è in esecuzione (grazie al \textit{prehemptive scheduling}).
1884 Ovviamente questo avviene solo per i processi che sono pronti per essere
1885 eseguiti (cioè nello stato \textit{runnable},\footnote{lo stato di un processo
1886   è riportato nel campo \texttt{STAT} dell'output del comando \cmd{ps},
1887   abbiamo già visto che lo stato di \textit{zombie} è indicato con \texttt{Z},
1888   gli stati \textit{runnable}, \textit{sleep} e di I/O (\textit{uninteruttible
1889     sleep}) sono invece indicati con \texttt{R}, \texttt{S} e \texttt{D}.})
1890 la priorità assoluta viene invece ignorata per quelli che sono bloccati su una
1891 richiesta di I/O o in stato di \textit{sleep}.  La priorità assoluta viene in
1892 genere indicata con un numero intero, ed un valore più alto comporta una
1893 priorità maggiore, su questa politica di scheduling torneremo in
1894 \secref{sec:proc_real_time}.  
1895
1896 In generale quello che succede in tutti gli Unix moderni è che ai processi
1897 normali viene sempre data una priorità assoluta pari a zero, e la decisione di
1898 assegnazione della CPU è fatta solo in base ad una priorità dinamica che è
1899 calcolata indipendentemente. È tuttavia possibile assegnare anche una priorità
1900 assoluta nel qual caso un processo avrà la precedenza su tutti gli altri di
1901 priorità inferiore che saranno eseguiti solo quando quest'ultimo non avrà
1902 bisogno della CPU.
1903
1904
1905 \subsection{Il meccanismo di \textit{scheduling} standard}
1906 \label{sec:proc_sched_stand}
1907
1908 A meno che non si abbiano specifiche esigenze, l'unico meccanismo di
1909 scheduling con il quale si avrà a che fare è quello tradizionale che prevede
1910 solo priorità dinamiche, ed è di questo che di norma ci si dovrà preoccupare
1911 nella programmazione.
1912
1913 Come accennato in Linux tutti i processi ordinari hanno la stessa priorità
1914 assoluta. Quello che determina quale, fra tutti i processi in attesa di
1915 esecuzione, sarà eseguito per primo, è la priorità dinamica, che è chiamata
1916 così proprio perché viene varia nel corso dell'esecuzione di un processo.
1917
1918
1919
1920
1921 \subsection{Il meccanismo di \textit{scheduling real-time}}
1922 \label{sec:proc_real_time}
1923
1924 Per settare le 
1925
1926
1927 \footnote{a meno che non si siano installate le patch di RTLinux o RTAI, con i
1928   quali è possibile ottenere un sistema effettivamente hard real-time.}
1929
1930 in realtà non si tratta di un vero hard real-time, in quanto
1931   la presenza di eventuali interrupt o di page fault può sempre interrompere
1932   l'esecuzione di un processo, a meno di non installare le estensioni di
1933   RTLinux o RTAI, il normale kernel non è real-time.
1934
1935
1936
1937
1938
1939 \section{Problematiche di programmazione multitasking}
1940 \label{sec:proc_multi_prog}
1941
1942 Benché i processi siano strutturati in modo da apparire il più possibile come
1943 indipendenti l'uno dall'altro, nella programmazione in un sistema multitasking
1944 occorre tenere conto di una serie di problematiche che normalmente non
1945 esistono quando si ha a che fare con un sistema in cui viene eseguito un solo
1946 programma alla volta.
1947
1948 Pur essendo questo argomento di carattere generale, ci è parso opportuno
1949 introdurre sinteticamente queste problematiche, che ritroveremo a più riprese
1950 in capitoli successivi, in questa sezione conclusiva del capitolo in cui
1951 abbiamo affrontato la gestione dei processi.
1952
1953
1954 \subsection{Le operazioni atomiche}
1955 \label{sec:proc_atom_oper}
1956
1957 La nozione di \textsl{operazione atomica} deriva dal significato greco della
1958 parola atomo, cioè indivisibile; si dice infatti che un'operazione è atomica
1959 quando si ha la certezza che, qualora essa venga effettuata, tutti i passaggi
1960 che devono essere compiuti per realizzarla verranno eseguiti senza possibilità
1961 di interruzione in una fase intermedia.
1962
1963 In un ambiente multitasking il concetto è essenziale, dato che un processo può
1964 essere interrotto in qualunque momento dal kernel che mette in esecuzione un
1965 altro processo o dalla ricezione di un segnale; occorre pertanto essere
1966 accorti nei confronti delle possibili \textit{race condition} (vedi
1967 \secref{sec:proc_race_cond}) derivanti da operazioni interrotte in una fase in
1968 cui non erano ancora state completate.
1969
1970 Nel caso dell'interazione fra processi la situazione è molto più semplice, ed
1971 occorre preoccuparsi della atomicità delle operazioni solo quando si ha a che
1972 fare con meccanismi di intercomunicazione (che esamineremo in dettaglio in
1973 \capref{cha:IPC}) o nelle operazioni con i file (vedremo alcuni esempi in
1974 \secref{sec:file_atomic}). In questi casi in genere l'uso delle appropriate
1975 funzioni di libreria per compiere le operazioni necessarie è garanzia
1976 sufficiente di atomicità in quanto le system call con cui esse sono realizzate
1977 non possono essere interrotte (o subire interferenze pericolose) da altri
1978 processi.
1979
1980 Nel caso dei segnali invece la situazione è molto più delicata, in quanto lo
1981 stesso processo, e pure alcune system call, possono essere interrotti in
1982 qualunque momento, e le operazioni di un eventuale \textit{signal handler}
1983 sono compiute nello stesso spazio di indirizzi del processo. Per questo, anche
1984 il solo accesso o l'assegnazione di una variabile possono non essere più
1985 operazioni atomiche (torneremo su questi aspetti in \secref{sec:sign_xxx}).
1986
1987 In questo caso il sistema provvede un tipo di dato, il \type{sig\_atomic\_t},
1988 il cui accesso è assicurato essere atomico.  In pratica comunque si può
1989 assumere che, in ogni piattaforma su cui è implementato Linux, il tipo
1990 \type{int}, gli altri interi di dimensione inferiore ed i puntatori sono
1991 atomici. Non è affatto detto che lo stesso valga per interi di dimensioni
1992 maggiori (in cui l'accesso può comportare più istruzioni in assembler) o per
1993 le strutture. In tutti questi casi è anche opportuno marcare come
1994 \type{volatile} le variabili che possono essere interessate ad accesso
1995 condiviso, onde evitare problemi con le ottimizzazioni del codice.
1996
1997
1998 \subsection{Le \textit{race condition} e i \textit{deadlock}}
1999 \label{sec:proc_race_cond}
2000
2001 Si definiscono \textit{race condition} tutte quelle situazioni in cui processi
2002 diversi operano su una risorsa comune, ed in cui il risultato viene a
2003 dipendere dall'ordine in cui essi effettuano le loro operazioni. Il caso
2004 tipico è quello di un'operazione che viene eseguita da un processo in più
2005 passi, e può essere compromessa dall'intervento di un altro processo che
2006 accede alla stessa risorsa quando ancora non tutti i passi sono stati
2007 completati.
2008
2009 Dato che in un sistema multitasking ogni processo può essere interrotto in
2010 qualunque momento per farne subentrare un'altro in esecuzione, niente può
2011 assicurare un preciso ordine di esecuzione fra processi diversi o che una
2012 sezione di un programma possa essere eseguita senza interruzioni da parte di
2013 altri. Queste situazioni comportano pertanto errori estremamente subdoli e
2014 difficili da tracciare, in quanto nella maggior parte dei casi tutto
2015 funzionerà regolarmente, e solo occasionalmente si avranno degli errori. 
2016
2017 Per questo occorre essere ben consapevoli di queste problematiche, e del fatto
2018 che l'unico modo per evitarle è quello di riconoscerle come tali e prendere
2019 gli adeguati provvedimenti per far si che non si verifichino. Casi tipici di
2020 \textit{race condition} si hanno quando diversi processi accedono allo stesso
2021 file, o nell'accesso a meccanismi di intercomunicazione come la memoria
2022 condivisa. In questi casi, se non si dispone della possibilità di eseguire
2023 atomicamente le operazioni necessarie, occorre che quelle parti di codice in
2024 cui si compiono le operazioni sulle risorse condivise (le cosiddette
2025 \textsl{sezioni critiche}) del programma, siano opportunamente protette da
2026 meccanismi di sincronizzazione (torneremo su queste problematiche di questo
2027 tipo in \secref{sec:ipc_semaph}).
2028
2029 Un caso particolare di \textit{race condition} sono poi i cosiddetti
2030 \textit{deadlock}, particolarmente gravi in quanto comportano spesso il blocco
2031 completo di un servizio, e non il fallimento di una singola operazione.
2032 L'esempio tipico di una situazione che può condurre ad un \textit{deadlock} è
2033 quello in cui un flag di ``occupazione'' viene rilasciato da un evento
2034 asincrono (come un segnale o un altro processo) fra il momento in cui lo si è
2035 controllato (trovandolo occupato) e la successiva operazione di attesa per lo
2036 sblocco. In questo caso, dato che l'evento di sblocco del flag è avvenuto
2037 senza che ce ne accorgessimo proprio fra il controllo e la messa in attesa,
2038 quest'ultima diventerà perpetua (da cui il nome di \textit{deadlock}).
2039
2040 In tutti questi casi è di fondamentale importanza il concetto di atomicità
2041 visto in \secref{sec:proc_atom_oper}; questi problemi infatti possono essere
2042 risolti soltanto assicurandosi, quando essa sia richiesta, che sia possibile
2043 eseguire in maniera atomica le operazioni necessarie.
2044
2045
2046 \subsection{Le funzioni rientranti}
2047 \label{sec:proc_reentrant}
2048
2049 Si dice \textsl{rientrante} una funzione che può essere interrotta in
2050 qualunque punto della sua esecuzione ed essere chiamata una seconda volta da
2051 un altro thread di esecuzione senza che questo comporti nessun problema
2052 nell'esecuzione della stessa. La problematica è comune nella programmazione
2053 multi-thread, ma si hanno gli stessi problemi quando si vogliono chiamare
2054 delle funzioni all'interno dei manipolatori dei segnali.
2055
2056 Fintanto che una funzione opera soltanto con le variabili locali è rientrante;
2057 queste infatti vengono allocate nello stack, e un'altra invocazione non fa
2058 altro che allocarne un'altra copia. Una funzione può non essere rientrante
2059 quando opera su memoria che non è nello stack.  Ad esempio una funzione non è
2060 mai rientrante se usa una variabile globale o statica.
2061
2062 Nel caso invece la funzione operi su un oggetto allocato dinamicamente, la
2063 cosa viene a dipendere da come avvengono le operazioni: se l'oggetto è creato
2064 ogni volta e ritornato indietro la funzione può essere rientrante, se invece
2065 esso viene individuato dalla funzione stessa, due chiamate alla stessa
2066 funzione potranno interferire quando entrambe faranno riferimento allo stesso
2067 oggetto.  Allo stesso modo una funzione può non essere rientrante se usa e
2068 modifica un oggetto che le viene fornito dal chiamante: due chiamate possono
2069 interferire se viene passato lo stesso oggetto; in tutti questi casi occorre
2070 molta cura da parte del programmatore.
2071
2072 In genere le funzioni di libreria non sono rientranti, molte di esse ad
2073 esempio utilizzano variabili statiche, le \acr{glibc} però mettono a
2074 disposizione due macro di compilatore, \macro{\_REENTRANT} e
2075 \macro{\_THREAD\_SAFE}, la cui definizione attiva le versioni rientranti di
2076 varie funzioni di libreria, che sono identificate aggiungendo il suffisso
2077 \code{\_r} al nome della versione normale.
2078
2079
2080
2081 %%% Local Variables: 
2082 %%% mode: latex
2083 %%% TeX-master: "gapil"
2084 %%% End: