Estetica
[gapil.git] / prochand.tex
index 2578683223646554cb6bc54923d57855dcc7e59e..8da07e6782f6d88339177dda974d1d7ce134a135 100644 (file)
@@ -207,10 +207,17 @@ Tutti i processi figli dello stesso processo padre sono detti
 \textit{sibling}, questa è una delle relazioni usate nel \textsl{controllo di
   sessione}, in cui si raggruppano i processi creati su uno stesso terminale,
 o relativi allo stesso login. Torneremo su questo argomento in dettaglio in
 \textit{sibling}, questa è una delle relazioni usate nel \textsl{controllo di
   sessione}, in cui si raggruppano i processi creati su uno stesso terminale,
 o relativi allo stesso login. Torneremo su questo argomento in dettaglio in
-\secref{cap:session}, dove esamineremo i vari identificativi associati ad un
-processo e le varie relazioni fra processi utilizzate per definire una
+\secref{cap:session}, dove esamineremo gli altri identificativi associati ad
+un processo e le varie relazioni fra processi utilizzate per definire una
 sessione.
 
 sessione.
 
+Oltre al \acr{pid} e al \acr{ppid}, e a quelli usati per il controllo di
+sessione, ad ogni processo sono associati altri identificatori, usati per il
+controllo di accesso, che servono per determinare se il processo può o meno
+eseguire le operazioni richieste, a seconda dei privilegi e dell'identità di
+chi lo ha posto in esecuzione; su questi torneremo in dettaglii più avanti in
+\secref{sec:proc_perm}.
+
 
 \subsection{La funzione \func{fork}}
 \label{sec:proc_fork}
 
 \subsection{La funzione \func{fork}}
 \label{sec:proc_fork}
@@ -370,6 +377,7 @@ periodo di attesa.
 Se eseguiamo il comando senza specificare attese (come si può notare in
 \texttt{\small 17--19} i valori di default specificano di non attendere),
 otterremo come output sul terminale:
 Se eseguiamo il comando senza specificare attese (come si può notare in
 \texttt{\small 17--19} i valori di default specificano di non attendere),
 otterremo come output sul terminale:
+\footnotesize
 \begin{verbatim}
 [piccardi@selidor sources]$ ./forktest 3
 Process 1963: forking 3 child
 \begin{verbatim}
 [piccardi@selidor sources]$ ./forktest 3
 Process 1963: forking 3 child
@@ -386,6 +394,7 @@ Child 3, parent 1963, exiting
 Spawned 3 child, pid 1966 
 Go to next child 
 \end{verbatim} %$
 Spawned 3 child, pid 1966 
 Go to next child 
 \end{verbatim} %$
+\normalsize
 
 Esaminiamo questo risultato: una prima conclusione che si può trarre è non si
 può dire quale processo fra il padre ed il figlio venga eseguito per
 
 Esaminiamo questo risultato: una prima conclusione che si può trarre è non si
 può dire quale processo fra il padre ed il figlio venga eseguito per
@@ -424,6 +433,7 @@ Un secondo aspetto molto importante nella creazione dei processi figli 
 quello dell'interazione dei vari processi con i file; per illustrarlo meglio
 proviamo a redirigere su un file l'output del nostro programma di test, quello
 che otterremo è:
 quello dell'interazione dei vari processi con i file; per illustrarlo meglio
 proviamo a redirigere su un file l'output del nostro programma di test, quello
 che otterremo è:
+\footnotesize
 \begin{verbatim}
 [piccardi@selidor sources]$ ./forktest 3 > output
 [piccardi@selidor sources]$ cat output
 \begin{verbatim}
 [piccardi@selidor sources]$ ./forktest 3 > output
 [piccardi@selidor sources]$ cat output
@@ -450,6 +460,7 @@ Go to next child
 Spawned 3 child, pid 1970 
 Go to next child 
 \end{verbatim}
 Spawned 3 child, pid 1970 
 Go to next child 
 \end{verbatim}
+\normalsize
 che come si vede è completamente diverso da quanto ottenevamo sul terminale.
 
 Il comportamento delle varie funzioni di interfaccia con i file è analizzato
 che come si vede è completamente diverso da quanto ottenevamo sul terminale.
 
 Il comportamento delle varie funzioni di interfaccia con i file è analizzato
