Aggiunte sugli IPC generici (controllo di accesso) e messa una vecchia

figura che mi ero scordato.

diff --git a/img/mmap_layout.dia b/img/mmap_layout.dia
new file mode 100644 (file)
index 0000000..8c964dc
Binary files /dev/null and b/img/mmap_layout.dia differ

diff --git a/ipc.tex b/ipc.tex
index 53e51b96794fba1fef5518a80372a80e32c3f938..261de58ac9e57599f89f96c98bc551b1af6d8141 100644 (file)
--- a/ipc.tex
+++ b/ipc.tex
@@ -584,8 +584,8 @@ molti altri devono poter leggere non pu
 Per questo nello sviluppo di System V vennero introdotti una serie di nuovi
 oggetti per la comunicazione fra processi ed una nuova interfaccia di
 programmazione, che fossero in grado di garantire una maggiore flessibilità.
 Per questo nello sviluppo di System V vennero introdotti una serie di nuovi
 oggetti per la comunicazione fra processi ed una nuova interfaccia di
 programmazione, che fossero in grado di garantire una maggiore flessibilità.

-In questa sezione esamineremo quello che viene ormai chiamato il
-\textsl{Sistema di comunicazione inter-processo} di System V, o
+In questa sezione esamineremo come Linux supporta quello che viene ormai
+chiamato il \textsl{Sistema di comunicazione inter-processo} di System V, o

 \textit{System V IPC (Inter-Process Comunication)}.
 
 
 \textit{System V IPC (Inter-Process Comunication)}.
 
 


@@ -617,11 +617,7 @@ Per risolvere il problema il kernel associa a ciascun oggetto una struttura
 variabile del tipo primitivo \type{key\_t}, che viene specificata in fase di
 creazione e tramite la quale è possibile ricavare l'identificatore. La
 struttura, la cui definizione è riportata in \figref{fig:ipc_ipc_perm},
 variabile del tipo primitivo \type{key\_t}, che viene specificata in fase di
 creazione e tramite la quale è possibile ricavare l'identificatore. La
 struttura, la cui definizione è riportata in \figref{fig:ipc_ipc_perm},

-contiene anche le varie proprietà associate all'oggetto, come gli
-identificatori del creatore (\var{cuid} e \var{cgid}) e del proprietario
-(\var{uid} e \var{gid}), e le modalità di accesso (\var{mode}) che ne
-specifica i permessi, che sono analoghi a quelli usati per i file (vedi
-\secref{sec:file_perm_overview}). 
+contiene anche le varie proprietà associate all'oggetto. 

 
 \begin{figure}[!htb]
   \footnotesize \centering
 
 \begin{figure}[!htb]
   \footnotesize \centering


@@ -713,6 +709,68 @@ inutilmente complessa.  Per questo ne 
 completa nello standard POSIX.1b, che tratteremo in \secref{sec:ipc_posix}.
 
 
 completa nello standard POSIX.1b, che tratteremo in \secref{sec:ipc_posix}.
 
 

