\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
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.
+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 di gestione}
+
+\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
-\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.
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
\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
\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}
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
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
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
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
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
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
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
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
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}}
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.
\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.
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
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}).
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
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
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
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
571 pts/0 Z 0:00 [forktest <defunct>]
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.
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
\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
specchietto riportato in \ntab:
\begin{table}[!htb]
\centering
+ \footnotesize
\begin{tabular}[c]{|c|p{10cm}|}
\hline
\textbf{Valore} & \textbf{Significato}\\
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
\begin{table}[!htb]
\centering
+ \footnotesize
\begin{tabular}[c]{|c|p{10cm}|}
\hline
\textbf{Macro} & \textbf{Descrizione}\\
\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
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
\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{<bits/waitstatus.h} ma questo file non deve mai
- essere usato direttamente, esso viene incluso attraverso
+Entrambe le funzioni di attesa 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, ecc\footnote{le
+ definizioni esatte si possono trovare in \file{<bits/waitstatus.h} ma questo
+ file non deve mai essere usato direttamente, esso viene incluso attraverso
\file{<sys/wait.h>}}. 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{<sys/wait.h>} ed elencate in \curtab\ (si tenga presente che
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}
\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{<sys/time.h>} 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{<sys/time.h>} 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, ...)}
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
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,
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
\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
-indicano le due funzioni che necessitano del \textit{pathname} assoluto del
-programma come valore del parametro \var{path}. Le altre quattro funzioni
-invece usano come parametro \var{file} un nome che viene cercato
-automaticamente fra i file presenti nella lista di directory specificate dalla
-variabile di ambiente \var{PATH}.
+specifica il programma che si vuole eseguire. Con lo mnemonico \code{p} si
+indicano le due funzioni che replicano il comportamento della shell nello
+specificare il comando da eseguire; quando il parametro \var{file} non
+contiene una \file{/} esso viene considerato come un nome di programma, e
+viene eseguita automaticamente una ricerca fra i file presenti nella lista di
+directory specificate dalla variabile di ambiente \var{PATH}. Il file che
+viene posto in esecuzione è il primo che viene trovato. Se si ha un errore di
+permessi negati (cioè l'esecuzione della sottostante \func{execve} ritorna un
+\macro{EACCESS}), la ricerca viene proseguita nelle eventuali ulteriori
+directory indicate nel \var{PATH}, solo se non viene trovato nessun altro file
+viene finalmente restituito \macro{EACCESS}.
+
+Le altre quattro funzioni si limitano invece a cercare di eseguire il file
+indicato dal parametro \var{path}, che viene interpretato come il
+\textit{pathname} del programma.
+
+\begin{figure}[htb]
+ \centering
+ \includegraphics[width=13cm]{img/exec_rel}
+ \caption{La interrelazione fra le sei funzioni della famiglia \func{exec}}
+ \label{fig:proc_exec_relat}
+\end{figure}
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
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}).
-\item i segnali sospesi (\textit{pending}) e la maschera dei segnali.
-\item i limiti sulle risorse (vedi \secref{sec:limits_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: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 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_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} (vedi \secref{sec:file_dir_read}) che effettua da sola il
+settaggio del flag di \textit{close-on-exec} sulle directory che apre, in
+maniera trasparente all'utente.
+
+Abbiamo detto che il \textit{real user id} ed il \textit{real group id}
+restano gli stessi all'esecuzione di \func{exec}; lo stesso vale per
+l'\textit{effective user id} ed l'\textit{effective group id}, tranne 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
+appartiene (per i dettagli vedi \secref{sec:proc_perms}).
+
+Se il file da eseguire è in formato \emph{a.out} e necessita di librerie
+condivise, viene lanciato il \textit{linker} dinamico \cmd{ld.so} prima del
+programma per caricare le librerie necessarie ed effettuare il link
+dell'eseguibile. Se il programma è in formato ELF per caricare le librerie
+dinamiche viene usato l'interprete indicato nel segmento \macro{PT\_INTERP},
+in genere questo è \file{/lib/ld-linux.so.1} per programmi linkati con le
+\emph{libc5}, e \file{/lib/ld-linux.so.2} per programmi linkati con le
+\emph{glibc}. Infine nel caso il file sia uno script esso deve iniziare con
+una linea nella forma \cmd{\#!/path/to/interpreter} dove l'interprete indicato
+deve esse un valido programma (binario, non un altro script) che verrà
+chiamato come se si fosse eseguito il comando \cmd{interpreter [arg]
+ filename}.
Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è
-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.
+
\section{Il controllo di accesso}
\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}
+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}.
-Abbiamo già accennato in \secref{sec:intro_multiuser} ad ogni utente ed gruppo
-sono associati due identificatori univoci, lo \acr{uid} e il \acr{gid} che li
-contraddistinguono nei confronti del kernel. Questi identificatori stanno alla
-base del sistema di permessi e protezioni di un sistema unix, e vengono usati
-anche nella gestione dei privilegi di accesso dei processi.
-
-In realtà ad ogni processo è associato un certo numero di identificatori, il
-cui elenco è riportato \ntab, in genere questi derivano direttamente
-dall'utente che ha lanciato il processo (attraverso i valori di \acr{uid} e
-\acr{gid}), e vengono usati sia per il controllo di accesso ai file che per la
-gestione dei privilegi associati ai processi stessi.
\begin{table}[htb]
\footnotesize
\centering
- \begin{tabular}[c]{|c|l|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}.
-Questi non vengono mai cambiati nella creazione di nuovi processi e restano
-sempre gli stessi per tutti i processi avviati in una sessione. In realtà è
-possibile modificarli (vedi \secref{sec:proc_setuid}), ma solo per un processo
-che abbia i privilegi di amministratore (ed è così infatti che \cmd{login},
-che gira con i privilegi di amministratore, li setta ai valori corrispondenti
-all'utente che entra nel sistema).
-
-L'\textit{effective user id}, l'\textit{effective group id} e gli eventuali
-\textit{supplementary group id} sono gli identificativi usati per il controllo
-di accesso ai file secondo quanto descritto in dettaglio in
-\secref{sec:file_perm_overview}. Normalmente sono uguali al \textit{real user
- id} e al \textit{real group id}, a meno che il file posto in esecuzione non
-abbia i bit \acr{suid} o \acr{sgid} settati, nel qual caso vengono settati
-rispettivamente all'\acr{uid} e \acr{gid} del file.
+Al primo gruppo appartengono il \textit{real user id} e il \textit{real group
+ id}: questi vengono settati al login ai valori corrispondenti all'utente con
+cui si accede al sistema (e relativo gruppo di default). Servono per
+l'identificazione dell'utente e normalmente non vengono mai cambiati. In
+realtà vedremo (in \secref{sec:proc_setuid}) che è possibile modificarli, ma
+solo ad un processo che abbia i privilegi di amministratore; questa
+possibilità è usata ad esempio da \cmd{login} che una volta completata la
+procedura di autenticazione lancia una shell per la quale setta questi
+identificatori ai valori corrispondenti all'utente che entra nel sistema.
+
+Al secondo gruppo appartengono l'\textit{effective user id} e
+l'\textit{effective group id} (a cui si aggiungono gli eventuali
+\textit{supplementary group id} dei gruppi dei quale l'utente fa parte).
+Questi sono invece gli identificatori usati nella verifiche dei permessi del
+processo e per il controllo di accesso ai file (argomento affrontato in
+dettaglio in \secref{sec:file_perm_overview}).
+
+Questi identificatori normalmente sono identici ai corrispondenti del gruppo
+\textsl{reale} tranne nel caso in cui, come accennato in
+\secref{sec:proc_exec}, il programma che si è posto in esecuzione abbia i bit
+\acr{suid} o \acr{sgid} settati (il significato di questi bit è affrontato in
+dettaglio in \secref{sec:file_suid_sgid}). In questo caso essi saranno settati
+all'utente e al gruppo proprietari del file; questo consente, per programmi in
+cui ci sia necessità, di dare a qualunque utente normale privilegi o permessi
+di un'altro (o dell'amministratore).
+
+Come nel caso del \acr{pid} e del \acr{ppid} tutti questi identificatori
+possono essere letti dal processo attraverso delle opportune funzioni, i cui
+prototipi sono i seguenti:
+\begin{functions}
+ \headdecl{unistd.h}
+ \headdecl{sys/types.h}
+ \funcdecl{uid\_t getuid(void)} Restituisce il \textit{real user id} del
+ processo corrente.
+
+ \funcdecl{uid\_t geteuid(void)} Restituisce l'\textit{effective user id} del
+ processo corrente.
+
+ \funcdecl{gid\_t getgid(void)} Restituisce il \textit{real group id} del
+ processo corrente.
+
+ \funcdecl{gid\_t getegid(void)} Restituisce l'\textit{effective group id} del
+ processo corrente.
+
+ \bodydesc{Queste funzioni non riportano condizioni di errore.}
+\end{functions}
+
+In generale l'uso di privilegi superiori deve essere limitato il più
+possibile, per evitare abusi e problemi di sicurezza, per questo occorre anche
+un meccanismo che consenta ad un programma di rilasciare gli eventuali
+maggiori privilegi necessari, una volta che si siano effettuate le operazioni
+per i quali erano richiesti, e a poterli eventualmente recuperare in caso
+servano di nuovo.
+
+Questo in Linux viene fatto usando altri due gruppi di identificatori, il
+\textit{saved} ed il \textit{filesystem}, analoghi ai precedenti. Il primo
+gruppo è lo stesso usato in SVr4, e previsto dallo standard POSIX quando è
+definita la costante \macro{\_POSIX\_SAVED\_IDS}\footnote{in caso si abbia a
+ cuore la portabilità del programma su altri Unix è buona norma controllare
+ sempre la disponibilità di queste funzioni controllando se questa costante è
+ definita}, il secondo gruppo è specifico di Linux e viene usato per
+migliorare la sicurezza con NFS.
Il \textit{saved user id} e il \textit{saved group id} sono copie
dell'\textit{effective user id} e dell'\textit{effective group id} del
-processo padre, e vengono settati all'avvio del processo, prima che
-\textit{effective user id} e \textit{effective group id} vengano modificati
-per tener conto di eventuali \acr{suid} o \acr{sgid}.
+processo padre, e vengono settati dalla funzione \func{exec} all'avvio del
+processo, come copie dell'\textit{effective user id} e dell'\textit{effective
+ group id} dopo che questo sono stati settati tenendo conto di eventuali
+\acr{suid} o \acr{sgid}. Essi quindi consentono di tenere traccia di quale
+fossero utente e gruppo effettivi all'inizio dell'esecuzione di un nuovo
+programma.
+
+Il \textit{filesystem user id} e il \textit{filesystem group id} sono una
+estensione introdotta in Linux per rendere più sicuro l'uso di NFS (torneremo
+sull'argomento in \secref{sec:proc_setfsuid}). Essi sono una replica dei
+corrispondenti \textit{effective id}, ai quali si sostituiscono per tutte le
+operazioni di verifica dei permessi relativi ai file (trattate in
+\secref{sec:file_perm_overview}). Ogni cambiamento effettuato sugli
+\textit{effective id} viene automaticamente riportato su di essi, per cui in
+condizioni normali se ne può tranquillamente ignorare l'esistenza, in quanto
+saranno del tutto equivalenti ai precedenti.
+
+Uno specchietto riassuntivo, contenente l'elenco completo degli identificatori
+di utente e gruppo associati dal kernel ad ogni processo, è riportato in
+\tabref{tab:proc_uid_gid}.
+
+
+\subsection{Le funzioni \func{setuid} e \func{setgid}}
+\label{sec:proc_setuid}
+Le due funzioni che vengono usate per cambiare identità (cioè utente e gruppo
+di appartenenza) ad un processo sono rispettivamente \func{setuid} e
+\func{setgid}; come accennato in \secref{sec:proc_access_id} in Linux esse
+seguono la semantica POSIX che prevede l'esistenza del \textit{saved user id}
+e del \textit{saved group id}; i loro prototipi sono:
+\begin{functions}
+\headdecl{unistd.h}
+\headdecl{sys/types.h}
-\subsection{Le funzioni \texttt{setuid} e \texttt{setgid}}
-\label{sec:proc_setuid}
+\funcdecl{int setuid(uid\_t uid)} Setta l'\textit{user id} del processo
+corrente.
+\funcdecl{int setgid(gid\_t gid)} Setta il \textit{group id} del processo
+corrente.
-\subsection{Le funzioni \texttt{seteuid} e \texttt{setegid}}
+\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}
+
+I processi non privilegiati possono settare i \textit{real id} soltanto ai
+valori dei loro \textit{effective id} o \textit{real id} e gli
+\textit{effective id} ai valori dei loro \textit{real id}, \textit{effective
+ id} o \textit{saved id}; valori diversi comportano il fallimento della
+chiamata; l'amministratore invece può specificare un valore qualunque.
+Specificando un valore di -1 l'identificatore corrispondente viene lasciato
+inalterato.
+
+Con queste funzione si possono scambiare fra loro \textit{real id} e
+\textit{effective id}, e pertanto è possibile implementare un comportamento
+simile a quello visto in precedenza per \func{setgid}, cedendo i privilegi con
+un primo scambio, e recuperandoli, eseguito il lavoro non privilegiato, con un
+secondo scambio.
+
+In questo caso però occorre porre molta attenzione quando si creano nuovi
+processi nella fase intermedia in cui si sono scambiati gli identificatori, in
+questo caso infatti essi avranno un \textit{real id} privilegiato, che dovrà
+essere esplicitamente eliminato prima di porre in esecuzione un nuovo
+programma (occorrerà cioè eseguire un'altra chiamata dopo la \func{fork}, e
+prima della \func{exec} per uniformare i \textit{real id} agli
+\textit{effective id}) in caso contrario quest'ultimo potrebbe a sua volta
+effettuare uno scambio e riottenere privilegi non previsti.
+
+Lo stesso problema di propagazione dei privilegi ad eventuali processi figli
+si porrebbe per i \textit{saved id}: queste funzioni derivano da
+un'implementazione che non ne prevede la presenza, e quindi non è possibile
+usarle per correggere la situazione come nel caso precedente. Per questo
+motivo in Linux tutte le volte che vengono usata per modificare uno degli
+identificatori ad un valore diverso dal \textit{real id} precedente, il
+\textit{saved id} viene sempre settato al valore dell'\textit{effective id}.
+
+
+
+\subsection{Le funzioni \func{seteuid} e \func{setegid}}
\label{sec:proc_seteuid}
+Queste funzioni sono un'estensione allo standard POSIX.1 (ma sono comunque
+supportate dalla maggior parte degli Unix) e usate per cambiare gli
+\textit{effective id}; i loro prototipi sono:
+\begin{functions}
+\headdecl{unistd.h}
+\headdecl{sys/types.h}
+
+\funcdecl{int seteuid(uid\_t uid)} Setta l'\textit{effective user id} del
+processo corrente a \var{uid}.
-\subsection{Le \textit{race condition}}
-\label{sec:proc_race_cond}
+\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}
-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.
+\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}
+
+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:
projects / gapil.git / blobdiff