%% 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",
caratteristiche fondanti di Unix, che esamineremo in dettaglio più avanti, è
che qualunque processo può a sua volta generarne altri. Ogni processo è
identificato presso il sistema da un numero univoco, il cosiddetto
-\textit{process identifier} o, più brevemente, \acr{pid}, assegnato in forma
-progressiva (vedi sez.~\ref{sec:proc_pid}) quando il processo viene creato.
+\itindex{Process~ID~(PID)} \textit{Process ID} o, più brevemente, \ids{PID},
+assegnato in forma progressiva (vedi sez.~\ref{sec:proc_pid}) quando il
+processo viene creato.
Una seconda caratteristica di un sistema unix-like è che la generazione di un
processo è un'operazione separata rispetto al lancio di un programma. In
di partenza esiste un processo speciale (che normalmente è \cmd{/sbin/init}),
che come abbiamo accennato in sez.~\ref{sec:intro_kern_and_sys} viene lanciato
dal kernel alla conclusione della fase di avvio. Essendo questo il primo
-processo lanciato dal sistema ha sempre il \acr{pid} uguale a 1 e non è figlio
+processo lanciato dal sistema ha sempre il \ids{PID} uguale a 1 e non è figlio
di nessun altro processo.
Ovviamente \cmd{init} è un processo speciale che in genere si occupa di far
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]
del tutto vero, in Linux, specialmente nelle versioni più recenti del
kernel, ci sono alcuni processi speciali (come \cmd{keventd}, \cmd{kswapd},
ecc.) che pur comparendo nei comandi come figli di \cmd{init}, o con
- \acr{pid} successivi ad uno, sono in realtà processi interni al kernel e che
+ \ids{PID} successivi ad uno, sono in realtà processi interni al kernel e che
non rientrano in questa classificazione.}
Il kernel mantiene una tabella dei processi attivi, la cosiddetta
Come accennato nella sezione precedente ogni processo viene identificato dal
sistema da un numero identificativo univoco, il \textit{process ID} o
-\acr{pid}. Questo è un tipo di dato standard, \type{pid\_t} che in genere è un
+\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 è
\ctyp{int}).
-Il \acr{pid} viene assegnato in forma progressiva ogni volta che un nuovo
+Il \ids{PID} viene assegnato in forma progressiva ogni volta che un nuovo
processo viene creato,\footnote{in genere viene assegnato il numero successivo
a quello usato per l'ultimo processo creato, a meno che questo numero non
- sia già utilizzato per un altro \acr{pid}, \acr{pgid} o \acr{sid} (vedi
+ sia già utilizzato per un altro \ids{PID}, \acr{pgid} o \acr{sid} (vedi
sez.~\ref{sec:sess_proc_group}).} fino ad un limite che, essendo il
-tradizionalmente il \acr{pid} un numero positivo memorizzato in un intero a 16
+tradizionalmente il \ids{PID} un numero positivo memorizzato in un intero a 16
bit, arriva ad un massimo di 32768. Oltre questo valore l'assegnazione
riparte dal numero più basso disponibile a partire da un minimo di
300,\footnote{questi valori, fino al kernel 2.4.x, erano definiti dalla macro
\const{PID\_MAX} nei file \file{threads.h} e \file{fork.c} dei sorgenti del
kernel, con il 2.6.x e la nuova interfaccia per i \itindex{thread}
- \textit{thread} anche il meccanismo di allocazione dei \acr{pid} è stato
+ \textit{thread} anche il meccanismo di allocazione dei \ids{PID} è stato
modificato ed il valore massimo è impostabile attraverso il file
\sysctlfile{kernel/pid\_max} e di default vale 32768.} che serve a
-riservare i \acr{pid} più bassi ai processi eseguiti direttamente dal kernel.
+riservare i \ids{PID} più bassi ai processi eseguiti direttamente dal kernel.
Per questo motivo, come visto in sez.~\ref{sec:proc_hierarchy}, il processo di
-avvio (\cmd{init}) ha sempre il \acr{pid} uguale a uno.
+avvio (\cmd{init}) ha sempre il \ids{PID} uguale a uno.
-Tutti i processi inoltre memorizzano anche il \acr{pid} del genitore da cui
-sono stati creati, questo viene chiamato in genere \acr{ppid} (da
-\textit{parent process ID}). Questi due identificativi possono essere
-ottenuti usando le due funzioni \funcd{getpid} e \funcd{getppid}, i cui
-prototipi sono:
+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:
\begin{funcproto}{
\fhead{sys/types.h}
\fhead{unistd.h}
\fdecl{pid\_t getpid(void)}
-\fdesc{Restituisce il \acr{pid} del processo corrente..}
+\fdesc{Restituisce il \ids{PID} del processo corrente..}
\fdecl{pid\_t getppid(void)}
-\fdesc{Restituisce il \acr{pid} del padre del processo corrente.}
+\fdesc{Restituisce il \ids{PID} del padre del processo corrente.}
}
{Entrambe le funzioni non riportano condizioni di errore.}
\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 \acr{pid} sia un numero univoco per il sistema lo rende un
+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
-\acr{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 \acr{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
un processo e le varie relazioni fra processi utilizzate per definire una
sessione.
-Oltre al \acr{pid} e al \acr{ppid}, e a quelli che vedremo in
+Oltre al \ids{PID} e al \ids{PPID}, e a quelli che vedremo in
sez.~\ref{sec:sess_proc_group}, relativi al controllo di sessione, ad ogni
processo vengono associati degli ulteriori identificatori ed in particolare
quelli che vengono usati per il controllo di accesso. Questi servono per
\fdecl{pid\_t fork(void)}
\fdesc{Crea un nuovo processo.}
}
-{La funzione ritorna il \acr{pid} del figlio al padre e $0$ al figlio in caso
+{La funzione ritorna il \ids{PID} del figlio al padre e $0$ al figlio in caso
di successo e $-1$ al padre senza creare il figlio per un errore,
nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
state modificate, e solo al momento della modifica stessa.
La differenza che si ha nei due processi è che nel processo padre il valore di
-ritorno della funzione \func{fork} è il \acr{pid} del processo figlio, mentre
+ritorno della funzione \func{fork} è il \ids{PID} del processo figlio, mentre
nel figlio è zero; in questo modo il programma può identificare se viene
eseguito dal padre o dal figlio. Si noti come la funzione \func{fork} ritorni
due volte, una nel padre e una nel figlio.
La scelta di questi valori di ritorno non è casuale, un processo infatti può
avere più figli, ed il valore di ritorno di \func{fork} è l'unico modo che gli
permette di identificare quello appena creato. Al contrario un figlio ha
-sempre un solo padre, il cui \acr{pid} può sempre essere ottenuto con
+sempre un solo padre, il cui \ids{PID} può sempre essere ottenuto con
\func{getppid}, come spiegato in sez.~\ref{sec:proc_pid}, per cui si usa il
-valore nullo, che non è il \acr{pid} di nessun processo.
+valore nullo, che non è il \ids{PID} di nessun processo.
Normalmente la chiamata a \func{fork} può fallire solo per due ragioni: o ci
sono già troppi processi nel sistema, il che di solito è sintomo che
\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}.
si può dire quale processo fra il padre ed il figlio venga eseguito per primo
dopo la chiamata a \func{fork}; dall'esempio si può notare infatti come nei
primi due cicli sia stato eseguito per primo il padre (con la stampa del
-\acr{pid} del nuovo processo) per poi passare all'esecuzione del figlio
+\ids{PID} del nuovo processo) per poi passare all'esecuzione del figlio
(completata con i due avvisi di esecuzione ed uscita), e tornare
all'esecuzione del padre (con la stampa del passaggio al ciclo successivo),
mentre la terza volta è stato prima eseguito il figlio (fino alla conclusione)
\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
dallo standard POSIX.1-2001.}
\begin{itemize*}
\item il valore di ritorno di \func{fork};
-\item il \acr{pid} (\textit{process id}), quello del figlio viene assegnato ad
+\item il \ids{PID} (\textit{process id}), quello del figlio viene assegnato ad
un nuovo valore univoco;
-\item il \acr{ppid} (\textit{parent process id}), quello del figlio viene
- impostato al \acr{pid} del padre;
+\item il \ids{PPID} (\textit{parent process id}), quello del figlio viene
+ impostato al \ids{PID} del padre;
\item i valori dei tempi di esecuzione (vedi sez.~\ref{sec:sys_cpu_times}) e
delle risorse usate (vedi sez.~\ref{sec:sys_resource_use}), che nel figlio
sono posti a zero;
\textsl{orfano}.
Questa complicazione viene superata facendo in modo che il processo orfano
-venga \textsl{adottato} da \cmd{init}, o meglio dal processo con \acr{pid} 1,
+venga \textsl{adottato} da \cmd{init}, o meglio dal processo con \ids{PID} 1,
cioè quello lanciato direttamente dal kernel all'avvio, che sta alla base
dell'albero dei processi visto in sez.~\ref{sec:proc_hierarchy} e che anche
per questo motivo ha un ruolo essenziale nel sistema e non può mai
fatale.}
Come già accennato quando un processo termina, il kernel controlla se è il
-padre di altri processi in esecuzione: in caso positivo allora il \acr{ppid}
-di tutti questi processi verrà sostituito dal kernel con il \acr{pid} di
+padre di altri processi in esecuzione: in caso positivo allora il \ids{PPID}
+di tutti questi processi verrà sostituito dal kernel con il \ids{PID} di
\cmd{init}, cioè con 1. In questo modo ogni processo avrà sempre un padre (nel
caso possiamo parlare di un padre \textsl{adottivo}) cui riportare il suo
stato di terminazione.
figli, tornando alla shell, che stampa il prompt sul terminale: circa due
secondi dopo viene stampato a video anche l'output dei tre figli che
terminano, e come si può notare in questo caso, al contrario di quanto visto
-in precedenza, essi riportano 1 come \acr{ppid}.
+in precedenza, essi riportano 1 come \ids{PPID}.
Altrettanto rilevante è il caso in cui il figlio termina prima del padre,
perché non è detto che il padre possa ricevere immediatamente lo stato di
informazioni riguardo ai processi che sta terminando.
Questo viene fatto mantenendo attiva la voce nella tabella dei processi, e
-memorizzando alcuni dati essenziali, come il \acr{pid}, i tempi di CPU usati
+memorizzando alcuni dati essenziali, come il \ids{PID}, i tempi di CPU usati
dal processo (vedi sez.~\ref{sec:sys_unix_time}) e lo stato di terminazione,
mentre la memoria in uso ed i file aperti vengono rilasciati immediatamente.
\fdecl{pid\_t wait(int *status)}
\fdesc{Attende la terminazione di un processo.}
}
-{La funzione ritorna il \acr{pid} del figlio in caso di successo e $-1$ per un
+{La funzione ritorna il \ids{PID} del figlio in caso di successo e $-1$ per un
errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{ECHILD}] il processo non ha nessun figlio di cui attendere
variabile puntata da \param{status} e tutte le risorse del kernel relative al
processo (vedi sez.~\ref{sec:proc_termination}) vengono rilasciate. Nel caso
un processo abbia più figli il valore di ritorno della funzione sarà impostato
-al \acr{pid} del processo di cui si è ricevuto lo stato di terminazione, cosa
+al \ids{PID} del processo di cui si è ricevuto lo stato di terminazione, cosa
che permette di identificare qual è il figlio che è terminato.
\itindend{termination~status}
\fdecl{pid\_t waitpid(pid\_t pid, int *status, int options)}
\fdesc{Attende il cambiamento di stato di un processo figlio.}
}
-{La funzione ritorna il \acr{pid} del processo che ha cambiato stato in caso
+{La funzione ritorna il \ids{PID} del processo che ha cambiato stato in caso
di successo, o 0 se è stata specificata l'opzione \const{WNOHANG} e il
processo non è uscito e $-1$ per un errore, nel qual caso \var{errno}
assumerà uno dei valori:
\itindex{process~group} \textit{process group}
(vedi sez.~\ref{sec:sess_proc_group}) è
uguale a quello del processo chiamante.\\
- $>0$& -- & Attende per un figlio il cui \acr{pid} è uguale
+ $>0$& -- & Attende per un figlio il cui \ids{PID} è uguale
al valore di \param{pid}.\\
\hline
\end{tabular}
L'uso dell'opzione \const{WNOHANG} consente di prevenire il blocco della
funzione qualora nessun figlio sia uscito o non si siano verificate le altre
condizioni per l'uscita della funzione. in tal caso. In tal caso la funzione,
-invece di restituire il \acr{pid} del processo (che è sempre un intero
+invece di restituire il \ids{PID} del processo (che è sempre un intero
positivo) ritornerà un valore nullo.
Le altre due opzioni, \const{WUNTRACED} e \const{WCONTINUED}, consentono
che esso sia stato fermato, o fatto ripartire, e sono utilizzate per la
gestione del controllo di sessione (vedi sez.~\ref{sec:sess_job_control}).
-Nel caso di \const{WUNTRACED} la funzione ritorna, restituendone il \acr{pid},
+Nel caso di \const{WUNTRACED} la funzione ritorna, restituendone il \ids{PID},
quando un processo figlio entra nello stato \textit{stopped}\footnote{in
realtà viene notificato soltanto il caso in cui il processo è stato fermato
da un segnale di stop (vedi sez.~\ref{sec:sess_ctrl_term}), e non quello in
indefinito il comportamento di queste funzioni quando \signal{SIGCHLD} viene
ignorato.} indipendentemente dal fatto \signal{SIGCHLD} sia ignorato o meno:
attendono la terminazione di un processo figlio e ritornano il relativo
-\acr{pid} e lo stato di terminazione nell'argomento \param{status}.
+\ids{PID} e lo stato di terminazione nell'argomento \param{status}.
In generale in un programma non si vuole essere forzati ad attendere la
conclusione di un processo figlio per proseguire l'esecuzione, specie se tutto
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}.
\hline
\hline
\const{P\_PID} & Indica la richiesta di attendere per un processo figlio
- il cui \acr{pid} corrisponda al valore dell'argomento
+ il cui \ids{PID} corrisponda al valore dell'argomento
\param{id}.\\
\const{P\_PGID}& Indica la richiesta di attendere per un processo figlio
appartenente al \textit{process group} (vedi
basta dire che al ritorno di \func{waitid} verranno avvalorati i seguenti
campi:
\begin{basedescript}{\desclabelwidth{2.0cm}}
-\item[\var{si\_pid}] con il \acr{pid} del figlio.
+\item[\var{si\_pid}] con il \ids{PID} del figlio.
\item[\var{si\_uid}] con l'\textsl{user-ID reale} (vedi
sez.~\ref{sec:proc_perms}) del figlio.
\item[\var{si\_signo}] con \signal{SIGCHLD}.
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
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
+nuovo programma, il \ids{PID} del processo non cambia, dato che non viene
creato un nuovo processo, la funzione semplicemente rimpiazza lo
\itindex{stack} \textit{stack}, i \index{segmento!dati} dati ed il
\index{segmento!testo} testo del processo corrente con un nuovo programma
\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[])}.
+\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
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
sez.~\ref{sec:proc_environ}) del processo di partenza per costruire
l'ambiente.
-Oltre a mantenere lo stesso \acr{pid}, il nuovo programma fatto partire da una
+Oltre a mantenere lo stesso \ids{PID}, il nuovo programma fatto partire da una
delle funzioni della famiglia \func{exec} mantiene la gran parte delle
proprietà del processo chiamante; una lista delle più significative è la
seguente:
\begin{itemize*}
-\item il \textit{process id} (\acr{pid}) ed il \textit{parent process id}
- (\acr{ppid});
+\item il \textit{process id} (\ids{PID}) ed il \textit{parent process id}
+ (\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});
vari controlli di accesso.
Abbiamo già accennato come il sistema associ ad ogni utente e gruppo due
-identificatori univoci, lo \textsl{user-ID} (abbreviato in \acr{uid}) ed il
-\textsl{group-ID} (abbreviato in \acr{gid}). Questi servono al kernel per
-identificare uno specifico utente o un gruppo di utenti, per poi poter
-controllare che essi siano autorizzati a compiere le operazioni richieste. Ad
-esempio in sez.~\ref{sec:file_access_control} vedremo come ad ogni file
-vengano associati un utente ed un gruppo (i suoi \textsl{proprietari},
-indicati appunto tramite un \acr{uid} ed un \acr{gid}) che vengono controllati
-dal kernel nella gestione dei permessi di accesso.
+identificatori univoci, lo \itindex{User~ID~(PID)} \textsl{User-ID}
+(abbreviato in \ids{UID}) ed il \itindex{Group~ID~(PID)} \textsl{Group-ID}
+(abbreviato in \ids{GID}). Questi servono al kernel per identificare uno
+specifico utente o un gruppo di utenti, per poi poter controllare che essi
+siano autorizzati a compiere le operazioni richieste. Ad esempio in
+sez.~\ref{sec:file_access_control} vedremo come ad ogni file vengano associati
+un utente ed un gruppo (i suoi \textsl{proprietari}, indicati appunto tramite
+un \ids{UID} ed un \ids{GID}) che vengono controllati dal kernel nella
+gestione dei permessi di accesso.
Dato che tutte le operazioni del sistema vengono compiute dai processi, è
evidente che per poter implementare un controllo sulle operazioni occorre
\begin{table}[htb]
\footnotesize
\centering
- \begin{tabular}[c]{|c|c|l|p{7.3cm}|}
+ \begin{tabular}[c]{|c|c|l|p{7cm}|}
\hline
\textbf{Suffisso} & \textbf{Gruppo} & \textbf{Denominazione}
& \textbf{Significato} \\
\hline
\hline
- \acr{uid} & \textit{real} & \textsl{user-ID reale}
- & Indica l'utente che ha lanciato il programma.\\
- \acr{gid} & '' &\textsl{group-ID reale}
- & Indica il gruppo principale dell'utente che ha lanciato
- il programma.\\
+ \texttt{uid} & \textit{real} & \textsl{user-ID reale}
+ & Indica l'utente che ha lanciato il programma.\\
+ \texttt{gid} & '' &\textsl{group-ID reale}
+ & Indica il gruppo principale dell'utente che ha lanciato
+ il programma.\\
\hline
- \acr{euid} & \textit{effective} &\textsl{user-ID effettivo}
- & Indica l'utente usato nel controllo di accesso.\\
- \acr{egid} & '' & \textsl{group-ID effettivo}
- & Indica il gruppo usato nel controllo di accesso.\\
- -- & -- & \textsl{group-ID supplementari}
- & Indicano gli ulteriori gruppi cui l'utente appartiene.\\
+ \texttt{euid}& \textit{effective} &\textsl{user-ID effettivo}
+ & Indica l'utente usato nel controllo di accesso.\\
+ \texttt{egid}& '' & \textsl{group-ID effettivo}
+ & Indica il gruppo usato nel controllo di accesso.\\
+ -- & -- & \textsl{group-ID supplementari}
+ & Indicano gli ulteriori gruppi cui l'utente appartiene.\\
\hline
- -- & \textit{saved} & \textsl{user-ID salvato}
- & È una copia dell'\acr{euid} iniziale.\\
- -- & '' & \textsl{group-ID salvato}
- & È una copia dell'\acr{egid} iniziale.\\
+ -- & \textit{saved} & \textsl{user-ID salvato}
+ & Mantiene una copia dell'\acr{euid} iniziale.\\
+ -- & '' & \textsl{group-ID salvato}
+ & Mantiene una copia dell'\acr{egid} iniziale.\\
\hline
- \acr{fsuid} & \textit{filesystem} &\textsl{user-ID di filesystem}
- & Indica l'utente effettivo per l'accesso al filesystem. \\
- \acr{fsgid} & '' & \textsl{group-ID di filesystem}
- & Indica il gruppo effettivo per l'accesso al filesystem.\\
+ \texttt{fsuid}& \textit{filesystem} &\textsl{user-ID di filesystem}
+ & Indica l'utente effettivo per l'accesso al filesystem. \\
+ \texttt{fsgid}& '' & \textsl{group-ID di filesystem}
+ & Indica il gruppo effettivo per l'accesso al filesystem.\\
\hline
\end{tabular}
\caption{Identificatori di utente e gruppo associati a ciascun processo con
\label{tab:proc_uid_gid}
\end{table}
-Al primo gruppo appartengono l'\acr{uid} \textsl{reale} ed il \acr{gid}
+Al primo gruppo appartengono l'\ids{UID} \textsl{reale} ed il \ids{GID}
\textsl{reale}: questi vengono impostati al login ai valori corrispondenti
all'utente con cui si accede al sistema (e relativo gruppo principale).
Servono per l'identificazione dell'utente e normalmente non vengono mai
imposta questi identificatori ai valori corrispondenti all'utente che entra
nel sistema.
-Al secondo gruppo appartengono l'\acr{uid} \textsl{effettivo} e il \acr{gid}
-\textsl{effettivo}, a cui si aggiungono gli eventuali \acr{gid}
+Al secondo gruppo appartengono l'\ids{UID} \textsl{effettivo} e il \ids{GID}
+\textsl{effettivo}, a cui si aggiungono gli eventuali \ids{GID}
\textsl{supplementari} dei gruppi dei quali l'utente fa parte. Questi sono
invece gli identificatori usati nelle verifiche dei permessi del processo e
per il controllo di accesso ai file (argomento affrontato in dettaglio in
cui ci sia questa necessità, di dare a qualunque utente i privilegi o i
permessi di un altro, compreso l'amministratore.
-Come nel caso del \acr{pid} e del \acr{ppid}, anche tutti questi
+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:
\fhead{unistd.h}
\fhead{sys/types.h}
\fdecl{uid\_t getuid(void)}
-\fdesc{Legge l'\acr{uid} reale del processo corrente.}
+\fdesc{Legge l'\ids{UID} reale del processo corrente.}
\fdecl{uid\_t geteuid(void)}
-\fdesc{Legge l'\acr{uid} effettivo del processo corrente.}
+\fdesc{Legge l'\ids{UID} effettivo del processo corrente.}
\fdecl{gid\_t getgid(void)}
-\fdesc{Legge il \acr{gid} reale del processo corrente.}
+\fdesc{Legge il \ids{GID} reale del processo corrente.}
\fdecl{gid\_t getegid(void)}
-\fdesc{Legge il \acr{gid} effettivo del processo corrente.}
+\fdesc{Legge il \ids{GID} effettivo del processo corrente.}
}
{Le funzioni ritornano i rispettivi identificativi del processo corrente, e
non sono previste condizioni di errore.}
\end{funcproto}
-In generale l'uso di privilegi superiori, ottenibile con un \acr{uid}
+In generale l'uso di privilegi superiori, ottenibile con un \ids{UID}
\textsl{effettivo} diverso da quello reale, deve essere limitato il più
possibile, per evitare abusi e problemi di sicurezza, per questo occorre anche
un meccanismo che consenta ad un programma di rilasciare gli eventuali
migliorare la sicurezza con NFS (il \textit{Network File System}, protocollo
che consente di accedere ai file via rete).
-L'\acr{uid} \textsl{salvato} ed il \acr{gid} \textsl{salvato} sono copie
-dell'\acr{uid} \textsl{effettivo} e del \acr{gid} \textsl{effettivo} del
+L'\ids{UID} \textsl{salvato} ed il \ids{GID} \textsl{salvato} sono copie
+dell'\ids{UID} \textsl{effettivo} e del \ids{GID} \textsl{effettivo} del
processo padre, e vengono impostati dalla funzione \func{exec} all'avvio del
-processo, come copie dell'\acr{uid} \textsl{effettivo} e del \acr{gid}
+processo, come copie dell'\ids{UID} \textsl{effettivo} e del \ids{GID}
\textsl{effettivo} dopo che questi sono stati impostati tenendo conto di
eventuali \itindex{suid~bit} \acr{suid} o \itindex{sgid~bit} \acr{sgid}. Essi
quindi consentono di tenere traccia di quale fossero utente e gruppo effettivi
all'inizio dell'esecuzione di un nuovo programma.
-L'\acr{uid} \textsl{di filesystem} e il \acr{gid} \textsl{di filesystem} sono
+L'\ids{UID} \textsl{di filesystem} e il \ids{GID} \textsl{di filesystem} sono
un'estensione introdotta in Linux per rendere più sicuro l'uso di NFS
(torneremo sull'argomento in sez.~\ref{sec:proc_setuid}). Essi sono una
replica dei corrispondenti identificatori del gruppo \textit{effective}, ai
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'\acr{uid} salvato e del \acr{gid} salvato; i loro
+prevede l'esistenza dell'\ids{UID} salvato e del \ids{GID} salvato; i loro
prototipi sono:
\begin{funcproto}{
\fhead{unistd.h}
\fhead{sys/types.h}
\fdecl{int setuid(uid\_t uid)}
-\fdesc{Imposta l'\acr{uid} del processo corrente.}
+\fdesc{Imposta l'\ids{UID} del processo corrente.}
\fdecl{int setgid(gid\_t gid)}
-\fdesc{Imposta il \acr{gid} del processo corrente.}
+\fdesc{Imposta il \ids{GID} del processo corrente.}
}
{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
caso \var{errno} può assumere solo il valore \errcode{EPERM}.
Il funzionamento di queste due funzioni è analogo, per cui considereremo solo
la prima, la seconda si comporta esattamente allo stesso modo facendo
-riferimento al \acr{gid} invece che all'\acr{uid}. Gli eventuali \acr{gid}
+riferimento al \ids{GID} invece che all'\ids{UID}. Gli eventuali \ids{GID}
supplementari non vengono modificati.
L'effetto della chiamata è diverso a seconda dei privilegi del processo; se
-l'\acr{uid} effettivo è zero (cioè è quello dell'amministratore di sistema)
+l'\ids{UID} effettivo è zero (cioè è quello dell'amministratore di sistema)
allora tutti gli identificatori (\textit{real}, \textit{effective} e
\textit{saved}) vengono impostati al valore specificato da \param{uid},
-altrimenti viene impostato solo l'\acr{uid} effettivo, e soltanto se il valore
-specificato corrisponde o all'\acr{uid} reale o all'\acr{uid} salvato. Negli
+altrimenti viene impostato solo l'\ids{UID} effettivo, e soltanto se il valore
+specificato corrisponde o all'\ids{UID} reale o all'\ids{UID} salvato. Negli
altri casi viene segnalato un errore con \errcode{EPERM}.
Come accennato l'uso principale di queste funzioni è quello di poter
consentire ad un programma con i bit \itindex{suid~bit} \acr{suid} o
\itindex{sgid~bit} \acr{sgid} impostati (vedi
-sez.~\ref{sec:file_special_perm}) di riportare l'\acr{uid} effettivo a quello
+sez.~\ref{sec:file_special_perm}) di riportare l'\ids{UID} effettivo a quello
dell'utente che ha lanciato il programma, effettuare il lavoro che non
necessita di privilegi aggiuntivi, ed eventualmente tornare indietro.
situazione degli identificatori è la seguente:
\begin{eqnarray*}
\label{eq:1}
- \textsl{group-ID reale} &=& \textrm{\acr{gid} (del chiamante)} \\
+ \textsl{group-ID reale} &=& \textrm{\ids{GID} (del chiamante)} \\
\textsl{group-ID effettivo} &=& \textrm{\acr{utmp}} \\
\textsl{group-ID salvato} &=& \textrm{\acr{utmp}}
\end{eqnarray*}
in tal caso infatti la situazione degli identificatori sarebbe:
\begin{eqnarray*}
\label{eq:2}
- \textsl{group-ID reale} &=& \textrm{\acr{gid} (invariato)} \\
- \textsl{group-ID effettivo} &=& \textrm{\acr{gid}} \\
+ \textsl{group-ID reale} &=& \textrm{\ids{GID} (invariato)} \\
+ \textsl{group-ID effettivo} &=& \textrm{\ids{GID}} \\
\textsl{group-ID salvato} &=& \textrm{\acr{utmp} (invariato)}
\end{eqnarray*}
-e ogni processo lanciato dal terminale avrebbe comunque \acr{gid} come
+e ogni processo lanciato dal terminale avrebbe comunque \ids{GID} come
\textsl{group-ID effettivo}. All'uscita dal terminale, per poter di nuovo
aggiornare lo stato di \sysfile{/var/run/utmp} il programma eseguirà una
\code{setgid(utmp)} (dove \var{utmp} è il valore numerico associato al gruppo
funzione avrà successo e riporterà la situazione a:
\begin{eqnarray*}
\label{eq:3}
- \textsl{group-ID reale} &=& \textrm{\acr{gid} (invariato)} \\
+ \textsl{group-ID reale} &=& \textrm{\ids{GID} (invariato)} \\
\textsl{group-ID effettivo} &=& \textrm{\acr{utmp}} \\
\textsl{group-ID salvato} &=& \textrm{\acr{utmp} (invariato)}
\end{eqnarray*}
processo, rendendo impossibile riguadagnare i privilegi di amministratore.
Questo comportamento è corretto per l'uso che ne fa \cmd{login} una volta che
crea una nuova shell per l'utente, ma quando si vuole cambiare soltanto
-l'\acr{uid} effettivo del processo per cedere i privilegi occorre
+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
\fhead{unistd.h}
\fhead{sys/types.h}
\fdecl{int setreuid(uid\_t ruid, uid\_t euid)}
-\fdesc{Imposta \acr{uid} reale e \acr{uid} effettivo del processo corrente.}
+\fdesc{Imposta \ids{UID} reale e \ids{UID} effettivo del processo corrente.}
\fdecl{int setregid(gid\_t rgid, gid\_t egid)}
-\fdesc{Imposta \acr{gid} reale e \acr{gid} effettivo del processo corrente.}
+\fdesc{Imposta \ids{GID} reale e \ids{GID} effettivo del processo corrente.}
}
{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
caso \var{errno} può assumere solo il valore \errcode{EPERM}.
\end{funcproto}
Le due funzioni sono identiche, quanto diremo per la prima riguardo gli
-\acr{uid} si applica alla seconda per i \acr{gid}. La funzione
-\func{setreuid} imposta rispettivamente l'\acr{uid} reale e l'\acr{uid}
+\ids{UID} si applica alla seconda per i \ids{GID}. La funzione
+\func{setreuid} imposta rispettivamente l'\ids{UID} reale e l'\ids{UID}
effettivo del processo corrente ai valori specificati da \param{ruid}
e \param{euid}. I processi non privilegiati possono impostare solo valori che
-corrispondano o al loro \acr{uid} effettivo o a quello reale o a quello
+corrispondano o al loro \ids{UID} effettivo o a quello reale o a quello
salvato, valori diversi comportano il fallimento della chiamata.
L'amministratore invece può specificare un valore qualunque. Specificando un
argomento di valore $-1$ l'identificatore corrispondente verrà lasciato
inalterato.
-Con queste funzioni si possono scambiare fra loro gli \acr{uid} reale ed
+Con queste funzioni si possono scambiare fra loro gli \ids{UID} reale ed
effettivo, e pertanto è possibile implementare un comportamento simile a
quello visto in precedenza per \func{setgid}, cedendo i privilegi con un primo
scambio, e recuperandoli, una volta eseguito il lavoro non privilegiato, con
In questo caso però occorre porre molta attenzione quando si creano nuovi
processi nella fase intermedia in cui si sono scambiati gli identificatori, in
-questo caso infatti essi avranno un \acr{uid} reale privilegiato, che dovrà
+questo caso infatti essi avranno un \ids{UID} reale privilegiato, che dovrà
essere esplicitamente eliminato prima di porre in esecuzione un nuovo
programma, occorrerà cioè eseguire un'altra chiamata dopo la \func{fork} e
-prima della \func{exec} per uniformare l'\acr{uid} reale a quello effettivo,
+prima della \func{exec} per uniformare l'\ids{UID} reale a quello effettivo,
perché in caso contrario il nuovo programma potrebbe a sua volta effettuare
uno scambio e riottenere dei privilegi non previsti.
Lo stesso problema di propagazione dei privilegi ad eventuali processi figli
-si pone anche per l'\acr{uid} salvato. Ma la funzione \func{setreuid} deriva
+si pone anche per l'\ids{UID} salvato. Ma la funzione \func{setreuid} deriva
da un'implementazione di sistema che non ne prevede la presenza, e quindi non
è possibile usarla per correggere la situazione come nel caso precedente. Per
questo motivo in Linux tutte le volte che si imposta un qualunque valore
-diverso da quello dall'\acr{uid} reale corrente, l'\acr{uid} salvato viene
-automaticamente uniformato al valore dell'\acr{uid} effettivo.
+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
\fhead{unistd.h}
\fhead{sys/types.h}
\fdecl{int seteuid(uid\_t uid)}
-\fdesc{Imposta l'\acr{uid} effettivo del processo corrente.}
+\fdesc{Imposta l'\ids{UID} effettivo del processo corrente.}
\fdecl{int setegid(gid\_t gid)}
-\fdesc{Imposta il \acr{gid} effettivo del processo corrente.}
+\fdesc{Imposta il \ids{GID} effettivo del processo corrente.}
}
{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
caso \var{errno} può assumere solo il valore \errcode{EPERM}.
\end{funcproto}
Ancora una volta le due funzioni sono identiche, e quanto diremo per la prima
-riguardo gli \acr{uid} si applica allo stesso modo alla seconda per i
-\acr{gid}. Con \func{seteuid} gli utenti normali possono impostare l'\acr{uid}
-effettivo solo al valore dell'\acr{uid} reale o dell'\acr{uid} salvato,
+riguardo gli \ids{UID} si applica allo stesso modo alla seconda per i
+\ids{GID}. Con \func{seteuid} gli utenti normali possono impostare l'\ids{UID}
+effettivo solo al valore dell'\ids{UID} reale o dell'\ids{UID} salvato,
l'amministratore può specificare qualunque valore. Queste funzioni sono usate
-per permettere all'amministratore di impostare solo l'\acr{uid} effettivo,
+per permettere all'amministratore di impostare solo l'\ids{UID} effettivo,
dato che l'uso normale di \func{setuid} comporta l'impostazione di tutti gli
identificatori.
\fhead{unistd.h}
\fhead{sys/types.h}
\fdecl{int setresuid(uid\_t ruid, uid\_t euid, uid\_t suid)}
-\fdesc{Imposta l'\acr{uid} reale, effettivo e salvato del processo corrente.}
+\fdesc{Imposta l'\ids{UID} reale, effettivo e salvato del processo corrente.}
\fdecl{int setresgid(gid\_t rgid, gid\_t egid, gid\_t sgid)}
-\fdesc{Imposta il \acr{gid} reale, effettivo e salvato del processo corrente.}
+\fdesc{Imposta il \ids{GID} reale, effettivo e salvato del processo corrente.}
}
{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
caso \var{errno} può assumere solo il valore \errcode{EPERM}.
\end{funcproto}
Di nuovo le due funzioni sono identiche e quanto detto per la prima riguardo
-gli \acr{uid} si applica alla seconda per i \acr{gid}. La funzione
-\func{setresuid} imposta l'\acr{uid} reale, l'\acr{uid} effettivo e
-l'\acr{uid} salvato del processo corrente ai valori specificati
+gli \ids{UID} si applica alla seconda per i \ids{GID}. La funzione
+\func{setresuid} imposta l'\ids{UID} reale, l'\ids{UID} effettivo e
+l'\ids{UID} salvato del processo corrente ai valori specificati
rispettivamente dagli argomenti \param{ruid}, \param{euid} e \param{suid}. I
-processi non privilegiati possono cambiare uno qualunque degli\acr{uid} solo
-ad un valore corrispondente o all'\acr{uid} reale, o a quello effettivo o a
+processi non privilegiati possono cambiare uno qualunque degli\ids{UID} solo
+ad un valore corrispondente o all'\ids{UID} reale, o a quello effettivo o a
quello salvato, l'amministratore può specificare i valori che vuole. Un valore
di $-1$ per un qualunque argomento lascia inalterato l'identificatore
corrispondente.
\fhead{unistd.h}
\fhead{sys/types.h}
\fdecl{int getresuid(uid\_t *ruid, uid\_t *euid, uid\_t *suid)}
-\fdesc{Legge l'\acr{uid} reale, effettivo e salvato del processo corrente.}
+\fdesc{Legge l'\ids{UID} reale, effettivo e salvato del processo corrente.}
\fdecl{int getresgid(gid\_t *rgid, gid\_t *egid, gid\_t *sgid)}
-\fdesc{Legge il \acr{gid} reale, effettivo e salvato del processo corrente.}
+\fdesc{Legge il \ids{GID} reale, effettivo e salvato del processo corrente.}
}
{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
caso \var{errno} può assumere solo il valore \errcode{EFAULT} se gli
Il server NFS infatti deve poter cambiare l'identificatore con cui accede ai
file per assumere l'identità del singolo utente remoto, ma se questo viene
-fatto cambiando l'\acr{uid} effettivo o l'\acr{uid} reale il server si espone
+fatto cambiando l'\ids{UID} effettivo o l'\ids{UID} reale il server si espone
alla ricezione di eventuali segnali ostili da parte dell'utente di cui ha
-temporaneamente assunto l'identità. Cambiando solo l'\acr{uid} di filesystem
+temporaneamente assunto l'identità. Cambiando solo l'\ids{UID} di filesystem
si ottengono i privilegi necessari per accedere ai file, mantenendo quelli
originari per quanto riguarda tutti gli altri controlli di accesso, così che
l'utente non possa inviare segnali al server NFS.
\begin{funcproto}{
\fhead{sys/fsuid.h}
\fdecl{int setfsuid(uid\_t fsuid)}
-\fdesc{Imposta l'\acr{uid} di filesystem del processo corrente.}
+\fdesc{Imposta l'\ids{UID} di filesystem del processo corrente.}
\fdecl{int setfsgid(gid\_t fsgid)}
-\fdesc{Legge il \acr{gid} di filesystem del processo corrente.}
+\fdesc{Legge il \ids{GID} di filesystem del processo corrente.}
}
{Le funzioni restituiscono il nuovo valore dell'identificativo in caso di
successo e quello corrente per un errore, in questo caso non viene però
La funzione legge gli identificatori dei gruppi supplementari del processo sul
vettore \param{list} che deve essere di dimensione pari a \param{size}. Non è
-specificato se la funzione inserisca o meno nella lista il \acr{gid} effettivo
+specificato se la funzione inserisca o meno nella lista il \ids{GID} effettivo
del processo. Se si specifica un valore di \param{size} uguale a $0$ allora
l'argomento \param{list} non viene modificato, ma si ottiene il numero di
gruppi supplementari.
La funzione esegue una scansione del database dei gruppi (si veda
sez.~\ref{sec:sys_user_group}) per leggere i gruppi supplementari dell'utente
-specificato per nome (e non con un \acr{uid}) nella stringa passata con
+specificato per nome (e non con un \ids{UID}) nella stringa passata con
l'argomento \param{user}. Ritorna poi nel vettore \param{groups} la lista dei
-\acr{gid} dei gruppi a cui l'utente appartiene. Si noti che \param{ngroups},
+\ids{GID} dei gruppi a cui l'utente appartiene. Si noti che \param{ngroups},
che in ingresso deve indicare la dimensione di \param{group}, è passato come
\itindex{value~result~argument} \textit{value result argument} perché, qualora
il valore specificato sia troppo piccolo, la funzione ritorna $-1$, passando
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
La funzione esegue la scansione del database dei gruppi (usualmente
\conffile{/etc/group}) cercando i gruppi di cui è membro l'utente \param{user}
-(di nuovo specificato per nome e non per \acr{uid}) con cui costruisce una
+(di nuovo specificato per nome e non per \ids{UID}) con cui costruisce una
lista di gruppi supplementari, a cui aggiunge anche
\param{group}, infine imposta questa lista per il processo corrente usando
\func{setgroups}. Si tenga presente che sia \func{setgroups} che
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à.
processo. Un utente normale infatti può modificare solo la priorità dei suoi
processi ed in genere soltanto diminuirla. Fino alla versione di kernel
2.6.12 Linux ha seguito le specifiche dello standard SUSv3, e come per tutti i
-sistemi derivati da SysV veniva richiesto che l'\acr{uid} reale o quello
-effettivo del processo chiamante corrispondessero all'\acr{uid} reale (e solo
+sistemi derivati da SysV veniva richiesto che l'\ids{UID} reale o quello
+effettivo del processo chiamante corrispondessero all'\ids{UID} reale (e solo
a quello) del processo di cui si intendeva cambiare la priorità. A partire
dalla versione 2.6.12 è stata adottata la semantica in uso presso i sistemi
derivati da BSD (SunOS, Ultrix, *BSD), in cui la corrispondenza può essere
-anche con l'\acr{uid} effettivo.
+anche con l'\ids{UID} effettivo.
Sempre a partire dal kernel 2.6.12 è divenuto possibile anche per gli utenti
ordinari poter aumentare la priorità dei propri processi specificando un
sez.~\ref{sec:proc_capabilities}.} può impostare senza restrizioni priorità
assolute diverse da zero o politiche \const{SCHED\_FIFO} e
\const{SCHED\_RR}. Un utente normale può modificare solo le priorità di
-processi che gli appartengono; è cioè richiesto che l'\acr{uid} effettivo del
-processo chiamante corrisponda all'\acr{uid} reale o effettivo del processo
+processi che gli appartengono; è cioè richiesto che l'\ids{UID} effettivo del
+processo chiamante corrisponda all'\ids{UID} reale o effettivo del processo
indicato con \param{pid}.
Fino al kernel 2.6.12 gli utenti normali non potevano impostare politiche
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
La funzione restituisce nell'argomento \param{tp} come una struttura
\struct{timespec}, (la cui definizione si può trovare in
fig.~\ref{fig:sys_timeval_struct}) il valore dell'intervallo di tempo usato
-per la politica \textit{round robin} dal processo indicato da \acr{pid}. Il
+per la politica \textit{round robin} dal processo indicato da \ids{PID}. Il
valore dipende dalla versione del kernel, a lungo infatti questo intervallo di
tempo era prefissato e non modificabile ad un valore di 150 millisecondi,
-restituito indipendentemente dal \acr{pid} indicato.
+restituito indipendentemente dal \ids{PID} indicato.
Con kernel recenti però è possibile ottenere una variazione della
\textit{time-slice}, modificando il valore di \textit{nice} del processo
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
dei processi che gli appartengono,\footnote{per la modifica delle priorità di
altri processi occorrono privilegi amministrativi, ed in particolare la
capacità \const{CAP\_SYS\_NICE} (vedi sez.~\ref{sec:proc_capabilities}).}
-cioè quelli il cui \acr{uid} reale corrisponde all'\acr{uid} reale o effettivo
+cioè quelli il cui \ids{UID} reale corrisponde all'\ids{UID} reale o effettivo
del chiamante. Data la possibilità di ottenere un blocco totale del sistema,
solo l'amministratore\footnote{o un processo con la capacità
\const{CAP\_SYS\_ADMIN} (vedi sez.~\ref{sec:proc_capabilities}).} può
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à
per sovrascriverne altri) viene cancellato quando si mette in esecuzione un
programma con i bit \acr{suid} e \acr{sgid} attivi (vedi
sez.~\ref{sec:file_special_perm}) o con l'uso delle funzioni per la modifica
- degli \acr{uid} dei processi (vedi sez.~\ref{sec:proc_setuid}).
+ degli \ids{UID} dei processi (vedi sez.~\ref{sec:proc_setuid}).
L'operazione è stata introdotta a partire dal kernel 2.3.20, fino al kernel
2.6.12 e per i kernel successivi al 2.6.17 era possibile usare solo un
\item[\const{PR\_SET\_KEEPCAPS}] Consente di controllare quali
\itindex{capabilities} \textit{capabilities} vengono cancellate quando si
- esegue un cambiamento di \acr{uid} del processo (per i dettagli si veda
+ esegue un cambiamento di \ids{UID} del processo (per i dettagli si veda
sez.~\ref{sec:proc_capabilities}, in particolare quanto illustrato a
pag.~\pageref{sec:capability-uid-transition}). Un valore nullo (il default)
per \param{arg2} comporta che vengano cancellate, il valore 1 che vengano
\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
+ 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}
Library}, vedi sez.~\ref{sec:linux_ntpl}) nella \acr{glibc}, essi vengono
utilizzati soltanto se si sono specificati rispettivamente i flag
\const{CLONE\_PARENT\_SETTID}, \const{CLONE\_SETTLS} e
-\const{CLONE\_CHILD\_CLEARTID}.
+\const{CLONE\_CHILD\_SETTID}.
+
+La funzione ritorna un l'identificatore del nuovo \textit{task}, denominato
+\texttt{Thread ID} (da qui in avanti \ids{TID}) il cui significato è analogo
+al \ids{PID} dei normali processi e che a questo corrisponde qualora si crei
+un processo.
Il comportamento di \func{clone}, che si riflette sulle caratteristiche del
-nuovo processo da essa creato, è controllato dall'argomento \param{flags}, che
-deve essere specificato come maschera binaria, ottenuta con un OR aritmetico
-di una delle costanti del seguente elenco, che illustra quelle attualmente
-disponibili:\footnote{si fa riferimento al momento della stesura di questa
- sezione, cioè con il kernel 3.2.}
+nuovo processo da essa creato, è controllato principalmente
+dall'argomento \param{flags}, che deve essere specificato come maschera
+binaria, ottenuta con un OR aritmetico di una delle costanti del seguente
+elenco, che illustra quelle attualmente disponibili:\footnote{si fa
+ 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
+\item[\const{CLONE\_CHILD\_CLEARTID}] cancella il valore del \ids{TID}
\item[\const{CLONE\_CHILD\_SETTID}]
\item[\const{CLONE\_FILES}]
\item[\const{CLONE\_FS}]
% 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