@@ -522,16 +533,17 @@ sequenza impredicibile. Le modalit
 Oltre ai file aperti i processi figli ereditano dal padre una serie di altre
 proprietà comuni; in dettaglio avremo che dopo l'esecuzione di una \func{fork}
 padre e figlio avranno in comune:
 Oltre ai file aperti i processi figli ereditano dal padre una serie di altre
 proprietà comuni; in dettaglio avremo che dopo l'esecuzione di una \func{fork}
 padre e figlio avranno in comune:
-\begin{itemize}
+\begin{itemize*}
 \item i file aperti (e gli eventuali flag di \textit{close-on-exec} se
   settati).
 \item gli identificatori per il controllo di accesso: il \textit{real user
     id}, il \textit{real group id}, l'\textit{effective user id},
   l'\textit{effective group id} e i \textit{supplementary group id} (vedi
 \item i file aperti (e gli eventuali flag di \textit{close-on-exec} se
   settati).
 \item gli identificatori per il controllo di accesso: il \textit{real user
     id}, il \textit{real group id}, l'\textit{effective user id},
   l'\textit{effective group id} e i \textit{supplementary group id} (vedi
-  \secref{tab:proc_uid_gid}).
+  \secref{sec:proc_user_group}).
 \item gli identificatori per il controllo di sessione: il \textit{process
 \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{sgid} (vedi \secref{sec:file_suid_sgid}).
+    group id} e il \textit{session id} e il terminale di controllo (vedi
+  \secref{sec:sess_xxx} e \secref{sec:sess_xxx}).
+\item i flag di \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 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}).
@@ -539,9 +551,9 @@ padre e figlio avranno in comune:
 \item i segmenti di memoria condivisa agganciati al processo. 
 \item i limiti sulle risorse
 \item le variabili di ambiente (vedi \secref{sec:proc_environ}).
 \item i segmenti di memoria condivisa agganciati al processo. 
 \item i limiti sulle risorse
 \item le variabili di ambiente (vedi \secref{sec:proc_environ}).
-\end{itemize}
+\end{itemize*}
 le differenze invece sono:
 le differenze invece sono:
-\begin{itemize}
+\begin{itemize*}
 \item il valore di ritorno di \func{fork}.
 \item il \textit{process id}. 
 \item il \textit{parent process id} (quello del figlio viene settato al
 \item il valore di ritorno di \func{fork}.
 \item il \textit{process id}. 
 \item il \textit{parent process id} (quello del figlio viene settato al
@@ -550,7 +562,7 @@ le differenze invece sono:
   \var{tms\_cutime}, \var{tms\_uetime}) che nel figlio sono posti a zero.
 \item i \textit{file lock}, che non vengono ereditati dal figlio.
 \item gli allarmi pendenti, che per il figlio vengono cancellati.
   \var{tms\_cutime}, \var{tms\_uetime}) che nel figlio sono posti a zero.
 \item i \textit{file lock}, che non vengono ereditati dal figlio.
 \item gli allarmi pendenti, che per il figlio vengono cancellati.
-\end{itemize}
+\end{itemize*}
 
 
 \subsection{La funzione \func{vfork}}
 
 
 \subsection{La funzione \func{vfork}}
@@ -603,7 +615,7 @@ Qualunque sia la modalit
 comunque una serie di operazioni: chiude tutti i file aperti, rilascia la
 memoria che stava usando, e così via; l'elenco completo delle operazioni
 eseguite alla chiusura di un processo è il seguente:
 comunque una serie di operazioni: chiude tutti i file aperti, rilascia la
 memoria che stava usando, e così via; l'elenco completo delle operazioni
 eseguite alla chiusura di un processo è il seguente:
-\begin{itemize}
+\begin{itemize*}
 \item tutti i descrittori dei file sono chiusi.
 \item viene memorizzato lo stato di terminazione del processo.
 \item ad ogni processo figlio viene assegnato un nuovo padre.
 \item tutti i descrittori dei file sono chiusi.
 \item viene memorizzato lo stato di terminazione del processo.
 \item ad ogni processo figlio viene assegnato un nuovo padre.
@@ -614,7 +626,7 @@ eseguite alla chiusura di un processo 
 \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}.
 \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}
