X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=prochand.tex;h=f81dcc95dcdcc76c9a09689031a2e9bfe07d991f;hp=def38644e8c2370fcd94a0161766a631b0dd948e;hb=f4469c536e047bd645eb84db1d5bed531ffde3b5;hpb=83de30b430dcc90d2c7799d461974353343caadd diff --git a/prochand.tex b/prochand.tex index def3864..f81dcc9 100644 --- a/prochand.tex +++ b/prochand.tex @@ -8,16 +8,20 @@ base per l'allocazione e l'uso delle risorse del sistema. Nel precedente capitolo abbiamo visto come funziona un singolo processo, in questo capitolo affronteremo i dettagli della creazione e della distruzione dei processi, della gestione dei loro attributi e privilegi, e di tutte le -funzioni a questo connesse. +funzioni a questo connesse. Infine nella sezione finale affronteremo alcune +problematiche generiche della programmazione in ambiente multitasking. + \section{Introduzione} \label{sec:proc_gen} Partiremo con una introduzione generale ai concetti che stanno alla base della -gestione dei processi in unix. Introdurremo in questa sezione l'architettura -della gestione dei processi e le sue principali caratteristiche, e daremo una -panoramica sull'uso delle principali funzioni per la gestione dei processi. +gestione dei processi in un sistema unix-like. 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} @@ -215,7 +219,7 @@ Oltre al \acr{pid} e al \acr{ppid}, e a quelli usati per il controllo di sessione, ad ogni processo sono associati altri identificatori, usati per il controllo di accesso, che servono per determinare se il processo può o meno eseguire le operazioni richieste, a seconda dei privilegi e dell'identità di -chi lo ha posto in esecuzione; su questi torneremo in dettaglii più avanti in +chi lo ha posto in esecuzione; su questi torneremo in dettagli più avanti in \secref{sec:proc_perm}. @@ -496,10 +500,9 @@ Quello che succede lo stesso avviene anche per tutti i figli; la funzione \func{fork} infatti ha la caratteristica di duplicare (allo stesso modo in cui lo fa la funzione \func{dup}, trattata in \secref{sec:file_dup}) nei figli tutti i file -descriptor aperti nel padre, il che comporta che padre e figli condividono -le stesse voci della file table (per la spiegazione di questi termini si veda -\secref{sec:file_sharing} e referenza a figura da fare) e quindi anche -l'offset corrente nel file. +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 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 @@ -533,11 +536,10 @@ sequenza impredicibile. Le modalit \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: +proprietà; la lista dettagliata delle proprietà che padre e figlio hanno in +comune dopo l'esecuzione di una \func{fork} è la seguente: \begin{itemize*} -\item i file aperti (e gli eventuali flag di \textit{close-on-exec} se - settati). +\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 @@ -549,12 +551,12 @@ padre e figlio avranno in comune: \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 la maschera dei segnali bloccati e le azioni installate. \item i segmenti di memoria condivisa agganciati al processo. -\item i limiti sulle risorse +\item i limiti sulle risorse. \item le variabili di ambiente (vedi \secref{sec:proc_environ}). \end{itemize*} -le differenze invece sono: +le differenze fra padre e figlio dopo la \func{fork} invece sono: \begin{itemize*} \item il valore di ritorno di \func{fork}. \item il \textit{process id}. @@ -563,7 +565,7 @@ le differenze invece sono: \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. +\item gli allarmi ed i segnali pendenti, che per il figlio vengono cancellati. \end{itemize*} @@ -756,7 +758,7 @@ di terminare il processo che li ha generati, in modo che \cmd{init} possa adottarli e provvedere a concludere la terminazione. -\subsection{Le funzioni \texttt{wait} e \texttt{waitpid}} +\subsection{Le funzioni \func{wait} e \func{waitpid}} \label{sec:proc_wait} Abbiamo già accennato come uno degli usi possibili delle capacità multitasking @@ -787,6 +789,7 @@ caso di errore; \var{errno} pu \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 @@ -959,6 +962,7 @@ accessibili definendo la costante \macro{\_USE\_BSD}, sono: Prima versione, equivalente a \func{wait4(-1, \&status, opt, rusage)} è ormai deprecata in favore di \func{wait4}. \end{functions} +\noindent la struttura \type{rusage} è definita in \file{sys/resource.h}, e viene utilizzata anche dalla funzione \func{getrusage} per ottenere le risorse di sistema usate dal processo; in Linux è definita come: @@ -988,7 +992,7 @@ struct rusage { \end{lstlisting} \end{minipage} \normalsize - \caption{La struttura \texttt{rusage} per la lettura delle informazioni dei + \caption{La struttura \var{rusage} per la lettura delle informazioni dei delle risorse usate da un processo.} \label{fig:proc_rusage_struct} \end{figure} @@ -1000,7 +1004,7 @@ sono mantenuti sono: \var{ru\_utime}, \var{ru\_stime}, \var{ru\_minflt}, \var{ru\_majflt}, e \var{ru\_nswap}. -\subsection{Le funzioni \texttt{exec}} +\subsection{Le funzioni \func{exec}} \label{sec:proc_exec} Abbiamo già detto che una delle modalità principali con cui si utilizzano i @@ -1328,7 +1332,7 @@ il programma che si settati (il significato di questi bit è affrontato in dettaglio in \secref{sec:file_suid_sgid}). In questo caso essi saranno settati all'utente e al gruppo proprietari del file; questo consente, per programmi in cui ci sia -necessità, di dare a qualunquee utente normale privilegi o permessi di +necessità, di dare a qualunque utente normale privilegi o permessi di un'altro (o dell'amministratore). Come nel caso del \acr{pid} e del \acr{ppid} tutti questi identificatori @@ -1393,10 +1397,10 @@ di utente e gruppo associati dal kernel ad ogni processo, \subsection{Le funzioni \func{setuid} e \func{setgid}} \label{sec:proc_setuid} -Le due funzioni che venfono usate per cambiare identità (cioè utente e gruppo +Le due funzioni che vengono usate per cambiare identità (cioè utente e gruppo di appartenenza) ad un processo sono rispettivamente \func{setuid} e \func{setgid}; come accennato in \secref{sec:proc_user_group} in Linux esse -seguono la sematica POSIX che prevede l'esistenza di \textit{saved user id} e +seguono la semantica POSIX che prevede l'esistenza di \textit{saved user id} e \textit{saved group id}; i loro prototipi sono: \begin{functions} @@ -1422,7 +1426,7 @@ delle funzioni che tratteremo in questa sezione. L'effetto della chiamata è diverso a seconda dei privilegi del processo; se l'\textit{effective user id} è zero (cioè è quello dell'amministratore di -sistema) allora tutti gli identificatatori (\textit{real}, \textit{effective} +sistema) allora tutti gli identificatori (\textit{real}, \textit{effective} e \textit{saved}) vengono settati al valore specificato da \var{uid}, altrimenti viene settato solo l'\textit{effective user id}, e soltanto se il valore specificato corrisponde o al \textit{real user id} o al \textit{saved @@ -1437,7 +1441,7 @@ eventualmente tornare indietro. Come esempio per chiarire dell'uso di queste funzioni prediamo quello con cui viene gestito l'accesso al file \file{/var/log/utmp}. In questo file viene registrato chi sta usando il sistema al momento corrente; chiaramente non può -essere lasciato aperto in scrittura a qualunque utente, che protrebbe +essere lasciato aperto in scrittura a qualunque utente, che potrebbe falsificare la registrazione. Per questo motivo questo file (e l'analogo \file{/var/log/wtmp} su cui vengono registrati login e logout) appartengono ad un gruppo dedicato (\acr{utmp}) ed i programmi che devono accedervi (ad @@ -1515,7 +1519,7 @@ Le funzioni restituiscono 0 in caso di successo e -1 in caso di fallimento: l'unico errore possibile è \macro{EPERM}. \end{functions} -I processi non privileguiati possono settare i \textit{real id} soltanto ai +I processi non privilegiati possono settare i \textit{real id} soltanto ai valori dei loro \textit{effective id} o \textit{real id} e gli \textit{effective id} ai valori dei loro \textit{real id}, \textit{effective id} o \textit{saved id}; valori diversi comportano il fallimento della @@ -1574,9 +1578,11 @@ l'unico errore possibile I processi non privilegiati possono cambiare uno qualunque degli identificatori usando uno qualunque dei valori correnti di \textit{real id}, -\textit{effective id} o \textit{saved id}, l'ammnistratore può specificare i +\textit{effective id} o \textit{saved id}, l'amministratore può specificare i valori che vuole; un valore di -1 per un qualunque parametro lascia inalterato -l'dentificatore corrispondente. +l'identificatore corrispondente. + + \subsection{Le funzioni \func{seteuid} e \func{setegid}} \label{sec:proc_seteuid} @@ -1590,10 +1596,10 @@ supportate dalla maggior parte degli unix) e usate per cambiare gli \headdecl{sys/types.h} \funcdecl{int seteuid(uid\_t uid)} setta l'\textit{effective user ID} del -processo corrente. +processo corrente a \var{uid}. \funcdecl{int setegid(gid\_t gid)} setta l'\textit{effective group ID} del -processo corrente. +processo corrente a \var{gid}. Le funzioni restituiscono 0 in caso di successo e -1 in caso di fallimento: l'unico errore possibile è \macro{EPERM}. @@ -1601,22 +1607,161 @@ l'unico errore possibile Gli utenti normali possono settare l'\textit{effective id} solo al valore del \textit{real id} o del \textit{saved id}, l'amministratore può specificare -qualunque valore. - - +qualunque valore. Queste funzioni sono usate per permettere a root di settare +solo l'\textit{effective id}, dato che l'uso normale di \func{setuid} comporta +il settaggio di tutti gli identificatori. + \subsection{Le funzioni \func{setfsuid} e \func{setfsgid}} \label{sec:proc_setfsuid} +Queste funzioni sono usate per settare gli identificatori usati da Linux per +il controllo dell'accesso ai file. Come già accennato in +\secref{sec:proc_user_group} in Linux è definito questo ulteriore gruppo di +identificatori, che di norma sono assolutamente equivalenti agli +\textit{effective id}, dato che ogni cambiamento di questi ultimi viene +immediatamente riportato sui \textit{filesystem id}. + +C'è un solo caso in cui si ha necessità di introdurre una differenza fra +\textit{effective id} e \textit{filesystem id}, ed è per ovviare ad un +problema di sicurezza che si presenta quando si deve implementare un server +NFS. Il server NFS infatti deve poter cambiare l'identificatore con cui accede +ai file per assumere l'identità del singolo utente remoto, ma se questo viene +fatto cambiando l'\textit{effective id} o il \textit{real id} il server si +espone alla ricezione di eventuali segnali ostili da parte dell'utente di cui +ha temporaneamente assunto l'identità. Cambiando solo il \textit{filesystem + id} si ottengono i privilegi necessari per accedere ai file, mantenendo +quelli originari per quanto riguarda tutti gli altri controlli di accesso. + +Le due funzioni usate per cambiare questi identificatori sono \func{setfsuid} +e \func{setfsgid}, ovviamente sono specifiche di Linux e non devono essere +usate se si intendono scrivere programmi portabili; i loro prototipi sono: +\begin{functions} +\headdecl{sys/fsuid.h} -\subsection{Le \textit{race condition}} +\funcdecl{int setfsuid(uid\_t fsuid)} setta il \textit{filesystem user ID} del +processo corrente a \var{fsuid}. + +\funcdecl{int setfsgid(gid\_t fsgid)} setta l'\textit{filesystem group ID} del +processo corrente a \var{fsgid}. + +Le funzioni restituiscono 0 in caso di successo e -1 in caso di fallimento: +l'unico errore possibile è \macro{EPERM}. +\end{functions} + +Queste funzioni hanno successo solo se il processo chiamante ha i privilegi di +amministratore o, per gli altri utenti, se il valore specificato coincide con +uno dei \textit{real}, \textit{effective} o \textit{saved id}. + + +\section{Problematiche di programmazione multitasking} +\label{sec:proc_multi_prog} + +Benché i processi siano strutturati in modo da apparire il più possibile come +indipendenti l'uno dall'altro, nella programmazione in un sistema multiutente +occorre tenere conto di tutta una serie di problematiche che normalmente non +esistono quando si ha a che fare con un sistema in cui viene eseguito un solo +programma alla volta. + +Pur non essendo tutto questo direttamente legato alla modalità specifica in +cui il multitasking è implementato in un sistema unix-like, né al solo +concetto di multitasking (le stesse problematiche si presentano ad esempio +nella gestione degli interrupt hardware), in questa sezione conclusiva del +capitolo in cui abbiamo affrontato la gestione dei processi, introdurremo +sinteticamente queste problematiche, che ritroveremo a più riprese in capitoli +successivi, con una breve definizione della terminologia e delle loro +caratteristiche di fondo. + + +\subsection{Le operazioni atomiche} +\label{sec:proc_atom_oper} + +La nozione di \textsl{operazione atomica} deriva dal significato greco della +parola atomo, cioè indivisibile; si dice infatti che una operazione è atomica +quando si ha la certezza che, qualora essa venga effettuata, tutti i passaggi +che devono essere compiuti per realizzarla verranno eseguiti senza possibilità +di interruzione in una fase intermedia. + +In un ambiente multitasking il concetto è essenziale, dato che un processo può +essere interrotto in qualunque momento dal kernel che mette in esecuzione un +altro processo o dalla ricezione di un segnale; occorre pertanto essere +accorti nei confronti delle possibili \textit{race condition} (vedi +\secref{sec:proc_race_cond}) derivanti da operazioni interrotte in una fase in +cui non erano ancora state completate. + +Nel caso dell'interazione fra processi la situazione è molto più semplice, ed +occorre preoccuparsi della atomicità delle operazioni solo quando si ha a che +fare con meccanismi di intercomunicazione (che esamineremo in dettaglio in +\capref{cha:ipc}) o nella operazioni con i file (vedremo alcuni esempi in +\secref{sec:file_atomic}). In questi casi in genere l'uso delle appropriate +funzioni di libreria per compiere le operazioni necessarie è garanzia +sufficiente di atomicità in quanto le system call con cui esse sono realizzate +non possono essere interrotte (o subire interferenze pericolose) da altri +processi. + +Nel caso dei segnali invece la situazione è molto più delicata, in quanto lo +stesso processo può essere interrotto in qualunque momento, e le operazioni di +un eventuale \textit{signal handler} saranno compiute nello stesso spazio di +indirizzi. Per questo anche solo il solo accesso o l'assegnazione di una +variabile possono non essere più operazioni atomiche (torneremo su questi +aspetti in \secref{sec:sign_xxx}). + +In questo caso il sistema provvede un tipo di dato, il \type{sig\_atomic\_t}, +il cui accesso è assicurato essere atomico. In pratica comunque si può +assumere che in ogni piattaforma su cui è implementato Linux il tipo +\type{int} (e gli altri interi di dimensione inferiore) ed i puntatori sono +atomici. Non è affatto detto che lo stesso valga per interi di dimensioni +maggiori (in cui l'accesso può comportare più istruzioni in assembler) o per +le strutture. In questi casi è anche opportuno marcare come \type{volatile} le +variabili che possono essere interessate ad accesso condiviso, onde evitare +problemi con le ottimizzazioni del codice. + + +\subsection{Le \textit{race condition} e i \textit{deadlock}} \label{sec:proc_race_cond} Si 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. +l'ordine di esecuzione di un processo rispetto agli altri, 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. + +Casi tipici di \textit{race condition} si hanno quando diversi processi +accedono allo stesso file, o nell'accesso a meccanismi di intercomunicazione +come la memoria condivisa. In questi casi, se non si dispone della possibilità +di eseguire atomicamente le operazioni necessarie, occorre che le risorse +condivise siano opportunamente protette da meccanismi di sincronizzazione +(torneremo su queste problematiche di questo tipo in \secref{sec:ipc_semaph}). + +Un caso particolare di \textit{race condition} sono poi i cosiddetti +\textit{deadlock}; l'esempio tipico è quello di un flag di ``occupazione'' che +viene rilasciato da un evento asincrono fra il controllo (in cui viene trovato +occupato) e la successiva messa in attesa, attesa che a questo punto diventerà +perpetua (da cui il nome di \textit{deadlock}) in quanto l'evento di sblocco +di questa è stato perso. + + +\subsection{Le funzioni rientranti} +\label{sec:proc_reentrant} + +Si dice rientrante una funzione che può essere interrotta in qualunque momento +ed essere chiamata da capo (da questo il nome) da un altro filone di +esecuzione (thread e manipolatori di segnali sono i casi in cui occorre +prestare attenzione a questa problematica) senza che questo comporti nessun +problema. + +In genere una funzione non è rientrante se opera direttamente su memoria che +non è nello stack. Ad esempio una funzione non è rientrante se usa una +variabile globale o statica od un oggetto allocato dinamicamente che trova da +sola: due chiamate alla stessa funzione interferiranno. Una funzione può non +essere rientrante se usa e modifica un oggetto che le viene fornito dal +chiamante: due chiamate possono interferire se viene passato lo stesso +oggetto. + +Le glibc mettono a disposizione due macro di compilatore \macro{\_REENTRANT} e +\macro{\_THREAD\_SAFE} per assicurare che siano usate delle versioni rientranti +delle funzioni di libreria. +