From: Simone Piccardi Date: Fri, 16 Aug 2002 19:18:56 +0000 (+0000) Subject: Aggiunte sugli IPC generici (controllo di accesso) e messa una vecchia X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=1c9b13f0f2292729be45593d013bbd38f0b9de95;p=gapil.git 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 index 0000000..8c964dc Binary files /dev/null and b/img/mmap_layout.dia differ diff --git a/ipc.tex b/ipc.tex index 53e51b9..261de58 100644 --- 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à. -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)}. @@ -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}, -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 @@ -713,6 +709,68 @@ inutilmente complessa. Per questo ne 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} @@ -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 è -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 -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