+\end{itemize*}
 ma al di la di queste operazioni è necessario poter disporre di un meccanismo
 ulteriore che consenta di sapere come questa terminazione è avvenuta; dato che
 in un sistema unix-like tutto viene gestito attraverso i processi il
 ma al di la di queste operazioni è necessario poter disporre di un meccanismo
 ulteriore che consenta di sapere come questa terminazione è avvenuta; dato che
 in un sistema unix-like tutto viene gestito attraverso i processi il
@@ -652,6 +664,7 @@ avr
 di terminazione.  Come verifica di questo comportamento possiamo eseguire il
 comando \cmd{forktest} imponendo a ciascun processo figlio due
 secondi di attesa prima di uscire, il risultato è:
 di terminazione.  Come verifica di questo comportamento possiamo eseguire il
 comando \cmd{forktest} imponendo a ciascun processo figlio due
 secondi di attesa prima di uscire, il risultato è:
+\footnotesize
 \begin{verbatim}
 [piccardi@selidor sources]$ ./forktest -c2 3
 Process 1972: forking 3 child
 \begin{verbatim}
 [piccardi@selidor sources]$ ./forktest -c2 3
 Process 1972: forking 3 child
@@ -668,6 +681,7 @@ Go to next child
 Child 2, parent 1, exiting
 Child 1, parent 1, exiting
 \end{verbatim}
 Child 2, parent 1, exiting
 Child 1, parent 1, exiting
 \end{verbatim}
+\normalsize
 come si può notare in questo caso il processo padre si conclude prima dei
 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
 come si può notare in questo caso il processo padre si conclude prima dei
 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
@@ -697,6 +711,7 @@ condizione: lanciamo il comando \cmd{forktest} in background, indicando al
 processo padre di aspettare 10 secondi prima di uscire; in questo caso, usando
 \cmd{ps} sullo stesso terminale (prima dello scadere dei 10 secondi)
 otterremo:
 processo padre di aspettare 10 secondi prima di uscire; in questo caso, usando
 \cmd{ps} sullo stesso terminale (prima dello scadere dei 10 secondi)
 otterremo:
+\footnotesize
 \begin{verbatim}
 [piccardi@selidor sources]$ ps T
   PID TTY      STAT   TIME COMMAND
 \begin{verbatim}
 [piccardi@selidor sources]$ ps T
   PID TTY      STAT   TIME COMMAND
@@ -707,6 +722,7 @@ otterremo:
   571 pts/0    Z      0:00 [forktest <defunct>]
   572 pts/0    R      0:00 ps T
 \end{verbatim} %$
   571 pts/0    Z      0:00 [forktest <defunct>]
   572 pts/0    R      0:00 ps T
 \end{verbatim} %$
+\normalsize 
 e come si vede, dato che non si è fatto nulla per riceverne lo stato di
 terminazione, i tre processi figli sono ancora presenti pur essendosi
 conclusi, con lo stato di zombie e l'indicazione che sono stati terminati.
 e come si vede, dato che non si è fatto nulla per riceverne lo stato di
 terminazione, i tre processi figli sono ancora presenti pur essendosi
 conclusi, con lo stato di zombie e l'indicazione che sono stati terminati.
@@ -978,6 +994,7 @@ 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},
 \var{ru\_majflt}, e \var{ru\_nswap}.
 
 sono mantenuti sono: \var{ru\_utime}, \var{ru\_stime}, \var{ru\_minflt},
 \var{ru\_majflt}, e \var{ru\_nswap}.
 
+
 \subsection{Le funzioni \texttt{exec}}
 \label{sec:proc_exec}
 
 \subsection{Le funzioni \texttt{exec}}
 \label{sec:proc_exec}
 
@@ -1122,7 +1139,6 @@ indicato dal parametro \var{path}, che viene interpretato come il
   \label{fig:proc_exec_relat}
 \end{figure}
 
   \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
 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
@@ -1133,7 +1149,7 @@ 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:
 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}
+\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
 \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
@@ -1153,7 +1169,7 @@ la lista completa 
 \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})..
 \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}
+\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
 
 Oltre a questo i segnali che sono stati settati per essere ignorati nel
 processo chiamante mantengono lo stesso settaggio pure nuovo programma, tutti
@@ -1197,9 +1213,9 @@ 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 è
   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
+basata la gestione dei processi in unix: con \func{fork} si crea un nuovo
 processo, con \func{exec} si avvia un nuovo programma, con \func{exit} e
 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