+\subsection{Il controllo di accesso}
+\label{sec:ipc_sysv_access_control}
+
+Oltre alle chiavi, abbiamo visto che ad ogni oggetto sono associate in
+\var{ipc\_perm} ulteriori informazioni, come gli identificatori del creatore
+(nei campi \var{cuid} e \var{cgid}) e del proprietario (nei campi \var{uid} e
+\var{gid}) dello stesso, e un insieme di permessi (nel campo \var{mode}). In
+questo modo è possibile definire un controllo di accesso sugli oggetti, simile
+a quello che si ha per i file (vedi \secref{sec:file_perm_overview}).  
+
+Benché il controllo di accesso relativo agli oggetti di intercomunicazione sia
+molto simile a quello dei file, restano delle importanti differenze. La prima
+è che il permesso di esecuzione non esiste (e viene ignorato), per cui si può
+parlare solo di permessi di lettura e scrittura (nel caso dei semafori poi
+quest'ultimo è più propriamente il permesso di modificarne lo stato). I valori
+di \var{mode} sono gli stessi ed hanno lo stesso significato di quelli
+riportati in \secref{tab:file_mode_flags}\footnote{se però si vogliono usare
+  le costanti simboliche ivi definite occorrerà includere il file
+  \file{sys/stat.h}, alcuni sistemi definiscono le costanti \macro{MSG\_R}
+  (\texttt{0400}) e \macro{MSG\_W} (\texttt{0200}) per indicare i permessi
+  base di lettura e scrittura per il proprietario, da utilizzare, con gli
+  opportuni shift, pure per il gruppo e gli altri, in Linux, visto la loro
+  scarsa utilità, queste costanti non sono definite.} e come per i file
+definiscono gli accessi per il proprietario, il suo gruppo e tutti gli altri.
+
+Si tenga presente che per gli oggetti di IPC han senso solo i permessi di
+lettura e scrittura, quelli di esecuzione vengono ignorati. Quando l'oggetto
+viene creato i campi \var{cuid} e \var{uid} di \var{ipc\_perm} ed i campi
+\var{cgid} e \var{gid} vengono settati rispettivamente al valore dell'userid e
+del groupid effettivo del processo che ha chiamato la funzione, ma mentre i
+campi \var{uid} e \var{gid} possono essere cambiati, \var{cuid} e \var{cgid}
+restano sempre gli stessi.
+
+Il controllo di accesso è effettuato a due livelli. Il primo è nelle funzioni
+che richiedono l'identificatore di un oggetto data la chiave, che specificano
+tutte un argomento \param{flag}.  In tal caso quando viene effettuata la
+ricerca di una chiave, se \param{flag} specifica dei permessi, questi vengono
+controllati e l'identificatore viene restituito solo se essi corrispondono a
+quelli dell'oggetto. Se sono presenti dei permessi non presenti in \var{mode}
+l'accesso sarà invece negato. Questo però è di utilità indicativa, dato che è
+sempre possibile specificare un valore nullo per \param{flag}, nel qual caso
+il controllo avrà sempre successo.
+
+Il secondo livello è quello delle varie funzioni che accedono (in lettura o
+scrittura) all'oggetto. In tal caso lo schema dei controlli è simile a quello
+dei file, ed avviene secondo questa sequenza:
+\begin{enumerate}
+\item se il processo ha i privilegi di amministatore l'accesso è sempre
+  consentito. 
+\item se l'userid effettivo del processo corrisponde o al valore del campo
+  \var{cuid} o a quello del campo \var{uid} ed il permesso per il proprietario
+  in \var{mode} è appropriato\footnote{per appropriato si intende che è
+    settato il permesso di scrittura per le operazioni di scrittura e quello
+    di lettura per le operazioni di lettura.} l'accesso è consentito.
+\item se il groupid effettivo del processo corrisponde o al
+  valore del campo \var{cgid} o a quello del campo \var{gid} ed il permesso
+  per il gruppo in \var{mode} è appropriato l'accesso è consentito.
+\item 
+\end{enumerate}
+
+
+

 \subsection{Code di messaggi}
 \label{sec:ipc_sysv_mq}
 
 \subsection{Code di messaggi}
 \label{sec:ipc_sysv_mq}
 


@@ -753,34 +811,30 @@ ottenere l'identificatore di una coda di messaggi esistente, che a crearne una
 nuova. L'argomento \param{key} specifica la chiave che è associata
 all'oggetto, eccetto il caso in cui si specifichi il valore
 \macro{IPC\_PRIVATE}, nel qual caso la coda è creata ex-novo e non vi è
 nuova. L'argomento \param{key} specifica la chiave che è associata
 all'oggetto, eccetto il caso in cui si specifichi il valore
 \macro{IPC\_PRIVATE}, nel qual caso la coda è creata ex-novo e non vi è

-associata alcuna chiave. 
+associata alcuna chiave, il processo (ed i suoi eventuali figli) potranno
+farvi riferimento solo attraverso l'identificatore.

 
 

-Se invece si specifica un valore l'effetto della funzione dipende dal valore
-di \param{flag}, se questo è nullo la funzione si limita ad effettuare una
-ricerca sugli oggetti esistenti, restituendo l'identificatore se trova una
-corrispondenza, o fallendo con un errore di \macro{ENOENT} altrimenti.
+Se invece si specifica un valore diverso da \macro{IPC\_PRIVATE}\footnote{in
+  Linux questo significa un valore diverso da zero.} l'effetto della funzione
+dipende dal valore di \param{flag}, se questo è nullo la funzione si limita ad
+effettuare una ricerca sugli oggetti esistenti, restituendo l'identificatore
+se trova una corrispondenza, o fallendo con un errore di \macro{ENOENT} se non
+esiste o di \macro{EACCESS} se si sono specificati dei permessi non validi.

 
 Se invece si vuole creare una nuova coda di messaggi \param{flag} non può
 essere nullo e deve essere fornito come maschera binaria, impostando il bit
 corrispondente al valore \macro{IPC\_CREAT}. In questo caso i nove bit meno
 significativi di \param{flag} saranno usati come permessi per il nuovo
 
 Se invece si vuole creare una nuova coda di messaggi \param{flag} non può
 essere nullo e deve essere fornito come maschera binaria, impostando il bit
 corrispondente al valore \macro{IPC\_CREAT}. In questo caso i nove bit meno
 significativi di \param{flag} saranno usati come permessi per il nuovo

-oggetto, con gli stessi valori e significati di quelli riportati in
-\secref{tab:file_mode_flags}.\footnote{per usare i quali però occorrerà
-  includere il file \file{sys/stat.h}.} Se si imposta anche il bit
-corrispondente a \macro{IPC\_EXCL} la funzione avrà successo solo se l'oggetto
-non esiste già, fallendo con un errore di \macro{EEXIST} altrimenti.
-
-Si tenga presente che per gli oggetti di IPC han senso solo i permessi di
-lettura e scrittura, quelli di esecuzione vengono ignorati. Quando l'oggetto
-viene creato i campi \var{cuid} e \var{uid} di \var{ipc\_perm} ed i campi
-\var{cgid} e \var{gid} vengono settati rispettivamente al valore dell'userid e
-del groupid effettivo del processo che ha chiamato la funzione.
-
+oggetto, secondo quanto illustrato in \secref{sec:ipc_sysv_access_control}.
+Se si imposta anche il bit corrispondente a \macro{IPC\_EXCL} la funzione avrà
+successo solo se l'oggetto non esiste già, fallendo con un errore di
+\macro{EEXIST} altrimenti.

 
 
 
 
 
 

-Esse sono infatti costituite da una \textit{linked list} in cui nuovi messaggi
-vengono inseriti in coda e letti dalla cima.
+Una coda di messaggi è costituita da una \textit{linked list} in cui nuovi
+messaggi vengono inseriti in coda e letti dalla cima, con una struttura del
+tipo di quella illustrata in