%% 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]
Come accennato nella sezione precedente ogni processo viene identificato dal
sistema da un numero identificativo univoco, il \textit{process ID} o
\ids{PID}. Questo è un tipo di dato standard, \type{pid\_t} che in genere è un
-intero con segno (nel caso di Linux e delle \acr{glibc} il tipo usato è
+intero con segno (nel caso di Linux e della \acr{glibc} il tipo usato è
\ctyp{int}).
Il \ids{PID} viene assegnato in forma progressiva ogni volta che un nuovo
Tutti i processi inoltre memorizzano anche il \ids{PID} del genitore da cui
sono stati creati, questo viene chiamato in genere \ids{PPID} (da
\itindex{Parent~Process~ID~(PPID)} \textit{Parent Process ID}). Questi due
-identificativi possono essere ottenuti usando le due funzioni \funcd{getpid} e
-\funcd{getppid}, i cui prototipi sono:
+identificativi possono essere ottenuti usando le due funzioni di sistema
+\funcd{getpid} e \funcd{getppid}, i cui prototipi sono:
\begin{funcproto}{
\fhead{sys/types.h}
\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
\subsection{La funzione \func{fork} e le funzioni di creazione dei processi}
\label{sec:proc_fork}
-La funzione \funcd{fork} è la funzione fondamentale della gestione dei
-processi: come si è detto tradizionalmente l'unico modo di creare un nuovo
+La funzione di sistema \funcd{fork} è la funzione fondamentale della gestione
+dei processi: come si è detto tradizionalmente l'unico modo di creare un nuovo
processo era attraverso l'uso di questa funzione,\footnote{in realtà oggi la
\textit{system call} usata da Linux per creare nuovi processi è \func{clone}
- (vedi \ref{sec:process_clone}), anche perché a partire dalle \acr{glibc}
+ (vedi \ref{sec:process_clone}), anche perché a partire dalla \acr{glibc}
2.3.3 non viene più usata la \textit{system call} originale, ma la stessa
\func{fork} viene implementata tramite \func{clone}, cosa che consente una
migliore interazione coi \textit{thread}.} essa quindi riveste un ruolo
\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}.
Un secondo aspetto molto importante nella creazione dei processi figli è
quello dell'interazione dei vari processi con i file. Ne parleremo qui anche
se buona parte dei concetti relativi ai file verranno trattati più avanti
-(principalmente nel cap.~\ref{cha:file_unix_interface}). Per illustrare meglio
+(principalmente in sez.~\ref{sec:file_unix_interface}). Per illustrare meglio
quello che avviene si può redirigere su un file l'output del programma di
test, quello che otterremo è:
\begin{Command}
che come si vede è completamente diverso da quanto ottenevamo sul terminale.
Il comportamento delle varie funzioni di interfaccia con i file è analizzato
-in gran dettaglio in cap.~\ref{cha:file_unix_interface} per l'interfaccia
-nativa Unix ed in cap.~\ref{cha:files_std_interface} per la standardizzazione
+in gran dettaglio in sez.~\ref{sec:file_unix_interface} per l'interfaccia
+nativa Unix ed in sez.~\ref{sec:files_std_interface} per la standardizzazione
adottata nelle librerie del linguaggio C e valida per qualunque sistema
operativo. Qui basta accennare che si sono usate le funzioni standard della
libreria del C che prevedono l'output bufferizzato. Il punto è che questa
L'esempio ci mostra un altro aspetto fondamentale dell'interazione con i file,
valido anche per l'esempio precedente, ma meno evidente: il fatto cioè che non
solo processi diversi possono scrivere in contemporanea sullo stesso file
-(l'argomento della condivisione dei file è trattato in dettaglio in
-sez.~\ref{sec:file_sharing}), ma anche che, a differenza di quanto avviene per
-le variabili in memoria, la posizione corrente sul file è condivisa fra il
-padre e tutti i processi figli.
+(l'argomento dell'accesso concorrente ai file è trattato in dettaglio in
+sez.~\ref{sec:file_shared_access}), ma anche che, a differenza di quanto
+avviene per le variabili in memoria, la posizione corrente sul file è
+condivisa fra il padre e tutti i processi figli.
Quello che succede è che quando lo \textit{standard output}\footnote{si chiama
così il file su cui un programma scrive i suoi dati in uscita, tratteremo
- l'argomento in dettaglio in sez.~\ref{sec:file_std_descr}.} del padre viene
+ l'argomento in dettaglio in sez.~\ref{sec:file_fd}.} del padre viene
rediretto come si è fatto nell'esempio, lo stesso avviene anche per tutti i
figli. La funzione \func{fork} infatti ha la caratteristica di duplicare nei
processi figli tutti i \textit{file descriptor} (vedi sez.~\ref{sec:file_fd})
dei file aperti nel processo padre (allo stesso modo in cui lo fa la funzione
\func{dup}, trattata in sez.~\ref{sec:file_dup}), il che comporta che padre e
figli condividono le stesse voci della \itindex{file~table} \textit{file
- table} (tratteremo in dettagli questi termini in
-sez.~\ref{sec:file_sharing}) fra cui c'è anche la posizione corrente nel file.
+ table} (tratteremo in dettaglio questi termini in
+sez.~\ref{sec:file_shared_access}) fra cui c'è anche la posizione corrente nel
+file.
In questo modo se un processo scrive su un file aggiornerà la posizione
corrente sulla \itindex{file~table} \textit{file table}, e tutti gli altri
\begin{itemize*}
\item i file aperti e gli eventuali flag di \itindex{close-on-exec}
\textit{close-on-exec} impostati (vedi sez.~\ref{sec:proc_exec} e
- sez.~\ref{sec:file_fcntl});
+ sez.~\ref{sec:file_fcntl_ioctl});
\item gli identificatori per il controllo di accesso: l'\textsl{user-ID
reale}, il \textsl{group-ID reale}, l'\textsl{user-ID effettivo}, il
\textsl{group-ID effettivo} ed i \textit{group-ID supplementari} (vedi
\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.
Si è già sottolineato al paragrafo precedente come in questo caso diventi
necessario gestire esplicitamente la conclusione dei figli onde evitare di
riempire di \itindex{zombie} \textit{zombie} la tabella dei
-processi. Tratteremo in questa sezione le funzioni deputate a questo compito;
-la prima è \funcd{wait} ed il suo prototipo è:
+processi. Tratteremo in questa sezione le funzioni di sistema deputate a
+questo compito; la prima è \funcd{wait} ed il suo prototipo è:
\begin{funcproto}{
\fhead{sys/types.h}
sez.~\ref{sec:sess_job_control}). Dato che è possibile ottenere lo stesso
comportamento di \func{wait}\footnote{in effetti il codice
\code{wait(\&status)} è del tutto equivalente a \code{waitpid(WAIT\_ANY,
- \&status, 0)}.} si consiglia di utilizzare sempre questa nuova funzione,
-\funcd{waitpid}, il cui prototipo è:
+ \&status, 0)}.} si consiglia di utilizzare sempre questa nuova funzione di
+sistema, \funcd{waitpid}, il cui prototipo è:
\begin{funcproto}{
\fhead{sys/types.h}
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}.
A partire dal kernel 2.6.9, sempre in conformità allo standard POSIX.1-2001, è
stata introdotta una nuova funzione di attesa che consente di avere un
controllo molto più preciso sui possibili cambiamenti di stato dei processi
-figli e più dettagli sullo stato di uscita; la funzione è \funcd{waitid} ed il
-suo prototipo è:
+figli e più dettagli sullo stato di uscita; la funzione di sistema è
+\funcd{waitid} ed il suo prototipo è:
\begin{funcproto}{
\fhead{sys/types.h}
precedenti ma che prevedono un ulteriore argomento attraverso il quale il
kernel può restituire al padre informazioni sulle risorse (vedi
sez.~\ref{sec:sys_res_limits}) usate dal processo terminato e dai vari figli.
-Le due funzioni sono \funcd{wait3} e \funcd{wait4}, che diventano accessibili
-definendo la macro \macro{\_USE\_BSD}, i loro prototipi sono:
+Le due funzioni di sistema sono \funcd{wait3} e \funcd{wait4}, che diventano
+accessibili definendo la macro \macro{\_USE\_BSD}, i loro prototipi sono:
\begin{funcproto}{
\fhead{sys/types.h}
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
-\code{main(int argc, char *argv[], char *envp[])}.
+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}).
+% TODO aggiungere la parte sul numero massimo di argomenti, da man execve
In caso di successo la funzione non ritorna, in quanto al posto del programma
chiamante viene eseguito il nuovo programma indicato da \param{filename}. Se
sez.~\ref{sec:process_ptrace}) in caso di successo viene emesso il segnale
\signal{SIGTRAP}.
-% TODO aggiungere la parte sul numero massimo di argomenti, da man execve
-
Le altre funzioni della famiglia (\funcd{execl}, \funcd{execv},
\funcd{execle}, \funcd{execlp}, \funcd{execvp}) servono per fornire all'utente
una serie di possibili diverse interfacce nelle modalità di passaggio degli
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}.
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{figure}[!htb]
- \centering \includegraphics[width=12cm]{img/exec_rel}
+ \centering \includegraphics[width=10cm]{img/exec_rel}
\caption{La interrelazione fra le sei funzioni della famiglia \func{exec}.}
\label{fig:proc_exec_relat}
\end{figure}
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});
La gestione dei file aperti nel passaggio al nuovo programma lanciato con
\func{exec} dipende dal valore che ha il flag di \itindex{close-on-exec}
-\textit{close-on-exec} (vedi sez.~\ref{sec:file_fcntl}) per ciascun
+\textit{close-on-exec} (vedi sez.~\ref{sec:file_fcntl_ioctl}) per ciascun
\textit{file descriptor}. I file per cui è impostato vengono chiusi, tutti gli
altri file restano aperti. Questo significa che il comportamento predefinito è
che i file restano aperti attraverso una \func{exec}, a meno di una chiamata
programma è in formato ELF per caricare le librerie dinamiche viene usato
l'interprete indicato nel segmento \const{PT\_INTERP} previsto dal formato
stesso, in genere questo è \sysfile{/lib/ld-linux.so.1} per programmi
-collegati con le \acr{libc5}, e \sysfile{/lib/ld-linux.so.2} per programmi
-collegati con le \acr{glibc}.
+collegati con la \acr{libc5}, e \sysfile{/lib/ld-linux.so.2} per programmi
+collegati con la \acr{glibc}.
Infine nel caso il programma che si vuole eseguire sia uno script e non un
binario, questo deve essere un file di testo che deve iniziare con una linea
Come nel caso del \ids{PID} e del \ids{PPID}, anche tutti questi
identificatori possono essere ottenuti da un programma attraverso altrettante
-funzioni di lettura, queste sono \funcd{getuid}, \funcd{geteuid},
-\funcd{getgid} e \funcd{getegid}, ed i loro prototipi sono:
+funzioni di sistema dedicate alla loro lettura, queste sono \funcd{getuid},
+\funcd{geteuid}, \funcd{getgid} e \funcd{getegid}, ed i loro prototipi sono:
\begin{funcproto}{
\fhead{unistd.h}
\subsection{Le funzioni di gestione degli identificatori dei processi}
\label{sec:proc_setuid}
-Le due funzioni più comuni che vengono usate per cambiare identità (cioè
-utente e gruppo di appartenenza) ad un processo sono rispettivamente
-\funcd{setuid} e \funcd{setgid}; come accennato in
-sez.~\ref{sec:proc_access_id} in Linux esse seguono la semantica POSIX che
-prevede l'esistenza dell'\ids{UID} salvato e del \ids{GID} salvato; i loro
-prototipi sono:
+Le funzioni di sistema più comuni che vengono usate per cambiare identità
+(cioè utente e gruppo di appartenenza) ad un processo, e che come accennato in
+sez.~\ref{sec:proc_access_id} seguono la semantica POSIX che prevede
+l'esistenza dell'\ids{UID} salvato e del \ids{GID} salvato, sono
+rispettivamente \funcd{setuid} e \funcd{setgid}; i loro prototipi sono:
\begin{funcproto}{
\fhead{unistd.h}
l'\ids{UID} effettivo del processo per cedere i privilegi occorre
ricorrere ad altre funzioni.
-Le due funzioni \funcd{setreuid} e \funcd{setregid} derivano da BSD che, non
-supportando (almeno fino alla versione 4.3+BSD) gli identificatori del gruppo
-\textit{saved}, le usa per poter scambiare fra di loro \textit{effective} e
-\textit{real}; i rispettivi prototipi sono:
+Le due funzioni di sistema \funcd{setreuid} e \funcd{setregid} derivano da BSD
+che, non supportando (almeno fino alla versione 4.3+BSD) gli identificatori
+del gruppo \textit{saved}, le usa per poter scambiare fra di loro
+\textit{effective} e \textit{real}; i rispettivi prototipi sono:
\begin{funcproto}{
\fhead{unistd.h}
diverso da quello dall'\ids{UID} reale corrente, l'\ids{UID} salvato viene
automaticamente uniformato al valore dell'\ids{UID} effettivo.
-Altre due funzioni, \funcd{seteuid} e \funcd{setegid}, sono un'estensione
-dello standard POSIX.1, ma sono comunque supportate dalla maggior parte degli
-Unix, esse vengono usate per cambiare gli identificatori del gruppo
-\textit{effective} ed i loro prototipi sono:
+Altre due funzioni di sistema, \funcd{seteuid} e \funcd{setegid}, sono
+un'estensione dello standard POSIX.1, ma sono comunque supportate dalla
+maggior parte degli Unix, esse vengono usate per cambiare gli identificatori
+del gruppo \textit{effective} ed i loro prototipi sono:
\begin{funcproto}{
\fhead{unistd.h}
dato che l'uso normale di \func{setuid} comporta l'impostazione di tutti gli
identificatori.
-Le due funzioni \funcd{setresuid} e \funcd{setresgid} sono invece
+Le due funzioni di sistema \funcd{setresuid} e \funcd{setresgid} sono invece
un'estensione introdotta in Linux (a partire dal kernel 2.1.44) e permettono
un completo controllo su tutti e tre i gruppi di identificatori
(\textit{real}, \textit{effective} e \textit{saved}), i loro prototipi sono:
di $-1$ per un qualunque argomento lascia inalterato l'identificatore
corrispondente.
-Per queste funzioni esistono anche due controparti, \funcd{getresuid} e
-\funcd{getresgid},\footnote{le funzioni non sono standard, anche se appaiono
- in altri kernel, su Linux sono presenti dal kernel 2.1.44 e con le versioni
- della \acr{glibc} a partire dalla 2.3.2, definendo la macro
- \macro{\_GNU\_SOURCE}.} che permettono di leggere in blocco i vari
+Per queste funzioni di sistema esistono anche due controparti,
+\funcd{getresuid} e \funcd{getresgid},\footnote{le funzioni non sono standard,
+ anche se appaiono in altri kernel, su Linux sono presenti dal kernel 2.1.44
+ e con le versioni della \acr{glibc} a partire dalla 2.3.2, definendo la
+ macro \macro{\_GNU\_SOURCE}.} che permettono di leggere in blocco i vari
identificatori; i loro prototipi sono:
\begin{funcproto}{
originari per quanto riguarda tutti gli altri controlli di accesso, così che
l'utente non possa inviare segnali al server NFS.
-Le due funzioni usate per cambiare questi identificatori sono \funcd{setfsuid}
-e \funcd{setfsgid}, ed ovviamente sono specifiche di Linux e non devono essere
-usate se si intendono scrivere programmi portabili; i loro prototipi sono:
+Le due funzioni di sistema usate per cambiare questi identificatori sono
+\funcd{setfsuid} e \funcd{setfsgid}, ed ovviamente sono specifiche di Linux e
+non devono essere usate se si intendono scrivere programmi portabili; i loro
+prototipi sono:
\begin{funcproto}{
\fhead{sys/fsuid.h}
gruppi supplementari cui un utente può appartenere. Ogni processo può avere
almeno \const{NGROUPS\_MAX} gruppi supplementari\footnote{il numero massimo di
gruppi secondari può essere ottenuto con \func{sysconf} (vedi
- sez.~\ref{sec:sys_sysconf}), leggendo il parametro
+ sez.~\ref{sec:sys_limits}), leggendo il parametro
\texttt{\_SC\_NGROUPS\_MAX}.} in aggiunta al gruppo primario; questi vengono
ereditati dal processo padre e possono essere cambiati con queste funzioni.
-La funzione che permette di leggere i gruppi supplementari associati ad un
-processo è \funcd{getgroups}; questa funzione è definita nello standard
-POSIX.1, ed il suo prototipo è:
+La funzione di sistema che permette di leggere i gruppi supplementari
+associati ad un processo è \funcd{getgroups}; questa funzione è definita nello
+standard POSIX.1, ed il suo prototipo è:
\begin{funcproto}{
\fhead{sys/types.h}
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}
- \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
+amministratore.\footnote{e più precisamente se si ha la \itindex{capabilities}
+ \textit{capability} \macro{CAP\_SETGID}.} La prima delle due è la funzione
+di sistema \funcd{setgroups},\footnote{la funzione è definita in BSD e SRv4,
+ ma a differenza di \func{getgroups} non è stata inclusa in POSIX.1-2001, per
poterla utilizzare deve essere definita la macro \macro{\_BSD\_SOURCE}.} ed
il suo prototipo è:
che si possono impostare è un parametro di sistema, che può essere ricavato
con le modalità spiegate in sez.~\ref{sec:sys_characteristics}.
-Se invece si vogliono impostare i gruppi supplementari del processo a quelli di
-un utente specifico, si può usare \funcd{initgroups} il cui prototipo è:
+Se invece si vogliono impostare i gruppi supplementari del processo a quelli
+di un utente specifico, si può usare la funzione \funcd{initgroups} il cui
+prototipo è:
\begin{funcproto}{
\fhead{sys/types.h}
di adeguati privilegi, di diminuire un valore di \textit{nice} precedentemente
innalzato.
-Fino alle \acr{glibc} 2.2.4 la funzione di libreria riportava direttamente il
+Fino alla \acr{glibc} 2.2.4 la funzione di libreria riportava direttamente il
risultato dalla \textit{system call}, violando lo standard, per cui per
ottenere il nuovo valore occorreva una successiva chiamata alla funzione
\func{getpriority}. A partire dalla \acr{glibc} 2.2.4 \func{nice} è stata
verificarne il valore quando \func{nice} restituisce $-1$.
Per leggere il valore di \textit{nice} di un processo occorre usare la
-funzione \funcd{getpriority}, derivata da BSD; il suo prototipo è:
+funzione di sistema \funcd{getpriority}, derivata da BSD; il suo prototipo è:
\begin{funcproto}{
\fhead{sys/time.h}
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à.
quando si ottiene un valore di ritorno uguale a $-1$ per verificare che essa
resti uguale a zero.
-Analoga a \func{getpriority} è la funzione \funcd{setpriority} che permette di
-impostare la priorità di uno o più processi; il suo prototipo è:
+Analoga a \func{getpriority} è la funzione di sistema \funcd{setpriority} che
+permette di impostare la priorità di uno o più processi; il suo prototipo è:
\begin{funcproto}{
\fhead{sys/time.h}
Lo standard POSIX.1-2001 prevede una funzione che consenta sia di modificare
le politiche di \textit{scheduling}, passando da \textit{real-time} a
ordinarie o viceversa, che di specificare, in caso di politiche
-\textit{real-time}, la eventuale priorità statica; la funzione è
+\textit{real-time}, la eventuale priorità statica; la funzione di sistema è
\funcd{sched\_setscheduler} ed il suo prototipo è:
\begin{funcproto}{
\begin{figure}[!htbp]
\footnotesize \centering
- \begin{minipage}[c]{\textwidth}
+ \begin{minipage}[c]{0.5\textwidth}
\includestruct{listati/sched_param.c}
\end{minipage}
\normalsize
impostato con le funzioni viste in precedenza.
Lo standard POSIX.1b prevede comunque che l'intervallo dei valori delle
-priorità statiche possa essere ottenuto tramite le due funzioni
+priorità statiche possa essere ottenuto con le funzioni di sistema
\funcd{sched\_get\_priority\_max} e \funcd{sched\_get\_priority\_min}, i cui
prototipi sono:
politica ordinaria.
Se si intende operare solo sulla priorità statica di un processo si possono
-usare le due funzioni \funcd{sched\_setparam} e \funcd{sched\_getparam} che
-consentono rispettivamente di impostarne e leggerne il valore, i loro
-prototipi sono:
+usare le due funzioni di sistema \funcd{sched\_setparam} e
+\funcd{sched\_getparam} che consentono rispettivamente di impostarne e
+leggerne il valore, i loro prototipi sono:
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{sched.h}
\fdecl{int sched\_setparam(pid\_t pid, const struct sched\_param *param)}
\fdesc{Imposta la priorità statica di un processo.}
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
-prototipo è:
+processo si può usare la funzione di sistema \funcd{sched\_getscheduler}, il
+cui prototipo è:
\begin{funcproto}{
\fhead{sched.h}
processo specificato dall'argomento \param{pid}, se questo è nullo viene
restituito il valore relativo al processo chiamante.
-L'ultima funzione che permette di leggere le informazioni relative ai processi
-real-time è \funcd{sched\_rr\_get\_interval}, che permette di ottenere la
-lunghezza della \textit{time-slice} usata dalla politica \textit{round robin};
-il suo prototipo è:
+L'ultima funzione di sistema che permette di leggere le informazioni relative
+ai processi real-time è \funcd{sched\_rr\_get\_interval}, che permette di
+ottenere la lunghezza della \textit{time-slice} usata dalla politica
+\textit{round robin}; il suo prototipo è:
\begin{funcproto}{
\fhead{sched.h}
\textit{real-time}.
Come accennato ogni processo può rilasciare volontariamente la CPU in modo da
-consentire agli altri processi di essere eseguiti; la funzione che consente di
-fare tutto ciò è \funcd{sched\_yield}, il cui prototipo è:
+consentire agli altri processi di essere eseguiti; la funzione di sistema che
+consente di fare tutto questo è \funcd{sched\_yield}, il cui prototipo è:
\begin{funcproto}{
\fhead{sched.h}
solo una preferenza, non un requisito assoluto.} e per poter risolvere
questo tipo di problematiche nei nuovi kernel\footnote{le due \textit{system
call} per la gestione della \textit{CPU affinity} sono state introdotte
- nel kernel 2.5.8, e le funzioni di libreria nelle \textsl{glibc} 2.3.} è
-stata introdotta l'opportuna infrastruttura ed una nuova \textit{system call}
-che permette di impostare su quali processori far eseguire un determinato
-processo attraverso una \textsl{maschera di affinità}. La corrispondente
-funzione di libreria è \funcd{sched\_setaffinity} ed il suo prototipo è:
+ nel kernel 2.5.8, e le corrispondenti funzioni di sistema nella
+ \textsl{glibc} 2.3.} è stata introdotta l'opportuna infrastruttura ed una
+nuova \textit{system call} che permette di impostare su quali processori far
+eseguire un determinato processo attraverso una \textsl{maschera di
+ affinità}. La corrispondente funzione di sistema è
+\funcd{sched\_setaffinity} ed il suo prototipo è:
\index{insieme~di~processori|(}
\begin{funcproto}{
\fhead{sched.h}
-\fdecl{int sched\_setaffinity (pid\_t pid, size\_t setsize,
+\fdecl{int sched\_setaffinity(pid\_t pid, size\_t setsize,
cpu\_set\_t *mask)}
\fdesc{Imposta la maschera di affinità di un processo.}
}
ed inoltre anche \errval{EFAULT} nel suo significato generico.}
\end{funcproto}
-Questa funzione e la corrispondente \func{sched\_setaffinity} hanno una storia
+Questa funzione e la corrispondente \func{sched\_getaffinity} hanno una storia
abbastanza complessa, la sottostante \textit{system call} infatti prevede
l'uso di due soli argomenti (per il pid e l'indicazione della maschera dei
processori), che corrispondono al fatto che l'implementazione effettiva usa
-una semplice maschera binaria. Quando le funzioni vennero incluse nelle
+una semplice maschera binaria. Quando le funzioni vennero incluse nella
\acr{glibc} assunsero invece un prototipo simile a quello mostrato però con il
secondo argomento di tipo \ctyp{unsigned int}. A complicare la cosa si
-aggiunge il fatto che nella versione 2.3.3 delle \acr{glibc} detto argomento
+aggiunge il fatto che nella versione 2.3.3 della \acr{glibc} detto argomento
venne stato eliminato, per poi essere ripristinato nella versione 2.3.4 nella
forma attuale.\footnote{pertanto se la vostra pagina di manuale non è
- aggiornata, o usate quella particolare versione delle \acr{glibc}, potrete
+ aggiornata, o usate quella particolare versione della \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
di processore.
Dato che il numero di processori può variare a seconda delle architetture, per
-semplificare l'uso dell'argomento \param{mask} le \acr{glibc} hanno introdotto
-un apposito dato di tipo, \type{cpu\_set\_t},\footnote{questa è una estensione
- specifica delle \acr{glibc}, da attivare definendo la macro
+semplificare l'uso dell'argomento \param{mask} la \acr{glibc} ha introdotto un
+apposito dato di tipo, \type{cpu\_set\_t},\footnote{questa è una estensione
+ specifica della \acr{glibc}, da attivare definendo la macro
\macro{\_GNU\_SOURCE}, non esiste infatti una standardizzazione per questo
tipo di interfaccia e POSIX al momento non prevede nulla al riguardo.} che
permette di identificare un insieme di processori. Il dato è normalmente una
valutato più volte. Questo significa ad esempio che non si può usare al suo
posto una funzione o un'altra macro, altrimenti queste verrebbero eseguite più
volte, l'argomento cioè non deve avere \textsl{effetti collaterali} (in gergo
-\itindex{side!effects} \textit{side effects}).\footnote{nel linguaggio C si
+\itindex{side~effects} \textit{side effects}).\footnote{nel linguaggio C si
parla appunto di \textit{side effects} quando si usano istruzioni la cui
valutazione comporta effetti al di fuori dell'istruzione stessa, come il
caso indicato in cui si passa una funzione ad una macro che usa l'argomento
A meno di non aver utilizzato \func{sched\_setaffinity}, in condizioni
ordinarie la maschera di affinità di un processo è preimpostata dal sistema in
modo che esso possa essere eseguito su qualunque processore. Se ne può
-comunque ottenere il valore usando la funzione \funcd{sched\_getaffinity}, il
-cui prototipo è:
+comunque ottenere il valore corrente usando la funzione di sistema
+\funcd{sched\_getaffinity}, il cui prototipo è:
\begin{funcproto}{
\fhead{sched.h}
kernel.
Una volta che si sia impostato lo \textit{scheduler} CFQ ci sono due
-specifiche system call, specifiche di Linux, che consentono di leggere ed
-impostare le priorità di I/O.\footnote{se usate in corrispondenza ad uno
- \textit{scheduler} diverso il loro utilizzo non avrà alcun effetto.} Dato
-che non esiste una interfaccia diretta nelle \acr{glibc} per queste due
+specifiche \textit{system call}, specifiche di Linux, che consentono di
+leggere ed impostare le priorità di I/O.\footnote{se usate in corrispondenza
+ ad uno \textit{scheduler} diverso il loro utilizzo non avrà alcun effetto.}
+Dato che non esiste una interfaccia diretta nella \acr{glibc} per queste due
funzioni\footnote{almeno al momento della scrittura di questa sezione, con la
versione 2.11 della \acr{glibc}.} occorrerà invocarle tramite la funzione
\func{syscall} (come illustrato in sez.~\ref{sec:proc_syscall}). Le due
-funzioni sono \funcd{ioprio\_get} ed \funcd{ioprio\_set}; i rispettivi
-prototipi sono:
+\textit{system call} sono \funcd{ioprio\_get} ed \funcd{ioprio\_set}; i
+rispettivi prototipi sono:
\begin{funcproto}{
\fhead{linux/ioprio.h}
\hline
\hline
\macro{IOPRIO\_PRIO\_CLASS}\texttt{(\textit{value})}
- & dato il valore di una priorità come
+ & Dato il valore di una priorità come
restituito da \func{ioprio\_get} estrae il
valore della classe.\\
\macro{IOPRIO\_PRIO\_DATA}\texttt{(\textit{value})}
- & dato il valore di una priorità come
+ & Dato il valore di una priorità come
restituito da \func{ioprio\_get} estrae il
valore della priorità.\\
\macro{IOPRIO\_PRIO\_VALUE}\texttt{(\textit{class},\textit{prio})}
- & dato un valore di priorità ed una classe
+ & Dato un valore di priorità ed una classe
ottiene il valore numerico da passare a
\func{ioprio\_set}.\\
\hline
proprietà e caratteristiche particolari dei processi non coperte da esse, per
la cui gestione è stata predisposta una apposita \textit{system call} che
fornisce una interfaccia generica per tutte le operazioni specialistiche. La
-funzione è \funcd{prctl} ed il suo prototipo è:\footnote{la funzione non è
- standardizzata ed è specifica di Linux, anche se ne esiste una analoga in
- IRIX; è stata introdotta con il kernel 2.1.57.}
+funzione di sistema è \funcd{prctl} ed il suo prototipo è:\footnote{la
+ funzione non è standardizzata ed è specifica di Linux, anche se ne esiste
+ una analoga in IRIX; è stata introdotta con il kernel 2.1.57.}
\begin{funcproto}{
\fhead{sys/prctl.h}
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
Oltre a questo la funzione consente, ad uso delle nuove funzionalità di
virtualizzazione dei processi, di creare nuovi \textit{namespace} per una
-serie di proprietà generali dei processi (come l'elenco dei PID, l'albero dei
-file, i \itindex{mount~point} \textit{mount point}, la rete, ecc.), che
-consentono di creare gruppi di processi che vivono in una sorta di spazio
-separato dagli altri, che costituisce poi quello che viene chiamato un
+serie di proprietà generali dei processi (come l'elenco dei \ids{PID},
+l'albero dei file, i \itindex{mount~point} \textit{mount point}, la rete,
+ecc.), che consentono di creare gruppi di processi che vivono in una sorta di
+spazio separato dagli altri, che costituisce poi quello che viene chiamato un
\textit{container}.
La \textit{system call} richiede soltanto due argomenti: il
\textit{stack} totalmente indipendente da quello del padre.
Dato che l'uso principale della nuova \textit{system call} è quello relativo
-alla creazione dei \textit{thread}, le \acr{glibc} definiscono una funzione di
+alla creazione dei \textit{thread}, la \acr{glibc} definisce una funzione di
libreria con una sintassi diversa, orientata a questo scopo, e la
\textit{system call} resta accessibile solo se invocata esplicitamente come
visto in sez.~\ref{sec:proc_syscall}.\footnote{ed inoltre per questa
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}
occorre preoccuparsi della atomicità delle operazioni solo quando si ha a che
fare con meccanismi di intercomunicazione (che esamineremo in dettaglio in
cap.~\ref{cha:IPC}) o nelle operazioni con i file (vedremo alcuni esempi in
-sez.~\ref{sec:file_atomic}). In questi casi in genere l'uso delle appropriate
-funzioni di libreria per compiere le operazioni necessarie è garanzia
-sufficiente di atomicità in quanto le \textit{system call} con cui esse sono
-realizzate non possono essere interrotte (o subire interferenze pericolose) da
-altri processi.
+sez.~\ref{sec:file_shared_access}). In questi casi in genere l'uso delle
+appropriate funzioni di libreria per compiere le operazioni necessarie è
+garanzia sufficiente di atomicità in quanto le \textit{system call} con cui
+esse sono realizzate non possono essere interrotte (o subire interferenze
+pericolose) da altri processi.
Nel caso dei segnali invece la situazione è molto più delicata, in quanto lo
stesso processo, e pure alcune \textit{system call}, possono essere interrotti
parte del programmatore.
In genere le funzioni di libreria non sono rientranti, molte di esse ad
-esempio utilizzano \index{variabili!statiche} variabili statiche, le
-\acr{glibc} però mettono a disposizione due macro di compilatore,
+esempio utilizzano \index{variabili!statiche} variabili statiche, la
+\acr{glibc} però mette a disposizione due macro di compilatore,
\macro{\_REENTRANT} e \macro{\_THREAD\_SAFE}, la cui definizione attiva le
versioni rientranti di varie funzioni di libreria, che sono identificate
aggiungendo il suffisso \code{\_r} al nome della versione normale.
% 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
projects / gapil.git / blobdiff