vengono ereditati (compresi gli zombie) verranno adottati da \cmd{init}, il
quale provvederà a completarne la terminazione.
-Si tenga presente infine che siccome gli zombie sono processi già terminati,
-non c'è modo di eliminarli con il comando \cmd{kill}; l'unica possibilità è
-quella di terminare il processo che li ha generati, in modo che \cmd{init}
-possa adottarli e provvedere a concludere la terminazione.
+Si tenga presente infine che siccome gli zombie sono processi già usciti, non
+c'è modo di eliminarli con il comando \cmd{kill}; l'unica possibilità è quella
+di terminare il processo che li ha generati, in modo che \cmd{init} possa
+adottarli e provvedere a concludere la terminazione.
\subsection{Le funzioni \texttt{wait} e \texttt{waitpid}}
\begin{table}[!htb]
\centering
+ \footnotesize
\begin{tabular}[c]{|c|p{10cm}|}
\hline
\textbf{Macro} & \textbf{Descrizione}\\
sono mantenuti sono: \var{ru\_utime}, \var{ru\_stime}, \var{ru\_minflt},
\var{ru\_majflt}, e \var{ru\_nswap}.
-\subsection{Le \textit{race condition}}
-\label{sec:proc_race_cond}
-
-Si definisce una \textit{race condition} il caso in cui diversi processi
-stanno cercando di fare qualcosa con una risorsa comune ed il risultato finale
-viene a dipendere dall'ordine di esecuzione dei medesimi. Ovviamente dato che
-l'ordine di esecuzione di un processo, senza appositi meccanismi di
-sincronizzazione, non è assolutamente prevedibile, queste situazioni sono
-fonti di errori molto subdoli, che possono verificarsi solo in condizioni
-particolari e quindi difficilmente riproducibili.
-
-
\subsection{Le funzioni \texttt{exec}}
\label{sec:proc_exec}
heap, i dati ed il testo del processo corrente con un nuovo programma letto da
disco.
-Con \func{exec} si chiude il cerchio delle funzioni su cui si basa il
-controllo dei processi in unix: con \func{fork} si crea un nuovo processo, con
-\func{exec} si avvia un nuovo programma, con \func{exit} e\func{wait} si
-effettua e si gestisce la conclusione dei programmi.
-
Ci sono sei diverse versioni di \func{exec} (per questo la si è chiamata
famiglia di funzioni) che possono essere usate per questo compito, che in
realtà (come mostrato in \figref{fig:proc_exec_relat}), costituiscono un
-front-end a \func{execve}. Il suo prototipo è:
+front-end a \func{execve}. Il prototipo di quest'ultima è:
\begin{prototype}{unistd.h}
{int execve(const char * filename, char * const argv [], char * const envp[])}
montato in \cmd{noexec}, oppure non è un file normale o un interprete.
\item \macro{EPERM} il file ha i bit \acr{suid} o \acr{sgid} ma l'utente non
è root o il filesystem è montato con \cmd{nosuid}, oppure
- \item \macro{ENOEXEC}
- \item \macro{ENOENT}
- \item \macro{ENOTDIR}
- \item \macro{ETXTBSY}
- \item \macro{ENFILE}
- \item \macro{EMFILE}
- \item \macro{EINVAL}
- \item \macro{EISDIR}
- \item \macro{ELIBBAD}
+ \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
+ necessari per eseguirlo non esistono.
+ \item \macro{ETXTBSY} L'eseguibile è aperto in scrittura da uno o più
+ processi.
+ \item \macro{EINVAL} L'eseguibile ELF ha più di un segmento
+ \macro{PF\_INTERP}, cioè chiede di essere eseguito da più di un interprete.
+ \item \macro{ELIBBAD} Un interprete ELF non è in un formato riconoscibile.
\end{errlist}
- ed inoltre anche \macro{EFAULT}, \macro{ENOMEM}, \macro{EIO}, \macro{ENAMETOOLONG}, \macro{E2BIG}, \macro{ELOOP}.
+ ed inoltre anche \macro{EFAULT}, \macro{ENOMEM}, \macro{EIO},
+ \macro{ENAMETOOLONG}, \macro{E2BIG}, \macro{ELOOP}, \macro{ENOTDIR},
+ \macro{ENFILE}, \macro{EMFILE}.
\end{prototype}
+Le altre funzioni della famiglia servono per fornire all'utente una serie
+possibile di diverse interfacce per la creazione di un nuovo processo. I loro
+prototipi sono:
+
+\begin{functions}
+\headdecl{unistd.h}
+\funcdecl{int execl(const char *path, const char *arg, ...)}
+\funcdecl{int execv(const char *path, char *const argv[])}
+\funcdecl{int execle(const char *path, const char *arg, ..., char
+* const envp[])}
+\funcdecl{int execlp(const char *file, const char *arg, ...)}
+\funcdecl{int execvp(const char *file, char *const argv[])}
+
+Sostituiscono l'immagine corrente del processo con quella indicata nel primo
+argomento. I parametri successivi consentono di specificare gli argomenti a
+linea di comando e l'ambiente ricevuti dal nuovo processo.
+
+Queste funzioni ritornano solo in caso di errore, restituendo -1; nel qual
+caso \var{errno} andrà ad assumere i valori visti in precedenza per
+\func{execve}.
+\end{functions}
+
+Per capire meglio le differenze fra le funzioni della famiglia si può fare
+riferimento allo specchietto riportato in \ntab. La prima differenza riguarda
+le modalità di passaggio dei parametri che poi andranno a costituire gli
+argomenti a linea di comando (cioè i valori di \var{argv} e \var{argc} visti
+dalla funzione \func{main} del programma chiamato).
+
+Queste modalità sono due e sono riassunte dagli mnenonici \func{v} e \func{l}
+che stanno rispettivamente per \textit{vector} e \textit{list}. Nel primo caso
+gli argomenti sono passati tramite il vettore di puntatori \var{argv[]} a
+stringhe terminate con zero che costituiranno gli argomenti a riga di comando,
+questo vettore \emph{deve} essere terminato da un puntatore nullo.
+
+Nel secondo caso le stringhe degli argomenti sono passate alla funzione come
+lista di puntatori, nella forma:
+\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
+ char * arg0, char * arg1, ..., char * argn, NULL
+\end{lstlisting}
+che deve essere terminata da un puntatore nullo. In entrambi i casi vale la
+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{table}[!htb]
+ \footnotesize
+ \centering
+ \begin{tabular}[c]{|l|c|c|c||c|c|c|}
+ \hline
+ \multicolumn{1}{|c|}{\textbf{Caratteristiche}} &
+ \multicolumn{6}{|c|}{\textbf{Funzioni}} \\
+ \hline
+ &\func{execl\ }&\func{execlp}&\func{execle}
+ &\func{execv\ }& \func{execvp}& \func{execve} \\
+ \hline
+ \hline
+ argomenti a lista &$\bullet$&$\bullet$&$\bullet$&&& \\
+ argomenti a vettore &&&&$\bullet$&$\bullet$&$\bullet$\\
+ \hline
+ filename completo &&$\bullet$&&&$\bullet$& \\
+ ricerca su \var{PATH}&$\bullet$&&$\bullet$&$\bullet$&&$\bullet$ \\
+ \hline
+ ambiente a vettore &&&$\bullet$&&&$\bullet$ \\
+ uso di \var{environ} &$\bullet$&$\bullet$&&$\bullet$&$\bullet$& \\
+ \hline
+ \end{tabular}
+ \caption{Confronto delle caratteristiche delle varie funzioni della
+ famiglia \func{exec}.}
+ \label{tab:proc_exec_scheme}
+\end{table}
+
+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 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 inter-relazione 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
+un vettore di parametri \var{envp[]} analogo a quello usato per gli argomenti
+a riga di comando (terminato quindi da un \macro{NULL}), le altre usano il
+valore della variabile \var{environ} (vedi \secref{sec:proc_environ}) del
+processo di partenza per costruire l'ambiente.
+
+Oltre a mantenere lo stesso \acr{pid}, il nuovo programma fatto partire da
+\func{exec} assume anche una serie di altre proprietà del processo chiamante;
+la lista completa è la seguente:
+\begin{itemize}
+\item il \textit{process ID} (\acr{pid}) ed il \textit{parent process ID}
+ (\acr{ppid}).
+\item il \textit{real user ID} ed il \textit{real group ID} (vedi
+ \secref{sec:proc_user_group}).
+\item i \textit{supplementary group ID} (vedi \secref{sec:proc_user_group}).
+\item il \textit{session ID} ed il \textit{process group ID} (vedi
+ \secref{sec:sess_xxx}).
+\item il terminale di controllo (vedi \secref{sec:sess_xxx}).
+\item il tempo restante ad un allarme.
+\item la directory radice e la directory di lavoro corrente (vedi
+ \secref{sec:file_work_dir}).
+\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 (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 resettatto 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 eseguitio 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
+processo, con \func{exec} si avvia un nuovo programma, con \func{exit} e
+\func{wait} si effettua e si gestisce la conclusione dei programmi. Tutte le
+altre funzioni sono ausiliarie e servono la lettura e il settaggio dei vari
+parametri connessi ai processi.
+
\section{Il controllo di accesso}
\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.
+Abbiamo già accennato in \secref{sec:intro_multiuser} che ad ogni utente e
+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
+oltre che per il controllo di accesso ai file 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
\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
\begin{tabular}[c]{|c|l|p{8cm}|}
\hline
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 indetificatoru 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}}
\subsection{Le funzioni \texttt{seteuid} e \texttt{setegid}}
\label{sec:proc_seteuid}
+
+\subsection{Le \textit{race condition}}
+\label{sec:proc_race_cond}
+
+Si definisce una \textit{race condition} il caso in cui diversi processi
+stanno cercando di fare qualcosa con una risorsa comune ed il risultato finale
+viene a dipendere dall'ordine di esecuzione dei medesimi. Ovviamente dato che
+l'ordine di esecuzione di un processo, senza appositi meccanismi di
+sincronizzazione, non è assolutamente prevedibile, queste situazioni sono
+fonti di errori molto subdoli, che possono verificarsi solo in condizioni
+particolari e quindi difficilmente riproducibili.
+
+
projects / gapil.git / blobdiff