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
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.
sono stati creati, questo viene chiamato in genere \acr{ppid} (da
\textit{parent process id}). Questi due identificativi possono essere
ottenuti da programma usando le funzioni:
+
\begin{functions}
\headdecl{sys/types.h}
\headdecl{unistd.h}
\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
\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}).
\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}
(\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
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}).
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.
\textit{zombie} la tabella dei processi; le funzioni deputate a questo compito
sono sostanzialmente due, \func{wait} e \func{waitpid}. La prima, il cui
prototipo è:
+
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/wait.h}
ampie, legate anche al controllo di sessione. Dato che è possibile ottenere
lo stesso comportamento di \func{wait} si consiglia di utilizzare sempre
questa funzione; il suo prototipo è:
+
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/wait.h}
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
\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
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
\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}
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
\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
+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},
*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.
è 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.
\begin{figure}[htb]
\centering
\includegraphics[width=13cm]{img/exec_rel.eps}
- \caption{La inter-relazione fra le sei funzioni della famiglia \func{exec}}
+ \caption{La interrelazione fra le sei funzioni della famiglia \func{exec}}
\label{fig:proc_exec_relat}
\end{figure}
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
+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
\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 eseguitio il comando \cmd{interpreter [arg]
+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 è
\subsection{Utente e gruppo di un processo}
\label{sec:proc_user_group}
-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.
+Come accennato in \secref{sec:intro_multiuser} il modello base\footnote{in
+ realtà esistono estensioni di questo modello, che lo rendono più flessibile
+ e controllabile, come le \textit{capabilities}, le ACL per i file o il
+ modello a ``... NdT riprendere i dati'' di SELinux} di sicurezza di un
+sistema unix-like è fondato sui concetti di utente e gruppo, e sulla
+separazione fra l'amministratore, che non è sottoposto a restrizioni, e il
+resto degli utenti, per i quali vengono effettuati i vari controlli di
+accesso.
+
+%Benché il sistema sia piuttosto semplice il sistema permette una
+%notevole fles
-Abbiamo già incontrato in \secref{sec:file_perm_overview}
+Abbiamo già visto come il sistema associ ad ogni utente e gruppo due
+identificatori, lo \acr{uid} e il \acr{gid}, che li contraddistinguono e che
+sono questi quelli che vengono controllati dal kernel nella gestione di
+permessi e protezioni; in \secref{sec:file_access_control} si è visto come
+essi vengano utilizzati per il controllo di accesso ai file, vedremo ora come
+come sono usati nella gestione dei privilegi di accesso dei processi.
+In \secref{sec:file_perm_overview} abbiamo visto come ogni file appartenga ad
+un utente e ad un gruppo, e che il controllo di accesso viene eseguito sulla
+base del
Ad ogni processo è associato un certo numero di identificatori, il cui elenco
& \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
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 indetificatoru ai
+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
projects / gapil.git / blobdiff