sessione, in cui si raggruppano tutti i processi creati su uno stesso
terminale una volta che si è effettuato il login. Torneremo su questo
argomento in \secref{cap:terminal}, dove esamineremo tutti gli altri
-identificativi associati ad un processo.
-
-\subsection{Utente e gruppo di un processo}
-\label{sec:proc_user_group}
-
-Come 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 confonti 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:file_perm_overview} che ad ogni processo
-associato un certo numero di identificatori (riportati \ntab) che fanno
-riferimento all'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]
- \centering
- \begin{tabular}[c]{|c|l|l|}
- \hline
- Sigla & Significato & Utilizzo \\
- \hline
- \hline
- \acr{ruid} & \textit{real user id} & indica l'utente reale che ha lanciato
- il programma\\
- \acr{rgid} & \textit{real group id} & indica il gruppo reale dell'utente
- che ha lanciato il programma \\
- \acr{euid} & \textit{effective user id} & indica l'utente effettivo usato
- dal programma \\
- \acr{egid} & \textit{effective group id} & indica il gruppo effettivo usato
- dal programma \\
- & \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{fsuid} & \textit{filesystem user id} & indica l'utente effettivo per
- il filesystem \\
- \acr{fsgid} & \textit{filesystem group id} & indica il gruppo effettivo
- per il filesystem \\
- \hline
- \end{tabular}
- \caption{Identificatori di utente e gruppo associati a ciascun processo.}
- \label{tab:proc_uid_gid}
-\end{table}
-
-
-
+identificativi associati ad un processo relativi al controllo di sessione.
\subsection{La funzione \func{fork}}
\end{functions}
Dopo l'esecuzione di una \func{fork} sia il processo padre che il processo
-figlio continuano ad essere eseguiti normalmente, ed il processo figlio esegue
-esattamente lo stesso codice del padre. La sola differenza è che nel processo
-padre il valore di ritorno della funzione fork è il \acr{pid} del processo
-figlio, mentre nel figlio è zero; in questo modo il programma può identificare
-se viene eseguito dal padre o dal figlio.
-
+figlio continuano ad essere eseguiti normalmente alla istruzione seguente la
+\func{fork}; il processo figlio è però una copia del padre, e riceve una copia
+dei segmenti di testo, stack e dati (vedi \secref{sec:proc_mem_layout}), ed
+esegue esattamente lo stesso codice del padre, ma la memoria è copiata, non
+condivisa\footnote{In generale il segmento di testo, che è identico, è
+ condiviso e tenuto in read-only, linux poi utilizza la tecnica del
+ \textit{copy-on-write}, per cui la memoria degli altri segmenti viene
+ copiata dal kernel per il nuovo processo solo in caso di scrittura, rendendo
+ molto più efficiente il meccanismo} pertanto padre e figlio vedono variabili
+diverse.
+
+La differenza che si ha nei due processi è che nel processo padre il valore di
+ritorno della funzione fork è il \acr{pid} del processo figlio, mentre nel
+figlio è zero; in questo modo il programma può identificare se viene eseguito
+dal padre o dal figlio.
+
+\begin{figure}[!htb]
+ \footnotesize
+ \begin{lstlisting}{}
+#include <errno.h> /* error definitions and routines */
+#include <stdlib.h> /* C standard library */
+#include <unistd.h> /* unix standard library */
+#include <stdio.h> /* standard I/O library */
+#include <string.h> /* string functions */
+
+/* Help printing routine */
+void usage(void);
+
+int main(int argc, char *argv[])
+{
+/*
+ * Variables definition
+ */
+ int i;
+ int nchild;
+ pid_t pid;
+
+ ... /* handling options */
+
+ /* There must be remaing parameters */
+ if (optind == argc) {
+ usage();
+ }
+ nchild = atoi(argv[optind]);
+ printf("Test for forking %d child\n", nchild);
+ /* loop to fork children */
+ for (i=0; i<nchild; i++) {
+ if ( (pid = fork()) < 0) {
+ printf("Error on %d child creation, %s\n", i, strerror(errno));
+ }
+ if (pid == 0) { /* child */
+ printf("Child %d successfully executing\n", i++);
+ sleep(2);
+ printf("Child %d exiting\n", i);
+ exit(0);
+ } else { /* parent */
+ printf("Spawned %d child, pid %d \n", i, pid);
+ }
+ }
+ /* normal exit */
+ return 0;
+}
+ \end{lstlisting}
+ \caption{Esempio di codice per la creazione di nuovi processi.}
+ \label{fig:proc_fork_code}
+\end{figure}
+
+Si noti come la funzione \func{fork} ritorni \textbf{due} volte: una nel padre
+e una nel figlio. La sola differenza che si ha nei due processi è il valore di
+ritorno restituito dalla funzione, che nel padre è il \acr{pid} del figlio
+mentre nel figlio è zero; in questo modo il programma può identificare se
+viene eseguito dal padre o dal figlio.
+
+La scelta di questi valori comunque non è casuale, un processo infatti può
+avere più figli, ed il valore di ritorno di \func{fork} è l'unico modo che
+permette di identificare quello appena creato; al contrario un figlio ha
+sempre un solo padre (il cui \acr{pid} può sempre essere ottenuto con
+\func{getppid}, vista in \secref{sec:proc_pid}) e si usa il valore nullo, che
+non può essere il \acr{pid} di nessun processo.
+
+In \curfig\ si è riportato il corpo del codice dell'esempio \cmd{forktest},
+che ci permette di illustrare l'uso della funzione \func{fork}, creando un
+numero di figli specificato a linea di comando; il codice completo, compresa
+la parte che gestisce le opzioni a riga di comando, è disponibile nel file
+\file{ForkTest.c}.
+
+Decifrato il numero di figli da creare, il ciclo principale del programma
+(\texttt{\small 28--40}) esegue in successione la creazione dei processi figli
+controllando il successo della chiamata a \func{fork} (\texttt{\small
+ 29--31}); ciascun figlio (\texttt{\small 29--31}) si limita a stampare il
+suo numero di successione, attendere 3 secondi e scrivere un messaggio prima
+di uscire. Il processo padre invece (\texttt{\small 29--31}) stampa un
+messaggio di creazione e procede nell'esecuzione del ciclo. Se eseguiamo il
+comando otterremo come output sul terminale:
+\begin{verbatim}
+[piccardi@selidor sources]$ ./forktest 5
+Test for forking 5 child
+Spawned 1 child, pid 840
+Child 1 successfully executing
+Child 2 successfully executing
+Spawned 2 child, pid 841
+Spawned 3 child, pid 842
+Child 3 successfully executing
+Spawned 4 child, pid 843
+Child 4 successfully executing
+Child 5 successfully executing
+Spawned 5 child, pid 844
+[piccardi@selidor sources]$ Child 2 exiting
+Child 1 exiting
+Child 4 exiting
+Child 3 exiting
+Child 5 exiting
+\end{verbatim}
+
+Come si vede non si può dire quale processo fra il padre ed il figlio venga
+eseguito per primo\footnote{anche se nel kernel 2.4.x era stato introdotto un
+ meccanismo che metteva in esecuzione sempre il xxx per primo (TODO
+ recuperare le informazioni esatte)} dopo la chiamata a \func{fork}, nel caso
+mostrato sopra ad esempio si può notare come dopo la creazione il secondo ed
+il quinto figlio sia stato stati eseguiti per primi, mantre per gli altri
+figli è stato eseguito per primo il padre.
+
+In generale l'ordine di esecuzione dipenderà, oltre che dall'algoritmo di
+scheduling usato dal kernel, dalla particolare situazione in si trova la
+macchina al momento della chiamata, risultando del tutto impredicibile.
+Eseguendo più volte il programma di prova, si sono ottenute situazioni
+completamente diverse, compreso caso in cui il processo padre ha eseguito più
+di una \func{fork} prima che uno dei figli venisse messo in
+esecuzione.
+
+Pertanto non si può fare nessuna assunzione sulla sequenza di esecuzione delle
+istruzioni del codice fra padre e figli, e se è necessaria una qualche forma
+di precedenza occorrerà provvedere ad espliciti meccanismi di
+sincronizzazione, pena il rischio di incorrere nelle cosiddette \textit{race
+ conditions}.
+
+Si ricordi inoltre che come accennato, essendo i segmenti di memoria
+utilizzati dai singoli processi completamente separati, le modifiche delle
+variabili nei processi figli (come l'incremento di \var{i} in \texttt{\small
+ 33}) saranno effettive solo per essi, e non hanno alcun effetto sul valore
+che le stesse variabili hanno nel processo padre.
\subsection{Le funzioni \texttt{wait} e \texttt{waitpid}}
\label{sec:proc_wait}
+
\subsection{Le funzioni \texttt{exec}}
\label{sec:proc_exec}
\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.
+
+
+\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 confonti 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.
+\begin{table}[htb]
+ \centering
+ \begin{tabular}[c]{|c|l|l|}
+ \hline
+ Sigla & Significato & Utilizzo \\
+ \hline
+ \hline
+ \acr{ruid} & \textit{real user id} & indica l'utente reale che ha lanciato
+ il programma\\
+ \acr{rgid} & \textit{real group id} & indica il gruppo reale dell'utente
+ che ha lanciato il programma \\
+ \acr{euid} & \textit{effective user id} & indica l'utente effettivo usato
+ dal programma \\
+ \acr{egid} & \textit{effective group id} & indica il gruppo effettivo usato
+ dal programma \\
+ & \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{fsuid} & \textit{filesystem user id} & indica l'utente effettivo per
+ il filesystem \\
+ \acr{fsgid} & \textit{filesystem group id} & indica il gruppo effettivo
+ per il filesystem \\
+ \hline
+ \end{tabular}
+ \caption{Identificatori di utente e gruppo associati a ciascun processo.}
+ \label{tab:proc_uid_gid}
+\end{table}
+
+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).
+
+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.
+
+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}.
+
\subsection{Le funzioni \texttt{setuid} e \texttt{setgid}}
\label{sec:proc_setuid}
projects / gapil.git / blobdiff