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
risultato del comando \cmd{pstree} che permette di mostrare questa struttura,
-alla cui base c'è il \cmd{init} che è progenitore di tutti gli altri processi.
+alla cui base c'è \cmd{init} che è progenitore di tutti gli altri processi.
\subsection{Una panoramica sulle funzioni di gestione}
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}}
opportune opzioni tramite la variabile \var{option}. I valori possibili sono
il già citato \macro{WNOHANG}, che previene il blocco della funzione quando il
processo figlio non è terminato, e \macro{WUNTRACED} (usata per il controllo
-di sessione) 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 l'OR binario di zero con le suddette
-costanti.
-
-Entrambe le funzioni restituiscono lo stato di terminazione del processo
-tramite il puntatore \var{status} (se non interessa memorizzare lo stato si
-può passare un puntatore nullo). Il valore restituito da entrambe le funzioni
-dipende dall'implementazione, e tradizionalmente alcuni bit sono riservati per
-memorizzare lo stato di uscita (in genere 8) altri per indicare il segnale che
-ha causato la terminazione (in caso di conclusione anomala), uno per indicare
-se è stato generato un core file, etc.\footnote{le definizioni esatte si
- possono trovare in \file{<bits/waitstatus.h}, che non deve mai essere usato
- direttamente ma incluso attraverso \file{<sys/wait.h>}}. Lo standard
-POSIX.1 definisce una serie di macro di preprocessore da usare per analizzare
-lo stato di uscita; esse sono definite in \file{<sys/wait.h>} ed elencate in
-\ntab\ (si tenga presente che queste macro prendono come parametro la
-variabile di tipo \type{int} puntata da \var{status}).
-
+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.
+
+La terminazione di un processo figlio è chiaramente un evento asincrono
+rispetto all'esecuzione di un programma e può avvenire in un qualunque
+momento, per questo motivo, come si è visto nella sezione precedente, una
+delle azioni prese dal kernel alla conclusione di un processo è quella di
+mandare un segnale di \macro{SIGCHLD} al padre. Questo segnale viene ignorato
+di default, ma costituisce il meccanismo di comunicazione asincrona con cui il
+kernel avverte un processo padre che uno dei suoi figli è terminato.
+
+In genere in un programma non si vuole essere forzati ad attendere la
+conclusione di un processo per proseguire, specie se tutto questo serve solo
+per leggerne lo stato di chiusura (ed evitare la presenza di \textit{zombie}),
+per questo la modalità più usata per chiamare queste funzioni è quella di
+utilizzarle all'interno di un \textit{signal handler} (torneremo sui segnali e
+su come gestire \macro{SIGCHLD} in \secref{sec:sig_sigwait_xxx}) nel qual
+caso, dato che il segnale è generato dalla terminazione un figlio, avremo la
+certezza che la chiamata a \func{wait} non si bloccherà.
\begin{table}[!htb]
\centering
verificare lo stato di terminazione \var{s} di un processo.}
\label{tab:proc_status_macro}
\end{table}
-
-Come abbiamo appena visto una delle azioni prese dal kernel alla terminazione
-di un processo è quella di salvarne lo stato e mandare un segnale di
-\macro{SIGCHLD} al padre (torneremo su questa parte in \secref{sec:sig_xxx}).
+Entrambe le funzioni restituiscono lo stato di terminazione del processo
+tramite il puntatore \var{status} (se non interessa memorizzare lo stato si
+può passare un puntatore nullo). Il valore restituito da entrambe le funzioni
+dipende dall'implementazione, e tradizionalmente alcuni bit sono riservati per
+memorizzare lo stato di uscita (in genere 8) altri per indicare il segnale che
+ha causato la terminazione (in caso di conclusione anomala), uno per indicare
+se è stato generato un core file, etc.\footnote{le definizioni esatte si
+ possono trovare in \file{<bits/waitstatus.h} ma questo file non deve mai
+ essere usato direttamente, esso viene incluso attraverso
+ \file{<sys/wait.h>}}. Lo standard POSIX.1 definisce una serie di macro di
+preprocessore da usare per analizzare lo stato di uscita; esse sono definite
+sempre in \file{<sys/wait.h>} ed elencate in \curtab\ (si tenga presente che
+queste macro prendono come parametro la variabile di tipo \type{int} puntata
+da \var{status}).
+
+Si tenga conto che nel caso di conclusione anomala il valore restituito da
+\macro{WTERMSIG} può essere controllato contro le costanti definite in
+\file{signal.h}, e stampato usando le funzioni definite in
+\secref{sec:sig_strsignal}.
+
+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:
+\begin{functions}
+ \headdecl{sys/times.h}
+ \headdecl{sys/types.h}
+ \headdecl{sys/wait.h}
+ \headdecl{sys/resource.h}
+ \funcdecl{pid\_t wait4(pid\_t pid, int * status, int options, struct rusage
+ * rusage)}
+ 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}.
+\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
+sistema usate dal processo; in Linux è definita come:
+\begin{figure}[!htb]
+ \footnotesize
+ \centering
+ \begin{minipage}[c]{15cm}
+ \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
+struct rusage {
+ struct timeval ru_utime; /* user time used */
+ struct timeval ru_stime; /* system time used */
+ long ru_maxrss; /* maximum resident set size */
+ long ru_ixrss; /* integral shared memory size */
+ long ru_idrss; /* integral unshared data size */
+ long ru_isrss; /* integral unshared stack size */
+ long ru_minflt; /* page reclaims */
+ long ru_majflt; /* page faults */
+ long ru_nswap; /* swaps */
+ long ru_inblock; /* block input operations */
+ long ru_oublock; /* block output operations */
+ long ru_msgsnd; /* messages sent */
+ long ru_msgrcv; /* messages received */
+ long ru_nsignals; ; /* signals received */
+ long ru_nvcsw; /* voluntary context switches */
+ long ru_nivcsw; /* involuntary context switches */
+};
+ \end{lstlisting}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \texttt{rusage} per la lettura delle informazioni dei
+ delle risorse usate da un processo.}
+ \label{fig:proc_rusage_struct}
+\end{figure}
+In genere includere esplicitamente \file{<sys/time.h>} non è più necessario,
+ma aumenta la portabiltà, 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 funzioni \texttt{exec}}
\label{sec:proc_exec}
+Abbiamo già detto che una delle modalità principali con cui si utilizzano i
+processi in unix è quella di usarli per lanciare nuovi programmi: questo viene
+fatto attraverso una delle funzioni della famiglia \func{exec}. Quando un
+processo chiama una di queste funzioni esso viene completamente sostituito dal
+nuovo programma; il \acr{pid} del processo non cambia, dato che non viene
+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.
+
+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'ultima è:
+
+\begin{prototype}{unistd.h}
+{int execve(const char * filename, char * const argv [], char * const envp[])}
+
+ La funzione esegue il file o lo script indicato da \var{filename},
+ passandogli la lista di argomenti indicata da \var{argv} e come ambiente la
+ lista di stringhe indicata da \var{envp}; entrambe le liste devono essere
+ terminate da un puntatore nullo. I vettori degli argomenti e dell'ambiente
+ possono essere acceduti dal nuovo programma quando la sua funzione
+ \func{main} è dichiarata nella forma \func{main(int argc, char *argv[], char
+ *envp[])}.
+
+ La funzione ritorna -1 solo in caso di errore, nel qual caso caso la
+ variabile \texttt{errno} è settata come:
+ \begin{errlist}
+ \item \macro{EACCES} il file non è eseguibile, oppure il filesystem è
+ 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} 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}, \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 necessitano del \textit{pathname} assoluto del
+programma come valore del parametro \var{path}. Le altre quattro funzioni
+invece usano come parametro \var{file} un nome che viene cercato
+automaticamente fra i file presenti nella lista di directory specificate dalla
+variabile di ambiente \var{PATH}.
+
+
+La terza differenza è .
+
+
+
+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}
\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|l|}
+ \begin{tabular}[c]{|c|l|p{8cm}|}
\hline
- Sigla & Significato & Utilizzo \\
+ \textbf{Sigla} & \textbf{Significato} & \textbf{Utilizzo} \\
\hline
\hline
\acr{ruid} & \textit{real user id} & indica l'utente reale che ha lanciato
\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.
+
+
projects / gapil.git / blobdiff