X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=prochand.tex;h=741496827f564a4894f4b0d482b20d87e60e5199;hp=57ba6abf5fba57720b0bca5372436a964a23e805;hb=4ad4523de32d786ae4c24ef157bd4b8fe4aac534;hpb=1c947e9304d40b64591837ced98125fa3839126e diff --git a/prochand.tex b/prochand.tex index 57ba6ab..7414968 100644 --- a/prochand.tex +++ b/prochand.tex @@ -30,35 +30,35 @@ qualunque processo pu numero unico, il cosiddetto \textit{process identifier} o, più brevemente, \acr{pid}. -Una seconda caratteristica è che la generazione di un processo è una -operazione separata rispetto al lancio di un programma. In genere la sequenza -è sempre quella di creare un nuovo processo, il quale eseguirà, in un passo -successivo, il programma voluto: questo è ad esempio quello che fa la shell -quando mette in esecuzione il programma che gli indichiamo nella linea di -comando. - -Una terza caratteristica è che ogni processo viene sempre generato da un altro -che viene chiamato processo padre (\textit{parent process}). Questo vale per -tutti i processi, con una sola eccezione: dato che ci deve essere un punto di -partenza esiste sempre un processo speciale (che normalmente è +Una seconda caratteristica di un sistema unix è che la generazione di un +processo è una operazione separata rispetto al lancio di un programma. In +genere la sequenza è sempre quella di creare un nuovo processo, il quale +eseguirà, in un passo successivo, il programma voluto: questo è ad esempio +quello che fa la shell quando mette in esecuzione il programma che gli +indichiamo nella linea di comando. + +Una terza caratteristica è che ogni processo è sempre stato generato da un +altro, che viene chiamato processo padre (\textit{parent process}). Questo +vale per tutti i processi, con una sola eccezione: dato che ci deve essere un +punto di partenza esiste un processo speciale (che normalmente è \cmd{/sbin/init}), che viene lanciato dal kernel alla conclusione della fase -di avvio, essendo questo il primo processo lanciato dal sistema ha sempre il +di avvio; essendo questo il primo processo lanciato dal sistema ha sempre il \acr{pid} uguale a 1 e non è figlio di nessun altro processo. Ovviamente \cmd{init} è un processo speciale che in genere si occupa di far partire tutti gli altri processi necessari al funzionamento del sistema, inoltre \cmd{init} è essenziale per svolgere una serie di compiti -amministrativi nelle operazioni ordinarie del sistema (torneremo si alcuni di +amministrativi nelle operazioni ordinarie del sistema (torneremo su alcuni di essi in \secref{sec:proc_termination}) e non può mai essere terminato. La struttura del sistema comunque consente di lanciare al posto di \cmd{init} -qualunque altro programma (e in casi di emergenza, ad esempio se il file di -\cmd{init} si fosse corrotto, è ad esempio possibile lanciare una shell al suo -posto, passando la riga \cmd{init=/bin/sh} come parametro di avvio). +qualunque altro programma, e in casi di emergenza (ad esempio se il file di +\cmd{init} si fosse corrotto) è ad esempio possibile lanciare una shell al suo +posto, passando la riga \cmd{init=/bin/sh} come parametro di avvio. \begin{figure}[!htb] \footnotesize \begin{verbatim} -[piccardi@selidor piccardi]$ pstree -n +[piccardi@gont piccardi]$ pstree -n init-+-keventd |-kapm-idled |-kreiserfsd @@ -103,7 +103,7 @@ Dato che tutti i processi attivi nel sistema sono comunque generati da kernel, (come \cmd{keventd}, \cmd{kswapd}, etc.)} si possono classificare i processi con la relazione padre/figlio in una organizzazione gerarchica ad albero, in maniera analoga a come i file sono organizzati in un albero di -directory (si veda \secref{sec:file_file_struct}); in \nfig\ si è mostrato il +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. @@ -189,6 +189,7 @@ ottenuti da programma usando le funzioni: \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 @@ -529,7 +530,7 @@ padre e figlio avranno in comune: \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 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}). @@ -609,7 +610,7 @@ eseguite alla chiusura di un processo \item se il processo è un leader di sessione viene mandato un segnale di \macro{SIGHUP} a tutti i processi in background e il terminale di controllo viene disconnesso. -\item se la conclusione di un processe rende orfano un \textit{process group} +\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} @@ -620,7 +621,7 @@ 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 tremite il valore del cosiddetto \textit{exit status}, cioè il +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 @@ -637,7 +638,7 @@ 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 protrebbe essere già +che sia così alla sua conclusione, dato che il padre potrebbe essere già terminato (si potrebbe avere cioè quello che si chiama un processo \textsl{orfano}). @@ -686,7 +687,7 @@ ma il cui stato di terminazione non chiamati \textit{zombie}, essi restano presenti nella tabella dei processi ed in genere possono essere identificati dall'output di \cmd{ps} per la presenza di una \cmd{Z} nella colonna che ne indica lo stato. Quando il padre -effettuarà la lettura dello stato di uscita anche questa informazione, non più +effettuerà la lettura dello stato di uscita anche questa informazione, non più necessaria, verrà scartata e la terminazione potrà dirsi completamente conclusa. @@ -831,7 +832,7 @@ processo figlio non di sessione, trattato in \capref{cha:session}) che fa ritornare la funzione anche per i processi figli che sono bloccati ed il cui stato non è stato ancora riportato al padre. Il valore dell'opzione deve essere specificato come -mashera binaria ottenuta con l'OR delle suddette costanti con zero. +maschera binaria ottenuta con l'OR delle suddette costanti con zero. La terminazione di un processo figlio è chiaramente un evento asincrono rispetto all'esecuzione di un programma e può avvenire in un qualunque @@ -852,6 +853,7 @@ 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}\\ @@ -862,16 +864,16 @@ certezza che la chiamata a \func{wait} non si bloccher \macro{WEXITSTATUS(s)} & Restituisce gli otto bit meno significativi dello stato di uscita del processo (passato attraverso \func{\_exit}, \func{exit} o come valore di ritorno di \func{main}). Può essere valutata solo se - \macro{WIFEXITED} ha restitituito un valore non nullo.\\ + \macro{WIFEXITED} ha restituito un valore non nullo.\\ \macro{WIFSIGNALED(s)} & Vera se il processo figlio è terminato in maniera anomala a causa di un segnale che non è stato catturato (vedi \secref{sec:sig_notification}).\\ \macro{WTERMSIG(s)} & restituisce il numero del segnale che ha causato la terminazione anomala del processo. Può essere valutata solo se - \macro{WIFSIGNALED} ha restitituito un valore non nullo.\\ + \macro{WIFSIGNALED} ha restituito un valore non nullo.\\ \macro{WCOREDUMP(s)} & Vera se il processo terminato ha generato un file si \textit{core dump}. Può essere valutata solo se - \macro{WIFSIGNALED} ha restitituito un valore non nullo\footnote{questa + \macro{WIFSIGNALED} ha restituito un valore non nullo\footnote{questa macro non è definita dallo standard POSIX.1, ma è presente come estensione sia in Linux che in altri unix}.\\ \macro{WIFSTOPPED(s)} & Vera se il processo che ha causato il ritorno di @@ -879,7 +881,7 @@ certezza che la chiamata a \func{wait} non si bloccher l'opzione \macro{WUNTRACED}. \\ \macro{WSTOPSIG(s)} & restituisce il numero del segnale che ha bloccato il processo, Può essere valutata solo se \macro{WIFSTOPPED} ha - restitituito un valore non nullo. \\ + restituito un valore non nullo. \\ \hline \end{tabular} \caption{Descrizione delle varie macro di preprocessore utilizzabili per @@ -908,13 +910,16 @@ Si tenga conto che nel caso di conclusione anomala il valore restituito da \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 diventano accessibili definendo la costante \macro{\_USE\_BSD} -sono: +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} @@ -926,9 +931,9 @@ sono: 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}. + \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 @@ -964,24 +969,12 @@ struct rusage { \label{fig:proc_rusage_struct} \end{figure} In genere includere esplicitamente \file{} non è più necessario, -ma aumenta la portabiltà, e serve in caso si debba accedere ai campi di +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 \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. - - \subsection{Le funzioni \texttt{exec}} \label{sec:proc_exec} @@ -997,7 +990,7 @@ 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'utiltima è: +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[])} @@ -1011,7 +1004,7 @@ front-end a \func{execve}. Il prototipo di quest'utiltima *envp[])}. La funzione ritorna -1 solo in caso di errore, nel qual caso caso la - variabile \texttt{errno} è settata come: + \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. @@ -1019,7 +1012,7 @@ front-end a \func{execve}. Il prototipo di quest'utiltima è 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'inteprete + \item \macro{ENOENT} il file o una delle librerie dinamiche o l'interprete necessari per eseguirlo non esistono. \item \macro{ETXTBSY} L'eseguibile è aperto in scrittura da uno o più processi. @@ -1033,13 +1026,180 @@ front-end a \func{execve}. Il prototipo di quest'utiltima \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. +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. -Con \func{exec} si chiude il cerchio delle funzioni su cui si basa 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. \section{Il controllo di accesso} @@ -1047,25 +1207,34 @@ effettua e si gestisce la conclusione dei programmi. 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. +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} 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. +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 @@ -1083,7 +1252,7 @@ gestione dei privilegi associati ai processi stessi. & \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{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 @@ -1097,26 +1266,31 @@ gestione dei privilegi associati ai processi stessi. 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). + +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 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. +\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 all'avvio del processo, prima che -\textit{effective user id} e \textit{effective group id} vengano modificati -per tener conto di eventuali \acr{suid} o \acr{sgid}. +processo padre, e vengono settati dalla funzione \func{exec} all'avvio del +processo, 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. \subsection{Le funzioni \texttt{setuid} e \texttt{setgid}} @@ -1126,3 +1300,16 @@ per tener conto di eventuali \acr{suid} o \acr{sgid}. \subsection{Le funzioni \texttt{seteuid} e \texttt{setegid}} \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. + +