X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=prochand.tex;h=69bdb16e4224a89cfe216fca14896f760804029b;hp=e7db230ad1d2ae912ad7840743ffe96f9b5ef24e;hb=c6bb1ae340cad082718e43163b9595608ed123e1;hpb=63f75c2bcd061336dd717b197bff0198b5194837 diff --git a/prochand.tex b/prochand.tex index e7db230..69bdb16 100644 --- a/prochand.tex +++ b/prochand.tex @@ -54,7 +54,6 @@ comunque consente di lanciare al posto di \cmd{init} qualunque altro programma 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 @@ -71,9 +70,9 @@ processo \cmd{init} che 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 +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}). @@ -110,32 +109,37 @@ 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{Il controllo dei processi} -\label{sec:proc_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, +\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_id} - -Come accennato ogni processo viene identificato dal sistema da un numero -identificativo unico, il \textit{process id} o \acr{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 tipo di dato standard, il \texttt{pid\_t} che in genere è un -intero con segno (nel caso di Linux e delle glibc il tipo usato è -\type{int}). - -Tutti i processi inoltre portano traccia del pid del genitore, chiamato in -genere \textit{ppid} (da \textit{parent process id}). Questi identificativi -possono essere ottenuti da un programma usando le funzioni: +\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} @@ -146,52 +150,422 @@ possono essere ottenuti da un programma usando le funzioni: Entrambe le funzioni non riportano condizioni di errore. \end{functions} -Come accennato in \secref{sec:file_perm_overview} ciascun processo porta con -se un gruppo di identificatori (riportati in \ntab) che indicano l'utente che -lo ha posto in esecuzione, e sono usati per il controllo di accesso. +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 è 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 relativi al controllo di sessione. -\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 \\ - \acr{rgid} & \textit{real group id} & indica il gruppo reale \\ - \acr{euid} & \textit{effective user id} & indica l'utente reale \\ - \acr{egid} & \textit{effective group id} & indica il gruppo reale \\ - & \textit{supplementaru group id} & indica il gruppo \\ - \acr{suid} & \textit{saved user id} & indica l'utente reale \\ - \acr{sgid} & \textit{daved group id} & indica il gruppo reale \\ - \acr{fsuid} & \textit{real user id} & indica l'utente reale \\ - \acr{fsgid} & \textit{real group id} & indica il gruppo reale \\ - \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: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 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 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, +Dopo l'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}, vista +in \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; + + ... /* handling options */ + + /* There must be remaing parameters */ + if (optind == argc) { + usage(); + } + 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 +Test for forking 3 child +Child 1 successfully executing +Child 1 exiting +Test for forking 3 child +Spawned 1 child, pid 836 +Go to next child +Child 2 successfully executing +Child 2 exiting +Test for forking 3 child +Spawned 1 child, pid 836 +Go to next child +Spawned 2 child, pid 837 +Go to next child +Child 3 successfully executing +Child 3 exiting +Test for forking 3 child +Spawned 1 child, pid 836 +Go to next child +Spawned 2 child, pid 837 +Go to next child +Spawned 3 child, pid 838 +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{suid} (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 tre modalità con cui +si conclude un programma in maniera normale: la chiamata di \func{exit} (che +esegue le funzioni registrate e chiude gli stream), il ritorno dalla funzione +\func{main} (equivalente alla chiamata di \func{exit}), e la chiamata ad +\func{\_exit} (che esegue direttamente la terminazione del processo). + +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. Ma per ciascuna delle varie modalità +di chiusura al padre deve essere riportato come il figlio è terminato. + +Nel caso di conclusione normale per riportare lo stato di uscita del processo +viene usato l'\textit{exit status} specificato dal 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 kernel +che deve generare un \textit{termination status} per indicare le ragioni della +conclusione anomala. Si noti che si è distinto fra \textit{exit status} e +\textit{termination status} in quanto anche in caso di conclusione normale, il +kernel usa il primo per produrre il secondo. + +In ogni caso il valore dello stato di conclusione del processo può essere +letto attraverso le funzioni \func{wait} o \func{waitpid}. \subsection{Le funzioni \texttt{wait} e \texttt{waitpid}} \label{sec:proc_wait} + + \subsection{Le funzioni \texttt{exec}} \label{sec:proc_exec} @@ -201,8 +575,79 @@ viene eseguito dal padre o dal figlio. \section{Il controllo di accesso} \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. +In questa sezione esamineremo le problematiche relative al controllo di +accesso dal punto di vista del processi; gli identificativi usati, come questi +vengono modificati nella creazione e nel lancio di nuovi processi, e le varie +funzioni per la loro manipolazione diretta. + + +\subsection{Utente e gruppo di un processo} +\label{sec:proc_user_group} + +Abbiamo già accennato in \secref{sec:intro_multiuser} 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] + \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} + +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. + +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}. + \subsection{Le funzioni \texttt{setuid} e \texttt{setgid}} \label{sec:proc_setuid}