+\func{wait} si effettua e verifica la conclusione dei programmi. Tutte le
 altre funzioni sono ausiliarie e servono la lettura e il settaggio dei vari
 parametri connessi ai processi.
 
 altre funzioni sono ausiliarie e servono la lettura e il settaggio dei vari
 parametri connessi ai processi.
 
@@ -1209,112 +1225,275 @@ parametri connessi ai processi.
 \label{sec:proc_perms}
 
 In questa sezione esamineremo le problematiche relative al controllo di
 \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
-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.
+accesso dal punto di vista del processi; vedremo quali sono gli identificatori
+usati, come questi possono essere modificati nella creazione e nel lancio di
+nuovi processi, e 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}
 
 Come accennato in \secref{sec:intro_multiuser} il modello base\footnote{in
 
 
 \subsection{Utente e gruppo di un processo}
 \label{sec:proc_user_group}
 
 Come accennato in \secref{sec:intro_multiuser} il modello base\footnote{in
-  realtà esistono estensioni di questo modello, che lo rendono più flessibile
-  e controllabile, come le \textit{capabilities}, le ACL per i file o il
-  modello a ``... NdT riprendere i dati'' di SELinux} di sicurezza di un
+  realtà già esistono estensioni di questo modello base, che lo rendono più
+  flessibile e controllabile, come le \textit{capabilities}, le ACL per i file
+  o il \textit{Mandatory Access Control} di SELinux} di sicurezza di un
 sistema unix-like è fondato sui concetti di utente e gruppo, e sulla
 sistema unix-like è fondato sui concetti di utente e gruppo, e sulla
-separazione fra l'amministratore, che non è sottoposto a restrizioni, e il
-resto degli utenti, per i quali vengono effettuati i vari controlli di
-accesso.
-
-%Benché il sistema sia piuttosto semplice il sistema permette una
-%notevole fles
-
-Abbiamo già visto come il sistema associ ad ogni utente e gruppo due
-identificatori, lo \acr{uid} e il \acr{gid}, che li contraddistinguono e che
-sono questi quelli che vengono controllati dal kernel nella gestione di
-permessi e protezioni; in \secref{sec:file_access_control} si è visto come
-essi vengano utilizzati per il controllo di accesso ai file, vedremo ora come
-come sono usati nella gestione dei privilegi di accesso dei processi.
-
-In \secref{sec:file_perm_overview} abbiamo visto come ogni file appartenga ad
-un utente e ad un gruppo, e che il controllo di accesso viene eseguito sulla
-base del 
-
-
-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.
+separazione fra l'amministratore (\textsl{root}, detto spesso anche
+\textit{superuser}) che non è sottoposto a restrizioni, ed il resto degli
+utenti, per i quali invece vengono effettuati i vari controlli di accesso.
+
+%Benché il sistema sia piuttosto semplice (è basato su un solo livello di
+% separazione) il sistema permette una
+%notevole flessibilità, 
+
+Abbiamo già accennato come il sistema associ ad ogni utente e gruppo due
+identificatori univoci, lo \acr{uid} e il \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 \secref{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.
+
+Dato che tutte le operazioni del sistema vengono compiute dai processi, è
+evidente che per poter implementare un controllo sulle operazioni occorre
+anche poter identificare chi è che ha lanciato un certo processo, e pertanto
+anche a ciascuno di essi è associato un utente e a un gruppo. 
+
+Un semplice controllo di una corrispondenza fra identificativi però non
+garantisce però sufficiente flessibilità per tutti quei casi in cui è
+necessario poter disporre di privilegi diversi, o dover impersonare un altro
+utente per un limitato insieme di operazioni. Per questo motivo in generale
+tutti gli unix prevedono che i processi abbiano almeno due gruppi di
+identificatori, chiamati rispettivamente \textit{real} ed \textit{effective}.
+
+
 \begin{table}[htb]
   \footnotesize
   \centering
 \begin{table}[htb]
   \footnotesize
   \centering
-  \begin{tabular}[c]{|c|l|p{8cm}|}
+  \begin{tabular}[c]{|c|l|p{6.5cm}|}
     \hline
     \hline
-    \textbf{Sigla} & \textbf{Significato} & \textbf{Utilizzo} \\ 
+    \textbf{Suffisso} & \textbf{Significato} & \textbf{Utilizzo} \\ 
     \hline
     \hline
     \hline
     \hline
-    \acr{ruid} & \textit{real user id} & indica l'utente reale che ha lanciato
+    \acr{uid}   & \textit{real user id} & indica l'utente che ha lanciato
     il programma\\ 
     il programma\\ 
-    \acr{rgid} & \textit{real group id} & indica il gruppo reale dell'utente 
+    \acr{gid}   & \textit{real group id} & indica il gruppo dell'utente 
     che ha lanciato il programma \\ 
     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
+    \acr{euid}  & \textit{effective user id} & indica l'utente usato
+    dal programma nel controllo di accesso \\ 
+    \acr{egid}  & \textit{effective group id} & indica il gruppo 
+    usato dal programma  nel controllo di accesso \\ 
+    --          & \textit{supplementary group id} & indica i gruppi cui
     l'utente appartiene  \\ 
     l'utente appartiene  \\ 
-    \acr{suid} & \textit{saved user id} & indica l'utente  \\ 
-    \acr{sgid} & \textit{saved group id} & indica il gruppo  \\ 
+    --          & \textit{saved user id} &  copia dell'\acr{euid} iniziale\\ 
+    --          & \textit{saved group id} &  copia dell'\acr{egid} iniziale \\ 
     \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}
     \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.}
+  \caption{Identificatori di utente e gruppo associati a ciascun processo con
+    indicazione dei suffissi usate dalle varie funzioni di manipolazione.}
   \label{tab:proc_uid_gid}
 \end{table}
 
   \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}.
-
-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 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.
+Al primo gruppo appartengono il \textit{real user ID} e il \textit{real group
+  ID}: questi vengono settati al login ai valori corrispondenti all'utente con
+cui si accede al sistema (e relativo gruppo di default). Servono per
+l'identificazione dell'utente e normalmente non vengono mai cambiati. In
+realtà vedremo (in \secref{sec:proc_setuid}) che è possibile modificarli, 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.
+
+Al secondo gruppo appartengono l'\textit{effective user ID} e
+l'\textit{effective group ID} (a cui si aggiungono gli eventuali
+\textit{supplementary group id} dei gruppi dei quale l'utente fa parte).
+Questi sono invece gli identificatori usati nella verifiche dei permessi del
+processo e per il controllo di accesso ai file (argomento affrontato in
+dettaglio in \secref{sec:file_perm_overview}). 
+
+Questi identificatori normalmente sono identici ai corrispondenti del gruppo
+\textsl{reale} tranne nel caso in cui, come visto in \secref{sec:proc_exec},
+il programma che si è posto in esecuzione abbia i bit \acr{suid} o \acr{sgid}
+settati (il significato di questi bit è affrontato in dettaglio in
+\secref{sec:file_suid_sgid}). In questo caso essi saranno settati all'utente e
+al gruppo proprietari del file; questo consente, per programmi in cui ci sia
+necessità, di dare a qualunquee utente normale privilegi o permessi di
+un'altro (o dell'amministratore).
+
+Come nel caso del \acr{pid} e del \acr{ppid} tutti questi identificatori
+possono essere letti dal processo attraverso delle opportune funzioni, i cui
+prototipi sono i seguenti:
+
+\begin{functions}
+\headdecl{unistd.h}
+\headdecl{sys/types.h}
+\funcdecl{uid\_t getuid(void)} restituisce il \textit{real user ID} del
+processo corrente.
+\funcdecl{uid\_t geteuid(void)} restituisce l'\textit{effective user ID} del
+processo corrente.
+\funcdecl{gid\_t getgid(void)} restituisce il \textit{real group ID} del
+processo corrente.
+\funcdecl{gid\_t getegid(void)} restituisce l'\textit{effective group ID} del
+processo corrente.
+
+Queste funzioni non riportano condizioni di errore. 
+\end{functions}
+
+In generale l'uso di privilegi superiori 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
+maggiori privilegi necessari, una volta che si siano effettuate le operazioni
+per i quali erano richiesti, e a poterli eventualmente recuperare in caso
+servano di nuovo.
+
+Questo in Linux viene fatto usando altri due gruppi di identificatori, il
+\textit{saved} ed il \textit{filesystem}, analoghi ai precedenti. Il primo
+gruppo è lo stesso usato in SVr4, e previsto dallo standard POSIX quando è
+definita la costante \macro{\_POSIX\_SAVED\_IDS}, il secondo gruppo è
+specifico di Linux e viene usato per migliorare la sicurezza con NFS. 
 
 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 dalla funzione \func{exec} all'avvio del
 
 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 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.
+processo, come copie dell'\textit{effective user id} e dell'\textit{effective
+  group id} dopo che questo sono stati settati tenendo conto di eventuali
+\acr{suid} o \acr{sgid}.  Essi quindi consentono di tenere traccia di quale
+fossero utente e gruppo effettivi all'inizio dell'esecuzione di un nuovo
+programma.
+
+Il \textit{filesystem user id} e il \textit{filesystem group id} sono una
+estensione introdotta in Linux per rendere più sicuro l'uso di NFS (torneremo
+sull'argomento in \secref{sec:proc_setfsuid}). Essi sono una replica dei
+corrispondenti \textit{effective id}, ai quali si sostituiscono per tutte le
+operazioni di verifica dei permessi relativi ai file (trattate in
+\secref{sec:file_perm_overview}).  Ogni cambiamento effettuato sugli
+\textit{effective id} viene automaticamente riportato su di essi, per cui in
+condizioni normali se ne può tranquillamente ignorare l'esistenza, in quanto
+saranno del tutto equivalenti ai precedenti.
+
+Uno specchietto riassuntivo, contenente l'elenco completo degli identificatori
+di utente e gruppo associati dal kernel ad ogni processo, è riportato in
+\tabref{tab:proc_uid_gid}.
+
+
+\subsection{Le funzioni \func{setuid} e \func{setgid}}
+\label{sec:proc_setuid}
 
 
+Le due funzioni che venfono usate per cambiare identità (cioè utente e gruppo
+di appartenenza) ad un processo sono rispettivamente \func{setuid} e
+\func{setgid}; come accennato in \secref{sec:proc_user_group} in Linux esse
+seguono la sematica POSIX che prevede l'esistenza di \textit{saved user id} e
+\textit{saved group id}; i loro prototipi sono:
 
 
-\subsection{Le funzioni \texttt{setuid} e \texttt{setgid}}
-\label{sec:proc_setuid}
+\begin{functions}
+\headdecl{unistd.h}
+\headdecl{sys/types.h}
 
 
+\funcdecl{int setuid(uid\_t uid)} setta l' \textit{user ID} del processo
+corrente.  
+
+\funcdecl{int setgid(gid\_t gid)} setta il \textit{group ID} del processo
+corrente.
+
+Le funzioni restituiscono 0 in caso di successo e -1 in caso di fallimento:
+l'unico errore possibile è \macro{EPERM}. 
+\end{functions}
 
 
-\subsection{Le funzioni \texttt{seteuid} e \texttt{setegid}}
+Il funzionamento di queste due funzioni è analogo, per cui considereremo solo
+la prima; la seconda si comporta esattamente allo stesso modo facendo
+riferimento al \textit{group id} invece che all'\textit{user id}.  
+
+
+L'effetto della chiamata è diverso a seconda dei privilegi del processo; se
+l'\textit{effective user id} è zero (cioè è quello dell'amministratore di
+sistema) allora tutti gli identificatatori (\textit{real}, \textit{effective}
+e \textit{saved}) vengono settati al valore specificato da \var{uid},
+altrimenti viene settato solo l'\textit{effective user id}, e soltanto se il
+valore specificato corrisponde o al \textit{real user id} o al \textit{saved
+  user id}. Negli altri casi segnalato un errore (con \macro{EPERM}).
+
+Come accennato l'uso principale di queste funzioni è quello di poter
+consentire ad un programma con i bit \acr{suid} o \acr{sgid} settati, di
+riportare l'\textit{effective user id} a quello dell'utente che ha lanciato il
+programma, per effettuare il lavoro che non necessita di privilegi aggiuntivi,
+ed eventualmente tornare indietro. 
+
+Occorre però tenere conto che tutto questo non è possibile nel caso di root,
+in tal caso infatti l'esecuzione una \func{setuid} con un \textit{effective
+  user id} uguale a zero comporta il cambiamento di tutti gli identificatori
+associati al processo rendendo impossibile riguadagnare i privilegi di
+amministratore. Questo è l'uso che ne fa \cmd{login} una volta che crea una
+nuova shell per l'utente, ma se si vuole cambiare soltanto l'\textit{effective
+  user id} occorre ricorrere ad altre funzioni (si veda ad esempio
+\secref{sec:proc_seteuid}).
+
+Come esempio per chiarire dell'uso di queste funzioni prediamo quello con cui
+viene gestito l'accesso al file \file{/var/log/utmp}.  In questo file viene
+registrato chi sta usando il sistema al momento corrente; chiaramente non può
+essere lasciato aperto in scrittura a qualunque utente, che protrebbe
+falsificare la registrazione. Per questo motivo questo file (e l'analogo
+\file{/var/log/wtmp} su cui vengono registrati login e logout) appartengono ad
+un gruppo dedicato (\acr{utmp}) ed i programmi che devono accedervi (ad
+esempio tutti i programmi di terminale in X, o il programma \cmd{screen}
+che crea terminali multipli su una console) appartengono a questo gruppo ed
+hanno il bit \acr{sgid} settato.
+
+Quando uno di questi programmi (ad esempio \cmd{xterm}) viene lanciato la
+situazione degli identificatori è la seguente:
+\begin{eqnarray*}
+  \label{eq:1}
+  \textit{real group id}      &=& \textrm{\acr{gid} (del chiamante)} \\
+  \textit{effective group id} &=& \textrm{\acr{utmp}} \\
+  \textit{saved group id}     &=& \textrm{\acr{utmp}}
+\end{eqnarray*}
+in questo modo, dato che l'\textit{effective group id} è quello giusto, il
+programma può accedere a \file{/var/log/utmp} in scrittura ed aggiornarlo, a
+questo punto il programma può eseguire una \func{setgid(getgid())} per settare
+l'\textit{effective group id} a quello dell'utente (ed usando il \textit{real
+  group id} la funzione avrà successo), in questo modo non sarà possibile
+lanciare dal terminale programmi che modificano detto file, in tal caso
+infatti la situazione degli identificatori sarebbe:
+\begin{eqnarray*}
+  \label{eq:2}
+  \textit{real group id}      &=& \textrm{\acr{gid} (invariato)}  \\
+  \textit{effective group id} &=& \textrm{\acr{gid}} \\
+  \textit{saved group id}     &=& \textrm{\acr{utmp} (invariato)}
+\end{eqnarray*}
+e ogni processo lanciato dal terminale avrebbe comunque \acr{gid} come
+\textit{effective group id}. All'uscita dal terminale, per poter di nuovo
+aggiornare lo stato di \file{/var/log/utmp} il programma eseguirà una
+\func{setgid(utmp)} (dove \var{utmp} è il valore numerico associato al gruppo
+\acr{utmp}, ottenuto ad esempio con una \func{getegid}), dato che in questo
+caso il valore richiesto corrisponde al \textit{saved group id} la funzione
+avrà successo e riporterà la situazione a:
+\begin{eqnarray*}
+  \label{eq:3}
+  \textit{real group id}      &=& \textrm{\acr{gid} (invariato)}  \\
+  \textit{effective group id} &=& \textrm{\acr{utmp}} \\
+  \textit{saved group id}     &=& \textrm{\acr{utmp} (invariato)}
+\end{eqnarray*}
+consentendo l'accesso a \file{/var/log/utmp}.
+
+
+\subsection{Le funzioni \func{seteuid} e \func{setegid}}
 \label{sec:proc_seteuid}
 
 
 \label{sec:proc_seteuid}
 
 
+\subsection{Le funzioni \func{setreuid} e \func{setresuid}}
+\label{sec:proc_setreuid}
+
+
+\subsection{Le funzioni \func{setfsuid} e \func{setfsgid}}
+\label{sec:proc_setfsuid}
+
+
+
 \subsection{Le \textit{race condition}}
 \label{sec:proc_race_cond}
 
 \subsection{Le \textit{race condition}}
 \label{sec:proc_race_cond}
 
@@ -1325,5 +1504,3 @@ 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.
 sincronizzazione, non è assolutamente prevedibile, queste situazioni sono
 fonti di errori molto subdoli, che possono verificarsi solo in condizioni
 particolari e quindi difficilmente riproducibili.
-
-