X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=prochand.tex;h=741496827f564a4894f4b0d482b20d87e60e5199;hp=40a880dddf5c867c205a0110c2d868812d32e9dc;hb=4ad4523de32d786ae4c24ef157bd4b8fe4aac534;hpb=b65121906b3a8fff20f19fa84d3a42c0877477ac diff --git a/prochand.tex b/prochand.tex index 40a880d..7414968 100644 --- a/prochand.tex +++ b/prochand.tex @@ -11,138 +11,1305 @@ dei processi, della gestione dei loro attributi e privilegi, e di tutte le funzioni a questo connesse. -\section{Una panoramica sui concetti base} -\label{sec:prochand_gen} - -Una delle caratteristiche essenziali di unix (che esamineremo in dettaglio più -avanti) è che ogni processo può a sua volta generare altri processi figli -(\textit{child}): questo è ad esempio quello che fa la shell quando mette in -esecuzione il programma che gli indichiamo nella linea di comando. - -Una seconda caratteristica è che ogni processo viene sempre generato in tale -modo da un processo genitore (\textit{parent}) attraverso una apposita system -call. Questo vale per tutti i processi, tranne per un processo speciale, che -normalmente è \texttt{/sbin/init}, che invece viene lanciato dal kernel finita -la fase di avvio e che quindi non è figlio di nessuno. - -Tutto ciò significa che, come per i file su disco, i processi sono organizzati -gerarchicamente dalla relazione fra genitori e figli; alla base dell'albero in -questo caso c'è init che è progenitore di ogni altro processo. - - -\section{Gli identificatori dei processi} -\label{sec:prochand_id} - -Ogni processo viene identificato dal sistema da un numero identificativo -unico, il \textit{process id} o \textit{pid}. Questo viene assegnato in forma -progressiva ogni volta che un nuovo processo viene creato, fino ad un limite -massimo (in genere essendo detto numero memorizzato in un intero a 16 bit si -arriva a 32767) oltre il quale si riparte dal numero più basso disponibile -(FIXME: verificare, non sono sicuro). Per questo motivo processo il processo -di avvio (init) ha sempre il pid uguale a uno. - -Ogni processo è identificato univocamente dal sistema per il suo -pid; quest'ultimo è un apposito tipo di dato, il \texttt{pid\_t} che in -genere è un intero con segno (nel caso di Linux e delle glibc il tipo usato è -\texttt{int}. - -Tutti i processi inoltre portano traccia del pid del genitore, chiamato in -genere \textit{ppid} (da \textit{Parente Process Id}). Questi identificativi -possono essere ottenuti da un programma usando le funzioni: -\begin{itemize} - \item \texttt{pid\_t getpid(void)} restituisce il pid del processo corrente. - - \item \texttt{pid\_t getppid(void)} restituisce il pid del padre del processo - corrente. +\section{Introduzione} +\label{sec:proc_gen} -\end{itemize} -(per l'accesso a queste funzioni e ai relativi tipi di dati occorre includere -gli header files \texttt{unistd.h} e \texttt{sys/types.h}). +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. + +\subsection{La gerarchia 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 +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 di un sistema unix è che la generazione di un +processo è una operazione separata rispetto al lancio di un programma. In +genere la sequenza è sempre quella di creare un nuovo processo, il quale +eseguirà, in un passo successivo, il programma voluto: questo è ad esempio +quello che fa la shell quando mette in esecuzione il programma che gli +indichiamo nella linea di comando. +Una terza caratteristica è che ogni processo è sempre stato generato da un +altro, che viene chiamato processo padre (\textit{parent process}). Questo +vale per tutti i processi, con una sola eccezione: dato che ci deve essere un +punto di partenza esiste un processo speciale (che normalmente è +\cmd{/sbin/init}), che viene lanciato dal kernel alla conclusione della fase +di avvio; essendo questo il primo processo lanciato dal sistema ha sempre il +\acr{pid} uguale a 1 e non è figlio di nessun altro processo. -\section{Il controllo dei processi} -\label{sec:prochand_control} +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 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. -Esamineremo in questa sezione le varie funzioni per il controllo dei processi: -la lore creazione, la terminazione, l'esecuzione di altri programmi. Prima di -trattare in dettaglio le singole funzioni, faremo un'introduzione generale ai -contetti che stanno alla base della gestione dei processi in unix. +\begin{figure}[!htb] + \footnotesize +\begin{verbatim} +[piccardi@gont piccardi]$ pstree -n +init-+-keventd + |-kapm-idled + |-kreiserfsd + |-portmap + |-syslogd + |-klogd + |-named + |-rpc.statd + |-gpm + |-inetd + |-junkbuster + |-master-+-qmgr + | `-pickup + |-sshd + |-xfs + |-cron + |-bash---startx---xinit-+-XFree86 + | `-WindowMaker-+-ssh-agent + | |-wmtime + | |-wmmon + | |-wmmount + | |-wmppp + | |-wmcube + | |-wmmixer + | |-wmgtemp + | |-wterm---bash---pstree + | `-wterm---bash-+-emacs + | `-man---pager + |-5*[getty] + |-snort + `-wwwoffled +\end{verbatim} %$ + \caption{L'albero dei processi, così come riportato dal comando + \cmd{pstree}.} + \label{fig:proc_tree} +\end{figure} -\subsection{Una panoramica} -\label{sec:prochand_control_overview} +Dato che tutti i processi attivi nel sistema sono comunque generati da +\cmd{init} o da uno dei suoi figli\footnote{in realtà questo non è del tutto + vero, in Linux ci sono alcuni processi che pur comparendo come figli di + init, o con \acr{pid} successivi, sono in realtà generati direttamente dal + kernel, (come \cmd{keventd}, \cmd{kswapd}, etc.)} si possono classificare i +processi con la relazione padre/figlio in una organizzazione gerarchica ad +albero, in maniera analoga a come i file sono organizzati in un albero di +directory (si veda \secref{sec:file_file_struct}); 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. -I processi vengono creati dalla funzione \texttt{fork}; in genere questa è una -system call, ma linux però usa un'altra nomenclatura, e la funzione fork è -basata a sua volta sulla system call \texttt{clone}, che viene usata anche per -generare i \textit{thread}. Il processo figlio creato dalla \textit{fork} è -una copia identica del processo processo padre, solo che ha un suo pid -proprio. + +\subsection{Una panoramica sulle funzioni di gestione} +\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}). Se si vuole che il processo padre si fermi fino alla conclusione del processo -figlio questo deve essere specificato subito dopo la fork chiamando la -funzione \texttt{wait} o la funzione \texttt{waitpid}, che restituiscono anche -una informazione abbastanza limitata (il codice di uscita) sulle cause della -terminazione 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. Quando un processo ha concluso il suo compito o ha incontrato un errore non -risolvibile esso può essere terminato con la funzione \texttt{exit} (la -questione è più complessa ma ci torneremo più avanti). La vita del processo -però termina solo quando viene chiamata la quando la sua conclusione viene -ricevuta dal processo padre, a quel punto tutte le risorse allocate nel -sistema ad esso associate vengono rilasciate. +risolvibile esso può essere terminato con la funzione \func{exit} (si veda +quanto discusso in \secref{sec:proc_conclusion}). La vita del processo però +termina solo quando la notifica della sua conclusione viene ricevuta dal +processo padre, a quel punto tutte le risorse allocate nel sistema ad esso +associate vengono rilasciate. Avere due processi che eseguono esattamente lo stesso codice non è molto -utile, mormalmente si genera un secondo processo per affidagli l'esecuzione di -un compito specifico (ad esempio gestire una connessione dopo che questa è +utile, normalmente si genera un secondo processo per affidargli l'esecuzione +di un compito specifico (ad esempio gestire una connessione dopo che questa è stata stabilita), o fargli eseguire (come fa la shell) un altro programma. Per -questo si usa la seconda funzione fondamentale per programmazione coi processi -che è la \texttt{exec}. +quest'ultimo caso si usa la seconda funzione fondamentale per programmazione +coi processi che è la \func{exec}. -Il programma che un processo sta eseguendo si chiama immagine del processo -(\textit{process image}), le funzioni della famiglia \textit{exec} permettono -di caricare un'altro programma da disco sostituendo quest'ultimo alla process -image corrente, questo fa si che la precedente immagine venga completamente -cancellata e quando il nuovo programma esce anche il processo termina, senza -ritornare alla precedente immagine. +Il programma che un processo sta eseguendo si chiama immagine del processo (o +\textit{process image}), le funzioni della famiglia \func{exec} permettono di +caricare un'altro programma da disco sostituendo quest'ultimo all'immagine +corrente; questo fa si che l'immagine precedente venga completamente +cancellata. Questo significa che quando il nuovo programma esce anche il +processo termina, e non si può tornare alla precedente immagine. -Per questo motivo la \texttt{fork} e la \texttt{exec} sono funzioni molto +Per questo motivo la \func{fork} e la \func{exec} sono funzioni molto particolari con caratteristiche uniche rispetto a tutte le altre, infatti la prima ritorna due volte (nel processo padre e nel figlio) mentre la seconda non ritorna mai (in quanto con essa viene eseguito un altro programma). -\subsection{La funzione \texttt{fork}} -\label{sec:prochand_fork} +\section{La 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 +programmi. + + +\subsection{Gli identificatori dei processi} +\label{sec:proc_pid} + +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}). + +Il \acr{pid} viene assegnato in forma progressiva ogni volta che un nuovo +processo viene creato, fino ad un limite massimo (in genere essendo detto +numero memorizzato in un intero a 16 bit si arriva a 32767) oltre il quale si +riparte dal numero più basso disponibile (FIXME: verificare, non sono sicuro). +Per questo motivo processo il processo di avvio (\cmd{init}) ha sempre il +\acr{pid} uguale a uno. + +Tutti i processi inoltre memorizzano anche il \acr{pid} del genitore da cui +sono stati creati, questo viene chiamato in genere \acr{ppid} (da +\textit{parent process id}). Questi due identificativi possono essere +ottenuti da programma usando le funzioni: +\begin{functions} +\headdecl{sys/types.h} +\headdecl{unistd.h} +\funcdecl{pid\_t getpid(void)} restituisce il pid del processo corrente. +\funcdecl{pid\_t getppid(void)} restituisce il pid del padre del processo + corrente. + +Entrambe le funzioni non riportano condizioni di errore. +\end{functions} +esempi dell'uso di queste funzioni sono riportati in +\figref{fig:proc_fork_code}, nel programma di esempio \file{ForkTest.c}. + +Il fatto che il \acr{pid} sia un numero univoco per il sistema lo rende il +candidato ideale per generare ulteriori indicatori associati al processo di +cui diventa possibile garantire l'unicità: ad esempio la funzione +\func{tmpname} (si veda \secref{sec:file_temp_file}) usa il \acr{pid} per +generare un pathname univoco, che non potrà essere replicato da un'altro +processo che usi la stessa funzione. + +Tutti i processi figli dello stesso processo padre sono detti +\textit{sibling}, questa è una delle relazioni usate nel \textsl{controllo di + sessione}, in cui si raggruppano i processi creati su uno stesso terminale, +o relativi allo stesso login. Torneremo su questo argomento in dettaglio in +\secref{cap:session}, dove esamineremo i vari identificativi associati ad un +processo e le varie relazioni fra processi utilizzate per definire una +sessione. + + +\subsection{La funzione \func{fork}} +\label{sec:proc_fork} + +La funzione \func{fork} è la funzione fondamentale della gestione dei +processi: come si è detto l'unico modo di creare un nuovo processo è +attraverso l'uso di questa funzione, essa quindi riveste un ruolo centrale +tutte le volte che si devono scrivere programmi che usano il multitasking. Il +prototipo della funzione è: + +\begin{functions} + \headdecl{sys/types.h} + \headdecl{unistd.h} + \funcdecl{pid\_t fork(void)} + Restituisce zero al padre e il \acr{pid} al figlio in caso di successo, + ritorna -1 al padre (senza creare il figlio) in caso di errore; + \texttt{errno} può assumere i valori: + \begin{errlist} + \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 + strutture necessarie al kernel per creare il nuovo processo. + \end{errlist} +\end{functions} + +Dopo il successo dell'esecuzione di una \func{fork} sia il processo padre che +il processo figlio continuano ad essere eseguiti normalmente alla istruzione +seguente la \func{fork}; il processo figlio è però una copia del padre, e +riceve una copia dei segmenti di testo, stack e dati (vedi +\secref{sec:proc_mem_layout}), ed esegue esattamente lo stesso codice del +padre, ma la memoria è copiata, non condivisa\footnote{In generale il segmento + di testo, che è identico, è condiviso e tenuto in read-only, Linux poi + utilizza la tecnica del \textit{copy-on-write}, per cui la memoria degli + altri segmenti viene copiata dal kernel per il nuovo processo solo in caso + di scrittura, rendendo molto più efficiente il meccanismo} 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. + +\begin{figure}[!htb] + \footnotesize + \begin{lstlisting}{} +#include /* error definitions and routines */ +#include /* C standard library */ +#include /* unix standard library */ +#include /* standard I/O library */ +#include /* string functions */ + +/* Help printing routine */ +void usage(void); + +int main(int argc, char *argv[]) +{ +/* + * Variables definition + */ + int nchild, i; + pid_t pid; + int wait_child = 0; + int wait_parent = 0; + int wait_end = 0; + ... /* handling options */ + nchild = atoi(argv[optind]); + printf("Test for forking %d child\n", nchild); + /* loop to fork children */ + for (i=0; i output +[piccardi@selidor sources]$ cat output +Process 1967: forking 3 child +Child 1 successfully executing +Child 1, parent 1967, exiting +Test for forking 3 child +Spawned 1 child, pid 1968 +Go to next child +Child 2 successfully executing +Child 2, parent 1967, exiting +Test for forking 3 child +Spawned 1 child, pid 1968 +Go to next child +Spawned 2 child, pid 1969 +Go to next child +Child 3 successfully executing +Child 3, parent 1967, exiting +Test for forking 3 child +Spawned 1 child, pid 1968 +Go to next child +Spawned 2 child, pid 1969 +Go to next child +Spawned 3 child, pid 1970 +Go to next child +\end{verbatim} +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). + +Nel primo esempio allora avevamo che ad ogni chiamata a \func{printf} il +buffer veniva scaricato, e le singole righe erano stampate a video subito dopo +l'esecuzione della \func{printf}. Ma con la redirezione su file la scrittura +non avviene più alla fine di ogni riga e l'output resta nel buffer, per questo +motivo, dato che ogni figlio riceve una copia della memoria del padre, esso +riceverà anche quanto c'è nel buffer delle funzioni di I/O, comprese le linee +scritte dal padre fino allora. Così quando all'uscita del figlio il buffer +viene scritto su disco, troveremo nel file anche tutto quello che il processo +padre aveva scritto prima della sua creazione. E alla fine del file, dato che +in questo caso il padre esce per ultimo, troviamo anche l'output del padre. + +Ma l'esempio ci mostra un'altro aspetto fondamentale dell'interazione con i +file, che era valido anche per l'esempio precedente, ma meno evidente; il +fatto cioè che non solo processi diversi possono scrivere in contemporanea +sullo stesso file (l'argomento della condivisione dei file in unix è trattato +in dettaglio in \secref{sec:file_sharing}), ma anche che, a differenza di +quanto avviene per le variabili, la posizione corrente sul file è condivisa +fra il padre e tutti i processi figli. + +Quello che succede è che quando lo standard output del padre viene rediretto, +lo stesso avviene anche per tutti i figli; la funzione \func{fork} infatti ha +la caratteristica di duplicare (allo stesso modo in cui lo fa la funzione +\func{dup}, trattata in \secref{sec:file_dup}) nei figli tutti i file +descriptor aperti nel padre, il che comporta che padre e figli condividono +le stesse voci della file table (per la spiegazione di questi termini si veda +\secref{sec:file_sharing} e referenza a figura da fare) e quindi anche +l'offset corrente nel file. + +In questo modo se un processo scrive sul file aggiornerà l'offset sulla file +table, e tutti gli altri processi che condividono la file table vedranno il +nuovo valore; in questo modo si evita, in casi come quello appena mostrato in +cui diversi processi scrivono sullo stesso file, che l'output successivo di un +processo vada a sovrapporsi a quello dei precedenti (l'output potrà risultare +mescolato, ma non ci saranno parti perdute per via di una sovrascrittura). + +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. + +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: +\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. +\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. +\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). +\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}). +\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{sgid} (vedi \secref{sec:file_suid_sgid}). +\item la directory di lavoro e la directory radice (vedi + \secref{sec:file_work_dir}). +\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 le variabili di ambiente (vedi \secref{sec:proc_environ}). +\end{itemize} +le differenze 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} + + +\subsection{La funzione \func{vfork}} +\label{sec:proc_vfork} + +La funzione \func{vfork} è esattamente identica a \func{fork} ed ha la stessa +semantica e gli stessi errori; la sola differenza è che non viene creata la +tabella delle pagine né la struttura dei task per il nuovo processo. Il +processo padre è posto in attesa fintanto che il figlio non ha eseguito una +\func{execve} o non è uscito con una \func{\_exit}. Il figlio condivide la +memoria del padre (e modifiche possono avere effetti imprevedibili) e non deve +ritornare o uscire con \func{exit} ma usare esplicitamente \func{\_exit}. + +Questa funzione è un rimasuglio dei vecchi tempi in cui eseguire una +\func{fork} comportava anche la copia completa del segmento dati del processo +padre, che costituiva un inutile appesantimento in tutti quei casi in cui la +\func{fork} veniva fatto solo per poi eseguire una \func{exec}. La funzione +venne introdotta in BSD per migliorare le prestazioni. + +Dato che Linux supporta il \textit{copy on write} la perdita di prestazioni è +assolutamente trascurabile, e l'uso di questa funzione (che resta un caso +speciale della funzione \func{clone}), è deprecato, per questo eviteremo di +trattarla ulteriormente. + + +\subsection{La conclusione di un processo.} +\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 +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. + +Abbiamo già visto in \secref{sec:proc_conclusion} le tre modalità con cui un +programma viene terminato in maniera normale: la chiamata di \func{exit} (che +esegue le funzioni registrate per l'uscita e chiude gli stream), il ritorno +dalla funzione \func{main} (equivalente alla chiamata di \func{exit}), e la +chiamata ad \func{\_exit} (che passa direttamente alle operazioni di +terminazione del processo da parte del kernel). + +Ma oltre alla conclusione normale abbiamo accennato che esistono anche delle +modalità di conclusione anomala; queste sono in sostanza due: il programma può +chiamare la funzione \func{abort} per invocare una chiusura anomala, o essere +terminato da un segnale. In realtà anche la prima modalità si riconduce alla +seconda, dato che \func{abort} si limita a generare il segnale +\macro{SIGABRT}. + +Qualunque sia la modalità di conclusione di un processo, il kernel esegue +comunque una serie di operazioni: chiude tutti i file aperti, rilascia la +memoria che stava usando, e così via; l'elenco completo delle operazioni +eseguite alla chiusura di un processo è il seguente: +\begin{itemize} +\item tutti i descrittori dei file 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 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 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}. +\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. + +Nel caso di conclusione normale, lo stato di uscita del processo viene +caratterizzato tramite il valore del cosiddetto \textit{exit status}, cioè il +valore passato alle funzioni \func{exit} o \func{\_exit} (o dal valore di +ritorno per \func{main}). Ma se il processo viene concluso in maniera anomala +il programma non può specificare nessun \textit{exit status}, ed è il kernel +che deve generare autonomamente il \textit{termination status} per indicare le +ragioni della conclusione anomala. + +Si noti la distinzione fra \textit{exit status} e \textit{termination status}: +quello che contraddistingue lo stato di chiusura del processo e viene +riportato attraverso le funzioni \func{wait} o \func{waitpid} (vedi +\secref{sec:proc_wait}) è sempre quest'ultimo; in caso di conclusione normale +il kernel usa il primo (nel codice eseguito da \func{\_exit}) per produrre il +secondo. + +La scelta di riportare al padre lo stato di terminazione dei figli, pur +essendo l'unica possibile, comporta comunque alcune complicazioni: infatti se +alla sua creazione è scontato che ogni nuovo processo ha un padre, non è detto +che sia così alla sua conclusione, dato che il padre potrebbe essere già +terminato (si potrebbe avere cioè quello che si chiama un processo +\textsl{orfano}). + +Questa complicazione viene superata facendo in modo che il processo figlio +venga \textsl{adottato} da \cmd{init}: come già accennato quando un processo +termina il kernel controlla se è il padre di altri processi in esecuzione: in +caso positivo allora il \acr{ppid} di tutti questi processi viene sostituito +con il \acr{pid} di \cmd{init} (e cioè con 1); in questo modo ogni processo +avrà sempre un padre (nel caso \textsl{adottivo}) cui riportare il suo stato +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 è: +\begin{verbatim} +[piccardi@selidor sources]$ ./forktest -c2 3 +Process 1972: forking 3 child +Spawned 1 child, pid 1973 +Child 1 successfully executing +Go to next child +Spawned 2 child, pid 1974 +Child 2 successfully executing +Go to next child +Child 3 successfully executing +Spawned 3 child, pid 1975 +Go to next child +[piccardi@selidor sources]$ Child 3, parent 1, exiting +Child 2, parent 1, exiting +Child 1, parent 1, exiting +\end{verbatim} +come si può notare in questo caso il processo padre si conclude prima dei +figli, tornando alla shell, che stampa il prompt sul terminale: circa due +secondi dopo viene stampato a video anche l'output dei tre figli che +terminano, e come si può notare in questo caso, al contrario di quanto visto +in precedenza, essi riportano 1 come \acr{ppid}. -Dopo l'esecuzione di una fork sia il processo padre che il processo figlio -continuano ad essere eseguiti normalmente, ed il processo figlio esegue -esattamente lo stesso codice del padre. La sola differenza è che nel processo -padre il valore di ritorno della funzione fork è il pid del processo figlio, -mentre nel figlio è zero; in questo modo il programma può identificare se -viene eseguito dal padre o dal figlio. +Altrettanto rilevante è il caso in cui il figlio termina prima del padre, +perché non è detto che il padre possa ricevere immediatamente lo stato di +terminazione, quindi il kernel deve comunque conservare una certa quantità di +informazioni riguardo ai processi che sta terminando. +Questo viene fatto mantenendo attiva la voce nella tabella dei processi, e +memorizzando alcuni dati essenziali, come il \acr{pid}, i tempi di CPU usati +dal processo (vedi \secref{sec: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 +effettuerà la lettura dello stato di uscita anche questa informazione, non più +necessaria, verrà scartata e la terminazione potrà dirsi completamente +conclusa. +Possiamo utilizzare il nostro programma di prova per analizzare anche questa +condizione: lanciamo il comando \cmd{forktest} in background, indicando al +processo padre di aspettare 10 secondi prima di uscire; in questo caso, usando +\cmd{ps} sullo stesso terminale (prima dello scadere dei 10 secondi) +otterremo: +\begin{verbatim} +[piccardi@selidor sources]$ ps T + PID TTY STAT TIME COMMAND + 419 pts/0 S 0:00 bash + 568 pts/0 S 0:00 ./forktest -e10 3 + 569 pts/0 Z 0:00 [forktest ] + 570 pts/0 Z 0:00 [forktest ] + 571 pts/0 Z 0:00 [forktest ] + 572 pts/0 R 0:00 ps T +\end{verbatim} %$ +e come si vede, dato che non si è fatto nulla per riceverne lo stato di +terminazione, i tre processi figli sono ancora presenti pur essendosi +conclusi, con lo stato di zombie e l'indicazione che sono stati terminati. + +La possibilità di avere degli zombie deve essere tenuta sempre presente quando +si scrive un programma che deve essere mantenuto in esecuzione a lungo e +creare molti figli. In questo caso si deve sempre avere cura di far leggere +l'eventuale stato di uscita di tutti i figli (in genere questo si fa +attraverso un apposito \textit{signal handler}, che chiama la funzione +\func{wait}, vedi \secref{sec:sig_xxx} e \secref{sec:proc_wait}). Questa +operazione è necessaria perché anche se gli \textit{zombie} non consumano +risorse di memoria o processore, occupano comunque una voce nella tabella dei +processi, che a lungo andare potrebbe esaurirsi. + +Si noti che quando un processo adottato da \cmd{init} termina, esso non +diviene uno \textit{zombie}; questo perché una delle funzioni di \cmd{init} è +appunto quella di chiamare la funzione \func{wait} per i processi cui fa da +padre, completandone la terminazione. Questo è quanto avviene anche quando, +come nel caso del precedente esempio con \cmd{forktest}, il padre termina con +dei figli in stato di zombie: alla sua terminazione infatti tutti i suoi figli +vengono ereditati (compresi gli zombie) verranno adottati da \cmd{init}, il +quale provvederà a completarne la terminazione. + +Si tenga presente infine che siccome gli zombie sono processi già usciti, non +c'è modo di eliminarli con il comando \cmd{kill}; l'unica possibilità è quella +di terminare il processo che li ha generati, in modo che \cmd{init} possa +adottarli e provvedere a concludere la terminazione. \subsection{Le funzioni \texttt{wait} e \texttt{waitpid}} -\label{sec:prochand_wait} +\label{sec:proc_wait} + +Abbiamo già accennato come uno degli usi possibili delle capacità multitasking +di un sistema unix-like consista nella creazione di programmi di tipo server, +in cui un processo principale attende le richieste che vengono poi soddisfatte +creando una serie di processi figli. Si è già sottolineato al paragrafo +precedente come in questo caso diventi necessario gestire esplicitamente la +conclusione dei vari processi figli onde evitare di riempire di +\textit{zombie} la tabella dei processi; le funzioni deputate a questo compito +sono sostanzialmente due, \func{wait} e \func{waitpid}. La prima, il cui +prototipo è: +\begin{functions} +\headdecl{sys/types.h} +\headdecl{sys/wait.h} +\funcdecl{pid\_t wait(int * status)} + +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: + \begin{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. + +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 è: +\begin{functions} +\headdecl{sys/types.h} +\headdecl{sys/wait.h} +\funcdecl{pid\_t waitpid(pid\_t pid, int * status, int options)} + +La funzione restituisce il \acr{pid} del processo che è uscito, 0 se è stata +specificata l'opzione \macro{WNOHANG} e il processo non è uscito e -1 per un +errore, nel qual caso \var{errno} assumerà i valori: + \begin{errlist} + \item \macro{EINTR} se non è stata specificata l'opzione \macro{WNOHANG} e + la funzione è stata interrotta da un segnale. + \item \macro{ECHILD} il processo specificato da \var{pid} non esiste o non è + figlio del processo chiamante. + \end{errlist} +\end{functions} + +Le differenze principali fra le due funzioni sono che \func{wait} si blocca +sempre fino a che un processo figlio non termina, mentre \func{waitpid} ha la +possibilità si specificare un'opzione \macro{WNOHANG} che ne previene il +blocco; inoltre \func{waitpid} può specificare quale processo attendere sulla +base del valore specificato tramite la variabile \var{pid}, secondo lo +specchietto riportato in \ntab: +\begin{table}[!htb] + \centering + \begin{tabular}[c]{|c|p{10cm}|} + \hline + \textbf{Valore} & \textbf{Significato}\\ + \hline + \hline + $<-1$& attende per un figlio il cui \textit{process group} è uguale al + valore assoluto di \var{pid}. \\ + $-1$ & attende per un figlio qualsiasi, usata in questa maniera è + equivalente a \func{wait}.\\ + $0$ & attende per un figlio il cui \textit{process group} è uguale a + quello del processo chiamante. \\ + $>0$ & attende per un figlio il cui \acr{pid} è uguale al + valore di \var{pid}.\\ + \hline + \end{tabular} + \caption{Significato dei valori del parametro \var{pid} della funzione + \func{waitpid}.} + \label{tab:proc_waidpid_pid} +\end{table} + +Il comportamento di \func{waitpid} può essere modificato passando delle +opportune opzioni tramite la variabile \var{option}. I valori possibili sono +il già citato \macro{WNOHANG}, che previene il blocco della funzione quando il +processo figlio non è terminato, e \macro{WUNTRACED} (usata per il controllo +di sessione, trattato in \capref{cha:session}) che fa ritornare la funzione +anche per i processi figli che sono bloccati ed il cui stato non è stato +ancora riportato al padre. Il valore dell'opzione deve essere specificato come +maschera binaria ottenuta con l'OR delle suddette costanti con zero. + +La terminazione di un processo figlio è chiaramente un evento asincrono +rispetto all'esecuzione di un programma e può avvenire in un qualunque +momento, per questo motivo, come si è visto nella sezione precedente, una +delle azioni prese dal kernel alla conclusione di un processo è quella di +mandare un segnale di \macro{SIGCHLD} al padre. Questo segnale viene ignorato +di default, ma costituisce il meccanismo di comunicazione asincrona con cui il +kernel avverte un processo padre che uno dei suoi figli è terminato. + +In genere in un programma non si vuole essere forzati ad attendere la +conclusione di un processo per proseguire, specie se tutto questo serve solo +per leggerne lo stato di chiusura (ed evitare la presenza di \textit{zombie}), +per questo la modalità più usata per chiamare queste funzioni è quella di +utilizzarle all'interno di un \textit{signal handler} (torneremo sui segnali e +su come gestire \macro{SIGCHLD} in \secref{sec:sig_sigwait_xxx}) nel qual +caso, dato che il segnale è generato dalla terminazione un figlio, avremo la +certezza che la chiamata a \func{wait} non si bloccherà. + +\begin{table}[!htb] + \centering + \footnotesize + \begin{tabular}[c]{|c|p{10cm}|} + \hline + \textbf{Macro} & \textbf{Descrizione}\\ + \hline + \hline + \macro{WIFEXITED(s)} & Condizione vera (valore non nullo) per un processo + figlio che sia terminato normalmente. \\ + \macro{WEXITSTATUS(s)} & Restituisce gli otto bit meno significativi dello + stato di uscita del processo (passato attraverso \func{\_exit}, \func{exit} + o come valore di ritorno di \func{main}). Può essere valutata solo se + \macro{WIFEXITED} ha restituito un valore non nullo.\\ + \macro{WIFSIGNALED(s)} & Vera se il processo figlio è terminato + in maniera anomala a causa di un segnale che non è stato catturato (vedi + \secref{sec:sig_notification}).\\ + \macro{WTERMSIG(s)} & restituisce il numero del segnale che ha causato + la terminazione anomala del processo. Può essere valutata solo se + \macro{WIFSIGNALED} ha restituito un valore non nullo.\\ + \macro{WCOREDUMP(s)} & Vera se il processo terminato ha generato un + file si \textit{core dump}. Può essere valutata solo se + \macro{WIFSIGNALED} ha restituito un valore non nullo\footnote{questa + macro non è definita dallo standard POSIX.1, ma è presente come estensione + sia in Linux che in altri unix}.\\ + \macro{WIFSTOPPED(s)} & Vera se il processo che ha causato il ritorno di + \func{waitpid} è bloccato. L'uso è possibile solo avendo specificato + l'opzione \macro{WUNTRACED}. \\ + \macro{WSTOPSIG(s)} & restituisce il numero del segnale che ha bloccato + il processo, Può essere valutata solo se \macro{WIFSTOPPED} ha + restituito un valore non nullo. \\ + \hline + \end{tabular} + \caption{Descrizione delle varie macro di preprocessore utilizzabili per + verificare lo stato di terminazione \var{s} di un processo.} + \label{tab:proc_status_macro} +\end{table} + + +Entrambe le funzioni restituiscono lo stato di terminazione del processo +tramite il puntatore \var{status} (se non interessa memorizzare lo stato si +può passare un puntatore nullo). Il valore restituito da entrambe le funzioni +dipende dall'implementazione, e tradizionalmente alcuni bit sono riservati per +memorizzare lo stato di uscita (in genere 8) altri per indicare il segnale che +ha causato la terminazione (in caso di conclusione anomala), uno per indicare +se è stato generato un core file, etc.\footnote{le definizioni esatte si + possono trovare in \file{}}. Lo standard POSIX.1 definisce una serie di macro di +preprocessore da usare per analizzare lo stato di uscita; esse sono definite +sempre in \file{} ed elencate in \curtab\ (si tenga presente che +queste macro prendono come parametro la variabile di tipo \type{int} puntata +da \var{status}). + +Si tenga conto che nel caso di conclusione anomala il valore restituito da +\macro{WTERMSIG} può essere controllato contro le costanti definite in +\file{signal.h}, e stampato usando le funzioni definite 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, che diventano +accessibili definendo la costante \macro{\_USE\_BSD}, sono: + +\begin{functions} + \headdecl{sys/times.h} + \headdecl{sys/types.h} + \headdecl{sys/wait.h} + \headdecl{sys/resource.h} + \funcdecl{pid\_t wait4(pid\_t pid, int * status, int options, struct rusage + * rusage)} + 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}. +\end{functions} +la struttura \type{rusage} è definita in \file{sys/resource.h}, e viene +utilizzata anche dalla funzione \func{getrusage} per ottenere le risorse di +sistema usate dal processo; in Linux è definita come: +\begin{figure}[!htb] + \footnotesize + \centering + \begin{minipage}[c]{15cm} + \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{} +struct rusage { + struct timeval ru_utime; /* user time used */ + struct timeval ru_stime; /* system time used */ + long ru_maxrss; /* maximum resident set size */ + long ru_ixrss; /* integral shared memory size */ + long ru_idrss; /* integral unshared data size */ + long ru_isrss; /* integral unshared stack size */ + long ru_minflt; /* page reclaims */ + long ru_majflt; /* page faults */ + long ru_nswap; /* swaps */ + long ru_inblock; /* block input operations */ + long ru_oublock; /* block output operations */ + long ru_msgsnd; /* messages sent */ + long ru_msgrcv; /* messages received */ + long ru_nsignals; ; /* signals received */ + long ru_nvcsw; /* voluntary context switches */ + long ru_nivcsw; /* involuntary context switches */ +}; + \end{lstlisting} + \end{minipage} + \normalsize + \caption{La struttura \texttt{rusage} per la lettura delle informazioni dei + delle risorse usate da un processo.} + \label{fig:proc_rusage_struct} +\end{figure} +In genere includere esplicitamente \file{} non è più necessario, +ma aumenta la portabilità, 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}} -\label{sec:prochand_exec} +\label{sec:proc_exec} + +Abbiamo già detto che una delle modalità principali con cui si utilizzano i +processi in unix è quella di usarli per lanciare nuovi programmi: questo viene +fatto attraverso una delle funzioni della famiglia \func{exec}. Quando un +processo chiama una di queste funzioni esso viene completamente sostituito dal +nuovo programma; il \acr{pid} del processo non cambia, dato che non viene +creato un nuovo processo, la funzione semplicemente rimpiazza lo stack, o +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 è: + +\begin{prototype}{unistd.h} +{int execve(const char * filename, char * const argv [], char * const envp[])} + + 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 + \var{errno} può assumere i valori: + \begin{errlist} + \item \macro{EACCES} il file non è eseguibile, oppure il filesystem è + montato in \cmd{noexec}, oppure non è un file normale o un interprete. + \item \macro{EPERM} il file ha i bit \acr{suid} o \acr{sgid} 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 + riconosciuto come tale, o compilato per un'altra architettura. + \item \macro{ENOENT} il file o una delle librerie dinamiche o l'interprete + necessari per eseguirlo non esistono. + \item \macro{ETXTBSY} L'eseguibile è aperto in scrittura da uno o più + processi. + \item \macro{EINVAL} L'eseguibile ELF ha più di un segmento + \macro{PF\_INTERP}, cioè chiede di essere eseguito da più di un interprete. + \item \macro{ELIBBAD} Un interprete ELF non è in un formato riconoscibile. + \end{errlist} + ed inoltre anche \macro{EFAULT}, \macro{ENOMEM}, \macro{EIO}, + \macro{ENAMETOOLONG}, \macro{E2BIG}, \macro{ELOOP}, \macro{ENOTDIR}, + \macro{ENFILE}, \macro{EMFILE}. +\end{prototype} + +Le altre funzioni della famiglia servono per fornire all'utente una serie +possibile di diverse interfacce per la creazione di un nuovo processo. I loro +prototipi sono: + +\begin{functions} +\headdecl{unistd.h} +\funcdecl{int execl(const char *path, const char *arg, ...)} +\funcdecl{int execv(const char *path, char *const argv[])} +\funcdecl{int execle(const char *path, const char *arg, ..., char +* const envp[])} +\funcdecl{int execlp(const char *file, const char *arg, ...)} +\funcdecl{int execvp(const char *file, char *const argv[])} + +Sostituiscono l'immagine corrente del processo con quella indicata nel primo +argomento. I parametri successivi consentono di specificare gli argomenti a +linea di comando e l'ambiente ricevuti dal nuovo processo. + +Queste funzioni ritornano solo in caso di errore, restituendo -1; nel qual +caso \var{errno} andrà ad assumere i valori visti in precedenza per +\func{execve}. +\end{functions} + +Per capire meglio le differenze fra le funzioni della famiglia si può fare +riferimento allo specchietto riportato in \ntab. La prima differenza riguarda +le modalità di passaggio dei parametri che poi andranno a costituire gli +argomenti a linea di comando (cioè i valori di \var{argv} e \var{argc} visti +dalla funzione \func{main} del programma chiamato). + +Queste modalità sono due e sono riassunte dagli mnenonici \func{v} e \func{l} +che stanno rispettivamente per \textit{vector} e \textit{list}. Nel primo caso +gli argomenti sono passati tramite il vettore di puntatori \var{argv[]} a +stringhe terminate con zero che costituiranno gli argomenti a riga di comando, +questo vettore \emph{deve} essere terminato da un puntatore nullo. + +Nel secondo caso le stringhe degli argomenti sono passate alla funzione come +lista di puntatori, nella forma: +\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{} + char * arg0, char * arg1, ..., char * argn, NULL +\end{lstlisting} +che deve essere terminata da un puntatore nullo. In entrambi i casi vale la +convenzione che il primo argomento (\var{arg0} o \var{argv[0]}) viene usato +per indicare il nome del file che contiene il programma che verrà eseguito. + +\begin{table}[!htb] + \footnotesize + \centering + \begin{tabular}[c]{|l|c|c|c||c|c|c|} + \hline + \multicolumn{1}{|c|}{\textbf{Caratteristiche}} & + \multicolumn{6}{|c|}{\textbf{Funzioni}} \\ + \hline + &\func{execl\ }&\func{execlp}&\func{execle} + &\func{execv\ }& \func{execvp}& \func{execve} \\ + \hline + \hline + argomenti a lista &$\bullet$&$\bullet$&$\bullet$&&& \\ + argomenti a vettore &&&&$\bullet$&$\bullet$&$\bullet$\\ + \hline + filename completo &&$\bullet$&&&$\bullet$& \\ + ricerca su \var{PATH}&$\bullet$&&$\bullet$&$\bullet$&&$\bullet$ \\ + \hline + ambiente a vettore &&&$\bullet$&&&$\bullet$ \\ + uso di \var{environ} &$\bullet$&$\bullet$&&$\bullet$&$\bullet$& \\ + \hline + \end{tabular} + \caption{Confronto delle caratteristiche delle varie funzioni della + famiglia \func{exec}.} + \label{tab:proc_exec_scheme} +\end{table} + +La seconda differenza fra le funzioni riguarda le modalità con cui si +specifica il programma che si vuole eseguire. Con lo mnemonico \func{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.eps} + \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 +un vettore di parametri \var{envp[]} analogo a quello usato per gli argomenti +a riga di comando (terminato quindi da un \macro{NULL}), le altre usano il +valore della variabile \var{environ} (vedi \secref{sec:proc_environ}) del +processo di partenza per costruire l'ambiente. + +Oltre a mantenere lo stesso \acr{pid}, il nuovo programma fatto partire da +\func{exec} assume anche una serie di altre proprietà del processo chiamante; +la lista completa è la seguente: +\begin{itemize} +\item il \textit{process ID} (\acr{pid}) ed il \textit{parent process ID} + (\acr{ppid}). +\item il \textit{real user ID} ed il \textit{real group ID} (vedi + \secref{sec:proc_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 + \secref{sec:sess_xxx}). +\item il terminale di controllo (vedi \secref{sec:sess_xxx}). +\item il tempo restante ad un allarme. +\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 (si veda + \secref{sec:sig_xxx}). +\item i limiti sulle risorse (vedi \secref{sec:limits_xxx}).. +\item i valori delle variabili \var{tms\_utime}, \var{tms\_stime}, + \var{tms\_cutime}, \var{tms\_ustime} (vedi \secref{sec:xxx_xxx}).. +\end{itemize} + +Oltre a questo i segnali che sono stati settati per essere ignorati nel +processo chiamante mantengono lo stesso settaggio pure nuovo programma, tutti +gli altri segnali vengono settati alla loro azione di default. Un caso +speciale è il segnale \macro{SIGCHLD} che, quando settato a \macro{SIG\_IGN} +può anche non essere resettato a \macro{SIG\_DFL} (si veda +\secref{sec:sig_xxx}). + +La gestione dei file aperti dipende dal valore del flag di +\textit{close-on-exec} per ciascun file descriptor (si veda +\secref{sec:file_xxx}); i file per cui è settato vengono chiusi, tutti gli +altri file restano aperti. Questo significa che il comportamento di default è +che i file restano aperti attraverso una \func{exec}, a meno di una chiamata +esplicita a \func{fcntl} che setti il suddetto flag. + +Per le directory lo standard POSIX.1 richiede che esse vengano chiuse +attraverso una \func{exec}, in genere questo è fatto dalla funzione +\func{opendir} che effettua da sola il settaggio del flag di +\textit{close-on-exec} sulle directory che apre, in maniera trasparente +all'utente. + +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 +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 +altre funzioni sono ausiliarie e servono la lettura e il settaggio dei vari +parametri connessi ai processi. + \section{Il controllo di accesso} -\label{sec:prochand_perms} +\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 +possono essere modificati nella creazione e nel lancio di nuovi processi, le +varie funzioni per la loro manipolazione diretta e tutte le problematiche +connesse alla gestione accorta dei privilegi. + + +\subsection{Utente e gruppo di un processo} +\label{sec:proc_user_group} + +Abbiamo già accennato in \secref{sec:intro_multiuser} che il sistema base +della sicurezza in unix è basato sui concetti di utente e gruppo; ad essi sono +associati due identificatori univoci, lo \acr{uid} e il \acr{gid} che li +contraddistinguono nei confronti del kernel. Questi identificatori sono quelli +che vengono controllati nella gestione di permessi e protezioni in un sistema +unix, e oltre che per il controllo di accesso ai file, già esposto in +\secref{sec:file_access_control}, vengono usati anche nella gestione dei +privilegi di accesso dei processi. + +Abbiamo già incontrato in \secref{sec:file_perm_overview} + + + +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}|} + \hline + \textbf{Sigla} & \textbf{Significato} & \textbf{Utilizzo} \\ + \hline + \hline + \acr{ruid} & \textit{real user id} & indica l'utente reale che ha lanciato + il programma\\ + \acr{rgid} & \textit{real group id} & indica il gruppo reale 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 + l'utente appartiene \\ + \acr{suid} & \textit{saved user id} & indica l'utente \\ + \acr{sgid} & \textit{saved group id} & indica il gruppo \\ + \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.} + \label{tab:proc_uid_gid} +\end{table} + +Il \textit{real user id} e il \textit{real group id} indicano l'utente che ha +lanciato il processo, e vengono settati al login al valore standard di +\acr{uid} e \acr{gid} dell'utente letti direttamente da \file{/etc/passwd}. + +Esso servono ad identificare l'utente che ha lanciato il processo e non +vengono mai cambiati nella creazione di nuovi processi restando sempre gli +stessi per tutti i processi avviati in una sessione. In realtà vedremo che è +possibile possibile modificarli (in \secref{sec:proc_setuid}), ma solo ad un +processo che abbia i privilegi di amministratore; questa possibilità è usata +ad esempio da \cmd{login} che una volta completata la procedura di +autenticazione lancia una shell per la quale setta questi identificatori ai +valori corrispondenti all'utente che entra nel sistema. + +L'\textit{effective user id}, l'\textit{effective group id} e gli eventuali +\textit{supplementary group id} sono invece gli identificatori usati per il +controllo di accesso ai file (secondo quanto descritto in dettaglio in +\secref{sec:file_perm_overview}). Normalmente essi sono uguali al \textit{real + user id} e al \textit{real group id}, a meno che il file posto in esecuzione +non abbia o il bit \acr{suid} o il bit \acr{sgid} settato, in questo caso alla +la funzione \func{exec} (vedi \secref{}) li setta rispettivamente ai valori +dell'\acr{uid} e del \acr{gid} cui appartiene il file. + +Il \textit{saved user id} e il \textit{saved group id} sono copie +dell'\textit{effective user id} e dell'\textit{effective group id} del +processo padre, e vengono settati dalla funzione \func{exec} all'avvio del +processo, prima che \textit{effective user id} e \textit{effective group id} +vengano modificati per tener conto di eventuali \acr{suid} o \acr{sgid}, essi +quindi consentono di tenere traccia di quale fossero l'utente originale. -Va messo qui tutta la storia su effective, real, saved uid, e pure le cose di -linux come il filesystem uid. \subsection{Le funzioni \texttt{setuid} e \texttt{setgid}} -\label{sec:prochand_setuid} +\label{sec:proc_setuid} \subsection{Le funzioni \texttt{seteuid} e \texttt{setegid}} -\label{sec:prochand_setuid} +\label{sec:proc_seteuid} + + +\subsection{Le \textit{race condition}} +\label{sec:proc_race_cond} + +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. +