%% prochand.tex
%%
-%% Copyright (C) 2000-2011 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2012 Simone Piccardi. Permission is granted to
%% copy, distribute and/or modify this document under the terms of the GNU Free
%% Documentation License, Version 1.1 or any later version published by the
%% Free Software Foundation; with the Invariant Sections being "Un preambolo",
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.\footnote{la cosa si fa passando la riga \cmd{init=/bin/sh} come
- parametro di avvio del kernel, l'argomento è di natura amministrativa e
+ parametro di avvio del kernel, l'argomento è di natura sistemistica e
trattato in sez.~5.3 di \cite{AGL}.}
\begin{figure}[!htb]
\end{funcproto}
\noindent esempi dell'uso di queste funzioni sono riportati in
-fig.~\ref{fig:proc_fork_code}, nel programma \file{ForkTest.c}.
+fig.~\ref{fig:proc_fork_code}, nel programma \file{fork\_test.c}.
Il fatto che il \ids{PID} sia un numero univoco per il sistema lo rende un
candidato per generare ulteriori indicatori associati al processo di cui
diventa possibile garantire l'unicità: ad esempio in alcune implementazioni la
funzione \func{tempnam} (si veda sez.~\ref{sec:file_temp_file}) usa il
-\ids{PID} per generare un \itindex{pathname} \textit{pathname} univoco, che
-non potrà essere replicato da un altro processo che usi la stessa
-funzione. Questo utilizzo però può risultare pericoloso, un \ids{PID} infatti
-è univoco solo fintanto che un processo è attivo, una volta terminato esso
-potrà essere riutilizzato da un processo completamente diverso, e di questo
-bisogna essere ben consapevoli.
+\ids{PID} per generare un \textit{pathname} univoco, che non potrà essere
+replicato da un altro processo che usi la stessa funzione. Questo utilizzo
+però può risultare pericoloso, un \ids{PID} infatti è univoco solo fintanto
+che un processo è attivo, una volta terminato esso potrà essere riutilizzato
+da un processo completamente diverso, e di questo bisogna essere ben
+consapevoli.
Tutti i processi figli dello stesso processo padre sono detti
\textit{sibling}, questa è una delle relazioni usate nel \textsl{controllo di
\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{\codesamplewidth}
- \includecodesample{listati/ForkTest.c}
+ \includecodesample{listati/fork_test.c}
\end{minipage}
\normalsize
- \caption{Esempio di codice per la creazione di nuovi processi.}
+ \caption{Esempio di codice per la creazione di nuovi processi (da
+ \file{fork\_test.c}).}
\label{fig:proc_fork_code}
\end{figure}
degli eventuali tempi di attesa in secondi (eseguiti tramite la funzione
\func{sleep}) per il padre ed il figlio (con \cmd{forktest -h} si ottiene la
descrizione delle opzioni). Il codice completo, compresa la parte che gestisce
-le opzioni a riga di comando, è disponibile nel file \file{ForkTest.c},
+le opzioni a riga di comando, è disponibile nel file \file{fork\_test.c},
distribuito insieme agli altri sorgenti degli esempi su
\url{http://gapil.truelite.it/gapil_source.tgz}.
\item gli identificatori per il controllo di sessione: il
\itindex{process~group} \textit{process group-ID} e il \textit{session id}
ed il terminale di controllo (vedi sez.~\ref{sec:sess_proc_group});
-\item la directory di lavoro e la directory radice (vedi
- sez.~\ref{sec:file_work_dir} e sez.~\ref{sec:file_chroot});
+\item la \index{directory~di~lavoro} directory di lavoro e la directory radice
+ (vedi sez.~\ref{sec:file_work_dir} e sez.~\ref{sec:file_chroot});
\item la maschera dei permessi di creazione dei file (vedi
sez.~\ref{sec:file_perm_management});
\item la maschera dei segnali bloccati (vedi sez.~\ref{sec:sig_sigmask}) e le
\end{itemize*}
Una seconda funzione storica usata per la creazione di un nuovo processo è
-\func{vfork}, che è esattamente identica a \func{fork} ed ha la stessa
+\funcm{vfork}, che è esattamente identica a \func{fork} ed ha la stessa
semantica e gli stessi errori; la sola differenza è che non viene creata la
tabella delle pagine né la struttura dei task per il nuovo processo. Il
processo padre è posto in attesa fintanto che il figlio non ha eseguito una
Abbiamo visto in sez.~\ref{sec:proc_conclusion} le tre modalità con cui un
programma viene terminato in maniera normale: la chiamata di \func{exit}, che
esegue le funzioni registrate per l'uscita e chiude gli \textit{stream} e poi
-esegue \func{\_exit}, il ritorno dalla funzione \func{main} equivalente alla
+esegue \func{\_exit}, il ritorno dalla funzione \code{main} equivalente alla
chiamata di \func{exit}, e la chiamata diretta a \func{\_exit}, che passa
direttamente alle operazioni di terminazione del processo da parte del kernel.
sez.~\ref{sec:proc_conclusion} che lo stato di uscita del processo viene
caratterizzato tramite il valore del cosiddetto \textit{exit status}, cioè il
valore passato come argomento alle funzioni \func{exit} o \func{\_exit} o il
-valore di ritorno per \func{main}. Ma se il processo viene concluso in
+valore di ritorno per \code{main}. Ma se il processo viene concluso in
maniera anomala il programma non può specificare nessun \textit{exit status},
ed è il kernel che deve generare autonomamente il \textit{termination status}
per indicare le ragioni della conclusione anomala.
significativi dello stato di uscita del
processo (passato attraverso
\func{\_exit}, \func{exit} o come valore
- di ritorno di \func{main}); può essere
+ di ritorno di \code{main}); può essere
valutata solo se \val{WIFEXITED} ha
restituito un valore non nullo.\\
\macro{WIFSIGNALED}\texttt{(s)} & Condizione vera se il processo figlio è
Si tenga conto che nel caso di conclusione anomala il valore restituito da
\val{WTERMSIG} può essere confrontato con le costanti che identificano i
-segnali definite in \file{signal.h} ed elencate in
+segnali definite in \headfile{signal.h} ed elencate in
tab.~\ref{tab:sig_signal_list}, e stampato usando le apposite funzioni
trattate in sez.~\ref{sec:sig_strsignal}.
per i valori dei primi tre argomenti, ma in più restituisce nell'argomento
aggiuntivo \param{rusage} un sommario delle risorse usate dal processo. Questo
argomento è una struttura di tipo \struct{rusage} definita in
-\file{sys/resource.h}, che viene utilizzata anche dalla funzione
+\headfile{sys/resource.h}, che viene utilizzata anche dalla funzione
\func{getrusage} per ottenere le risorse di sistema usate da un processo. La
sua definizione è riportata in fig.~\ref{fig:sys_rusage_struct} e ne
tratteremo in dettaglio il significato sez.~\ref{sec:sys_resource_use}. La
\item[\errcode{EACCES}] il file o l'interprete non file ordinari, o non sono
eseguibili, o il file è su un filesystem montato con l'opzione
\cmd{noexec}, o manca il permesso di attraversamento di una delle
- directory del pathname.
+ directory del \textit{pathname}.
\item[\errcode{EINVAL}] l'eseguibile ELF ha più di un segmento
\const{PF\_INTERP}, cioè chiede di essere eseguito da più di un
interprete.
\end{funcproto}
La funzione \func{execve} esegue il programma o lo script indicato dal
-pathname \param{filename}, passandogli la lista di argomenti indicata
+\textit{pathname} \param{filename}, passandogli la lista di argomenti indicata
da \param{argv} e come ambiente la lista di stringhe indicata
da \param{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
+nuovo programma quando la sua funzione \code{main} è dichiarata nella forma
\code{main(int argc, char *argv[], char *envp[])}. Si tenga presente per il
passaggio degli argomenti e dell'ambiente esistono comunque dei limiti, su cui
torneremo in sez.~\ref{sec:sys_res_limits}).
La prima differenza fra le funzioni riguarda le modalità di passaggio dei
valori che poi andranno a costituire gli argomenti a linea di comando (cioè i
-valori di \param{argv} e \param{argc} visti dalla funzione \func{main} del
+valori di \param{argv} e \param{argc} visti dalla funzione \code{main} del
programma chiamato). Queste modalità sono due e sono riassunte dagli mnemonici
``\texttt{v}'' e ``\texttt{l}'' che stanno rispettivamente per \textit{vector}
e \textit{list}.
specificare il comando da eseguire; quando l'argomento \param{file} non
contiene una ``\texttt{/}'' 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 directory specificate dalla variabile di ambiente \envvar{PATH}. Il file
+che viene posto in esecuzione è il primo che viene trovato. Se si ha un errore
relativo a permessi di accesso insufficienti (cioè l'esecuzione della
sottostante \func{execve} ritorna un \errcode{EACCES}), la ricerca viene
-proseguita nelle eventuali ulteriori directory indicate in \var{PATH}; solo se
-non viene trovato nessun altro file viene finalmente restituito
+proseguita nelle eventuali ulteriori directory indicate in \envvar{PATH}; solo
+se non viene trovato nessun altro file viene finalmente restituito
\errcode{EACCES}. Le altre quattro funzioni si limitano invece a cercare di
eseguire il file indicato dall'argomento \param{path}, che viene interpretato
-come il \itindex{pathname} \textit{pathname} del programma.
+come il \textit{pathname} del programma.
La terza differenza è come viene passata la lista delle variabili di ambiente.
Con lo mnemonico ``\texttt{e}'' vengono indicate quelle funzioni che
(\ids{PPID});
\item l'\textsl{user-ID reale}, il \textit{group-ID reale} ed i
\textsl{group-ID supplementari} (vedi sez.~\ref{sec:proc_access_id});
-\item la directory radice e la directory di lavoro corrente (vedi
- sez.~\ref{sec:file_work_dir});
+\item la directory radice e la \index{directory~di~lavoro} directory di lavoro
+ corrente (vedi sez.~\ref{sec:file_work_dir});
\item la maschera di creazione dei file \itindex{umask} (\textit{umask}, vedi
sez.~\ref{sec:file_perm_management}) ed i \textit{lock} sui file (vedi
sez.~\ref{sec:file_locking});
Infine per impostare i gruppi supplementari di un processo ci sono due
funzioni, che possono essere usate solo se si hanno i privilegi di
-amministratore.\footnote{e più precisamente se si ha la \itindex{capability}
+amministratore.\footnote{e più precisamente se si ha la \itindex{capabilities}
\textit{capability} \macro{CAP\_SETGID}.} La prima delle due è
\funcd{setgroups},\footnote{la funzione è definita in BSD e SRv4, ma a
differenza di \func{getgroups} non è stata inclusa in POSIX.1-2001, per
nell'argomento \param{which}, di leggere il valore di \textit{nice} di un
processo, di un gruppo di processi (vedi sez.~\ref{sec:sess_proc_group}) o di
un utente indicato dall'argomento \param{who}. Nelle vecchie versioni può
-essere necessario includere anche \code{sys/time.h}, questo non è più
+essere necessario includere anche \headfile{sys/time.h}, questo non è più
necessario con versioni recenti delle librerie, ma è comunque utile per
portabilità.
che per i primi la priorità statica può essere soltanto nulla. La
disponibilità di entrambe le funzioni può essere verificata controllando la
macro \macro{\_POSIX\_PRIORITY\_SCHEDULING} che è definita nell'\textit{header
- file} \file{sched.h}.
+ file} \headfile{sched.h}.
Se invece si vuole sapere quale è politica di \textit{scheduling} di un
processo si può usare la funzione \funcd{sched\_getscheduler}, il cui
aggiornata, o usate quella particolare versione delle \acr{glibc}, potrete
trovare indicazioni diverse, il prototipo illustrato è quello riportato
nella versione corrente (maggio 2008) delle pagine di manuale e
- corrispondente alla definizione presente in \file{sched.h}.}
+ corrispondente alla definizione presente in \headfile{sched.h}.}
La funzione imposta, con l'uso del valore contenuto all'indirizzo
\param{mask}, l'insieme dei processori sui quali deve essere eseguito il
predefinite del seguente elenco, che illustra quelle disponibili al
momento:\footnote{alla stesura di questa sezione, cioè con il kernel 3.2.}
-\begin{basedescript}{\desclabelstyle{\pushlabel}}
+\begin{basedescript}{\desclabelwidth{2.cm}\desclabelstyle{\nextlinelabel}}
\item[\const{PR\_CAPBSET\_READ}] Controlla la disponibilità di una delle
\itindex{capabilities} \textit{capabilities} (vedi
sez.~\ref{sec:proc_capabilities}). La funzione ritorna 1 se la capacità
impostato ad 1. Una volta abilitato il \itindex{secure~computing~mode}
\textit{secure computing mode} il processo potrà utilizzare soltanto un
insieme estremamente limitato di \textit{system call}: \func{read},
- \func{write}, \func{\_exit} e \func{sigreturn}. Ogni altra \textit{system
- call} porterà all'emissione di un \func{SIGKILL} (vedi
+ \func{write}, \func{\_exit} e \funcm{sigreturn}. Ogni altra \textit{system
+ call} porterà all'emissione di un \signal{SIGKILL} (vedi
sez.~\ref{sec:sig_termination}). Il \textit{secure computing mode} è stato
ideato per fornire un supporto per l'esecuzione di codice esterno non fidato
e non verificabile a scopo di calcolo;\footnote{lo scopo è quello di poter
funzione è totalmente inutile in quanto l'unico valore ottenibile è 0, dato
che la chiamata di questa funzione in \itindex{secure~computing~mode}
\textit{secure computing mode} comporterebbe l'emissione di
- \texttt{SIGKILL}, è stata comunque definita per eventuali estensioni future.
+ \signal{SIGKILL}, è stata comunque definita per eventuali estensioni future.
Introdotta a partire dal kernel 2.6.23.
\item[\const{PR\_SET\_SECUREBITS}] Imposta i \itindex{securebits}
tecnologie di virtualizzazione dei processi (i cosiddetti \textit{container}).
Per questo l'interfaccia per la creazione di un nuovo processo è stata
-delegata ad una nuova \textit{system call}, \func{sys\_clone}, che consente di
-reimplementare anche la tradizionale \func{fork}. In realtà in questo caso più
-che di nuovi processi si può parlare della creazioni di nuovi
+delegata ad una nuova \textit{system call}, \funcm{sys\_clone}, che consente
+di reimplementare anche la tradizionale \func{fork}. In realtà in questo caso
+più che di nuovi processi si può parlare della creazioni di nuovi
``\textit{task}'' del kernel che possono assumere la veste sia di un processo
classico isolato dagli altri come quelli trattati finora, che di un
\textit{thread} in cui la memoria viene condivisa fra il processo chiamante ed
riferimento al momento della stesura di questa sezione, cioè con il kernel
3.2.}
-\begin{basedescript}{\desclabelstyle{\pushlabel}}
+\begin{basedescript}{\desclabelwidth{2.cm}\desclabelstyle{\nextlinelabel}}
\item[\const{CLONE\_CHILD\_CLEARTID}] cancella il valore del \ids{TID}
\item[\const{CLONE\_CHILD\_SETTID}]
\end{basedescript}
+%TODO trattare unshare
+
+
\subsection{La funzione \func{ptrace}}
\label{sec:process_ptrace}
% LocalWords: nell'header scheduler system interrupt timer HZ asm Hertz clock
% LocalWords: l'alpha tick fork wait waitpid exit exec image glibc int pgid ps
% LocalWords: sid thread Ingo Molnar ppid getpid getppid sys unistd LD threads
-% LocalWords: void ForkTest tempnam pathname sibling cap errno EAGAIN ENOMEM
+% LocalWords: void tempnam pathname sibling cap errno EAGAIN ENOMEM
% LocalWords: stack read only copy write tab client spawn forktest sleep PATH
% LocalWords: source LIBRARY scheduling race condition printf descriptor dup
% LocalWords: close group session tms lock vfork execve BSD stream main abort
% LocalWords: namespace vsyscall SETTID FILES NEWIPC NEWNET NEWNS NEWPID ptid
% LocalWords: NEWUTS SETTLS SIGHAND SYSVSEM UNTRACED tls ctid CLEARTID panic
% LocalWords: loader EISDIR SIGTRAP uninterrutible killable EQUAL sizeof XOR
-% LocalWords: destset srcset ALLOC num cpus setsize emacs
+% LocalWords: destset srcset ALLOC num cpus setsize emacs pager getty TID
%%% Local Variables:
%%% mode: latex