numero unico, il cosiddetto \textit{process identifier} o, più brevemente,
\acr{pid}.
-Una seconda caratteristica è che la generazione di un processo è una
-operazione separata rispetto al lancio di un programma. In genere la sequenza
-è sempre quella di creare un nuovo processo, il quale eseguirà, in un passo
-successivo, il programma voluto: questo è ad esempio quello che fa la shell
-quando mette in esecuzione il programma che gli indichiamo nella linea di
-comando.
-
-Una terza caratteristica è che ogni processo viene sempre generato da un altro
-che viene chiamato processo padre (\textit{parent process}). Questo vale per
-tutti i processi, con una sola eccezione: dato che ci deve essere un punto di
-partenza esiste sempre un processo speciale (che normalmente è
+Una seconda caratteristica di un sistema unix è che la generazione di un
+processo è una operazione separata rispetto al lancio di un programma. In
+genere la sequenza è sempre quella di creare un nuovo processo, il quale
+eseguirà, in un passo successivo, il programma voluto: questo è ad esempio
+quello che fa la shell quando mette in esecuzione il programma che gli
+indichiamo nella linea di comando.
+
+Una terza caratteristica è che ogni processo è sempre stato generato da un
+altro, che viene chiamato processo padre (\textit{parent process}). Questo
+vale per tutti i processi, con una sola eccezione: dato che ci deve essere un
+punto di partenza esiste un processo speciale (che normalmente è
\cmd{/sbin/init}), che viene lanciato dal kernel alla conclusione della fase
-di avvio, essendo questo il primo processo lanciato dal sistema ha sempre il
+di avvio; essendo questo il primo processo lanciato dal sistema ha sempre il
\acr{pid} uguale a 1 e non è figlio di nessun altro processo.
Ovviamente \cmd{init} è un processo speciale che in genere si occupa di far
partire tutti gli altri processi necessari al funzionamento del sistema,
inoltre \cmd{init} è essenziale per svolgere una serie di compiti
-amministrativi nelle operazioni ordinarie del sistema (torneremo si alcuni di
+amministrativi nelle operazioni ordinarie del sistema (torneremo su alcuni di
essi in \secref{sec:proc_termination}) e non può mai essere terminato. La
struttura del sistema comunque consente di lanciare al posto di \cmd{init}
-qualunque altro programma (e in casi di emergenza, ad esempio se il file di
-\cmd{init} si fosse corrotto, è ad esempio possibile lanciare una shell al suo
-posto, passando la riga \cmd{init=/bin/sh} come parametro di avvio).
+qualunque altro programma, e in casi di emergenza (ad esempio se il file di
+\cmd{init} si fosse corrotto) è ad esempio possibile lanciare una shell al suo
+posto, passando la riga \cmd{init=/bin/sh} come parametro di avvio.
\begin{figure}[!htb]
\footnotesize
\begin{verbatim}
-[piccardi@selidor piccardi]$ pstree -n
+[piccardi@gont piccardi]$ pstree -n
init-+-keventd
|-kapm-idled
|-kreiserfsd
kernel, (come \cmd{keventd}, \cmd{kswapd}, etc.)} si possono classificare i
processi con la relazione padre/figlio in una organizzazione gerarchica ad
albero, in maniera analoga a come i file sono organizzati in un albero di
-directory (si veda \secref{sec:file_file_struct}); in \nfig\ si è mostrato il
+directory (si veda \secref{sec:file_file_struct}); in \curfig\ si è mostrato il
risultato del comando \cmd{pstree} che permette di mostrare questa struttura,
alla cui base c'è \cmd{init} che è progenitore di tutti gli altri processi.
\funcdecl{pid\_t getpid(void)} restituisce il pid del processo corrente.
\funcdecl{pid\_t getppid(void)} restituisce il pid del padre del processo
corrente.
+
Entrambe le funzioni non riportano condizioni di errore.
\end{functions}
esempi dell'uso di queste funzioni sono riportati in
\secref{tab:proc_uid_gid}).
\item gli identificatori per il controllo di sessione: il \textit{process
group id} e il \textit{session id} e il terminale di controllo.
-\item i flag \acr{suid} e \acr{suid} (vedi \secref{sec:file_suid_sgid}).
+\item i flag \acr{suid} e \acr{sgid} (vedi \secref{sec:file_suid_sgid}).
\item la directory di lavoro e la directory radice (vedi
\secref{sec:file_work_dir}).
\item la maschera dei permessi di creazione (vedi \secref{sec:file_umask}).
\item se il processo è un leader di sessione viene mandato un segnale di
\macro{SIGHUP} a tutti i processi in background e il terminale di controllo
viene disconnesso.
-\item se la conclusione di un processe rende orfano un \textit{process group}
+\item se la conclusione di un processo rende orfano un \textit{process group}
ciascun membro del gruppo viene bloccato, e poi gli vengono inviati in
successione i segnali \macro{SIGHUP} e \macro{SIGCONT}.
\end{itemize}
(\textit{termination status}) di cui sopra al processo padre.
Nel caso di conclusione normale, lo stato di uscita del processo viene
-caratterizzato tremite il valore del cosiddetto \textit{exit status}, cioè il
+caratterizzato tramite il valore del cosiddetto \textit{exit status}, cioè il
valore passato alle funzioni \func{exit} o \func{\_exit} (o dal valore di
ritorno per \func{main}). Ma se il processo viene concluso in maniera anomala
il programma non può specificare nessun \textit{exit status}, ed è il kernel
La scelta di riportare al padre lo stato di terminazione dei figli, pur
essendo l'unica possibile, comporta comunque alcune complicazioni: infatti se
alla sua creazione è scontato che ogni nuovo processo ha un padre, non è detto
-che sia così alla sua conclusione, dato che il padre protrebbe essere già
+che sia così alla sua conclusione, dato che il padre potrebbe essere già
terminato (si potrebbe avere cioè quello che si chiama un processo
\textsl{orfano}).
chiamati \textit{zombie}, essi restano presenti nella tabella dei processi ed
in genere possono essere identificati dall'output di \cmd{ps} per la presenza
di una \cmd{Z} nella colonna che ne indica lo stato. Quando il padre
-effettuarà la lettura dello stato di uscita anche questa informazione, non più
+effettuerà la lettura dello stato di uscita anche questa informazione, non più
necessaria, verrà scartata e la terminazione potrà dirsi completamente
conclusa.
di sessione, trattato in \capref{cha:session}) che fa ritornare la funzione
anche per i processi figli che sono bloccati ed il cui stato non è stato
ancora riportato al padre. Il valore dell'opzione deve essere specificato come
-mashera binaria ottenuta con l'OR delle suddette costanti con zero.
+maschera binaria ottenuta con l'OR delle suddette costanti con zero.
La terminazione di un processo figlio è chiaramente un evento asincrono
rispetto all'esecuzione di un programma e può avvenire in un qualunque
\begin{table}[!htb]
\centering
+ \footnotesize
\begin{tabular}[c]{|c|p{10cm}|}
\hline
\textbf{Macro} & \textbf{Descrizione}\\
\macro{WEXITSTATUS(s)} & Restituisce gli otto bit meno significativi dello
stato di uscita del processo (passato attraverso \func{\_exit}, \func{exit}
o come valore di ritorno di \func{main}). Può essere valutata solo se
- \macro{WIFEXITED} ha restitituito un valore non nullo.\\
+ \macro{WIFEXITED} ha restituito un valore non nullo.\\
\macro{WIFSIGNALED(s)} & Vera se il processo figlio è terminato
in maniera anomala a causa di un segnale che non è stato catturato (vedi
\secref{sec:sig_notification}).\\
\macro{WTERMSIG(s)} & restituisce il numero del segnale che ha causato
la terminazione anomala del processo. Può essere valutata solo se
- \macro{WIFSIGNALED} ha restitituito un valore non nullo.\\
+ \macro{WIFSIGNALED} ha restituito un valore non nullo.\\
\macro{WCOREDUMP(s)} & Vera se il processo terminato ha generato un
file si \textit{core dump}. Può essere valutata solo se
- \macro{WIFSIGNALED} ha restitituito un valore non nullo\footnote{questa
+ \macro{WIFSIGNALED} ha restituito un valore non nullo\footnote{questa
macro non è definita dallo standard POSIX.1, ma è presente come estensione
sia in Linux che in altri unix}.\\
\macro{WIFSTOPPED(s)} & Vera se il processo che ha causato il ritorno di
l'opzione \macro{WUNTRACED}. \\
\macro{WSTOPSIG(s)} & restituisce il numero del segnale che ha bloccato
il processo, Può essere valutata solo se \macro{WIFSTOPPED} ha
- restitituito un valore non nullo. \\
+ restituito un valore non nullo. \\
\hline
\end{tabular}
\caption{Descrizione delle varie macro di preprocessore utilizzabili per
\file{signal.h}, e stampato usando le funzioni definite in
\secref{sec:sig_strsignal}.
+
+\subsection{Le funzioni \func{wait3} e \func{wait4}}
+\label{sec:proc_wait4}
+
Linux, seguendo una estensione di BSD, supporta altre due funzioni per la
lettura dello stato di terminazione di un processo, analoghe a \func{wait} e
\func{waitpid}, ma che prevedono un ulteriore parametro attraverso il quale il
kernel può restituire al processo padre ulteriori informazioni sulle risorse
-usate dal processo terminato e dai vari figli.
-Queste funzioni diventano accessibili definendo la costante \macro{\_USE\_BSD}
-sono:
+usate dal processo terminato e dai vari figli. Queste funzioni, che diventano
+accessibili definendo la costante \macro{\_USE\_BSD}, sono:
\begin{functions}
\headdecl{sys/times.h}
La funzione è identica a \func{waitpid} sia per comportamento che per i
valori dei parametri, ma restituisce in \var{rusage} un sommario delle
risorse usate dal processo (per i dettagli vedi \secref{sec:xxx_limit_res})
- \funcdecl{pid\_t wait3(int *status, int options, struct rusage *rusage)}
- Prima versione, equivalente a \func{wait4(-1, \&status, opt, rusage)} ormai
- deprecata in favore di \func{wait4}.
+ \funcdecl{pid\_t wait3(int *status, int options, struct rusage *rusage)}
+ Prima versione, equivalente a \func{wait4(-1, \&status, opt, rusage)} è
+ ormai deprecata in favore di \func{wait4}.
\end{functions}
la struttura \type{rusage} è definita in \file{sys/resource.h}, e viene
utilizzata anche dalla funzione \func{getrusage} per ottenere le risorse di
\label{fig:proc_rusage_struct}
\end{figure}
In genere includere esplicitamente \file{<sys/time.h>} non è più necessario,
-ma aumenta la portabiltà, e serve in caso si debba accedere ai campi di
+ma aumenta la portabilità, e serve in caso si debba accedere ai campi di
\var{rusage} definiti come \type{struct timeval}. La struttura è ripresa dalla
versione 4.3 Reno di BSD, attualmente (con il kernel 2.4.x) i soli campi che
sono mantenuti sono: \var{ru\_utime}, \var{ru\_stime}, \var{ru\_minflt},
*envp[])}.
La funzione ritorna -1 solo in caso di errore, nel qual caso caso la
- variabile \texttt{errno} è settata come:
+ \var{errno} può assumere i valori:
\begin{errlist}
\item \macro{EACCES} il file non è eseguibile, oppure il filesystem è
montato in \cmd{noexec}, oppure non è un file normale o un interprete.
è root o il filesystem è montato con \cmd{nosuid}, oppure
\item \macro{ENOEXEC} il file è in un formato non eseguibile o non
riconosciuto come tale, o compilato per un'altra architettura.
- \item \macro{ENOENT} il file o una delle librerie dinamiche o l'inteprete
+ \item \macro{ENOENT} il file o una delle librerie dinamiche o l'interprete
necessari per eseguirlo non esistono.
\item \macro{ETXTBSY} L'eseguibile è aperto in scrittura da uno o più
processi.
La seconda differenza fra le funzioni riguarda le modalità con cui si
specifica il programma che si vuole eseguire. Con lo mnemonico \func{p} si
-indicano le due funzioni che necessitano del \textit{pathname} assoluto del
-programma come valore del parametro \var{path}. Le altre quattro funzioni
-invece usano come parametro \var{file} un nome che viene cercato
-automaticamente fra i file presenti nella lista di directory specificate dalla
-variabile di ambiente \var{PATH}.
+indicano le due funzioni che replicano il comportamento della shell nello
+specificare il comando da eseguire; quando il parametro \var{file} non
+contiene una \file{/} 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
+permessi negati (cioè l'esecuzione della sottostante \func{execve} ritorna un
+\macro{EACCESS}), la ricerca viene proseguita nelle eventuali ulteriori
+directory indicate nel \var{PATH}, solo se non viene trovato nessun altro file
+viene finalmente restituito \macro{EACCESS}.
+
+Le altre quattro funzioni si limitano invece a cercare di eseguire il file
+indicato dal parametro \var{path}, che viene interpretato come il
+\textit{pathname} del programma.
+
+\begin{figure}[htb]
+ \centering
+ \includegraphics[width=13cm]{img/exec_rel.eps}
+ \caption{La interrelazione fra le sei funzioni della famiglia \func{exec}}
+ \label{fig:proc_exec_relat}
+\end{figure}
+
La terza differenza è come viene passata la lista delle variabili di ambiente.
Con lo mnemonico \func{e} vengono indicate quelle funzioni che necessitano di
\item la maschera di creazione dei file (\var{umask}, vedi
\secref{sec:file_umask}) ed i \textit{lock} sui file (vedi
\secref{sec:file_xxx}).
-\item i segnali sospesi (\textit{pending}) e la maschera dei segnali.
+\item i segnali sospesi (\textit{pending}) e la maschera dei segnali (si veda
+ \secref{sec:sig_xxx}).
\item i limiti sulle risorse (vedi \secref{sec:limits_xxx})..
\item i valori delle variabili \var{tms\_utime}, \var{tms\_stime},
\var{tms\_cutime}, \var{tms\_ustime} (vedi \secref{sec:xxx_xxx})..
\end{itemize}
-
-
-
+Oltre a questo i segnali che sono stati settati per essere ignorati nel
+processo chiamante mantengono lo stesso settaggio pure nuovo programma, tutti
+gli altri segnali vengono settati alla loro azione di default. Un caso
+speciale è il segnale \macro{SIGCHLD} che, quando settato a \macro{SIG\_IGN}
+può anche non essere resettato a \macro{SIG\_DFL} (si veda
+\secref{sec:sig_xxx}).
+
+La gestione dei file aperti dipende dal valore del flag di
+\textit{close-on-exec} per ciascun file descriptor (si veda
+\secref{sec:file_xxx}); i file per cui è settato vengono chiusi, tutti gli
+altri file restano aperti. Questo significa che il comportamento di default è
+che i file restano aperti attraverso una \func{exec}, a meno di una chiamata
+esplicita a \func{fcntl} che setti il suddetto flag.
+
+Per le directory lo standard POSIX.1 richiede che esse vengano chiuse
+attraverso una \func{exec}, in genere questo è fatto dalla funzione
+\func{opendir} che effettua da sola il settaggio del flag di
+\textit{close-on-exec} sulle directory che apre, in maniera trasparente
+all'utente.
+
+Abbiamo detto che il \textit{real user ID} ed il \textit{real group ID}
+restano gli stessi all'esecuzione di \func{exec}; lo stesso vale per
+l'\textit{effective user ID} ed l'\textit{effective group ID}, tranne il caso
+in cui il file che si va ad eseguire ha o il \acr{suid} bit o lo \acr{sgid}
+bit settato, nel qual caso \textit{effective user ID} e \textit{effective
+ group ID} vengono settati rispettivamente all'utente o al gruppo cui il file
+appartiene (per i dettagli vedi \secref{sec:proc_perms}).
+
+Se il file da eseguire è in formato \emph{a.out} e necessita di librerie
+condivise, viene lanciato il \textit{linker} dinamico \cmd{ld.so} prima del
+programma per caricare le librerie necessarie ed effettuare il link
+dell'eseguibile. Se il programma è in formato ELF per caricare le librerie
+dinamiche viene usato l'interprete indicato nel segmento \macro{PT\_INTERP},
+in genere questo è \file{/lib/ld-linux.so.1} per programmi linkati con le
+\emph{libc5}, e \file{/lib/ld-linux.so.2} per programmi linkati con le
+\emph{glibc}. Infine nel caso il file sia uno script esso deve iniziare con
+una linea nella forma \cmd{\#!/path/to/interpreter} dove l'interprete indicato
+deve esse un valido programma (binario, non un altro script) che verrà
+chiamato come se si fosse eseguito il comando \cmd{interpreter [arg]
+ filename}.
Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è
basato il controllo dei processi in unix: con \func{fork} si crea un nuovo
parametri connessi ai processi.
+
\section{Il controllo di accesso}
\label{sec:proc_perms}
In questa sezione esamineremo le problematiche relative al controllo di
accesso dal punto di vista del processi; gli identificativi usati, come questi
-vengono modificati nella creazione e nel lancio di nuovi processi, e le varie
-funzioni per la loro manipolazione diretta.
+possono essere modificati nella creazione e nel lancio di nuovi processi, le
+varie funzioni per la loro manipolazione diretta e tutte le problematiche
+connesse alla gestione accorta dei privilegi.
\subsection{Utente e gruppo di un processo}
\label{sec:proc_user_group}
-Abbiamo già accennato in \secref{sec:intro_multiuser} ad ogni utente ed gruppo
-sono associati due identificatori univoci, lo \acr{uid} e il \acr{gid} che li
-contraddistinguono nei confronti del kernel. Questi identificatori stanno alla
-base del sistema di permessi e protezioni di un sistema unix, e vengono usati
-anche nella gestione dei privilegi di accesso dei processi.
-
-In realtà ad ogni processo è associato un certo numero di identificatori, il
-cui elenco è riportato \ntab, in genere questi derivano direttamente
-dall'utente che ha lanciato il processo (attraverso i valori di \acr{uid} e
-\acr{gid}), e vengono usati sia per il controllo di accesso ai file che per la
-gestione dei privilegi associati ai processi stessi.
+Abbiamo già accennato in \secref{sec:intro_multiuser} che il sistema base
+della sicurezza in unix è basato sui concetti di utente e gruppo; ad essi sono
+associati due identificatori univoci, lo \acr{uid} e il \acr{gid} che li
+contraddistinguono nei confronti del kernel. Questi identificatori sono quelli
+che vengono controllati nella gestione di permessi e protezioni in un sistema
+unix, e oltre che per il controllo di accesso ai file, già esposto in
+\secref{sec:file_access_control}, vengono usati anche nella gestione dei
+privilegi di accesso dei processi.
+
+Abbiamo già incontrato in \secref{sec:file_perm_overview}
+
+
+
+Ad ogni processo è associato un certo numero di identificatori, il cui elenco
+è riportato \ntab, in genere questi derivano direttamente dall'utente che ha
+lanciato il processo (attraverso i valori di \acr{uid} e \acr{gid}), e vengono
+usati sia per il controllo di accesso ai file che per la gestione dei
+privilegi associati ai processi stessi.
\begin{table}[htb]
\footnotesize
\centering
& \textit{supplementary group id} & indica i gruppi cui
l'utente appartiene \\
\acr{suid} & \textit{saved user id} & indica l'utente \\
- \acr{sgid} & \textit{daved group id} & indica il gruppo \\
+ \acr{sgid} & \textit{saved group id} & indica il gruppo \\
\acr{fsuid} & \textit{filesystem user id} & indica l'utente effettivo per
il filesystem \\
\acr{fsgid} & \textit{filesystem group id} & indica il gruppo effettivo
Il \textit{real user id} e il \textit{real group id} indicano l'utente che ha
lanciato il processo, e vengono settati al login al valore standard di
\acr{uid} e \acr{gid} dell'utente letti direttamente da \file{/etc/passwd}.
-Questi non vengono mai cambiati nella creazione di nuovi processi e restano
-sempre gli stessi per tutti i processi avviati in una sessione. In realtà è
-possibile modificarli (vedi \secref{sec:proc_setuid}), ma solo per un processo
-che abbia i privilegi di amministratore (ed è così infatti che \cmd{login},
-che gira con i privilegi di amministratore, li setta ai valori corrispondenti
-all'utente che entra nel sistema).
+
+Esso servono ad identificare l'utente che ha lanciato il processo e non
+vengono mai cambiati nella creazione di nuovi processi restando sempre gli
+stessi per tutti i processi avviati in una sessione. In realtà vedremo che è
+possibile possibile modificarli (in \secref{sec:proc_setuid}), ma solo ad un
+processo che abbia i privilegi di amministratore; questa possibilità è usata
+ad esempio da \cmd{login} che una volta completata la procedura di
+autenticazione lancia una shell per la quale setta questi identificatori ai
+valori corrispondenti all'utente che entra nel sistema.
L'\textit{effective user id}, l'\textit{effective group id} e gli eventuali
-\textit{supplementary group id} sono gli identificativi usati per il controllo
-di accesso ai file secondo quanto descritto in dettaglio in
-\secref{sec:file_perm_overview}. Normalmente sono uguali al \textit{real user
- id} e al \textit{real group id}, a meno che il file posto in esecuzione non
-abbia i bit \acr{suid} o \acr{sgid} settati, nel qual caso vengono settati
-rispettivamente all'\acr{uid} e \acr{gid} del file.
+\textit{supplementary group id} sono invece gli identificatori usati per il
+controllo di accesso ai file (secondo quanto descritto in dettaglio in
+\secref{sec:file_perm_overview}). Normalmente essi sono uguali al \textit{real
+ user id} e al \textit{real group id}, a meno che il file posto in esecuzione
+non abbia o il bit \acr{suid} o il bit \acr{sgid} settato, in questo caso alla
+la funzione \func{exec} (vedi \secref{}) li setta rispettivamente ai valori
+dell'\acr{uid} e del \acr{gid} cui appartiene il file.
Il \textit{saved user id} e il \textit{saved group id} sono copie
dell'\textit{effective user id} e dell'\textit{effective group id} del
-processo padre, e vengono settati all'avvio del processo, prima che
-\textit{effective user id} e \textit{effective group id} vengano modificati
-per tener conto di eventuali \acr{suid} o \acr{sgid}.
+processo padre, e vengono settati dalla funzione \func{exec} all'avvio del
+processo, prima che \textit{effective user id} e \textit{effective group id}
+vengano modificati per tener conto di eventuali \acr{suid} o \acr{sgid}, essi
+quindi consentono di tenere traccia di quale fossero l'utente originale.
\subsection{Le funzioni \texttt{setuid} e \texttt{setgid}}
projects / gapil.git / blobdiff