Aggiunte su fork
[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 ogni attività del sistema
5 viene svolta tramite i processi.  In sostanza i processi costituiscono l'unità
6 base per l'allocazione e l'uso delle risorse del sistema.
7
8 Nel precedente capitolo abbiamo visto come funziona un singolo processo, in
9 questo capitolo affronteremo i dettagli della creazione e della distruzione
10 dei processi, della gestione dei loro attributi e privilegi, e di tutte le
11 funzioni a questo connesse.
12
13
14 \section{Introduzione}
15 \label{sec:proc_gen}
16
17 Partiremo con una introduzione generale ai concetti che stanno alla base della
18 gestione dei processi in unix. Introdurremo in questa sezione l'architettura
19 della gestione dei processi e le sue principali caratteristiche, e daremo una
20 panoramica sull'uso delle principali funzioni per la gestione dei processi.
21
22 \subsection{La gerarchia dei processi}
23 \label{sec:proc_hierarchy}
24
25 A differenza di quanto avviene in altri sistemi (ad esempio nel VMS la
26 generazione di nuovi processi è un'operazione privilegiata) una delle
27 caratteristiche di unix (che esamineremo in dettaglio più avanti) è che
28 qualunque processo può a sua volta generarne altri, detti processi figli
29 (\textit{child process}). Ogni processo è identificato presso il sistema da un
30 numero unico, il \acr{pid} (da \textit{process identifier}).
31
32 Una seconda caratteristica è che la generazione di un processo è una
33 operazione separata rispetto al lancio di un programma. In genere la sequenza
34 è sempre quella di creare un nuovo processo, il quale si eseguirà, in un passo
35 successivo, il programma voluto: questo è ad esempio quello che fa la shell
36 quando mette in esecuzione il programma che gli indichiamo nella linea di
37 comando.
38
39 Una terza caratteristica è che ogni processo viene sempre generato da un altro
40 che viene chiamato processo genitore (\textit{parent process}). Questo vale
41 per tutti i processi, con una eccezione (dato che ci deve essere un punto di
42 partenza), esiste sempre infatti un processo speciale, che normalmente è
43 \cmd{/sbin/init}, che viene lanciato dal kernel quando questo ha finito la
44 fase di avvio, esso essendo il primo processo lanciato ha sempre il \acr{pid}
45 uguale a 1 e non è figlio di nessuno.
46
47 Questo è ovviamente un processo speciale, che in genere si occupa di far
48 partire tutti gli processi altri necessari al funzionamento del sistema,
49 inoltre \cmd{init} è essenziale per svolgere una serie di compiti
50 amministrativi nelle operazioni ordinarie del sistema (torneremo si alcuni di
51 essi in \secref{}) e non può mai essere terminato. La struttura del sistema
52 comunque consente di lanciare al posto di \cmd{init} qualunque altro programma
53 (e in casi di emergenza, ad esempio se il file di \cmd{init} si fosse
54 corrotto, è possibile farlo ad esempio passando la riga \cmd{init=/bin/sh}
55 all'avvio).
56
57 Dato che tutti i processi successivi sono comunque generati da \cmd{init} o da
58 suoi figli tutto ciò comporta che, i processi sono organizzati gerarchicamente
59 dalla relazione fra genitori e figli, in maniera analoga a come i file sono
60 organizzati in un albero di directory con alla base \file{/} (si veda
61 \secref{sec:file_file_struct}); in questo caso alla base dell'albero c'è il
62 processo \cmd{init} che è progenitore di ogni altro processo\footnote{in
63   realtà questo non è del tutto vero, in Linux ci sono alcuni processi che pur
64   comparendo come figli di init (ad esempio in \cmd{pstree}) sono generati
65   direttamente dal kernel, come \cmd{keventd}, \cmd{kswapd}, etc.}.
66
67
68 \subsection{Una panoramica sulle funzioni di gestione}
69 \label{sec:proc_handling_intro}
70
71 I processi vengono creati dalla funzione \func{fork}; in molti unix questa è
72 una system call, Linux però usa un'altra nomenclatura, e la funzione fork è
73 basata a sua volta sulla system call \func{\_\_clone}, che viene usata anche
74 per generare i \textit{thread}.  Il processo figlio creato dalla \func{fork} è
75 una copia identica del processo processo padre, ma ha nuovo \acr{pid} e viene
76 eseguito in maniera indipendente (le differenze fra padre e figlio sono
77 affrontate in dettaglio in \secref{sec:proc_fork}).
78
79 Se si vuole che il processo padre si fermi fino alla conclusione del processo
80 figlio questo deve essere specificato subito dopo la \func{fork} chiamando la
81 funzione \func{wait} o la funzione \func{waitpid}; queste funzioni
82 restituiscono anche una informazione abbastanza limitata (il codice di uscita)
83 sulle cause della terminazione del processo.
84
85 Quando un processo ha concluso il suo compito o ha incontrato un errore non
86 risolvibile esso può essere terminato con la funzione \func{exit} (si veda
87 quanto discusso in \secref{sec:proc_termination}). La vita del processo però
88 termina solo quando la notifica della sua conclusione viene ricevuta dal
89 processo padre, a quel punto tutte le risorse allocate nel sistema ad esso
90 associate vengono rilasciate.
91
92 Avere due processi che eseguono esattamente lo stesso codice non è molto
93 utile, normalmente si genera un secondo processo per affidargli l'esecuzione
94 di un compito specifico (ad esempio gestire una connessione dopo che questa è
95 stata stabilita), o fargli eseguire (come fa la shell) un altro programma. Per
96 quest'ultimo caso si usa la seconda funzione fondamentale per programmazione
97 coi processi che è la \func{exec}.
98
99 Il programma che un processo sta eseguendo si chiama immagine del processo (o
100 \textit{process image}), le funzioni della famiglia \func{exec} permettono di
101 caricare un'altro programma da disco sostituendo quest'ultimo all'immagine
102 corrente; questo fa si che l'immagine precedente venga completamente
103 cancellata. Questo significa che quando il nuovo programma esce anche il
104 processo termina, e non si può tornare alla precedente immagine.
105
106 Per questo motivo la \func{fork} e la \func{exec} sono funzioni molto
107 particolari con caratteristiche uniche rispetto a tutte le altre, infatti la
108 prima ritorna due volte (nel processo padre e nel figlio) mentre la seconda
109 non ritorna mai (in quanto con essa viene eseguito un altro programma).
110
111
112
113 \section{La gestione dei processi}
114 \label{sec:proc_handling}
115
116 In questa sezione tratteremo le funzioni per la gestione dei processi, a
117 partire dalle funzioni elementari che permettono di leggerne gli
118 identificatori, alle varie funzioni di manipolazione dei processi, che
119 riguardano la lore creazione, terminazione, e la messa in esecuzione di altri
120 programmi.
121
122
123 \subsection{Gli identificatori dei processi}
124 \label{sec:proc_pid}
125
126 Come accennato nell'introduzione ogni processo viene identificato dal sistema
127 da un numero identificativo unico, il \textit{process id} o \acr{pid};
128 quest'ultimo è un tipo di dato standard, il \type{pid\_t} che in genere è un
129 intero con segno (nel caso di Linux e delle glibc il tipo usato è \type{int}).
130
131 Il \acr{pid} viene assegnato in forma progressiva ogni volta che un nuovo
132 processo viene creato, fino ad un limite massimo (in genere essendo detto
133 numero memorizzato in un intero a 16 bit si arriva a 32767) oltre il quale si
134 riparte dal numero più basso disponibile (FIXME: verificare, non sono sicuro).
135 Per questo motivo processo il processo di avvio (\cmd{init}) ha sempre il
136 \acr{pid} uguale a uno. 
137
138 Tutti i processi inoltre memorizzano anche il \acr{pid} del genitore da cui
139 sono stati creati, questo viene chiamato in genere \acr{ppid} (da
140 \textit{parent process id}) ed è normalmente utilizzato per il controllo di
141 sessione.  Questi due identificativi possono essere ottenuti da programma
142 usando le funzioni:
143 \begin{functions}
144 \headdecl{sys/types.h}
145 \headdecl{unistd.h}
146 \funcdecl{pid\_t getpid(void)} restituisce il pid del processo corrente.
147 \funcdecl{pid\_t getppid(void)} restituisce il pid del padre del processo
148     corrente.
149
150 Entrambe le funzioni non riportano condizioni di errore. 
151 \end{functions}
152
153 Il fatto che il \acr{pid} sia un numero univoco per il sistema lo rende il
154 candidato ideale per generare ultieriori indicatori associati al processo di
155 cui diventa possibile garantire l'unicità: ad esempio la funzione
156 \func{tmpname} (si veda \secref{sec:file_temp_file}) usa il \acr{pid} per
157 generare un pathname univoco, che non potrà essere replicato da un'altro
158 processo che usi la stessa funzione. 
159
160 Tutti i processi figli dello stesso processo padre sono detti
161 \textit{sibling}, questa è un'altra delle relazioni usate nel controllo di
162 sessione, in cui si raggruppano tutti i processi creati su uno stesso
163 terminale una volta che si è effettuato il login. Torneremo su questo
164 argomento in \secref{cap:terminal}, dove esamineremo tutti gli altri
165 identificativi associati ad un processo relativi al controllo di sessione.
166
167
168 \subsection{La funzione \func{fork}}
169 \label{sec:proc_fork}
170
171 La funzione \func{fork} è la funzione fondamentale della gestione dei processi
172 in unix; come si è detto l'unico modo di creare un nuovo processo è attraverso
173 l'uso di questa funzione, che è quindi la base per il multitasking; il protipo
174 della funzione è:
175
176 \begin{functions}
177   \headdecl{sys/types.h} 
178   \headdecl{unistd.h} 
179   
180   \funcdecl{pid\_t fork(void)} 
181   
182   Restituisce zero al padre e il \acr{pid} al figlio in caso di successo,
183   ritorna -1 al padre (senza creare il figlio) in caso di errore;
184   \texttt{errno} può assumere i valori:
185   \begin{errlist}
186   \item \macro{EAGAIN} non ci sono risorse sufficienti per creare un'altro
187     processo (per allocare la tabella delle pagine e le strutture del task) o
188     si è esaurito il numero di processi disponibili.
189   \item \macro{ENOMEM} non è stato possibile allocare la memoria per le
190     strutture necessarie al kernel per creare il nuovo processo.
191   \end{errlist}
192 \end{functions}
193
194 Dopo l'esecuzione di una \func{fork} sia il processo padre che il processo
195 figlio continuano ad essere eseguiti normalmente alla istruzione seguente la
196 \func{fork}; il processo figlio è però una copia del padre, e riceve una copia
197 dei segmenti di testo, stack e dati (vedi \secref{sec:proc_mem_layout}), ed
198 esegue esattamente lo stesso codice del padre, ma la memoria è copiata, non
199 condivisa\footnote{In generale il segmento di testo, che è identico, è
200   condiviso e tenuto in read-only, linux poi utilizza la tecnica del
201   \textit{copy-on-write}, per cui la memoria degli altri segmenti viene
202   copiata dal kernel per il nuovo processo solo in caso di scrittura, rendendo
203   molto più efficiente il meccanismo} pertanto padre e figlio vedono variabili
204 diverse.
205
206 La differenza che si ha nei due processi è che nel processo padre il valore di
207 ritorno della funzione fork è il \acr{pid} del processo figlio, mentre nel
208 figlio è zero; in questo modo il programma può identificare se viene eseguito
209 dal padre o dal figlio.
210
211 Si noti come la funzione, caso unico che ne contraddistingue l'importanza,
212 ritorni \textbf{due} volte. Nel caso del padre viene restituito il \acr{pid}
213 del figlio in quanto potendo esservi più figli questo è il modo per poterne
214 tracciare la creazione, il figlio invece ha un unico padre (il cui \acr{pid}
215 può essere ottenuto con \func{getppid}, vista in \secref{sec:proc_pid}) e si
216 usa il valore nullo (che non può essere il \acr{pid} di nessun processo)
217
218
219
220 \subsection{Le funzioni \texttt{wait} e  \texttt{waitpid}}
221 \label{sec:proc_wait}
222
223
224 \subsection{Le funzioni \texttt{exec}}
225 \label{sec:proc_exec}
226
227
228
229
230 \section{Il controllo di accesso}
231 \label{sec:proc_perms}
232
233 In questa sezione esamineremo le problematiche relative al controllo di
234 accesso dal punto di vista del processi; gli identificativi usati, come questi
235 vengono modificati nella creazione e nel lancio di nuovi processi, e le varie
236 funzioni per la loro manipolazione diretta.
237
238
239 \subsection{Utente e gruppo di un processo}
240 \label{sec:proc_user_group}
241
242 Abbiamo già accennato in \secref{sec:intro_multiuser} ad ogni utente ed gruppo
243 sono associati due identificatori univoci, lo \acr{uid} e il \acr{gid} che li
244 contraddistinguono nei confonti del kernel. Questi identificatori stanno alla
245 base del sistema di permessi e protezioni di un sistema unix, e vengono usati
246 anche nella gestione dei privilegi di accesso dei processi.
247
248 In realtà ad ogni processo è associato un certo numero di identificatori, il
249 cui elenco è riportato \ntab, in genere questi derivano direttamente
250 dall'utente che ha lanciato il processo (attraverso i valori di \acr{uid} e
251 \acr{gid}), e vengono usati sia per il controllo di accesso ai file che per la
252 gestione dei privilegi associati ai processi stessi.
253 \begin{table}[htb]
254   \centering
255   \begin{tabular}[c]{|c|l|l|}
256     \hline
257     Sigla & Significato & Utilizzo \\ 
258     \hline
259     \hline
260     \acr{ruid} & \textit{real user id} & indica l'utente reale che ha lanciato
261     il programma\\ 
262     \acr{rgid} & \textit{real group id} & indica il gruppo reale dell'utente 
263     che ha lanciato il programma \\ 
264     \acr{euid} & \textit{effective user id} & indica l'utente effettivo usato
265     dal programma \\ 
266     \acr{egid} & \textit{effective group id} & indica il gruppo effettivo usato
267     dal programma \\ 
268                & \textit{supplementary group id} & indica i gruppi cui
269     l'utente appartiene  \\ 
270     \acr{suid} & \textit{saved user id} & indica l'utente  \\ 
271     \acr{sgid} & \textit{daved group id} & indica il gruppo  \\ 
272     \acr{fsuid} & \textit{filesystem user id} & indica l'utente effettivo per
273     il filesystem \\ 
274     \acr{fsgid} & \textit{filesystem group id} & indica il gruppo effettivo
275     per il filesystem  \\ 
276     \hline
277   \end{tabular}
278   \caption{Identificatori di utente e gruppo associati a ciascun processo.}
279   \label{tab:proc_uid_gid}
280 \end{table}
281
282 Il \textit{real user id} e il \textit{real group id} indicano l'utente che ha
283 lanciato il processo, e vengono settati al login al valore standard di
284 \acr{uid} e \acr{gid} dell'utente letti direttamente da \file{/etc/passwd}.
285 Questi non vengono mai cambiati nella creazione di nuovi processi e restano
286 sempre gli stessi per tutti i processi avviati in una sessione. In realtà è
287 possibile modificarli (vedi \secref{sec:proc_setuid}), ma solo per un processo
288 che abbia i privilegi di amministratore (ed è così infatti che \cmd{login},
289 che gira con i privilegi di amministratore, li setta ai valori corrispondenti
290 all'utente che entra nel sistema).
291
292 L'\textit{effective user id}, l'\textit{effective group id} e gli eventuali
293 \textit{supplementary group id} sono gli identificativi usati per il controllo
294 di accesso ai file secondo quanto descritto in dettaglio in
295 \secref{sec:file_perm_overview}. Normalmente sono uguali al \textit{real user
296   id} e al \textit{real group id}, a meno che il file posto in esecuzione non
297 abbia i bit \acr{suid} o \acr{sgid} settati, nel qual caso vengono settati
298 rispettivamente all'\acr{uid} e \acr{gid} del file.
299
300 Il \textit{saved user id} e il \textit{saved group id} sono copie
301 dell'\textit{effective user id} e dell'\textit{effective group id} del
302 processo padre, e vengono settati all'avvio del processo, prima che
303 \textit{effective user id} e \textit{effective group id} vengano modificati
304 per tener conto di eventuali \acr{suid} o \acr{sgid}.
305
306
307 \subsection{Le funzioni \texttt{setuid} e \texttt{setgid}}
308 \label{sec:proc_setuid}
309
310
311 \subsection{Le funzioni \texttt{seteuid} e \texttt{setegid}}
312 \label{sec:proc_seteuid}
313