X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=prochand.tex;h=b2f7b9ae409f9c1d5a86cae01ba2d4f4de095e17;hp=c8f6ad4f3a722e544c89ec215e0a691bbae41a55;hb=429f6e0da8fc282eb6611b6fe83fdf58ae8da611;hpb=b61786a321acb8edfc249dd27b596d2323859db6 diff --git a/prochand.tex b/prochand.tex index c8f6ad4..b2f7b9a 100644 --- a/prochand.tex +++ b/prochand.tex @@ -11,97 +11,97 @@ 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{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. -\end{functions} - - -\section{Il controllo dei processi} -\label{sec:prochand_control} - -Esamineremo in questa sezione le varie funzioni per il controllo dei processi: -la loro creazione, la terminazione, l'esecuzione di altri programmi. Prima di -trattare in dettaglio le singole funzioni, faremo un'introduzione generale ai -concetti che stanno alla base della gestione dei processi in unix. - -\subsection{Una panoramica} -\label{sec:prochand_control_overview} - -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. +\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. + +\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 \acr{pid} (da \textit{process identifier}). + +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 si 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 genitore (\textit{parent process}). Questo vale +per tutti i processi, con una eccezione (dato che ci deve essere un punto di +partenza), esiste sempre infatti un processo speciale, che normalmente è +\cmd{/sbin/init}, che viene lanciato dal kernel quando questo ha finito la +fase di avvio, esso essendo il primo processo lanciato ha sempre il \acr{pid} +uguale a 1 e non è figlio di nessuno. + +Questo è ovviamente un processo speciale, che in genere si occupa di far +partire tutti gli processi altri 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 +essi in \secref{}) 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, è possibile farlo ad esempio passando la riga \cmd{init=/bin/sh} +all'avvio). + +Dato che tutti i processi successivi sono comunque generati da \cmd{init} o da +suoi figli tutto ciò comporta che, i processi sono organizzati gerarchicamente +dalla relazione fra genitori e figli, in maniera analoga a come i file sono +organizzati in un albero di directory con alla base \file{/} (si veda +\secref{sec:file_file_struct}); in questo caso alla base dell'albero c'è il +processo \cmd{init} che è progenitore di ogni altro processo\footnote{in + realtà questo non è del tutto vero, in Linux ci sono alcuni processi che pur + comparendo come figli di init (ad esempio in \cmd{pstree}) sono generati + direttamente dal kernel, come \cmd{keventd}, \cmd{kswapd}, etc.}. + + +\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}; queste funzioni +restituiscono anche una informazione abbastanza limitata (il codice di uscita) +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} (si veda -quanto discusso in \secref{sec:proc_termination}). 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_termination}). 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, normalmente si genera un secondo processo per affidargli 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 \func{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 \func{fork} e la \func{exec} sono funzioni molto particolari con caratteristiche uniche rispetto a tutte le altre, infatti la @@ -109,41 +109,160 @@ 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). + +\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 lore 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}) ed è normalmente utilizzato per il controllo di +sessione. 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} + +Il fatto che il \acr{pid} sia un numero univoco per il sistema lo rende il +candidato ideale per generare ultieriori 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 è un'altra delle relazioni usate nel controllo di +sessione, in cui si raggruppano tutti i processi creati su uno stesso +terminale una volta che si è effettuato il login. Torneremo su questo +argomento in \secref{cap:terminal}, dove esamineremo tutti gli altri +identificativi associati ad un processo. + +\subsection{Utente e gruppo di un processo} +\label{sec:proc_user_group} + +Come 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 confonti 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. + +Abbiamo già accennato in \secref{sec:file_perm_overview} che ad ogni processo +associato un certo numero di identificatori (riportati \ntab) che fanno +riferimento all'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] + \centering + \begin{tabular}[c]{|c|l|l|} + \hline + Sigla & Significato & 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{daved 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} + + + + + \subsection{La funzione \func{fork}} -\label{sec:prochand_fork} +\label{sec:proc_fork} -La funzione \func{fork} +La funzione \func{fork} è la funzione fondamentale della gestione dei processi +in unix; come si è detto l'unico modo di creare un nuovo processo è attraverso +l'uso di questa funzione, che è quindi la base per il multitasking; il protipo +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 l'esecuzione di una fork sia il processo padre che il processo figlio -continuano ad essere eseguiti normalmente, ed il processo figlio esegue +Dopo l'esecuzione di una \func{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. - +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. \subsection{Le funzioni \texttt{wait} e \texttt{waitpid}} -\label{sec:prochand_wait} +\label{sec:proc_wait} \subsection{Le funzioni \texttt{exec}} -\label{sec:prochand_exec} +\label{sec:proc_exec} \section{Il controllo di accesso} -\label{sec:prochand_perms} +\label{sec:proc_perms} -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_seteuid} +\label{sec:proc_seteuid}