+Benché le pipe e le fifo siano ancora ampiamente usate, esse scontano il
+limite fondamentale che il meccanismo di comunicazione che forniscono è
+rigidamente sequenziale: una situazione in cui un processo scrive qualcosa che
+molti altri devono poter leggere non può essere implementata con una pipe.
+
+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 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)}.
+
+
+
+\subsection{Considerazioni generali}
+\label{sec:ipc_sysv_generic}
+
+La principale caratteristica del sistema di IPC di System V è quella di essere
+basato su oggetti permanenti che risiedono nel kernel. Questi, a differenza di
+quanto avviene per i file descriptor, non mantengono un contatore dei
+riferimenti, e non vengono cancellati dal sistema una volta che non sono più
+in uso. Questo comporta che, al contrario di quanto avviene per pipe e fifo,
+la memoria allocata per questi oggetti non viene rilasciata automaticamente,
+ed essi devono essere cancellati esplicitamente, altrimenti resteranno attivi
+fino al riavvio del sistema.
+
+Gli oggetti usati nel System V IPC vengono creati direttamente dal kernel, e
+sono accessibili solo specificando il relativo \textsl{identificatore}. Questo
+è il numero progressivo che il kernel assengna a ciascuno di essi quanto
+vengono creati (il prodedimento è simile a quello con cui si assegna il
+\acr{pid} ai processi). L'identificatore viene restituito dalle funzioni che
+creano l'oggetto, ed è quindi locale al processo che le ha eseguite. Dato che
+l'identificatore viene assegnato dinamicamente dal kernel non è possibile
+prevedere quale sarà, ne utilizzare un qualche valore statico, si pone perciò
+il problema di come processi diversi possono accedere allo stesso oggetto.
+
+Per risolvere il problema il kernel associa a ciascun oggetto una struttura
+\var{ipc\_perm}; questa contiene una \textsl{chiave}, identificata da una
+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.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm ]{}
+struct ipc_perm
+{
+ key_t key; /* Key. */
+ uid_t uid; /* Owner's user ID. */
+ gid_t gid; /* Owner's group ID. */
+ uid_t cuid; /* Creator's user ID. */
+ gid_t cgid; /* Creator's group ID. */
+ unsigned short int mode; /* Read/write permission. */
+ unsigned short int seq; /* Sequence number. */
+};
+ \end{lstlisting}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \var{ipc\_perm}, come definita in \file{sys/ipc.h}.}
+ \label{fig:ipc_ipc_perm}
+\end{figure}
+
+Usando la stessa chiave due processi diversi possono ricavare l'identificatore
+associato ad un oggetto ed accedervi. Il problema che sorge a questo punto è
+come devono fare per accordarsi sull'uso di una stessa chiave. Se i processi
+sono \textsl{parenti} la soluzione è relativamente semplice, in tal caso
+infatti si può usare il valore speciale \texttt{IPC\_PRIVATE} per creare un
+nuovo oggetto nel processo padre, l'idenficatore così ottenuto sarà
+disponibile in tutti i figli, e potrà essere passato come parametro attraverso
+una \func{exec}.
+
+Però quando i processi non sono \textsl{parenti} (come capita tutte le volte
+che si ha a che fare con un sistema client-server) tutto questo non è
+possibile; si potebbe comunque salvare l'identificatore su un file noto, ma
+questo ovviamente comporta lo svantaggio di doverselo andare a rileggere. Una
+alternativa più efficace è quella che i programmi usino un valore comune per
+la chiave (che ad esempio può essere dichiarato in un header comune), ma c'è
+sempre il rischio che questa chiave possa essere stata già utilizzata da
+qualcun altro. Dato che non esiste una convenzione su come assegnare queste
+chiavi in maniera univoca l'interfaccia mette a disposizione una funzione,
+\func{ftok}, che permette di ottenere una chiave specificando il nome di un
+file ed un numero di versione; il suo prototipo è:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/ipc.h}
+
+ \funcdecl{key\_t ftok(const char *pathname, int proj\_id)}
+
+ Restituisce una chiave per identificare un oggetto del System V IPC.
+
+ \bodydesc{La funzione restituisce la chiave in caso di successo e -1
+ altrimenti, nel qual caso \var{errno} viene settata ad uno dei possibili
+ codici di errore di \func{stat}.}
+\end{functions}
+
+La funzione determina un valore della chiave sulla base di \param{pathname},
+che deve specificare il pathname di un file effettivamente esistente e di un
+numero di progetto \param{proj\_id)}, che di norma viene specificato come
+carattere, dato che ne vengono utilizzati solo gli 8 bit meno
+significativi.\footnote{nelle libc4 e libc5, come avviene in SunOS,
+ l'argomento \param{proj\_id)} è dichiarato tipo \ctyp{char}, le \acr{glibc}
+ han modificato il prototipo, ma vengono lo stesso utilizzati gli 8 bit meno
+ significativi.}
+
+Il problema è che anche così non c'è la sicurezza che il valore della chiave
+sia univoco, infatti esso è costruito combinando il byte di \param{proj\_id)}
+con i 16 bit meno significativi dell'inode del file \param{pathname} (che
+vengono ottenuti attraverso \func{stat}, da cui derivano i possibili errori),
+e gli 8 bit meno significativi del numero del device su cui è il file. Diventa
+perciò relativamente facile ottenere delle collisioni, specie se i file sono
+su dispositivi con lo stesso \textit{minor number}, come \file{/dev/hda1} e
+\file{/dev/sda1}.
+
+In genere quello che si fa è utilizzare un file comune usato dai programmi che
+devono comunicare (ad esempio un haeder, o uno dei programmi che devono usare
+l'oggetto in questione), utilizzando il numero di progetto per ottere le
+chiavi che interessano. In ogni caso occorre sempre controllare, prima di
+creare un oggetto, che la chiave non sia già stata utilizzata. Se questo va
+bene in fase di creazione, le cose possono complicarsi per i programmi che
+devono solo accedere, in quanto, a parte gli eventuali controlli sugli altri
+attributi di \var{ipc\_perm}, non esiste una modalità semplice per essere
+sicuri della validità di una certa chiave.
+
+Questo è, insieme al fatto che gli oggetti sono permanenti e devono essere
+cancellati esplicitamente, il principale problema del sistema di IPC di System
+V. Non esiste infatti una modalità chiara per identificare un oggetto, come
+sarebbe stato se lo si fosse associato ad in file, e tutta l'interfaccia è
+inutilmente complessa. Per questo ne è stata effettuata una revisione
+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}
+
+