X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=blobdiff_plain;f=prochand.tex;h=09e1b59fbbd22c7bf9fa9eda3f1155c379fa193c;hb=60f259e7ef821c07d1361e44e134b7dbd1184fdb;hp=f8c99f2f6fee9b6263852139c93ceebd10845c34;hpb=5eb6fc6e2d60069d3a723309b7b490d0dd56113a;p=gapil.git diff --git a/prochand.tex b/prochand.tex index f8c99f2..09e1b59 100644 --- a/prochand.tex +++ b/prochand.tex @@ -728,10 +728,10 @@ 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à terminati, -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. +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}} @@ -970,18 +970,6 @@ 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} @@ -994,15 +982,10 @@ 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. -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. - 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 suo prototipo è: +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[])} @@ -1022,19 +1005,175 @@ front-end a \func{execve}. Il suo prototipo 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} - \item \macro{ENOENT} - \item \macro{ENOTDIR} - \item \macro{ETXTBSY} - \item \macro{ENFILE} - \item \macro{EMFILE} - \item \macro{EINVAL} - \item \macro{EISDIR} - \item \macro{ELIBBAD} + \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 + 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}. + 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=8cm]{img/exec_rel.eps} + \caption{La inter-relazione 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 resettatto 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, in +genere questo è fatto automaticamente dalla funzione \func{opendir} che +effettua il settaggio del flag in maniera trasparente all'utente. + + + + +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} @@ -1061,6 +1200,7 @@ 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 @@ -1121,3 +1261,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. + +