Correzioni minime

[gapil.git] / prochand.tex

diff --git a/prochand.tex b/prochand.tex
index 1dddba1edf3092f2fd1ee7b33b1e0dd1b4de49b4..22da5c0194b660c71df60ba5a39403221ef5c9c3 100644 (file)
--- a/prochand.tex
+++ b/prochand.tex
@@ -70,9 +70,9 @@ processo \cmd{init} che 
 
 I processi vengono creati dalla funzione \func{fork}; in molti unix questa è
 una system call, Linux però usa un'altra nomenclatura, e la funzione fork è
 
 I processi vengono creati dalla funzione \func{fork}; in molti unix questa è
 una system call, Linux però usa un'altra nomenclatura, e la funzione fork è

-basata a sua volta sulla system call \func{clone}, che viene usata anche per
-generare i \textit{thread}.  Il processo figlio creato dalla \func{fork} è una
-copia identica del processo processo padre, ma ha nuovo \acr{pid} e viene
+basata a sua volta sulla system call \func{\_\_clone}, che viene usata anche
+per generare i \textit{thread}.  Il processo figlio creato dalla \func{fork} è
+una copia identica del processo processo padre, ma ha nuovo \acr{pid} e viene

 eseguito in maniera indipendente (le differenze fra padre e figlio sono
 affrontate in dettaglio in \secref{sec:proc_fork}).
 
 eseguito in maniera indipendente (le differenze fra padre e figlio sono
 affrontate in dettaglio in \secref{sec:proc_fork}).
 


@@ -157,56 +157,12 @@ cui diventa possibile garantire l'unicit
 generare un pathname univoco, che non potrà essere replicato da un'altro
 processo che usi la stessa funzione. 
 
 generare un pathname univoco, che non potrà essere replicato da un'altro
 processo che usi la stessa funzione. 
 

-
-\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.
-
- a ciascun
-processo venfon
-
-
-Come accennato in \secref{sec:file_perm_overview} a processo viene associato
-un certo numero di identificatori (riportati in \ntab) che 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}
-
-
-
+Tutti i processi figli dello stesso processo padre sono detti
+\textit{sibling}, questa è un'altra delle relazioni usate nel controllo di
+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 relativi al controllo di sessione.

 
 
 \subsection{La funzione \func{fork}}
 
 
 \subsection{La funzione \func{fork}}


@@ -222,29 +178,167 @@ della funzione 
   \headdecl{unistd.h} 
   
   \funcdecl{pid\_t fork(void)} 
   \headdecl{unistd.h} 
   
   \funcdecl{pid\_t fork(void)} 

-
-  Le funzioni restituiscono zero in caso di successo e -1 per un errore, in
-  caso di errore \texttt{errno} può assumere i valori:
+  
+  Restituisce zero al padre e il \acr{pid} al figlio in caso di successo,
+  ritorna -1 al padre (senza creare il figlio) in caso di errore;
+  \texttt{errno} può assumere i valori:

   \begin{errlist}
   \begin{errlist}

-  \item \macro{EAGAIN}
-  \item \macro{ENOMEM}
+  \item \macro{EAGAIN} non ci sono risorse sufficienti per creare un'altro
+    processo (per allocare la tabella delle pagine e le strutture del task) o
+    si è esaurito il numero di processi disponibili.
+  \item \macro{ENOMEM} non è stato possibile allocare la memoria per le
+    strutture necessarie al kernel per creare il nuovo processo.

   \end{errlist}
 \end{functions}
 
   \end{errlist}
 \end{functions}
 

-
-Dopo l'esecuzione di una 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 pid del processo figlio,
+Dopo l'esecuzione di una \func{fork} sia il processo padre che il processo
+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. 
 
 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{wait} e  \texttt{waitpid}}
 \label{sec:proc_wait}
 

+

 \subsection{Le funzioni \texttt{exec}}
 \label{sec:proc_exec}
 
 \subsection{Le funzioni \texttt{exec}}
 \label{sec:proc_exec}
 


@@ -254,15 +348,26 @@ viene eseguito dal padre o dal figlio.
 \section{Il controllo di accesso}
 \label{sec:proc_perms}
 
 \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}

 
 

-
-Come accennato in \secref{sec:file_perm_overview} ciascun processo porta con
-se un gruppo di identificatori (riportati in \ntab) utilizzati per i controllo
-degli accessi, 
-
-
+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|}
 \begin{table}[htb]
   \centering
   \begin{tabular}[c]{|c|l|l|}


@@ -270,21 +375,52 @@ degli accessi,
     Sigla & Significato & Utilizzo \\ 
     \hline
     \hline
     Sigla & Significato & Utilizzo \\ 
     \hline
     \hline

-    \acr{ruid} & \textit{real user id} & indica l'utente reale \\ 
-    \acr{rgid} & \textit{real group id} & indica il gruppo reale \\ 
-    \acr{euid} & \textit{effective user id} & indica l'utente reale \\ 
-    \acr{egid} & \textit{effective group id} & indica il gruppo reale \\ 
-               & \textit{supplementaru group id} & indica il gruppo  \\ 
-    \acr{suid} & \textit{saved user id} & indica l'utente reale \\ 
-    \acr{sgid} & \textit{daved group id} & indica il gruppo reale \\ 
-    \acr{fsuid} & \textit{real user id} & indica l'utente reale \\ 
-    \acr{fsgid} & \textit{real group id} & indica il gruppo reale \\ 
+    \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}
 
     \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}
 
 \subsection{Le funzioni \texttt{setuid} e \texttt{setgid}}
 \label{sec:proc_setuid}