From 1c9b13f0f2292729be45593d013bbd38f0b9de95 Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Fri, 16 Aug 2002 19:18:56 +0000 Subject: [PATCH] Aggiunte sugli IPC generici (controllo di accesso) e messa una vecchia figura che mi ero scordato. --- img/mmap_layout.dia | Bin 0 -> 1894 bytes ipc.tex | 106 +++++++++++++++++++++++++++++++++----------- 2 files changed, 80 insertions(+), 26 deletions(-) create mode 100644 img/mmap_layout.dia diff --git a/img/mmap_layout.dia b/img/mmap_layout.dia new file mode 100644 index 0000000000000000000000000000000000000000..8c964dc05a66bdb6a24d3092cf2d5d48747686f7 GIT binary patch literal 1894 zcmV-s2buUEiwFP!000001MOW)Z{s!)zUNm6-m4>v)O)?jqI)P%pg@6kdp2l`vDuX= zLt>tX{`QiR65D#%vM4%nmj-qN$&(ok$?qd)hE%?MeOkxH15PuN(3=r3t&xH0B8doH z-i-eK{_Axx`g(iyB_ilE|F=xh+Tg!IGjVk@S~0fyJefQ`KAQ1!hFFrCF}XK0Joy*J zF`96p$>{dVFm@G0h#_&Wyo(r1$^4#SgQ7LQ8O_n+$1+XsX*4RNO1VW6C#ms(;+xT@ zyZkenlxik>dJgE`pbbu|YS)`2BV2?%Z)zefdc^-bGNn|;h3NA3(=X1a;*rW5TU|{L z+G>QYQMx3wZYRYkE*b)w0fg|i9ZokfS8pO#Zz5H1f@HHzlCl&LRyQ+Gk{BaeSYqit z?r$espqLMtL#}}S+V2Qs$&u&3Lvhx{f#UWXdQL^+G9}SrAnr-DXn7d zbbF!yS(*L^l973gn>-+tN%!}w`e#Y?vVDC|BAgxR?R}XRO{-FDa?J6nTvrc@Ta}3_ zHxZ*}oR;dpZKo)sY~vF6JFSq+|G^7Zy7w1DG(u@)TpQn#r_pxCO>5PGEdR3q6o!O>;KCh}zxdVtUWBh8u_FZAb_1!6irUl(Gv^cZ6 z{fy!muV;%SrS%DSFvoHmIgIPhy)mjIrG16Ta>d%!ySof=iuQSuMmRn8^pXeHMR$DWY^ImV7FoTa24tZIEYnksHEzS*f(-;FJPX() zUF(82|K|kTM??aYMS?ZvBQsD4gKI0FWw;fe!@w<20K^ZKD3Ech3j}%((oPV7rlTRy z6#}+A1T6LAzxYv(f1r92=`T4lQD6>6!}ipIJ^EcStGhzC^+3#4QGvD@Z^l_kF9RwtB;*( znzu34Yvms~LntOoy2j1jgz5ddq3(33u+>z#QA!BGAcO#wt_&^H2^?Q6)C31i9n%M{ zEsWY1K?xCJ#2}Qs5I$O7Uig(J2uXr~`*mnd5b6jb9E2b&<)LE;gE0sThTtnsamlS- z5JS*}YL*z3B`nPngR{i%gyN<$vo%0^)mIu;2$BG3c+hK;t{ zPyysoVXKD(G{ZMU*y4_IK-kC7U~4E`C=^{js!v9a(}mdNE`@WPQ_u7dV;_X zgi-e*mXRxrHhR%0w`klSVS3T1loRYhVoSAK6FC)FfEy9XXh%?j7l!;&#F@^=r-Y25 z#ShI1l7Xa7N1rW@bcUb=TWNI)mJ4Qk?4Dt+GLT4Y?E+0y*C~pvcQd+?eZ7&#Gc_PKJrw$LJ zY|d9jRQ2)0C`=znn&c~M9ZX3kSac{ga46Ms@Y9#CJ$UN(y1Hh#J?;QaNA*@$?^5@< zdLQ+m+yDPyHGUyDZHo=0H_+w9U#PUMQJS!MY#`1&16N{AKF2S!qoG0Fr+zYlm@o#A zDNcG1C*%w!Ugg6sJI%|&_tlAT_%x@=rXX#pN!-Lx@qYr;S`tWPL)9}mT z>n|&gTn=++I0T1!iV4)slfL5R6zAd3qdSHU6Nfi|L@)6M{xUf_UyN4D5*$A9JoBHn*=5&P{lW2j|} z+7Q&7p>ppHl-{D7pV3sA$nwRZ9&ZYO#F5j^_3f%R4FeQNIQ)La?Vd?khEjH{0Nr=O z*iqi020eh0qmfgftVj<6^;P;nd6hmm%Ly825Agm{sQQ3)e zA~GlQH9cv1()4sJ%#z-&9FCz%W(rIfLQim$7fwUd@qI^df)#%J=qkCp%kVpFxA~3n zmHgry0hFUUfZ88iI(kw{1@0gj7sYRw1GX7(Mi6G4aLO%)jvwSkFMtumyt2}aAe~a# gA7h#py3s;$o&RN&+pE1lopO8iAGPa^k6LU10ASXa@c;k- literal 0 HcmV?d00001 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 -- 2.30.2