X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=prochand.tex;h=70d7eb1d2e90ce7d0fd54c5b4f30b6eb6efb4483;hp=2fdd12f5fb7e2fa04a9b95e6b73b8c912ffc1a29;hb=4512628d19409474a37c29e82947f74e9a4ac80b;hpb=98d6e43e041f167c17010ca37eeb1b44f8474f8b diff --git a/prochand.tex b/prochand.tex index 2fdd12f..70d7eb1 100644 --- a/prochand.tex +++ b/prochand.tex @@ -1,64 +1,70 @@ \chapter{La gestione dei processi} \label{cha:process_handling} -Come accennato nell'introduzione in un sistema unix ogni attività del sistema +Come accennato nell'introduzione in un sistema Unix ogni attività del sistema viene svolta tramite i processi. In sostanza i processi costituiscono l'unità base per l'allocazione e l'uso delle risorse del sistema. -Nel precedente capitolo abbiamo visto come funziona un singolo processo, in -questo capitolo affronteremo i dettagli della creazione e della distruzione -dei processi, della gestione dei loro attributi e privilegi, e di tutte le -funzioni a questo connesse. +Nel precedente capitolo abbiamo esaminato il funzionamento di un processo come +unità a se stante, in questo esamineremo il funzionamento dei processi +all'interno del sistema. Saranno cioè affrontati i dettagli della creazione e +della distruzione dei processi, della gestione dei loro attributi e privilegi, +e di tutte le funzioni a questo connesse. Infine nella sezione finale +affronteremo alcune problematiche generiche della programmazione in ambiente +multitasking. + \section{Introduzione} \label{sec:proc_gen} -Partiremo con una introduzione generale ai concetti che stanno alla base della -gestione dei processi in unix. Introdurremo in questa sezione l'architettura -della gestione dei processi e le sue principali caratteristiche, e daremo una -panoramica sull'uso delle principali funzioni per la gestione dei processi. +Inizieremo con una introduzione generale ai concetti che stanno alla base +della gestione dei processi in un sistema unix-like. Introdurremo in questa +sezione l'architettura della gestione dei processi e le sue principali +caratteristiche, dando una panoramica sull'uso delle principali funzioni di +gestione. + -\subsection{La gerarchia dei processi} +\subsection{L'architettura della gestione dei processi} \label{sec:proc_hierarchy} A differenza di quanto avviene in altri sistemi (ad esempio nel VMS la generazione di nuovi processi è un'operazione privilegiata) una delle -caratteristiche di unix (che esamineremo in dettaglio più avanti) è che +caratteristiche di Unix (che esamineremo in dettaglio più avanti) è che qualunque processo può a sua volta generarne altri, detti processi figli (\textit{child process}). Ogni processo è identificato presso il sistema da un numero unico, il cosiddetto \textit{process identifier} o, più brevemente, \acr{pid}. -Una seconda caratteristica è che la generazione di un processo è una -operazione separata rispetto al lancio di un programma. In genere la sequenza -è sempre quella di creare un nuovo processo, il quale eseguirà, in un passo -successivo, il programma voluto: questo è ad esempio quello che fa la shell -quando mette in esecuzione il programma che gli indichiamo nella linea di -comando. - -Una terza caratteristica è che ogni processo viene sempre generato da un altro -che viene chiamato processo padre (\textit{parent process}). Questo vale per -tutti i processi, con una sola eccezione: dato che ci deve essere un punto di -partenza esiste sempre un processo speciale (che normalmente è +Una seconda caratteristica di un sistema Unix è che la generazione di un +processo è una operazione separata rispetto al lancio di un programma. In +genere la sequenza è sempre quella di creare un nuovo processo, il quale +eseguirà, in un passo successivo, il programma voluto: questo è ad esempio +quello che fa la shell quando mette in esecuzione il programma che gli +indichiamo nella linea di comando. + +Una terza caratteristica è che ogni processo è sempre stato generato da un +altro, che viene chiamato processo padre (\textit{parent process}). Questo +vale per tutti i processi, con una sola eccezione: dato che ci deve essere un +punto di partenza esiste un processo speciale (che normalmente è \cmd{/sbin/init}), che viene lanciato dal kernel alla conclusione della fase -di avvio, essendo questo il primo processo lanciato dal sistema ha sempre il +di avvio; essendo questo il primo processo lanciato dal sistema ha sempre il \acr{pid} uguale a 1 e non è figlio di nessun altro processo. Ovviamente \cmd{init} è un processo speciale che in genere si occupa di far partire tutti gli altri processi necessari al funzionamento del sistema, inoltre \cmd{init} è essenziale per svolgere una serie di compiti -amministrativi nelle operazioni ordinarie del sistema (torneremo si alcuni di +amministrativi nelle operazioni ordinarie del sistema (torneremo su alcuni di essi in \secref{sec:proc_termination}) e non può mai essere terminato. La struttura del sistema comunque consente di lanciare al posto di \cmd{init} -qualunque altro programma (e in casi di emergenza, ad esempio se il file di -\cmd{init} si fosse corrotto, è ad esempio possibile lanciare una shell al suo -posto, passando la riga \cmd{init=/bin/sh} come parametro di avvio). +qualunque altro programma, e in casi di emergenza (ad esempio se il file di +\cmd{init} si fosse corrotto) è ad esempio possibile lanciare una shell al suo +posto, passando la riga \cmd{init=/bin/sh} come parametro di avvio. \begin{figure}[!htb] \footnotesize \begin{verbatim} -[piccardi@selidor piccardi]$ pstree -n +[piccardi@gont piccardi]$ pstree -n init-+-keventd |-kapm-idled |-kreiserfsd @@ -103,28 +109,62 @@ Dato che tutti i processi attivi nel sistema sono comunque generati da kernel, (come \cmd{keventd}, \cmd{kswapd}, etc.)} si possono classificare i processi con la relazione padre/figlio in una organizzazione gerarchica ad albero, in maniera analoga a come i file sono organizzati in un albero di -directory (si veda \secref{sec:file_file_struct}); in \nfig\ si è mostrato il -risultato del comando \cmd{pstree} che permette di mostrare questa struttura, -alla cui base c'è \cmd{init} che è progenitore di tutti gli altri processi. +directory (si veda \secref{sec:file_organization}); in \curfig\ si è mostrato +il risultato del comando \cmd{pstree} che permette di mostrare questa +struttura, alla cui base c'è \cmd{init} che è progenitore di tutti gli altri +processi. + + +Il kernel mantiene una tabella dei processi attivi, la cosiddetta +\textit{process table}; per ciascun processo viene mantenuta una voce nella +tabella dei processi costituita da una struttura \type{task\_struct}, che +contiene tutte le informazioni rilevanti per quel processo. Tutte le strutture +usate a questo scopo sono dichiarate nell'header file \file{linux/sched.h}, ed +uno schema semplificato che riporta la struttura delle principali informazioni +contenute nella \type{task\_struct} (che in seguito incontreremo a più +riprese), è mostrato in \nfig. + +\begin{figure}[htb] + \centering + \includegraphics[width=13cm]{img/task_struct} + \caption{Schema semplificato dell'architettura delle strutture usate dal + kernel nella gestione dei processi.} + \label{fig:proc_task_struct} +\end{figure} + +Come accennato in \secref{sec:intro_unix_struct} è lo \textit{scheduler} che +decide quale processo mettere in esecuzione; esso viene eseguito ad ogni +system call ed ad ogni interrupt, (ma può essere anche attivato +esplicitamente). Il timer di sistema provvede comunque a che esso sia invocato +periodicamente, generando un interrupt periodico secondo la frequenza +specificata dalla costante \macro{HZ}, definita in \file{asm/param.h} Il +valore usuale è 100 (è espresso in Hertz), si ha cioè un interrupt dal timer +ogni centesimo di secondo. -\subsection{Una panoramica sulle funzioni di gestione} +Ogni volta che viene eseguito, lo \textit{scheduler} effettua il calcolo delle +priorità dei vari processi attivi (torneremo su questo in +\secref{sec:proc_priority}) e stabilisce quale di essi debba essere posto in +esecuzione fino alla successiva invocazione. + + +\subsection{Una panoramica sulle funzioni fondamentali} \label{sec:proc_handling_intro} I processi vengono creati dalla funzione \func{fork}; in molti unix questa è -una system call, Linux però usa un'altra nomenclatura, e la funzione fork è -basata a sua volta sulla system call \func{\_\_clone}, che viene usata anche -per generare i \textit{thread}. Il processo figlio creato dalla \func{fork} è -una copia identica del processo processo padre, ma ha nuovo \acr{pid} e viene -eseguito in maniera indipendente (le differenze fra padre e figlio sono -affrontate in dettaglio in \secref{sec:proc_fork}). +una system call, Linux però usa un'altra nomenclatura, e la funzione +\func{fork} è basata a sua volta sulla system call \func{\_\_clone}, che viene +usata anche per generare i \textit{thread}. Il processo figlio creato dalla +\func{fork} è una copia identica del processo processo padre, ma ha nuovo +\acr{pid} e viene eseguito in maniera indipendente (le differenze fra padre e +figlio sono affrontate in dettaglio in \secref{sec:proc_fork}). Se si vuole che il processo padre si fermi fino alla conclusione del processo figlio questo deve essere specificato subito dopo la \func{fork} chiamando la funzione \func{wait} o la funzione \func{waitpid} (si veda \secref{sec:proc_wait}); queste funzioni restituiscono anche una informazione abbastanza limitata (lo stato di terminazione) sulle cause della terminazione -del processo. +del processo figlio. Quando un processo ha concluso il suo compito o ha incontrato un errore non risolvibile esso può essere terminato con la funzione \func{exit} (si veda @@ -154,13 +194,14 @@ non ritorna mai (in quanto con essa viene eseguito un altro programma). -\section{La gestione dei processi} +\section{Le funzioni di base}% della gestione dei processi} \label{sec:proc_handling} -In questa sezione tratteremo le funzioni per la gestione dei processi, a -partire dalle funzioni elementari che permettono di leggerne gli -identificatori, alle varie funzioni di manipolazione dei processi, che -riguardano la loro creazione, terminazione, e la messa in esecuzione di altri +In questa sezione tratteremo le problematiche della gestione dei processi +all'interno del sistema, illustrandone tutti i dettagli. Inizieremo con le +funzioni elementari che permettono di leggerne gli identificatori, per poi +passare alla spiegazione delle funzioni base che si usano per la creazione e +la terminazione dei processi, e per la messa in esecuzione degli altri programmi. @@ -170,7 +211,7 @@ programmi. Come accennato nell'introduzione ogni processo viene identificato dal sistema da un numero identificativo unico, il \textit{process id} o \acr{pid}; quest'ultimo è un tipo di dato standard, il \type{pid\_t} che in genere è un -intero con segno (nel caso di Linux e delle glibc il tipo usato è \type{int}). +intero con segno (nel caso di Linux e delle \acr{glibc} il tipo usato è \type{int}). Il \acr{pid} viene assegnato in forma progressiva ogni volta che un nuovo processo viene creato, fino ad un limite massimo (in genere essendo detto @@ -186,12 +227,13 @@ ottenuti da programma usando le funzioni: \begin{functions} \headdecl{sys/types.h} \headdecl{unistd.h} -\funcdecl{pid\_t getpid(void)} restituisce il pid del processo corrente. -\funcdecl{pid\_t getppid(void)} restituisce il pid del padre del processo +\funcdecl{pid\_t getpid(void)} Restituisce il pid del processo corrente. +\funcdecl{pid\_t getppid(void)} Restituisce il pid del padre del processo corrente. -Entrambe le funzioni non riportano condizioni di errore. + +\bodydesc{Entrambe le funzioni non riportano condizioni di errore.} \end{functions} -esempi dell'uso di queste funzioni sono riportati in +\noindent esempi dell'uso di queste funzioni sono riportati in \figref{fig:proc_fork_code}, nel programma di esempio \file{ForkTest.c}. Il fatto che il \acr{pid} sia un numero univoco per il sistema lo rende il @@ -205,10 +247,18 @@ Tutti i processi figli dello stesso processo padre sono detti \textit{sibling}, questa è una delle relazioni usate nel \textsl{controllo di sessione}, in cui si raggruppano i processi creati su uno stesso terminale, o relativi allo stesso login. Torneremo su questo argomento in dettaglio in -\secref{cap:session}, dove esamineremo i vari identificativi associati ad un -processo e le varie relazioni fra processi utilizzate per definire una +\secref{cha:session}, dove esamineremo gli altri identificativi associati ad +un processo e le varie relazioni fra processi utilizzate per definire una sessione. +Oltre al \acr{pid} e al \acr{ppid}, (e a quelli che vedremo in +\secref{sec:sess_xxx}, relativi al controllo di sessione), ad ogni processo +vengono associati degli altri identificatori che vengono usati per il +controllo di accesso. Questi servono per determinare se un processo può +eseguire o meno le operazioni richieste, a seconda dei privilegi e +dell'identità di chi lo ha posto in esecuzione; l'argomento è complesso e sarà +affrontato in dettaglio in \secref{sec:proc_perms}. + \subsection{La funzione \func{fork}} \label{sec:proc_fork} @@ -218,21 +268,22 @@ processi: come si attraverso l'uso di questa funzione, essa quindi riveste un ruolo centrale tutte le volte che si devono scrivere programmi che usano il multitasking. Il prototipo della funzione è: - \begin{functions} \headdecl{sys/types.h} \headdecl{unistd.h} \funcdecl{pid\_t fork(void)} - Restituisce zero al padre e il \acr{pid} al figlio in caso di successo, - ritorna -1 al padre (senza creare il figlio) in caso di errore; - \texttt{errno} può assumere i valori: + Crea un nuovo processo. + + \bodydesc{Restituisce zero al padre e il \acr{pid} al figlio in caso di + successo, ritorna -1 al padre (senza creare il figlio) in caso di errore; + \var{errno} può assumere i valori: \begin{errlist} - \item \macro{EAGAIN} non ci sono risorse sufficienti per creare un'altro + \item[\macro{EAGAIN}] non ci sono risorse sufficienti per creare un'altro processo (per allocare la tabella delle pagine e le strutture del task) o si è esaurito il numero di processi disponibili. - \item \macro{ENOMEM} non è stato possibile allocare la memoria per le + \item[\macro{ENOMEM}] non è stato possibile allocare la memoria per le strutture necessarie al kernel per creare il nuovo processo. - \end{errlist} + \end{errlist}} \end{functions} Dopo il successo dell'esecuzione di una \func{fork} sia il processo padre che @@ -244,24 +295,21 @@ padre, ma la memoria di testo, che è identico, è condiviso e tenuto in read-only, Linux poi utilizza la tecnica del \textit{copy-on-write}, per cui la memoria degli altri segmenti viene copiata dal kernel per il nuovo processo solo in caso - di scrittura, rendendo molto più efficiente il meccanismo} pertanto padre e -figlio vedono variabili diverse. + di scrittura, rendendo molto più efficiente il meccanismo della creazione di + un nuovo processo}, pertanto padre e figlio vedono variabili diverse. La differenza che si ha nei due processi è che nel processo padre il valore di -ritorno della funzione fork è il \acr{pid} del processo figlio, mentre nel -figlio è zero; in questo modo il programma può identificare se viene eseguito -dal padre o dal figlio. Si noti come la funzione \func{fork} ritorni -\textbf{due} volte: una nel padre e una nel figlio. La sola differenza che si -ha nei due processi è il valore di ritorno restituito dalla funzione, che nel -padre è il \acr{pid} del figlio mentre nel figlio è zero; in questo modo il -programma può identificare se viene eseguito dal padre o dal figlio. - -La scelta di questi valori non è casuale, un processo infatti può avere più -figli, ed il valore di ritorno di \func{fork} è l'unico modo che permette di -identificare quello appena creato; al contrario un figlio ha sempre un solo -padre (il cui \acr{pid} può sempre essere ottenuto con \func{getppid}, vedi -\secref{sec:proc_pid}) e si usa il valore nullo, che non può essere il -\acr{pid} di nessun processo. +ritorno della funzione \func{fork} è il \acr{pid} del processo figlio, mentre +nel figlio è zero; in questo modo il programma può identificare se viene +eseguito dal padre o dal figlio. Si noti come la funzione \func{fork} ritorni +\textbf{due} volte: una nel padre e una nel figlio. + +La scelta di questi valori di ritorno non è casuale, un processo infatti può +avere più figli, ed il valore di ritorno di \func{fork} è l'unico modo che gli +permette di identificare quello appena creato; al contrario un figlio ha +sempre un solo padre (il cui \acr{pid} può sempre essere ottenuto con +\func{getppid}, vedi \secref{sec:proc_pid}) per cui si usa il valore nullo, +che non è il \acr{pid} di nessun processo. \begin{figure}[!htb] \footnotesize @@ -318,9 +366,7 @@ int main(int argc, char *argv[]) Normalmente la chiamata a \func{fork} può fallire solo per due ragioni, o ci sono già troppi processi nel sistema (il che di solito è sintomo che qualcos'altro non sta andando per il verso giusto) o si è ecceduto il limite -sul numero totale di processi permessi all'utente (il valore della costante -\macro{CHILD\_MAX} definito in \file{limits.h}, che fa riferimento ai processo -con lo stesso \textit{real user id}). +sul numero totale di processi permessi all'utente (vedi \secref{sec:sys_xxx}). L'uso di \func{fork} avviene secondo due modalità principali; la prima è quella in cui all'interno di un programma si creano processi figli per @@ -337,13 +383,14 @@ parleremo in \secref{sec:proc_exec}) subito dopo la \func{fork}. Alcuni sistemi operativi (il VMS ad esempio) combinano le operazioni di questa seconda modalità (una \func{fork} seguita da una \func{exec}) in un'unica operazione che viene chiamata \textit{spawn}. Nei sistemi unix-like è stato -scelto di mantenere questa separazione, dato che, come visto per la prima -modalità d'uso, esistono numerosi scenari in cui si può usare una \func{fork} -senza bisogno di una \func{exec}. Inoltre anche nel caso della seconda -modalità di operazioni, avere le due funzioni separate permette al figlio di +scelto di mantenere questa separazione, dato che, come per la prima modalità +d'uso, esistono numerosi scenari in cui si può usare una \func{fork} senza +aver bisogno di eseguire una \func{exec}. Inoltre, anche nel caso della +seconda modalità di uso, avere le due funzioni separate permette al figlio di cambiare gli attributi del processo (maschera dei segnali, redirezione -dell'output, \textit{user id}) prima della \func{exec}, rendendo molto più -flessibile la possibilità di modificare gli attributi del nuovo processo. +dell'output, \textit{user id}) prima della \func{exec}, rendendo così +relativamente facile intervenire sulle le modalità di esecuzione del nuovo +programma. In \curfig\ si è riportato il corpo del codice del programma di esempio \cmd{forktest}, che ci permette di illustrare molte caratteristiche dell'uso @@ -368,6 +415,8 @@ periodo di attesa. Se eseguiamo il comando senza specificare attese (come si può notare in \texttt{\small 17--19} i valori di default specificano di non attendere), otterremo come output sul terminale: + +\footnotesize \begin{verbatim} [piccardi@selidor sources]$ ./forktest 3 Process 1963: forking 3 child @@ -384,18 +433,20 @@ Child 3, parent 1963, exiting Spawned 3 child, pid 1966 Go to next child \end{verbatim} %$ +\normalsize Esaminiamo questo risultato: una prima conclusione che si può trarre è non si può dire quale processo fra il padre ed il figlio venga eseguito per -primo\footnote{anche se nel kernel 2.4.x era stato introdotto un meccanismo - che metteva in esecuzione sempre il xxx per primo (TODO recuperare le - informazioni esatte)} dopo la chiamata a \func{fork}; dall'esempio si può -notare infatti come nei primi due cicli sia stato eseguito per primo il padre -(con la stampa del \acr{pid} del nuovo processo) per poi passare -all'esecuzione del figlio (completata con i due avvisi di esecuzione ed -uscita), e tornare all'esecuzione del padre (con la stampa del passaggio al -ciclo successivo), mentre la terza volta è stato prima eseguito il figlio -(fino alla conclusione) e poi il padre. +primo\footnote{a partire dal kernel 2.5.2-pre10 è stato introdotto il nuovo + scheduler di Ingo Molnar che esegue sempre per primo il figlio; per + mantenere la portabilità è opportuno non fare comunque affidamento su questo + comportamento} dopo la chiamata a \func{fork}; dall'esempio si può notare +infatti come nei primi due cicli sia stato eseguito per primo il padre (con la +stampa del \acr{pid} del nuovo processo) per poi passare all'esecuzione del +figlio (completata con i due avvisi di esecuzione ed uscita), e tornare +all'esecuzione del padre (con la stampa del passaggio al ciclo successivo), +mentre la terza volta è stato prima eseguito il figlio (fino alla conclusione) +e poi il padre. In generale l'ordine di esecuzione dipenderà, oltre che dall'algoritmo di scheduling usato dal kernel, dalla particolare situazione in si trova la @@ -409,19 +460,22 @@ Pertanto non si pu istruzioni del codice fra padre e figli, nè sull'ordine in cui questi potranno essere messi in esecuzione, e se è necessaria una qualche forma di precedenza occorrerà provvedere ad espliciti meccanismi di sincronizzazione, pena il -rischio di incorrere nelle cosiddette \textit{race conditions}. +rischio di incorrere nelle cosiddette \textit{race condition} \index{race + condition} (vedi \secref{sec:proc_race_cond}. -Si noti inoltre che, come accennato, essendo i segmenti di memoria utilizzati -dai singoli processi completamente separati, le modifiche delle variabili nei -processi figli (come l'incremento di \var{i} in \texttt{\small 33}) sono -visibili solo al loro interno, e non hanno alcun effetto sul valore che le -stesse variabili hanno nel processo padre (ed in eventuali altri processi -figli che eseguano lo stesso codice). +Si noti inoltre che essendo i segmenti di memoria utilizzati dai singoli +processi completamente separati, le modifiche delle variabili nei processi +figli (come l'incremento di \var{i} in \texttt{\small 33}) sono visibili solo +a loro, e non hanno alcun effetto sul valore che le stesse variabili hanno nel +processo padre (ed in eventuali altri processi figli che eseguano lo stesso +codice). Un secondo aspetto molto importante nella creazione dei processi figli è quello dell'interazione dei vari processi con i file; per illustrarlo meglio proviamo a redirigere su un file l'output del nostro programma di test, quello che otterremo è: + +\footnotesize \begin{verbatim} [piccardi@selidor sources]$ ./forktest 3 > output [piccardi@selidor sources]$ cat output @@ -448,26 +502,29 @@ Go to next child Spawned 3 child, pid 1970 Go to next child \end{verbatim} +\normalsize che come si vede è completamente diverso da quanto ottenevamo sul terminale. Il comportamento delle varie funzioni di interfaccia con i file è analizzato in gran dettaglio in \capref{cha:file_unix_interface} e in \secref{cha:files_std_interface}. Qui basta accennare che si sono usate le funzioni standard della libreria del C che prevedono l'output bufferizzato; e -questa bufferizzazione varia a seconda che si tratti di un file su disco (in -cui il buffer viene scaricato su disco solo quando necessario) o di un -terminale (nel qual caso il buffer viene scaricato ad ogni a capo). +questa bufferizzazione (di veda \secref{sec:file_buffering}) varia a seconda +che si tratti di un file su disco (in cui il buffer viene scaricato su disco +solo quando necessario) o di un terminale (nel qual caso il buffer viene +scaricato ad ogni carattere di a capo). Nel primo esempio allora avevamo che ad ogni chiamata a \func{printf} il buffer veniva scaricato, e le singole righe erano stampate a video subito dopo l'esecuzione della \func{printf}. Ma con la redirezione su file la scrittura -non avviene più alla fine di ogni riga e l'output resta nel buffer, per questo +non avviene più alla fine di ogni riga e l'output resta nel buffer. Per questo motivo, dato che ogni figlio riceve una copia della memoria del padre, esso riceverà anche quanto c'è nel buffer delle funzioni di I/O, comprese le linee scritte dal padre fino allora. Così quando all'uscita del figlio il buffer viene scritto su disco, troveremo nel file anche tutto quello che il processo -padre aveva scritto prima della sua creazione. E alla fine del file, dato che -in questo caso il padre esce per ultimo, troviamo anche l'output del padre. +padre aveva scritto prima della sua creazione. E solo alla fine del file, +dato che in questo caso il padre esce per ultimo, troveremo anche l'output del +padre. Ma l'esempio ci mostra un'altro aspetto fondamentale dell'interazione con i file, che era valido anche per l'esempio precedente, ma meno evidente; il @@ -481,74 +538,80 @@ Quello che succede lo stesso avviene anche per tutti i figli; la funzione \func{fork} infatti ha la caratteristica di duplicare (allo stesso modo in cui lo fa la funzione \func{dup}, trattata in \secref{sec:file_dup}) nei figli tutti i file -descriptor aperti nel padre, il che comporta che padre e figli condividono -le stesse voci della file table (per la spiegazione di questi termini si veda -\secref{sec:file_sharing} e referenza a figura da fare) e quindi anche -l'offset corrente nel file. - -In questo modo se un processo scrive sul file aggiornerà l'offset sulla file -table, e tutti gli altri processi che condividono la file table vedranno il -nuovo valore; in questo modo si evita, in casi come quello appena mostrato in -cui diversi processi scrivono sullo stesso file, che l'output successivo di un -processo vada a sovrapporsi a quello dei precedenti (l'output potrà risultare -mescolato, ma non ci saranno parti perdute per via di una sovrascrittura). +descriptor aperti nel padre, il che comporta che padre e figli condividono le +stesse voci della \textit{file table} (per la spiegazione di questi termini si +veda \secref{sec:file_sharing}) e fra cui c'è anche la posizione corrente nel +file. + +In questo modo se un processo scrive sul file aggiornerà la posizione corrente +sulla \textit{file table}, e tutti gli altri processi, che vedono la stessa +\textit{file table}, vedranno il nuovo valore. In questo modo si evita, in +casi come quello appena mostrato in cui diversi processi scrivono sullo stesso +file, che l'output successivo di un processo vada a sovrapporsi a quello dei +precedenti: l'output potrà risultare mescolato, ma non ci saranno parti +perdute per via di una sovrascrittura. Questo tipo di comportamento è essenziale in tutti quei casi in cui il padre -crea un figlio ed attende la sua conclusione per proseguire, ed entrambi -scrivono sullo stesso file, ad esempio lo standard output (un caso tipico è la -shell). Se l'output viene rediretto con questo comportamento avremo che il -padre potrà continuare a scrivere automaticamente in coda a quanto scritto dal -figlio; se così non fosse ottenere questo comportamento sarebbe estremamente -complesso necessitando di una qualche forma di comunicazione fra i due -processi. +crea un figlio e attende la sua conclusione per proseguire, ed entrambi +scrivono sullo stesso file (un caso tipico è la shell quando lancia un +programma, il cui output va sullo standard output). + +In questo modo, anche se l'output viene rediretto, il padre potrà sempre +continuare a scrivere in coda a quanto scritto dal figlio in maniera +automatica; se così non fosse ottenere questo comportamento sarebbe +estremamente complesso necessitando di una qualche forma di comunicazione fra +i due processi per far riprendere al padre la scrittura al punto giusto. In generale comunque non è buona norma far scrivere più processi sullo stesso -file senza una qualche forma di sincronizzazione in quanto, come visto con il -nostro esempio, le varie scritture risulteranno mescolate fra loro in una -sequenza impredicibile. Le modalità con cui in genere si usano i file dopo una -\func{fork} sono sostanzialmente due: +file senza una qualche forma di sincronizzazione in quanto, come visto anche +con il nostro esempio, le varie scritture risulteranno mescolate fra loro in +una sequenza impredicibile. Per questo le modalità con cui in genere si usano +i file dopo una \func{fork} sono sostanzialmente due: \begin{enumerate} \item Il processo padre aspetta la conclusione del figlio. In questo caso non è necessaria nessuna azione riguardo ai file, in quanto la sincronizzazione - degli offset dopo eventuali operazioni di lettura e scrittura effettuate dal - figlio è automatica. + della posizione corrente dopo eventuali operazioni di lettura e scrittura + effettuate dal figlio è automatica. \item L'esecuzione di padre e figlio procede indipendentemente. In questo caso - ciascuno dei due deve chiudere i file che non gli servono una volta che la - \func{fork} è stata eseguita, per evitare ogni forma di interferenza. + ciascuno dei due processi deve chiudere i file che non gli servono una volta + che la \func{fork} è stata eseguita, per evitare ogni forma di interferenza. \end{enumerate} Oltre ai file aperti i processi figli ereditano dal padre una serie di altre -proprietà comuni; in dettaglio avremo che dopo l'esecuzione di una \func{fork} -padre e figlio avranno in comune: -\begin{itemize} -\item i file aperti (e gli eventuali flag di \textit{close-on-exec} se - settati). +proprietà; la lista dettagliata delle proprietà che padre e figlio hanno in +comune dopo l'esecuzione di una \func{fork} è la seguente: +\begin{itemize*} +\item i file aperti e gli eventuali flag di \textit{close-on-exec} settati + (vedi \secref{sec:proc_exec} e \secref{sec:file_fcntl}). \item gli identificatori per il controllo di accesso: il \textit{real user id}, il \textit{real group id}, l'\textit{effective user id}, - l'\textit{effective group id} e i \textit{supplementary group id} (vedi - \secref{tab:proc_uid_gid}). + l'\textit{effective group id} ed i \textit{supplementary group id} (vedi + \secref{sec:proc_access_id}). \item gli identificatori per il controllo di sessione: il \textit{process - group id} e il \textit{session id} e il terminale di controllo. -\item i flag \acr{suid} e \acr{suid} (vedi \secref{sec:file_suid_sgid}). + group id} e il \textit{session id} ed il terminale di controllo (vedi + \secref{sec:sess_xxx} e \secref{sec:sess_xxx}). \item la directory di lavoro e la directory radice (vedi - \secref{sec:file_work_dir}). + \secref{sec:file_work_dir} e \secref{sec:file_chroot}). \item la maschera dei permessi di creazione (vedi \secref{sec:file_umask}). -\item la maschera dei segnali. -\item i segmenti di memoria condivisa agganciati al processo. -\item i limiti sulle risorse +\item la maschera dei segnali bloccati e le azioni installate (vedi +\secref{sec:sig_xxx}). +\item i segmenti di memoria condivisa agganciati al processo (vedi +\secref{sec:ipc_xxx}). +\item i limiti sulle risorse (vedi \secref{sec:sys_xxx}). \item le variabili di ambiente (vedi \secref{sec:proc_environ}). -\end{itemize} -le differenze invece sono: -\begin{itemize} +\end{itemize*} +le differenze fra padre e figlio dopo la \func{fork} invece sono: +\begin{itemize*} \item il valore di ritorno di \func{fork}. \item il \textit{process id}. \item il \textit{parent process id} (quello del figlio viene settato al \acr{pid} del padre). -\item i valori dei tempi di esecuzione (\var{tms\_utime}, \var{tms\_stime}, - \var{tms\_cutime}, \var{tms\_uetime}) che nel figlio sono posti a zero. -\item i \textit{file lock}, che non vengono ereditati dal figlio. -\item gli allarmi pendenti, che per il figlio vengono cancellati. -\end{itemize} +\item i valori dei tempi di esecuzione (vedi \secref{sec:sys_xxx}) che + nel figlio sono posti a zero. +\item i \textit{file lock} (vedi \secref{sec:file_locking}), che non + vengono ereditati dal figlio. +\item gli allarmi ed i segnali pendenti (vedi \secref{sec:sig_xxx}), che per il figlio vengono cancellati. +\end{itemize*} \subsection{La funzione \func{vfork}} @@ -570,7 +633,7 @@ venne introdotta in BSD per migliorare le prestazioni. Dato che Linux supporta il \textit{copy on write} la perdita di prestazioni è assolutamente trascurabile, e l'uso di questa funzione (che resta un caso -speciale della funzione \func{clone}), è deprecato, per questo eviteremo di +speciale della funzione \func{clone}), è deprecato; per questo eviteremo di trattarla ulteriormente. @@ -578,7 +641,7 @@ trattarla ulteriormente. \label{sec:proc_termination} In \secref{sec:proc_conclusion} abbiamo già affrontato le modalità con cui -concludere un programma, ma dal punto di vista del programma stesso; avendo a +chiudere un programma, ma dal punto di vista del programma stesso; avendo a che fare con un sistema multitasking occorre adesso affrontare l'argomento dal punto di vista generale di come il sistema gestisce la conclusione dei processi. @@ -601,31 +664,34 @@ Qualunque sia la modalit comunque una serie di operazioni: chiude tutti i file aperti, rilascia la memoria che stava usando, e così via; l'elenco completo delle operazioni eseguite alla chiusura di un processo è il seguente: -\begin{itemize} -\item tutti i descrittori dei file sono chiusi. +\begin{itemize*} +\item tutti i file descriptor sono chiusi. \item viene memorizzato lo stato di terminazione del processo. -\item ad ogni processo figlio viene assegnato un nuovo padre. -\item viene inviato il segnale \macro{SIGCHLD} al processo padre. +\item ad ogni processo figlio viene assegnato un nuovo padre (in genere + \cmd{init}). +\item viene inviato il segnale \macro{SIGCHLD} al processo padre (vedi + \secref{sec:sig_xxx}). \item se il processo è un leader di sessione viene mandato un segnale di - \macro{SIGHUP} a tutti i processi in background e il terminale di controllo - viene disconnesso. -\item se la conclusione di un processe rende orfano un \textit{process group} - ciascun membro del gruppo viene bloccato, e poi gli vengono inviati in - successione i segnali \macro{SIGHUP} e \macro{SIGCONT}. -\end{itemize} + \macro{SIGHUP} a tutti i processi in background e il terminale di + controllo viene disconnesso (vedi \secref{sec:sess_xxx}). +\item se la conclusione di un processo rende orfano un \textit{process + group} ciascun membro del gruppo viene bloccato, e poi gli vengono + inviati in successione i segnali \macro{SIGHUP} e \macro{SIGCONT} + (vedi \secref{sec:sess_xxx}). +\end{itemize*} ma al di la di queste operazioni è necessario poter disporre di un meccanismo ulteriore che consenta di sapere come questa terminazione è avvenuta; dato che in un sistema unix-like tutto viene gestito attraverso i processi il -meccanismo scelto consiste nel riportare lo stato di terminazione -(\textit{termination status}) di cui sopra al processo padre. +meccanismo scelto consiste nel riportare lo stato di terminazione (il +cosiddetto \textit{termination status}) al processo padre. -Nel caso di conclusione normale, lo stato di uscita del processo viene -caratterizzato tremite il valore del cosiddetto \textit{exit status}, cioè il -valore passato alle funzioni \func{exit} o \func{\_exit} (o dal valore di -ritorno per \func{main}). Ma se il processo viene concluso in maniera anomala -il programma non può specificare nessun \textit{exit status}, ed è il kernel -che deve generare autonomamente il \textit{termination status} per indicare le -ragioni della conclusione anomala. +Nel caso di conclusione normale, abbiamo visto in \secref{sec:proc_conclusion} +che lo stato di uscita del processo viene caratterizzato tramite il valore del +cosiddetto \textit{exit status}, cioè il valore passato alle funzioni +\func{exit} o \func{\_exit} (o dal valore di ritorno per \func{main}). Ma se +il processo viene concluso in maniera anomala il programma non può specificare +nessun \textit{exit status}, ed è il kernel che deve generare autonomamente il +\textit{termination status} per indicare le ragioni della conclusione anomala. Si noti la distinzione fra \textit{exit status} e \textit{termination status}: quello che contraddistingue lo stato di chiusura del processo e viene @@ -637,7 +703,7 @@ secondo. La scelta di riportare al padre lo stato di terminazione dei figli, pur essendo l'unica possibile, comporta comunque alcune complicazioni: infatti se alla sua creazione è scontato che ogni nuovo processo ha un padre, non è detto -che sia così alla sua conclusione, dato che il padre protrebbe essere già +che sia così alla sua conclusione, dato che il padre potrebbe essere già terminato (si potrebbe avere cioè quello che si chiama un processo \textsl{orfano}). @@ -650,6 +716,8 @@ avr di terminazione. Come verifica di questo comportamento possiamo eseguire il comando \cmd{forktest} imponendo a ciascun processo figlio due secondi di attesa prima di uscire, il risultato è: + +\footnotesize \begin{verbatim} [piccardi@selidor sources]$ ./forktest -c2 3 Process 1972: forking 3 child @@ -666,6 +734,7 @@ Go to next child Child 2, parent 1, exiting Child 1, parent 1, exiting \end{verbatim} +\normalsize come si può notare in questo caso il processo padre si conclude prima dei figli, tornando alla shell, che stampa il prompt sul terminale: circa due secondi dopo viene stampato a video anche l'output dei tre figli che @@ -679,15 +748,15 @@ informazioni riguardo ai processi che sta terminando. Questo viene fatto mantenendo attiva la voce nella tabella dei processi, e memorizzando alcuni dati essenziali, come il \acr{pid}, i tempi di CPU usati -dal processo (vedi \secref{sec:intro_unix_time}) e lo stato di terminazione -\footnote{NdA verificare esattamente cosa c'è!}, mentre la memoria in uso ed i -file aperti vengono rilasciati immediatamente. I processi che sono terminati, -ma il cui stato di terminazione non è stato ancora ricevuto dal padre sono -chiamati \textit{zombie}, essi restano presenti nella tabella dei processi ed -in genere possono essere identificati dall'output di \cmd{ps} per la presenza -di una \cmd{Z} nella colonna che ne indica lo stato. Quando il padre -effettuarà la lettura dello stato di uscita anche questa informazione, non più -necessaria, verrà scartata e la terminazione potrà dirsi completamente +dal processo (vedi \secref{sec:sys_unix_time}) e lo stato di +terminazione\footnote{NdA verificare esattamente cosa c'è!}, mentre la memoria +in uso ed i file aperti vengono rilasciati immediatamente. I processi che sono +terminati, ma il cui stato di terminazione non è stato ancora ricevuto dal +padre sono chiamati \textit{zombie}, essi restano presenti nella tabella dei +processi ed in genere possono essere identificati dall'output di \cmd{ps} per +la presenza di una \texttt{Z} nella colonna che ne indica lo stato. Quando il +padre effettuerà la lettura dello stato di uscita anche questa informazione, +non più necessaria, verrà scartata e la terminazione potrà dirsi completamente conclusa. Possiamo utilizzare il nostro programma di prova per analizzare anche questa @@ -695,6 +764,8 @@ condizione: lanciamo il comando \cmd{forktest} in background, indicando al processo padre di aspettare 10 secondi prima di uscire; in questo caso, usando \cmd{ps} sullo stesso terminale (prima dello scadere dei 10 secondi) otterremo: + +\footnotesize \begin{verbatim} [piccardi@selidor sources]$ ps T PID TTY STAT TIME COMMAND @@ -705,6 +776,7 @@ otterremo: 571 pts/0 Z 0:00 [forktest ] 572 pts/0 R 0:00 ps T \end{verbatim} %$ +\normalsize e come si vede, dato che non si è fatto nulla per riceverne lo stato di terminazione, i tre processi figli sono ancora presenti pur essendosi conclusi, con lo stato di zombie e l'indicazione che sono stati terminati. @@ -734,7 +806,7 @@ di terminare il processo che li ha generati, in modo che \cmd{init} possa adottarli e provvedere a concludere la terminazione. -\subsection{Le funzioni \texttt{wait} e \texttt{waitpid}} +\subsection{Le funzioni \func{wait} e \func{waitpid}} \label{sec:proc_wait} Abbiamo già accennato come uno degli usi possibili delle capacità multitasking @@ -749,51 +821,55 @@ prototipo \begin{functions} \headdecl{sys/types.h} \headdecl{sys/wait.h} -\funcdecl{pid\_t wait(int * status)} +\funcdecl{pid\_t wait(int *status)} Sospende il processo corrente finché un figlio non è uscito, o finché un -segnale termina il processo o chiama una funzione di gestione. Se un figlio è -già uscito la funzione ritorna immediatamente. Al ritorno lo stato di -termininazione del processo viene salvato nella variabile puntata da -\var{status} e tutte le informazioni relative al processo (vedi -\secref{sec:proc_termination}) vengono rilasciate. - -La funzione restituisce il \acr{pid} del figlio in caso di successo e -1 in -caso di errore; \var{errno} può assumere i valori: +segnale termina il processo o chiama una funzione di gestione. + +\bodydesc{La funzione restituisce il \acr{pid} del figlio in caso di successo + e -1 in caso di errore; \var{errno} può assumere i valori: \begin{errlist} - \item \macro{EINTR} la funzione è stata interrotta da un segnale. - \end{errlist} + \item[\macro{EINTR}] la funzione è stata interrotta da un segnale. + \end{errlist}} \end{functions} -è presente fin dalle prime versioni di unix; la funzione ritorna alla -conclusione del primo figlio (o immediatamente se un figlio è già uscito). Nel -caso un processo abbia più figli il valore di ritorno permette di identificare -qual'è quello che è uscito. - -Questa funzione però ha il difetto di essere poco flessibile, in quanto -ritorna all'uscita di un figlio qualunque. Nelle occasioni in cui è necessario -attendere la conclusione di un processo specifico occorre predisporre un -meccanismo che tenga conto dei processi già terminati, e ripeta la chiamata -alla funzione nel caso il processo cercato sia ancora attivo. +\noindent +è presente fin dalle prime versioni di unix; la funzione ritorna non appena un +processo figlio termina. Se un figlio è già terminato la funzione ritorna +immediatamente. + +Al ritorno lo stato di termininazione del processo viene salvato nella +variabile puntata da \var{status} e tutte le informazioni relative al +processo (vedi \secref{sec:proc_termination}) vengono rilasciate. Nel +caso un processo abbia più figli il valore di ritorno permette di +identificare qual'è quello che è uscito. + +Questa funzione ha il difetto di essere poco flessibile, in quanto +ritorna all'uscita di un figlio qualunque. Nelle occasioni in cui è +necessario attendere la conclusione di un processo specifico occorre +predisporre un meccanismo che tenga conto dei processi già terminati, e +provveda a ripetere la chiamata alla funzione nel caso il processo +cercato sia ancora attivo. Per questo motivo lo standard POSIX.1 ha introdotto la funzione \func{waitpid} che effettua lo stesso servizio, ma dispone di una serie di funzionalità più ampie, legate anche al controllo di sessione. Dato che è possibile ottenere lo stesso comportamento di \func{wait} si consiglia di utilizzare sempre -questa funzione; il suo prototipo è: +questa funzione, il cui prototipo è: \begin{functions} \headdecl{sys/types.h} \headdecl{sys/wait.h} -\funcdecl{pid\_t waitpid(pid\_t pid, int * status, int options)} +\funcdecl{pid\_t waitpid(pid\_t pid, int *status, int options)} +Attende la conclusione di un processo figlio. -La funzione restituisce il \acr{pid} del processo che è uscito, 0 se è stata -specificata l'opzione \macro{WNOHANG} e il processo non è uscito e -1 per un -errore, nel qual caso \var{errno} assumerà i valori: +\bodydesc{La funzione restituisce il \acr{pid} del processo che è uscito, 0 se + è stata specificata l'opzione \macro{WNOHANG} e il processo non è uscito e + -1 per un errore, nel qual caso \var{errno} assumerà i valori: \begin{errlist} - \item \macro{EINTR} se non è stata specificata l'opzione \macro{WNOHANG} e + \item[\macro{EINTR}] se non è stata specificata l'opzione \macro{WNOHANG} e la funzione è stata interrotta da un segnale. - \item \macro{ECHILD} il processo specificato da \var{pid} non esiste o non è + \item[\macro{ECHILD}] il processo specificato da \var{pid} non esiste o non è figlio del processo chiamante. - \end{errlist} + \end{errlist}} \end{functions} Le differenze principali fra le due funzioni sono che \func{wait} si blocca @@ -804,6 +880,7 @@ base del valore specificato tramite la variabile \var{pid}, secondo lo specchietto riportato in \ntab: \begin{table}[!htb] \centering + \footnotesize \begin{tabular}[c]{|c|p{10cm}|} \hline \textbf{Valore} & \textbf{Significato}\\ @@ -831,7 +908,7 @@ processo figlio non di sessione, trattato in \capref{cha:session}) che fa ritornare la funzione anche per i processi figli che sono bloccati ed il cui stato non è stato ancora riportato al padre. Il valore dell'opzione deve essere specificato come -mashera binaria ottenuta con l'OR delle suddette costanti con zero. +maschera binaria ottenuta con l'OR delle suddette costanti con zero. La terminazione di un processo figlio è chiaramente un evento asincrono rispetto all'esecuzione di un programma e può avvenire in un qualunque @@ -863,16 +940,16 @@ certezza che la chiamata a \func{wait} non si bloccher \macro{WEXITSTATUS(s)} & Restituisce gli otto bit meno significativi dello stato di uscita del processo (passato attraverso \func{\_exit}, \func{exit} o come valore di ritorno di \func{main}). Può essere valutata solo se - \macro{WIFEXITED} ha restitituito un valore non nullo.\\ + \macro{WIFEXITED} ha restituito un valore non nullo.\\ \macro{WIFSIGNALED(s)} & Vera se il processo figlio è terminato in maniera anomala a causa di un segnale che non è stato catturato (vedi \secref{sec:sig_notification}).\\ \macro{WTERMSIG(s)} & restituisce il numero del segnale che ha causato la terminazione anomala del processo. Può essere valutata solo se - \macro{WIFSIGNALED} ha restitituito un valore non nullo.\\ + \macro{WIFSIGNALED} ha restituito un valore non nullo.\\ \macro{WCOREDUMP(s)} & Vera se il processo terminato ha generato un file si \textit{core dump}. Può essere valutata solo se - \macro{WIFSIGNALED} ha restitituito un valore non nullo\footnote{questa + \macro{WIFSIGNALED} ha restituito un valore non nullo\footnote{questa macro non è definita dallo standard POSIX.1, ma è presente come estensione sia in Linux che in altri unix}.\\ \macro{WIFSTOPPED(s)} & Vera se il processo che ha causato il ritorno di @@ -880,7 +957,7 @@ certezza che la chiamata a \func{wait} non si bloccher l'opzione \macro{WUNTRACED}. \\ \macro{WSTOPSIG(s)} & restituisce il numero del segnale che ha bloccato il processo, Può essere valutata solo se \macro{WIFSTOPPED} ha - restitituito un valore non nullo. \\ + restituito un valore non nullo. \\ \hline \end{tabular} \caption{Descrizione delle varie macro di preprocessore utilizzabili per @@ -888,16 +965,15 @@ certezza che la chiamata a \func{wait} non si bloccher \label{tab:proc_status_macro} \end{table} - -Entrambe le funzioni restituiscono lo stato di terminazione del processo -tramite il puntatore \var{status} (se non interessa memorizzare lo stato si -può passare un puntatore nullo). Il valore restituito da entrambe le funzioni -dipende dall'implementazione, e tradizionalmente alcuni bit sono riservati per -memorizzare lo stato di uscita (in genere 8) altri per indicare il segnale che -ha causato la terminazione (in caso di conclusione anomala), uno per indicare -se è stato generato un core file, etc.\footnote{le definizioni esatte si - possono trovare in \file{}}. Lo standard POSIX.1 definisce una serie di macro di preprocessore da usare per analizzare lo stato di uscita; esse sono definite sempre in \file{} ed elencate in \curtab\ (si tenga presente che @@ -906,17 +982,19 @@ da \var{status}). Si tenga conto che nel caso di conclusione anomala il valore restituito da \macro{WTERMSIG} può essere controllato contro le costanti definite in -\file{signal.h}, e stampato usando le funzioni definite in -\secref{sec:sig_strsignal}. +\file{signal.h} ed elencate in \tabref{tab:sig_signal_list}, e stampato usando +le apposite funzioni trattate in \secref{sec:sig_strsignal}. + + +\subsection{Le funzioni \func{wait3} e \func{wait4}} +\label{sec:proc_wait4} Linux, seguendo una estensione di BSD, supporta altre due funzioni per la lettura dello stato di terminazione di un processo, analoghe a \func{wait} e \func{waitpid}, ma che prevedono un ulteriore parametro attraverso il quale il -kernel può restituire al processo padre ulteriori informazioni sulle risorse -usate dal processo terminato e dai vari figli. -Queste funzioni diventano accessibili definendo la costante \macro{\_USE\_BSD} -sono: - +kernel può restituire al padre informazioni sulle risorse usate dal processo +terminato e dai vari figli. Queste funzioni, che diventano accessibili +definendo la costante \macro{\_USE\_BSD}, sono: \begin{functions} \headdecl{sys/times.h} \headdecl{sys/types.h} @@ -924,107 +1002,83 @@ sono: \headdecl{sys/resource.h} \funcdecl{pid\_t wait4(pid\_t pid, int * status, int options, struct rusage * rusage)} - La funzione è identica a \func{waitpid} sia per comportamento che per i - valori dei parametri, ma restituisce in \var{rusage} un sommario delle - risorse usate dal processo (per i dettagli vedi \secref{sec:xxx_limit_res}) - \funcdecl{pid\_t wait3(int *status, int options, struct rusage *rusage)} - Prima versione, equivalente a \func{wait4(-1, \&status, opt, rusage)} ormai - deprecata in favore di \func{wait4}. + È identica a \func{waitpid} sia per comportamento che per i + valori dei parametri, ma restituisce in \param{rusage} un sommario delle + risorse usate dal processo (per i dettagli vedi \secref{sec:sys_xxx}) + + \funcdecl{pid\_t wait3(int *status, int options, struct rusage *rusage)} + Prima versione, equivalente a \code{wait4(-1, \&status, opt, rusage)} è + ormai deprecata in favore di \func{wait4}. \end{functions} +\noindent la struttura \type{rusage} è definita in \file{sys/resource.h}, e viene -utilizzata anche dalla funzione \func{getrusage} per ottenere le risorse di -sistema usate dal processo; in Linux è definita come: -\begin{figure}[!htb] - \footnotesize - \centering - \begin{minipage}[c]{15cm} - \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{} -struct rusage { - struct timeval ru_utime; /* user time used */ - struct timeval ru_stime; /* system time used */ - long ru_maxrss; /* maximum resident set size */ - long ru_ixrss; /* integral shared memory size */ - long ru_idrss; /* integral unshared data size */ - long ru_isrss; /* integral unshared stack size */ - long ru_minflt; /* page reclaims */ - long ru_majflt; /* page faults */ - long ru_nswap; /* swaps */ - long ru_inblock; /* block input operations */ - long ru_oublock; /* block output operations */ - long ru_msgsnd; /* messages sent */ - long ru_msgrcv; /* messages received */ - long ru_nsignals; ; /* signals received */ - long ru_nvcsw; /* voluntary context switches */ - long ru_nivcsw; /* involuntary context switches */ -}; - \end{lstlisting} - \end{minipage} - \normalsize - \caption{La struttura \texttt{rusage} per la lettura delle informazioni dei - delle risorse usate da un processo.} - \label{fig:proc_rusage_struct} -\end{figure} -In genere includere esplicitamente \file{} non è più necessario, -ma aumenta la portabiltà, e serve in caso si debba accedere ai campi di -\var{rusage} definiti come \type{struct timeval}. La struttura è ripresa dalla -versione 4.3 Reno di BSD, attualmente (con il kernel 2.4.x) i soli campi che -sono mantenuti sono: \var{ru\_utime}, \var{ru\_stime}, \var{ru\_minflt}, -\var{ru\_majflt}, e \var{ru\_nswap}. - -\subsection{Le funzioni \texttt{exec}} +utilizzata anche dalla funzione \func{getrusage} (vedi \secref{sec:sys_xxx}) +per ottenere le risorse di sistema usate dal processo; la sua definizione è +riportata in \figref{fig:sys_rusage_struct}. + +In genere includere esplicitamente \file{} non è più +necessario, ma aumenta la portabilità, e serve in caso si debba accedere +ai campi di \var{rusage} definiti come \type{struct timeval}. La +struttura è ripresa da BSD 4.3, attualmente (con il kernel 2.4.x) i soli +campi che sono mantenuti sono: \var{ru\_utime}, \var{ru\_stime}, +\var{ru\_minflt}, \var{ru\_majflt}, e \var{ru\_nswap}. + + +\subsection{Le funzioni \func{exec}} \label{sec:proc_exec} Abbiamo già detto che una delle modalità principali con cui si utilizzano i -processi in unix è quella di usarli per lanciare nuovi programmi: questo viene +processi in Unix è quella di usarli per lanciare nuovi programmi: questo viene fatto attraverso una delle funzioni della famiglia \func{exec}. Quando un processo chiama una di queste funzioni esso viene completamente sostituito dal nuovo programma; il \acr{pid} del processo non cambia, dato che non viene -creato un nuovo processo, la funzione semplicemente rimpiazza lo stack, o +creato un nuovo processo, la funzione semplicemente rimpiazza lo stack, lo heap, i dati ed il testo del processo corrente con un nuovo programma letto da disco. Ci sono sei diverse versioni di \func{exec} (per questo la si è chiamata -famiglia di funzioni) che possono essere usate per questo compito, che in -realtà (come mostrato in \figref{fig:proc_exec_relat}), costituiscono un -front-end a \func{execve}. Il prototipo di quest'ultima è: - +famiglia di funzioni) che possono essere usate per questo compito, in realtà +(come mostrato in \figref{fig:proc_exec_relat}), sono tutte un front-end a +\func{execve}. Il prototipo di quest'ultima è: \begin{prototype}{unistd.h} -{int execve(const char * filename, char * const argv [], char * const envp[])} +{int execve(const char *filename, char *const argv[], char *const envp[])} + Esegue il programma contenuto nel file \param{filename}. - La funzione esegue il file o lo script indicato da \var{filename}, - passandogli la lista di argomenti indicata da \var{argv} e come ambiente la - lista di stringhe indicata da \var{envp}; entrambe le liste devono essere - terminate da un puntatore nullo. I vettori degli argomenti e dell'ambiente - possono essere acceduti dal nuovo programma quando la sua funzione - \func{main} è dichiarata nella forma \func{main(int argc, char *argv[], char - *envp[])}. - - La funzione ritorna -1 solo in caso di errore, nel qual caso caso la - variabile \texttt{errno} è settata come: + \bodydesc{La funzione ritorna -1 solo in caso di errore, nel qual caso + caso la \var{errno} può assumere i valori: \begin{errlist} - \item \macro{EACCES} il file non è eseguibile, oppure il filesystem è + \item[\macro{EACCES}] il file non è eseguibile, oppure il filesystem è montato in \cmd{noexec}, oppure non è un file normale o un interprete. - \item \macro{EPERM} il file ha i bit \acr{suid} o \acr{sgid} ma l'utente non + \item[\macro{EPERM}] il file ha i bit \acr{suid} o \acr{sgid} ma l'utente non è root o il filesystem è montato con \cmd{nosuid}, oppure - \item \macro{ENOEXEC} il file è in un formato non eseguibile o non + \item[\macro{ENOEXEC}] il file è in un formato non eseguibile o non riconosciuto come tale, o compilato per un'altra architettura. - \item \macro{ENOENT} il file o una delle librerie dinamiche o l'inteprete + \item[\macro{ENOENT}] il file o una delle librerie dinamiche o l'interprete necessari per eseguirlo non esistono. - \item \macro{ETXTBSY} L'eseguibile è aperto in scrittura da uno o più + \item[\macro{ETXTBSY}] L'eseguibile è aperto in scrittura da uno o più processi. - \item \macro{EINVAL} L'eseguibile ELF ha più di un segmento - \macro{PF\_INTERP}, cioè chiede di essere eseguito da più di un interprete. - \item \macro{ELIBBAD} Un interprete ELF non è in un formato riconoscibile. + \item[\macro{EINVAL}] L'eseguibile ELF ha più di un segmento + \macro{PF\_INTERP}, cioè chiede di essere eseguito da più di un + interprete. + \item[\macro{ELIBBAD}] Un interprete ELF non è in un formato + riconoscibile. \end{errlist} ed inoltre anche \macro{EFAULT}, \macro{ENOMEM}, \macro{EIO}, \macro{ENAMETOOLONG}, \macro{E2BIG}, \macro{ELOOP}, \macro{ENOTDIR}, - \macro{ENFILE}, \macro{EMFILE}. + \macro{ENFILE}, \macro{EMFILE}.} \end{prototype} +La funzione \func{exec} esegue il file o lo script indicato da +\var{filename}, passandogli la lista di argomenti indicata da \var{argv} +e come ambiente la lista di stringhe indicata da \var{envp}; entrambe le +liste devono essere terminate da un puntatore nullo. I vettori degli +argomenti e dell'ambiente possono essere acceduti dal nuovo programma +quando la sua funzione \func{main} è dichiarata nella forma +\code{main(int argc, char *argv[], char *envp[])}. + Le altre funzioni della famiglia servono per fornire all'utente una serie possibile di diverse interfacce per la creazione di un nuovo processo. I loro prototipi sono: - \begin{functions} \headdecl{unistd.h} \funcdecl{int execl(const char *path, const char *arg, ...)} @@ -1038,9 +1092,9 @@ Sostituiscono l'immagine corrente del processo con quella indicata nel primo argomento. I parametri successivi consentono di specificare gli argomenti a linea di comando e l'ambiente ricevuti dal nuovo processo. -Queste funzioni ritornano solo in caso di errore, restituendo -1; nel qual -caso \var{errno} andrà ad assumere i valori visti in precedenza per -\func{execve}. +\bodydesc{Queste funzioni ritornano solo in caso di errore, restituendo + -1; nel qual caso \var{errno} andrà ad assumere i valori visti in + precedenza per \func{execve}.} \end{functions} Per capire meglio le differenze fra le funzioni della famiglia si può fare @@ -1049,7 +1103,7 @@ le modalit argomenti a linea di comando (cioè i valori di \var{argv} e \var{argc} visti dalla funzione \func{main} del programma chiamato). -Queste modalità sono due e sono riassunte dagli mnenonici \func{v} e \func{l} +Queste modalità sono due e sono riassunte dagli mnemonici \code{v} e \code{l} che stanno rispettivamente per \textit{vector} e \textit{list}. Nel primo caso gli argomenti sono passati tramite il vettore di puntatori \var{argv[]} a stringhe terminate con zero che costituiranno gli argomenti a riga di comando, @@ -1058,7 +1112,7 @@ questo vettore \emph{deve} essere terminato da un puntatore nullo. Nel secondo caso le stringhe degli argomenti sono passate alla funzione come lista di puntatori, nella forma: \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{} - char * arg0, char * arg1, ..., char * argn, NULL + char *arg0, char *arg1, ..., char *argn, NULL \end{lstlisting} che deve essere terminata da un puntatore nullo. In entrambi i casi vale la convenzione che il primo argomento (\var{arg0} o \var{argv[0]}) viene usato @@ -1092,7 +1146,7 @@ per indicare il nome del file che contiene il programma che verr \end{table} La seconda differenza fra le funzioni riguarda le modalità con cui si -specifica il programma che si vuole eseguire. Con lo mnemonico \func{p} si +specifica il programma che si vuole eseguire. Con lo mnemonico \code{p} si indicano le due funzioni che replicano il comportamento della shell nello specificare il comando da eseguire; quando il parametro \var{file} non contiene una \file{/} esso viene considerato come un nome di programma, e @@ -1110,14 +1164,13 @@ indicato dal parametro \var{path}, che viene interpretato come il \begin{figure}[htb] \centering - \includegraphics[width=13cm]{img/exec_rel.eps} - \caption{La inter-relazione fra le sei funzioni della famiglia \func{exec}} + \includegraphics[width=13cm]{img/exec_rel} + \caption{La interrelazione fra le sei funzioni della famiglia \func{exec}} \label{fig:proc_exec_relat} \end{figure} - La terza differenza è come viene passata la lista delle variabili di ambiente. -Con lo mnemonico \func{e} vengono indicate quelle funzioni che necessitano di +Con lo mnemonico \code{e} vengono indicate quelle funzioni che necessitano di un vettore di parametri \var{envp[]} analogo a quello usato per gli argomenti a riga di comando (terminato quindi da un \macro{NULL}), le altre usano il valore della variabile \var{environ} (vedi \secref{sec:proc_environ}) del @@ -1126,54 +1179,54 @@ processo di partenza per costruire l'ambiente. Oltre a mantenere lo stesso \acr{pid}, il nuovo programma fatto partire da \func{exec} assume anche una serie di altre proprietà del processo chiamante; la lista completa è la seguente: -\begin{itemize} -\item il \textit{process ID} (\acr{pid}) ed il \textit{parent process ID} +\begin{itemize*} +\item il \textit{process id} (\acr{pid}) ed il \textit{parent process id} (\acr{ppid}). -\item il \textit{real user ID} ed il \textit{real group ID} (vedi - \secref{sec:proc_user_group}). -\item i \textit{supplementary group ID} (vedi \secref{sec:proc_user_group}). -\item il \textit{session ID} ed il \textit{process group ID} (vedi +\item il \textit{real user id} ed il \textit{real group id} (vedi + \secref{sec:proc_access_id}). +\item i \textit{supplementary group id} (vedi \secref{sec:proc_access_id}). +\item il \textit{session id} ed il \textit{process group id} (vedi \secref{sec:sess_xxx}). \item il terminale di controllo (vedi \secref{sec:sess_xxx}). -\item il tempo restante ad un allarme. +\item il tempo restante ad un allarme (vedi \secref{sec:sig_xxx}). \item la directory radice e la directory di lavoro corrente (vedi \secref{sec:file_work_dir}). \item la maschera di creazione dei file (\var{umask}, vedi \secref{sec:file_umask}) ed i \textit{lock} sui file (vedi - \secref{sec:file_xxx}). + \secref{sec:file_locking}). \item i segnali sospesi (\textit{pending}) e la maschera dei segnali (si veda \secref{sec:sig_xxx}). -\item i limiti sulle risorse (vedi \secref{sec:limits_xxx}).. +\item i limiti sulle risorse (vedi \secref{sec:sys_limits}). \item i valori delle variabili \var{tms\_utime}, \var{tms\_stime}, - \var{tms\_cutime}, \var{tms\_ustime} (vedi \secref{sec:xxx_xxx}).. -\end{itemize} + \var{tms\_cutime}, \var{tms\_ustime} (vedi \secref{sec:xxx_xxx}). +\end{itemize*} Oltre a questo i segnali che sono stati settati per essere ignorati nel -processo chiamante mantengono lo stesso settaggio pure nuovo programma, tutti -gli altri segnali vengono settati alla loro azione di default. Un caso -speciale è il segnale \macro{SIGCHLD} che, quando settato a \macro{SIG\_IGN} -può anche non essere resettatto a \macro{SIG\_DFL} (si veda +processo chiamante mantengono lo stesso settaggio pure nel nuovo programma, +tutti gli altri segnali vengono settati alla loro azione di default. Un caso +speciale è il segnale \macro{SIGCHLD} che, quando settato a \macro{SIG\_IGN}, +può anche non essere resettato a \macro{SIG\_DFL} (si veda \secref{sec:sig_xxx}). La gestione dei file aperti dipende dal valore del flag di \textit{close-on-exec} per ciascun file descriptor (si veda -\secref{sec:file_xxx}); i file per cui è settato vengono chiusi, tutti gli +\secref{sec:file_fcntl}); i file per cui è settato vengono chiusi, tutti gli altri file restano aperti. Questo significa che il comportamento di default è che i file restano aperti attraverso una \func{exec}, a meno di una chiamata esplicita a \func{fcntl} che setti il suddetto flag. Per le directory lo standard POSIX.1 richiede che esse vengano chiuse attraverso una \func{exec}, in genere questo è fatto dalla funzione -\func{opendir} che effettua da sola il settaggio del flag di -\textit{close-on-exec} sulle directory che apre, in maniera trasparente -all'utente. +\func{opendir} (vedi \secref{sec:file_dir_read}) che effettua da sola il +settaggio del flag di \textit{close-on-exec} sulle directory che apre, in +maniera trasparente all'utente. -Abbiamo detto che il \textit{real user ID} ed il \textit{real group ID} +Abbiamo detto che il \textit{real user id} ed il \textit{real group id} restano gli stessi all'esecuzione di \func{exec}; lo stesso vale per -l'\textit{effective user ID} ed l'\textit{effective group ID}, tranne il caso +l'\textit{effective user id} ed l'\textit{effective group id}, tranne il caso in cui il file che si va ad eseguire ha o il \acr{suid} bit o lo \acr{sgid} -bit settato, nel qual caso \textit{effective user ID} e \textit{effective - group ID} vengono settati rispettivamente all'utente o al gruppo cui il file +bit settato, nel qual caso \textit{effective user id} e \textit{effective + group id} vengono settati rispettivamente all'utente o al gruppo cui il file appartiene (per i dettagli vedi \secref{sec:proc_perms}). Se il file da eseguire è in formato \emph{a.out} e necessita di librerie @@ -1186,13 +1239,13 @@ in genere questo \emph{glibc}. Infine nel caso il file sia uno script esso deve iniziare con una linea nella forma \cmd{\#!/path/to/interpreter} dove l'interprete indicato deve esse un valido programma (binario, non un altro script) che verrà -chiamato come se si fosse eseguitio il comando \cmd{interpreter [arg] +chiamato come se si fosse eseguito il comando \cmd{interpreter [arg] filename}. Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è -basato il controllo dei processi in unix: con \func{fork} si crea un nuovo +basata la gestione dei processi in Unix: con \func{fork} si crea un nuovo processo, con \func{exec} si avvia un nuovo programma, con \func{exit} e -\func{wait} si effettua e si gestisce la conclusione dei programmi. Tutte le +\func{wait} si effettua e verifica la conclusione dei programmi. Tutte le altre funzioni sono ausiliarie e servono la lettura e il settaggio dei vari parametri connessi ai processi. @@ -1202,103 +1255,707 @@ parametri connessi ai processi. \label{sec:proc_perms} In questa sezione esamineremo le problematiche relative al controllo di -accesso dal punto di vista del processi; gli identificativi usati, come questi -vengono modificati nella creazione e nel lancio di nuovi processi, e le varie -funzioni per la loro manipolazione diretta. - - -\subsection{Utente e gruppo di un processo} -\label{sec:proc_user_group} - -Abbiamo già accennato in \secref{sec:intro_multiuser} che ad ogni utente e -gruppo sono associati due identificatori univoci, lo \acr{uid} e il \acr{gid} -che li contraddistinguono nei confronti del kernel. Questi identificatori -stanno alla base del sistema di permessi e protezioni di un sistema unix, e -oltre che per il controllo di accesso ai file vengono usati anche nella -gestione dei privilegi di accesso dei processi. - -In realtà ad ogni processo è associato un certo numero di identificatori, il -cui elenco è riportato \ntab, in genere questi derivano direttamente -dall'utente che ha lanciato il processo (attraverso i valori di \acr{uid} e -\acr{gid}), e vengono usati sia per il controllo di accesso ai file che per la -gestione dei privilegi associati ai processi stessi. +accesso dal punto di vista del processi; vedremo quali sono gli identificatori +usati, come questi possono essere modificati nella creazione e nel lancio di +nuovi processi, e le varie funzioni per la loro manipolazione diretta e tutte +le problematiche connesse ad una gestione accorta dei privilegi. + + +\subsection{Gli identificatori del controllo di accesso} +\label{sec:proc_access_id} + +Come accennato in \secref{sec:intro_multiuser} il modello base\footnote{in + realtà già esistono estensioni di questo modello base, che lo rendono più + flessibile e controllabile, come le \textit{capabilities}, le ACL per i file + o il \textit{Mandatory Access Control} di SELinux} di sicurezza di un +sistema unix-like è fondato sui concetti di utente e gruppo, e sulla +separazione fra l'amministratore (\textsl{root}, detto spesso anche +\textit{superuser}) che non è sottoposto a restrizioni, ed il resto degli +utenti, per i quali invece vengono effettuati i vari controlli di accesso. + +%Benché il sistema sia piuttosto semplice (è basato su un solo livello di +% separazione) il sistema permette una +%notevole flessibilità, + +Abbiamo già accennato come il sistema associ ad ogni utente e gruppo due +identificatori univoci, lo \acr{uid} e il \acr{gid}; questi servono al kernel +per identificare uno specifico utente o un gruppo di utenti, per poi poter +controllare che essi siano autorizzati a compiere le operazioni richieste. Ad +esempio in \secref{sec:file_access_control} vedremo come ad ogni file vengano +associati un utente ed un gruppo (i suoi \textsl{proprietari}, indicati +appunto tramite un \acr{uid} ed un \acr{gid}) che vengono controllati dal +kernel nella gestione dei permessi di accesso. + +Dato che tutte le operazioni del sistema vengono compiute dai processi, è +evidente che per poter implementare un controllo sulle operazioni occorre +anche poter identificare chi è che ha lanciato un certo programma, e pertanto +anche a ciascun processo è associato un utente e a un gruppo. + +Un semplice controllo di una corrispondenza fra identificativi però non +garantisce però sufficiente flessibilità per tutti quei casi in cui è +necessario poter disporre di privilegi diversi, o dover impersonare un altro +utente per un limitato insieme di operazioni. Per questo motivo in generale +tutti gli Unix prevedono che i processi abbiano almeno due gruppi di +identificatori, chiamati rispettivamente \textit{real} ed \textit{effective}. + \begin{table}[htb] \footnotesize \centering - \begin{tabular}[c]{|c|l|p{8cm}|} + \begin{tabular}[c]{|c|l|p{6.5cm}|} \hline - \textbf{Sigla} & \textbf{Significato} & \textbf{Utilizzo} \\ + \textbf{Suffisso} & \textbf{Significato} & \textbf{Utilizzo} \\ \hline \hline - \acr{ruid} & \textit{real user id} & indica l'utente reale che ha lanciato + \acr{uid} & \textit{real user id} & indica l'utente che ha lanciato il programma\\ - \acr{rgid} & \textit{real group id} & indica il gruppo reale dell'utente + \acr{gid} & \textit{real group id} & indica il gruppo dell'utente che ha lanciato il programma \\ - \acr{euid} & \textit{effective user id} & indica l'utente effettivo usato - dal programma \\ - \acr{egid} & \textit{effective group id} & indica il gruppo effettivo usato - dal programma \\ - & \textit{supplementary group id} & indica i gruppi cui + \hline + \acr{euid} & \textit{effective user id} & indica l'utente usato + dal programma nel controllo di accesso \\ + \acr{egid} & \textit{effective group id} & indica il gruppo + usato dal programma nel controllo di accesso \\ + -- & \textit{supplementary group id} & indica i gruppi cui l'utente appartiene \\ - \acr{suid} & \textit{saved user id} & indica l'utente \\ - \acr{sgid} & \textit{daved group id} & indica il gruppo \\ + \hline + -- & \textit{saved user id} & copia dell'\acr{euid} iniziale\\ + -- & \textit{saved group id} & copia dell'\acr{egid} iniziale \\ + \hline \acr{fsuid} & \textit{filesystem user id} & indica l'utente effettivo per il filesystem \\ \acr{fsgid} & \textit{filesystem group id} & indica il gruppo effettivo per il filesystem \\ \hline \end{tabular} - \caption{Identificatori di utente e gruppo associati a ciascun processo.} + \caption{Identificatori di utente e gruppo associati a ciascun processo con + indicazione dei suffissi usate dalle varie funzioni di manipolazione.} \label{tab:proc_uid_gid} \end{table} -Il \textit{real user id} e il \textit{real group id} indicano l'utente che ha -lanciato il processo, e vengono settati al login al valore standard di -\acr{uid} e \acr{gid} dell'utente letti direttamente da \file{/etc/passwd}. - -Esso servono ad identificare l'utente che ha lanciato il processo e non -vengono mai cambiati nella creazione di nuovi processi restando sempre gli -stessi per tutti i processi avviati in una sessione. In realtà vedremo che è -possibile possibile modificarli (in \secref{sec:proc_setuid}), ma solo ad un -processo che abbia i privilegi di amministratore; questa possibilità è usata -ad esempio da \cmd{login} che una volta completata la procedura di -autenticazione lancia una shell per la quale setta questi indetificatoru ai -valori corrispondenti all'utente che entra nel sistema. - -L'\textit{effective user id}, l'\textit{effective group id} e gli eventuali -\textit{supplementary group id} sono invece gli identificatori usati per il -controllo di accesso ai file (secondo quanto descritto in dettaglio in -\secref{sec:file_perm_overview}). Normalmente essi sono uguali al \textit{real - user id} e al \textit{real group id}, a meno che il file posto in esecuzione -non abbia o il bit \acr{suid} o il bit \acr{sgid} settato, in questo caso alla -la funzione \func{exec} (vedi \secref{}) li setta rispettivamente ai valori -dell'\acr{uid} e del \acr{gid} cui appartiene il file. +Al primo gruppo appartengono il \textit{real user id} e il \textit{real group + id}: questi vengono settati al login ai valori corrispondenti all'utente con +cui si accede al sistema (e relativo gruppo di default). Servono per +l'identificazione dell'utente e normalmente non vengono mai cambiati. In +realtà vedremo (in \secref{sec:proc_setuid}) che è possibile modificarli, ma +solo ad un processo che abbia i privilegi di amministratore; questa +possibilità è usata ad esempio da \cmd{login} che una volta completata la +procedura di autenticazione lancia una shell per la quale setta questi +identificatori ai valori corrispondenti all'utente che entra nel sistema. + +Al secondo gruppo appartengono l'\textit{effective user id} e +l'\textit{effective group id} (a cui si aggiungono gli eventuali +\textit{supplementary group id} dei gruppi dei quale l'utente fa parte). +Questi sono invece gli identificatori usati nella verifiche dei permessi del +processo e per il controllo di accesso ai file (argomento affrontato in +dettaglio in \secref{sec:file_perm_overview}). + +Questi identificatori normalmente sono identici ai corrispondenti del gruppo +\textsl{reale} tranne nel caso in cui, come accennato in +\secref{sec:proc_exec}, il programma che si è posto in esecuzione abbia i bit +\acr{suid} o \acr{sgid} settati (il significato di questi bit è affrontato in +dettaglio in \secref{sec:file_suid_sgid}). In questo caso essi saranno settati +all'utente e al gruppo proprietari del file; questo consente, per programmi in +cui ci sia necessità, di dare a qualunque utente normale privilegi o permessi +di un'altro (o dell'amministratore). + +Come nel caso del \acr{pid} e del \acr{ppid} tutti questi identificatori +possono essere letti dal processo attraverso delle opportune funzioni, i cui +prototipi sono i seguenti: +\begin{functions} + \headdecl{unistd.h} + \headdecl{sys/types.h} + \funcdecl{uid\_t getuid(void)} Restituisce il \textit{real user id} del + processo corrente. + + \funcdecl{uid\_t geteuid(void)} Restituisce l'\textit{effective user id} del + processo corrente. + + \funcdecl{gid\_t getgid(void)} Restituisce il \textit{real group id} del + processo corrente. + + \funcdecl{gid\_t getegid(void)} Restituisce l'\textit{effective group id} del + processo corrente. + + \bodydesc{Queste funzioni non riportano condizioni di errore.} +\end{functions} + +In generale l'uso di privilegi superiori deve essere limitato il più +possibile, per evitare abusi e problemi di sicurezza, per questo occorre anche +un meccanismo che consenta ad un programma di rilasciare gli eventuali +maggiori privilegi necessari, una volta che si siano effettuate le operazioni +per i quali erano richiesti, e a poterli eventualmente recuperare in caso +servano di nuovo. + +Questo in Linux viene fatto usando altri due gruppi di identificatori, il +\textit{saved} ed il \textit{filesystem}, analoghi ai precedenti. Il primo +gruppo è lo stesso usato in SVr4, e previsto dallo standard POSIX quando è +definita la costante \macro{\_POSIX\_SAVED\_IDS}\footnote{in caso si abbia a + cuore la portabilità del programma su altri Unix è buona norma controllare + sempre la disponibilità di queste funzioni controllando se questa costante è + definita}, il secondo gruppo è specifico di Linux e viene usato per +migliorare la sicurezza con NFS. Il \textit{saved user id} e il \textit{saved group id} sono copie dell'\textit{effective user id} e dell'\textit{effective group id} del processo padre, e vengono settati dalla funzione \func{exec} all'avvio del -processo, prima che \textit{effective user id} e \textit{effective group id} -vengano modificati per tener conto di eventuali \acr{suid} o \acr{sgid}, essi -quindi consentono di tenere traccia di quale fossero l'utente originale. +processo, come copie dell'\textit{effective user id} e dell'\textit{effective + group id} dopo che questo sono stati settati tenendo conto di eventuali +\acr{suid} o \acr{sgid}. Essi quindi consentono di tenere traccia di quale +fossero utente e gruppo effettivi all'inizio dell'esecuzione di un nuovo +programma. + +Il \textit{filesystem user id} e il \textit{filesystem group id} sono una +estensione introdotta in Linux per rendere più sicuro l'uso di NFS (torneremo +sull'argomento in \secref{sec:proc_setfsuid}). Essi sono una replica dei +corrispondenti \textit{effective id}, ai quali si sostituiscono per tutte le +operazioni di verifica dei permessi relativi ai file (trattate in +\secref{sec:file_perm_overview}). Ogni cambiamento effettuato sugli +\textit{effective id} viene automaticamente riportato su di essi, per cui in +condizioni normali se ne può tranquillamente ignorare l'esistenza, in quanto +saranno del tutto equivalenti ai precedenti. + +Uno specchietto riassuntivo, contenente l'elenco completo degli identificatori +di utente e gruppo associati dal kernel ad ogni processo, è riportato in +\tabref{tab:proc_uid_gid}. + + +\subsection{Le funzioni \func{setuid} e \func{setgid}} +\label{sec:proc_setuid} +Le due funzioni che vengono usate per cambiare identità (cioè utente e gruppo +di appartenenza) ad un processo sono rispettivamente \func{setuid} e +\func{setgid}; come accennato in \secref{sec:proc_access_id} in Linux esse +seguono la semantica POSIX che prevede l'esistenza del \textit{saved user id} +e del \textit{saved group id}; i loro prototipi sono: +\begin{functions} +\headdecl{unistd.h} +\headdecl{sys/types.h} -\subsection{Le funzioni \texttt{setuid} e \texttt{setgid}} -\label{sec:proc_setuid} +\funcdecl{int setuid(uid\_t uid)} Setta l'\textit{user id} del processo +corrente. + +\funcdecl{int setgid(gid\_t gid)} Setta il \textit{group id} del processo +corrente. +\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso + di fallimento: l'unico errore possibile è \macro{EPERM}.} +\end{functions} + +Il funzionamento di queste due funzioni è analogo, per cui considereremo solo +la prima; la seconda si comporta esattamente allo stesso modo facendo +riferimento al \textit{group id} invece che all'\textit{user id}. Gli +eventuali \textit{supplementary group id} non vengono modificati da nessuna +delle funzioni che tratteremo in questa sezione. + + +L'effetto della chiamata è diverso a seconda dei privilegi del processo; se +l'\textit{effective user id} è zero (cioè è quello dell'amministratore di +sistema) allora tutti gli identificatori (\textit{real}, \textit{effective} +e \textit{saved}) vengono settati al valore specificato da \var{uid}, +altrimenti viene settato solo l'\textit{effective user id}, e soltanto se il +valore specificato corrisponde o al \textit{real user id} o al \textit{saved + user id}. Negli altri casi viene segnalato un errore (con \macro{EPERM}). + +Come accennato l'uso principale di queste funzioni è quello di poter +consentire ad un programma con i bit \acr{suid} o \acr{sgid} settati di +riportare l'\textit{effective user id} a quello dell'utente che ha lanciato il +programma, effettuare il lavoro che non necessita di privilegi aggiuntivi, ed +eventualmente tornare indietro. + +Come esempio per chiarire dell'uso di queste funzioni prediamo quello con cui +viene gestito l'accesso al file \file{/var/log/utmp}. In questo file viene +registrato chi sta usando il sistema al momento corrente; chiaramente non può +essere lasciato aperto in scrittura a qualunque utente, che potrebbe +falsificare la registrazione. Per questo motivo questo file (e l'analogo +\file{/var/log/wtmp} su cui vengono registrati login e logout) appartengono ad +un gruppo dedicato (\acr{utmp}) ed i programmi che devono accedervi (ad +esempio tutti i programmi di terminale in X, o il programma \cmd{screen} +che crea terminali multipli su una console) appartengono a questo gruppo ed +hanno il bit \acr{sgid} settato. + +Quando uno di questi programmi (ad esempio \cmd{xterm}) viene lanciato la +situazione degli identificatori è la seguente: +\begin{eqnarray*} + \label{eq:1} + \textit{real group id} &=& \textrm{\acr{gid} (del chiamante)} \\ + \textit{effective group id} &=& \textrm{\acr{utmp}} \\ + \textit{saved group id} &=& \textrm{\acr{utmp}} +\end{eqnarray*} +in questo modo, dato che l'\textit{effective group id} è quello giusto, il +programma può accedere a \file{/var/log/utmp} in scrittura ed aggiornarlo, a +questo punto il programma può eseguire una \code{setgid(getgid())} per settare +l'\textit{effective group id} a quello dell'utente (e dato che il \textit{real + group id} corrisponde la funzione avrà successo), in questo modo non sarà +possibile lanciare dal terminale programmi che modificano detto file, in tal +caso infatti la situazione degli identificatori sarebbe: +\begin{eqnarray*} + \label{eq:2} + \textit{real group id} &=& \textrm{\acr{gid} (invariato)} \\ + \textit{effective group id} &=& \textrm{\acr{gid}} \\ + \textit{saved group id} &=& \textrm{\acr{utmp} (invariato)} +\end{eqnarray*} +e ogni processo lanciato dal terminale avrebbe comunque \acr{gid} come +\textit{effective group id}. All'uscita dal terminale, per poter di nuovo +aggiornare lo stato di \file{/var/log/utmp} il programma eseguirà una +\code{setgid(utmp)} (dove \var{utmp} è il valore numerico associato al gruppo +\acr{utmp}, ottenuto ad esempio con una \func{getegid}), dato che in questo +caso il valore richiesto corrisponde al \textit{saved group id} la funzione +avrà successo e riporterà la situazione a: +\begin{eqnarray*} + \label{eq:3} + \textit{real group id} &=& \textrm{\acr{gid} (invariato)} \\ + \textit{effective group id} &=& \textrm{\acr{utmp}} \\ + \textit{saved group id} &=& \textrm{\acr{utmp} (invariato)} +\end{eqnarray*} +consentendo l'accesso a \file{/var/log/utmp}. + +Occorre però tenere conto che tutto questo non è possibile con un processo con +i privilegi di root, in tal caso infatti l'esecuzione una \func{setuid} +comporta il cambiamento di tutti gli identificatori associati al processo, +rendendo impossibile riguadagnare i privilegi di amministratore. Questo +comportamento è corretto per l'uso che ne fa \cmd{login} una volta che crea +una nuova shell per l'utente; ma quando si vuole cambiare soltanto +l'\textit{effective user id} del processo per cedere i privilegi occorre +ricorrere ad altre funzioni (si veda ad esempio \secref{sec:proc_seteuid}). + + +\subsection{Le funzioni \func{setreuid} e \func{setresuid}} +\label{sec:proc_setreuid} + +Queste due funzioni derivano da BSD che, non supportando\footnote{almeno fino + alla versione 4.3+BSD TODO, verificare e aggiornare la nota.} i +\textit{saved id}, le usava per poter scambiare fra di loro \textit{effective} +e \textit{real id}. I loro prototipi sono: +\begin{functions} +\headdecl{unistd.h} +\headdecl{sys/types.h} + +\funcdecl{int setreuid(uid\_t ruid, uid\_t euid)} Setta il \textit{real user + id} e l'\textit{effective user id} del processo corrente ai valori +specificati da \var{ruid} e \var{euid}. + +\funcdecl{int setregid(gid\_t rgid, gid\_t egid)} Setta il \textit{real group + id} e l'\textit{effective group id} del processo corrente ai valori +specificati da \var{rgid} e \var{egid}. + +\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso + di fallimento: l'unico errore possibile è \macro{EPERM}.} +\end{functions} -\subsection{Le funzioni \texttt{seteuid} e \texttt{setegid}} +I processi non privilegiati possono settare i \textit{real id} soltanto ai +valori dei loro \textit{effective id} o \textit{real id} e gli +\textit{effective id} ai valori dei loro \textit{real id}, \textit{effective + id} o \textit{saved id}; valori diversi comportano il fallimento della +chiamata; l'amministratore invece può specificare un valore qualunque. +Specificando un valore di -1 l'identificatore corrispondente viene lasciato +inalterato. + +Con queste funzione si possono scambiare fra loro \textit{real id} e +\textit{effective id}, e pertanto è possibile implementare un comportamento +simile a quello visto in precedenza per \func{setgid}, cedendo i privilegi con +un primo scambio, e recuperandoli, eseguito il lavoro non privilegiato, con un +secondo scambio. + +In questo caso però occorre porre molta attenzione quando si creano nuovi +processi nella fase intermedia in cui si sono scambiati gli identificatori, in +questo caso infatti essi avranno un \textit{real id} privilegiato, che dovrà +essere esplicitamente eliminato prima di porre in esecuzione un nuovo +programma (occorrerà cioè eseguire un'altra chiamata dopo la \func{fork}, e +prima della \func{exec} per uniformare i \textit{real id} agli +\textit{effective id}) in caso contrario quest'ultimo potrebbe a sua volta +effettuare uno scambio e riottenere privilegi non previsti. + +Lo stesso problema di propagazione dei privilegi ad eventuali processi figli +si porrebbe per i \textit{saved id}: queste funzioni derivano da +un'implementazione che non ne prevede la presenza, e quindi non è possibile +usarle per correggere la situazione come nel caso precedente. Per questo +motivo in Linux tutte le volte che vengono usata per modificare uno degli +identificatori ad un valore diverso dal \textit{real id} precedente, il +\textit{saved id} viene sempre settato al valore dell'\textit{effective id}. + + + +\subsection{Le funzioni \func{seteuid} e \func{setegid}} \label{sec:proc_seteuid} +Queste funzioni sono un'estensione allo standard POSIX.1 (ma sono comunque +supportate dalla maggior parte degli Unix) e usate per cambiare gli +\textit{effective id}; i loro prototipi sono: +\begin{functions} +\headdecl{unistd.h} +\headdecl{sys/types.h} -\subsection{Le \textit{race condition}} -\label{sec:proc_race_cond} +\funcdecl{int seteuid(uid\_t uid)} Setta l'\textit{effective user id} del +processo corrente a \var{uid}. + +\funcdecl{int setegid(gid\_t gid)} Setta l'\textit{effective group id} del +processo corrente a \var{gid}. + +\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso + di fallimento: l'unico errore possibile è \macro{EPERM}.} +\end{functions} + +Gli utenti normali possono settare l'\textit{effective id} solo al valore del +\textit{real id} o del \textit{saved id}, l'amministratore può specificare +qualunque valore. Queste funzioni sono usate per permettere a root di settare +solo l'\textit{effective id}, dato che l'uso normale di \func{setuid} comporta +il settaggio di tutti gli identificatori. + + +\subsection{Le funzioni \func{setresuid} e \func{setresgid}} +\label{sec:proc_setresuid} + +Queste due funzioni sono una estensione introdotta in Linux dal kernel 2.1.44, +e permettono un completo controllo su tutti gli identificatori (\textit{real}, +\textit{effective} e \textit{saved}), i prototipi sono: +\begin{functions} +\headdecl{unistd.h} +\headdecl{sys/types.h} + +\funcdecl{int setresuid(uid\_t ruid, uid\_t euid, uid\_t suid)} Setta il +\textit{real user id}, l'\textit{effective user id} e il \textit{saved user + id} del processo corrente ai valori specificati rispettivamente da +\var{ruid}, \var{euid} e \var{suid}. + +\funcdecl{int setresgid(gid\_t rgid, gid\_t egid, gid\_t sgid)} Setta il +\textit{real group id}, l'\textit{effective group id} e il \textit{saved group + id} del processo corrente ai valori specificati rispettivamente da +\var{rgid}, \var{egid} e \var{sgid}. + +\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso + di fallimento: l'unico errore possibile è \macro{EPERM}.} +\end{functions} + +I processi non privilegiati possono cambiare uno qualunque degli +identificatori usando uno qualunque dei valori correnti di \textit{real id}, +\textit{effective id} o \textit{saved id}, l'amministratore può specificare i +valori che vuole; un valore di -1 per un qualunque parametro lascia inalterato +l'identificatore corrispondente. + +Per queste funzioni esistono anche due controparti che permettono di leggere +in blocco i vari identificatori: \func{getresuid} e \func{getresgid}; i loro +prototipi sono: +\begin{functions} +\headdecl{unistd.h} +\headdecl{sys/types.h} + +\funcdecl{int getresuid(uid\_t *ruid, uid\_t *euid, uid\_t *suid)} Legge il +\textit{real user id}, l'\textit{effective user id} e il \textit{saved user + id} del processo corrente. + +\funcdecl{int getresgid(gid\_t *rgid, gid\_t *egid, gid\_t *sgid)} Legge il +\textit{real group id}, l'\textit{effective group id} e il \textit{saved group + id} del processo corrente. + +\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso di + fallimento: l'unico errore possibile è \macro{EFAULT} se gli indirizzi delle + variabili di ritorno non sono validi.} +\end{functions} + +Anche queste funzioni sono una estensione specifica di Linux, e non richiedono +nessun privilegio. I valori sono restituiti negli argomenti, che vanno +specificati come puntatori (è un'altro esempio di \textit{value result + argument}). Si noti che queste funzioni sono le uniche in grado di leggere i +\textit{saved id}. + + +\subsection{Le funzioni \func{setfsuid} e \func{setfsgid}} +\label{sec:proc_setfsuid} + +Queste funzioni sono usate per settare gli identificatori usati da Linux per +il controllo dell'accesso ai file. Come già accennato in +\secref{sec:proc_access_id} in Linux è definito questo ulteriore gruppo di +identificatori, che di norma sono assolutamente equivalenti agli +\textit{effective id}, dato che ogni cambiamento di questi ultimi viene +immediatamente riportato sui \textit{filesystem id}. + +C'è un solo caso in cui si ha necessità di introdurre una differenza fra +\textit{effective id} e \textit{filesystem id}, ed è per ovviare ad un +problema di sicurezza che si presenta quando si deve implementare un server +NFS. Il server NFS infatti deve poter cambiare l'identificatore con cui accede +ai file per assumere l'identità del singolo utente remoto, ma se questo viene +fatto cambiando l'\textit{effective id} o il \textit{real id} il server si +espone alla ricezione di eventuali segnali ostili da parte dell'utente di cui +ha temporaneamente assunto l'identità. Cambiando solo il \textit{filesystem + id} si ottengono i privilegi necessari per accedere ai file, mantenendo +quelli originari per quanto riguarda tutti gli altri controlli di accesso, +così che l'utente non possa inviare segnali al server NFS. + +Le due funzioni usate per cambiare questi identificatori sono \func{setfsuid} +e \func{setfsgid}, ovviamente sono specifiche di Linux e non devono essere +usate se si intendono scrivere programmi portabili; i loro prototipi sono: +\begin{functions} +\headdecl{sys/fsuid.h} + +\funcdecl{int setfsuid(uid\_t fsuid)} Setta il \textit{filesystem user id} del +processo corrente a \var{fsuid}. + +\funcdecl{int setfsgid(gid\_t fsgid)} Setta l'\textit{filesystem group id} del +processo corrente a \var{fsgid}. + +\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso + di fallimento: l'unico errore possibile è \macro{EPERM}.} +\end{functions} +\noindent queste funzioni hanno successo solo se il processo chiamante ha i +privilegi di amministratore o, per gli altri utenti, se il valore specificato +coincide con uno dei \textit{real}, \textit{effective} o \textit{saved id}. + + +\subsection{Le funzioni \func{setgroups} e \func{getgroups}} +\label{sec:proc_setgroups} + +Le ultime funzioni che esamineremo sono quelle sono quelle che permettono di +operare sui gruppi supplementari. Ogni processo può avere fino a +\macro{NGROUPS\_MAX} gruppi supplementari in aggiunta al gruppo primario, +questi vengono ereditati dal processo padre e possono essere cambiati con +queste funzioni. + +La funzione che permette di leggere i gruppi supplementari è \func{getgroups}; +questa funzione è definita nello standard POSIX ed il suo prototipo è: +\begin{functions} + \headdecl{sys/types.h} + \headdecl{unistd.h} + + \funcdecl{int getgroups(int size, gid\_t list[])} Legge gli identificatori + dei gruppi supplementari del processo sul vettore \param{list} di dimensione + \param{size}. + + \bodydesc{La funzione restituisce il numero di gruppi letti in caso di + successo e -1 in caso di fallimento, nel qual caso \var{errno} viene + settata a: + \begin{errlist} + \item[\macro{EFAULT}] \param{list} non ha un indirizzo valido. + \item[\macro{EINVAL}] il valore di \param{size} è diverso da zero ma + minore del numero di gruppi supplementari del processo. + \end{errlist}} +\end{functions} +\noindent non è specificato se la funzione inserisca o meno nella lista +l'\textit{effective user id} del processo. Se si specifica un valore di +\param{size} uguale a 0 \param{list} non viene modificato, ma si ottiene il +numero di gruppi supplementari. + +Una seconda funzione, \func{getgrouplist}, può invece essere usata per +ottenere tutti i gruppi a cui appartiene un utente; il suo prototipo è: +\begin{functions} + \headdecl{sys/types.h} + \headdecl{grp.h} + + \funcdecl{int getgrouplist(const char *user, gid\_t group, gid\_t *groups, + int *ngroups)} Legge i gruppi supplementari dell'utente \param{user}. + + \bodydesc{La funzione legge fino ad un massimo di \param{ngroups} valori, + restituisce 0 in caso di successo e -1 in caso di fallimento.} +\end{functions} +\noindent la funzione esegue una scansione del database dei gruppi (si veda +\secref{sec:sys_xxx}) e ritorna in \param{groups} la lista di quelli a cui +l'utente appartiene. Si noti che \param{ngroups} è passato come puntatore +perché qualora il valore specificato sia troppo piccolo la funzione ritorna -1 +e passando indietro il numero dei gruppi trovati. + +Per settare i gruppi supplementari di un processo ci sono due funzioni, che +possono essere usate solo se si hanno i privilegi di amministratore. La prima +delle due è \func{setgroups}, ed il suo prototipo è: +\begin{functions} + \headdecl{sys/types.h} + \headdecl{grp.h} + + \funcdecl{int setgroups(size\_t size, gid\_t *list)} Setta i gruppi + supplementari del processo ai valori specificati in \param{list}. + + \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di + fallimento, nel qual caso \var{errno} viene settata a: + \begin{errlist} + \item[\macro{EFAULT}] \param{list} non ha un indirizzo valido. + \item[\macro{EPERM}] il processo non ha i privilegi di amministratore. + \item[\macro{EINVAL}] il valore di \param{size} è maggiore del valore + massimo (\macro{NGROUPS}, che per Linux è 32). + \end{errlist}} +\end{functions} + +Se invece si vogliono settare i gruppi supplementari del processo a quelli di +un utente specifico si può usare \func{initgroups} il cui prototipo è: +\begin{functions} + \headdecl{sys/types.h} + \headdecl{grp.h} + + \funcdecl{int initgroups(const char *user, gid\_t group)} Setta i gruppi + supplementari del processo a quelli di cui è membro l'utente \param{user}, + aggiungendo il gruppo addizionale \param{group}. + + \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di + fallimento, nel qual caso \var{errno} viene settata agli stessi valori di + \func{setgroups} più \macro{ENOMEM} quando non c'è memoria sufficiente per + allocare lo spazio per informazioni dei gruppi.} +\end{functions} -Si definisce una \textit{race condition} il caso in cui diversi processi -stanno cercando di fare qualcosa con una risorsa comune ed il risultato finale -viene a dipendere dall'ordine di esecuzione dei medesimi. Ovviamente dato che -l'ordine di esecuzione di un processo, senza appositi meccanismi di -sincronizzazione, non è assolutamente prevedibile, queste situazioni sono -fonti di errori molto subdoli, che possono verificarsi solo in condizioni -particolari e quindi difficilmente riproducibili. +La funzione esegue la scansione del database dei gruppi (usualmente +\file{/etc/groups}) cercando i gruppi di cui è membro \param{user} costruendo +una lista di gruppi supplementari a cui aggiunge \param{group}, che poi setta +usando \func{setgroups}. +Si tenga presente che sia \func{setgroups} che \func{initgroups} non sono +definite nello standard POSIX.1 e che pertanto non è possibile utilizzarle +quando si definisce \macro{\_POSIX\_SOURCE} o si compila con il flag +\cmd{-ansi}. + + +\section{La gestione della priorità di esecuzione} +\label{sec:proc_priority} + +In questa sezione tratteremo più approfonditamente i meccanismi con il quale +lo \textit{scheduler} assegna la CPU ai vari processi attivi, illustrando le +varie funzioni che permettono di leggere e modificare le priorità di +esecuzione dei programmi. + + + + + +\section{Problematiche di programmazione multitasking} +\label{sec:proc_multi_prog} + +Benché i processi siano strutturati in modo da apparire il più possibile come +indipendenti l'uno dall'altro, nella programmazione in un sistema multitasking +occorre tenere conto di una serie di problematiche che normalmente non +esistono quando si ha a che fare con un sistema in cui viene eseguito un solo +programma alla volta. + +Pur essendo questo argomento di carattere generale, in questa sezione +conclusiva del capitolo in cui abbiamo affrontato la gestione dei processi ci +è parso opportuno introdurre sinteticamente queste problematiche, che +ritroveremo a più riprese in capitoli successivi, dando una breve descrizione +delle loro caratteristiche principali e della terminologia relativa. + + +\subsection{Le operazioni atomiche} +\label{sec:proc_atom_oper} + +La nozione di \textsl{operazione atomica} deriva dal significato greco della +parola atomo, cioè indivisibile; si dice infatti che una operazione è atomica +quando si ha la certezza che, qualora essa venga effettuata, tutti i passaggi +che devono essere compiuti per realizzarla verranno eseguiti senza possibilità +di interruzione in una fase intermedia. + +In un ambiente multitasking il concetto è essenziale, dato che un processo può +essere interrotto in qualunque momento dal kernel che mette in esecuzione un +altro processo o dalla ricezione di un segnale; occorre pertanto essere +accorti nei confronti delle possibili \textit{race condition} (vedi +\secref{sec:proc_race_cond}) derivanti da operazioni interrotte in una fase in +cui non erano ancora state completate. + +Nel caso dell'interazione fra processi la situazione è molto più semplice, ed +occorre preoccuparsi della atomicità delle operazioni solo quando si ha a che +fare con meccanismi di intercomunicazione (che esamineremo in dettaglio in +\capref{cha:IPC}) o nella operazioni con i file (vedremo alcuni esempi in +\secref{sec:file_atomic}). In questi casi in genere l'uso delle appropriate +funzioni di libreria per compiere le operazioni necessarie è garanzia +sufficiente di atomicità in quanto le system call con cui esse sono realizzate +non possono essere interrotte (o subire interferenze pericolose) da altri +processi. + +Nel caso dei segnali invece la situazione è molto più delicata, in quanto lo +stesso processo, e pure alcune system call, possono essere interrotti in +qualunque momento, e le operazioni di un eventuale \textit{signal handler} +sono compiute nello stesso spazio di indirizzi del processo. Per questo anche +il solo accesso o l'assegnazione di una variabile possono non essere più +operazioni atomiche (torneremo su questi aspetti in \secref{sec:sign_xxx}). + +In questo caso il sistema provvede un tipo di dato, il \type{sig\_atomic\_t}, +il cui accesso è assicurato essere atomico. In pratica comunque si può +assumere che in ogni piattaforma su cui è implementato Linux il tipo +\type{int} (e gli altri interi di dimensione inferiore) ed i puntatori sono +atomici. Non è affatto detto che lo stesso valga per interi di dimensioni +maggiori (in cui l'accesso può comportare più istruzioni in assembler) o per +le strutture. In questi casi è anche opportuno marcare come \type{volatile} le +variabili che possono essere interessate ad accesso condiviso, onde evitare +problemi con le ottimizzazioni del codice. + + +\subsection{Le \textit{race condition} e i \textit{deadlock}} +\label{sec:proc_race_cond} +Si definiscono \textit{race condition} tutte quelle situazioni in cui processi +diversi operano su una risorsa comune, ed in cui il risultato viene a +dipendere dall'ordine in cui essi effettuano le loro operazioni. Il caso +tipico è quella di una operazione che viene eseguita da un processo in più +passi, e può essere compromessa dall'intervento di un altro processo che +accede alla stessa risorsa quando ancora non tutti i passi sono stati +completati. + +Dato che in un sistema multitasking ogni processo può essere interrotto in +qualunque momento per farne subentrare un'altro in esecuzione, niente può +assicurare un preciso ordine di esecuzione fra processi diversi o che una +sezione di un programma possa essere eseguita senza interruzioni da parte di +altri. Queste situazioni comportano pertanto errori estremamente subdoli e +difficili da tracciare, in quanto nella maggior parte dei casi tutto +funzionerà regolarmente, e solo occasionalmente si avranno degli errori. + +Per questo occorre essere ben consapevoli di queste problematiche, e del fatto +che l'unico modo per evitarle è quello di riconoscerle come tali e prendere +gli adeguati provvedimenti per far si che non si verifichino. Casi tipici di +\textit{race condition} si hanno quando diversi processi accedono allo stesso +file, o nell'accesso a meccanismi di intercomunicazione come la memoria +condivisa. In questi casi, se non si dispone della possibilità di eseguire +atomicamente le operazioni necessarie, occorre che quelle parti di codice in +cui si compiono le operazioni critiche sulle risorse condivise, le cosiddette +\textsl{sezioni critiche} del programma, siano opportunamente protette da +meccanismi di sincronizzazione (torneremo su queste problematiche di questo +tipo in \secref{sec:ipc_semaph}). + +Un caso particolare di \textit{race condition} sono poi i cosiddetti +\textit{deadlock}, particolarmente gravi in quanto comportano spesso il blocco +completo di un servizio, e non il fallimento di una singola operazione. +L'esempio tipico di una situazione che può condurre ad un \textit{deadlock} è +quello in cui un flag di ``occupazione'' viene rilasciato da un evento +asincrono (come un segnale o un altro processo) fra il momento in cui lo si è +controllato (trovandolo occupato) e la successiva operazione di attesa per lo +sblocco. In questo caso, dato che l'evento di sblocco del flag è avvenuto +senza che ce ne accorgessimo proprio fra il controllo e la messa in attesa, +quest'ultima diventerà perpetua (da cui il nome di \textit{deadlock}). + +In tutti questi casi è di fondamentale importanza il concetto di atomicità +visto in \secref{sec:proc_atom_oper}; questi problemi infatti possono essere +risolti soltanto assicurandosi, quando essa sia richiesta, che sia possibile +eseguire in maniera atomica le operazioni necessarie, proteggendo con gli +adeguati meccanismi le \textsl{sezioni critiche} del programma. + + +\subsection{Le funzioni rientranti} +\label{sec:proc_reentrant} + +Si dice \textsl{rientrante} una funzione che può essere interrotta in +qualunque punto della sua esecuzione ed essere chiamata una seconda volta da +un altro thread di esecuzione senza che questo comporti nessun problema nella +esecuzione della stessa. La problematica è comune nella programmazione +multi-thread, ma si hanno gli stessi problemi quando si vogliono chiamare +delle funzioni all'interno dei manipolatori dei segnali. + +Fintanto che una funzione opera soltanto con le variabili locali è rientrante; +queste infatti vengono tutte le volte allocate nello stack, e un'altra +invocazione non fa altro che allocarne un'altra copia. Una funzione può non +essere rientrante quando opera su memoria che non è nello stack. Ad esempio +una funzione non è mai rientrante se usa una variabile globale o statica. + +Nel caso invece la funzione operi su un oggetto allocato dinamicamente la cosa +viene a dipendere da come avvengono le operazioni; se l'oggetto è creato ogni +volta e ritornato indietro la funzione può essere rientrante, se invece esso +viene individuato dalla funzione stessa due chiamate alla stessa funzione +potranno interferire quando entrambe faranno riferimento allo stesso oggetto. +Allo stesso modo una funzione può non essere rientrante se usa e modifica un +oggetto che le viene fornito dal chiamante: due chiamate possono interferire +se viene passato lo stesso oggetto; in tutti questi casi occorre molta cura da +parte del programmatore. + +In genere le funzioni di libreria non sono rientranti, molte di esse ad +esempio utilizzano variabili statiche, le \acr{glibc} però mettono a +disposizione due macro di compilatore, \macro{\_REENTRANT} e +\macro{\_THREAD\_SAFE}, la cui definizione attiva le versioni rientranti di +varie funzioni di libreria, che sono identificate aggiungendo il suffisso +\code{\_r} al nome della versione normale. + + + +%%% Local Variables: +%%% mode: latex +%%% TeX-master: "gapil" +%%% End: