X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=prochand.tex;h=4eb3d74603609dbed04093089a5cf81e3d6bd93d;hp=173c0bed7e7d585913bacce51ee78a8742d1f6ff;hb=470f15a82390d6120981e85202f45fc102f3e8a3;hpb=30cb49b067deded2d7f8c8331d466c3a937c4288

diff --git a/prochand.tex b/prochand.tex
index 173c0be..4eb3d74 100644
--- a/prochand.tex
+++ b/prochand.tex
@@ -991,13 +991,13 @@ le apposite funzioni trattate 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,
-\func{wait} e \func{waitpd}, per la lettura dello stato di terminazione di un
-processo, analoghe alle precedenti ma che prevedono un ulteriore parametro
-attraverso il quale il kernel può restituire al padre informazioni sulle
-risorse usate dal processo terminato e dai vari figli.  I prototipi di queste
-funzioni, che diventano accessibili definendo la costante \macro{\_USE\_BSD},
-sono:
+Linux, seguendo una estensione di BSD, supporta altre due funzioni per la
+lettura dello stato di terminazione di un processo \func{wait3} e
+\func{wait4}, analoghe alle precedenti ma che prevedono un ulteriore
+parametro attraverso il quale il kernel può restituire al padre informazioni
+sulle risorse usate dal processo terminato e dai vari figli.  I prototipi di
+queste funzioni, che diventano accessibili definendo la costante
+\macro{\_USE\_BSD}, sono:
 \begin{functions}
   \headdecl{sys/times.h} 
   \headdecl{sys/types.h} 
@@ -1052,8 +1052,9 @@ famiglia di funzioni) che possono essere usate per questo compito, in realt
   \begin{errlist}
   \item[\macro{EACCES}] il file non è eseguibile, oppure il filesystem è
     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{EPERM}] il file ha i bit \acr{suid} o \acr{sgid}, l'utente non
+    è root, e o il processo viene tracciato, o il filesystem è montato con
+    l'opzione \cmd{nosuid}.
   \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'interprete
@@ -1211,12 +1212,12 @@ speciale 
 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_fcntl}); 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.
+La gestione dei file aperti dipende dal valore che ha il flag di
+\textit{close-on-exec} (trattato in \secref{sec:file_fcntl}) per ciascun file
+descriptor. 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
@@ -1226,9 +1227,9 @@ 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
+l'\textit{effective user id} ed l'\textit{effective group id}, tranne quando
+il file che si va ad eseguire abbia o il \acr{suid} bit o lo \acr{sgid} bit
+settato, in questo caso l'\textit{effective user id} e l'\textit{effective
   group id} vengono settati rispettivamente all'utente o al gruppo cui il file
 appartiene (per i dettagli vedi \secref{sec:proc_perms}).
 
@@ -1260,8 +1261,8 @@ parametri connessi ai processi.
 In questa sezione esamineremo le problematiche relative al controllo di
 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 ad una gestione accorta dei privilegi.
+nuovi processi, le varie funzioni per la loro manipolazione diretta e tutte le
+problematiche connesse ad una gestione accorta dei privilegi.
 
 
 \subsection{Gli identificatori del controllo di accesso}
@@ -1294,12 +1295,12 @@ evidente che per poter implementare un controllo sulle operazioni occorre
 anche poter identificare chi è che ha lanciato un certo programma, e pertanto
 anche a ciascun processo è 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}.
+Un semplice controllo di una corrispondenza fra identificativi 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
@@ -1341,8 +1342,8 @@ 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
+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
@@ -1357,7 +1358,7 @@ Questi identificatori normalmente sono identici ai corrispondenti del gruppo
 \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
+all'utente e al gruppo proprietari del file. Questo consente, per programmi in
 cui ci sia necessità, di dare a qualunque utente normale privilegi o permessi
 di un'altro (o dell'amministratore).
 
@@ -1447,8 +1448,7 @@ corrente.
 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}.  Gli
-eventuali \textit{supplementary group id} non vengono modificati da nessuna
-delle funzioni che tratteremo in questa sezione.
+eventuali \textit{supplementary group id} non vengono modificati.
 
 
 L'effetto della chiamata è diverso a seconda dei privilegi del processo; se
@@ -1465,16 +1465,16 @@ riportare l'\textit{effective user id} a quello dell'utente che ha lanciato il
 programma, effettuare il lavoro che non necessita di privilegi aggiuntivi, ed
 eventualmente tornare indietro.
 
-Come esempio per chiarire dell'uso di queste funzioni prediamo quello con cui
+Come esempio per chiarire dell'uso di queste funzioni prendiamo 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 potrebbe
 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.
+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:
@@ -1526,7 +1526,7 @@ ricorrere ad altre funzioni (si veda ad esempio \secref{sec:proc_seteuid}).
 \label{sec:proc_setreuid}
 
 Queste due funzioni derivano da BSD che, non supportando\footnote{almeno fino
-  alla versione 4.3+BSD TODO, verificare e aggiornare la nota.} i
+  alla versione 4.3+BSD TODO, FIXME verificare e aggiornare la nota.} i
 \textit{saved id}, le usava per poter scambiare fra di loro \textit{effective}
 e \textit{real id}. I loro prototipi sono:
 \begin{functions}
@@ -1750,8 +1750,8 @@ ottenere tutti i gruppi a cui appartiene un utente; il suo prototipo 
     restituisce 0 in caso di successo e -1 in caso di fallimento.}
 \end{functions}
 \noindent la funzione esegue una scansione del database dei gruppi (si veda
-\secref{sec:sys_xxx}) e ritorna in \param{groups} la lista di quelli a cui
-l'utente appartiene. Si noti che \param{ngroups} è passato come puntatore
+\secref{sec:sys_user_group}) e ritorna in \param{groups} la lista di quelli a
+cui l'utente appartiene. Si noti che \param{ngroups} è passato come puntatore
 perché qualora il valore specificato sia troppo piccolo la funzione ritorna -1
 e passando indietro il numero dei gruppi trovati.
 
@@ -1823,11 +1823,10 @@ occorre tenere conto di una serie di problematiche che normalmente non
 esistono quando si ha a che fare con un sistema in cui viene eseguito un solo
 programma alla volta.
 
-Pur essendo questo argomento di carattere generale, in questa sezione
-conclusiva del capitolo in cui abbiamo affrontato la gestione dei processi ci
-è parso opportuno introdurre sinteticamente queste problematiche, che
-ritroveremo a più riprese in capitoli successivi, dando una breve descrizione
-delle loro caratteristiche principali e della terminologia relativa.
+Pur essendo questo argomento di carattere generale, ci è parso opportuno
+introdurre sinteticamente queste problematiche, che ritroveremo a più riprese
+in capitoli successivi, in questa sezione conclusiva del capitolo in cui
+abbiamo affrontato la gestione dei processi.
 
 
 \subsection{Le operazioni atomiche}
@@ -1849,7 +1848,7 @@ cui non erano ancora state completate.
 Nel caso dell'interazione fra processi la situazione è molto più semplice, ed
 occorre preoccuparsi della atomicità delle operazioni solo quando si ha a che
 fare con meccanismi di intercomunicazione (che esamineremo in dettaglio in
-\capref{cha:IPC}) o nella operazioni con i file (vedremo alcuni esempi in
+\capref{cha:IPC}) o nelle operazioni con i file (vedremo alcuni esempi in
 \secref{sec:file_atomic}). In questi casi in genere l'uso delle appropriate
 funzioni di libreria per compiere le operazioni necessarie è garanzia
 sufficiente di atomicità in quanto le system call con cui esse sono realizzate
@@ -1865,13 +1864,13 @@ operazioni atomiche (torneremo su questi aspetti in \secref{sec:sign_xxx}).
 
 In questo caso il sistema provvede un tipo di dato, il \type{sig\_atomic\_t},
 il cui accesso è assicurato essere atomico.  In pratica comunque si può
-assumere che in ogni piattaforma su cui è implementato Linux il tipo
-\type{int} (e gli altri interi di dimensione inferiore) ed i puntatori sono
+assumere che, in ogni piattaforma su cui è implementato Linux, il tipo
+\type{int}, gli altri interi di dimensione inferiore ed i puntatori sono
 atomici. Non è affatto detto che lo stesso valga per interi di dimensioni
 maggiori (in cui l'accesso può comportare più istruzioni in assembler) o per
-le strutture. In questi casi è anche opportuno marcare come \type{volatile} le
-variabili che possono essere interessate ad accesso condiviso, onde evitare
-problemi con le ottimizzazioni del codice.
+le strutture. In tutti questi casi è anche opportuno marcare come
+\type{volatile} le variabili che possono essere interessate ad accesso
+condiviso, onde evitare problemi con le ottimizzazioni del codice.
 
 
 \subsection{Le \textit{race condition} e i \textit{deadlock}}
@@ -1880,7 +1879,7 @@ problemi con le ottimizzazioni del codice.
 Si definiscono \textit{race condition} tutte quelle situazioni in cui processi
 diversi operano su una risorsa comune, ed in cui il risultato viene a
 dipendere dall'ordine in cui essi effettuano le loro operazioni. Il caso
-tipico è quella di una operazione che viene eseguita da un processo in più
+tipico è quello di una operazione che viene eseguita da un processo in più
 passi, e può essere compromessa dall'intervento di un altro processo che
 accede alla stessa risorsa quando ancora non tutti i passi sono stati
 completati.
@@ -1900,8 +1899,8 @@ gli adeguati provvedimenti per far si che non si verifichino. Casi tipici di
 file, o nell'accesso a meccanismi di intercomunicazione come la memoria
 condivisa. In questi casi, se non si dispone della possibilità di eseguire
 atomicamente le operazioni necessarie, occorre che quelle parti di codice in
-cui si compiono le operazioni critiche sulle risorse condivise, le cosiddette
-\textsl{sezioni critiche} del programma, siano opportunamente protette da
+cui si compiono le operazioni sulle risorse condivise (le cosiddette
+\textsl{sezioni critiche}) del programma, siano opportunamente protette da
 meccanismi di sincronizzazione (torneremo su queste problematiche di questo
 tipo in \secref{sec:ipc_semaph}).
 
@@ -1919,8 +1918,7 @@ quest'ultima diventer
 In tutti questi casi è di fondamentale importanza il concetto di atomicità
 visto in \secref{sec:proc_atom_oper}; questi problemi infatti possono essere
 risolti soltanto assicurandosi, quando essa sia richiesta, che sia possibile
-eseguire in maniera atomica le operazioni necessarie, proteggendo con gli
-adeguati meccanismi le \textsl{sezioni critiche} del programma.
+eseguire in maniera atomica le operazioni necessarie.
 
 
 \subsection{Le funzioni rientranti}