POSIX.1 ha definito dei nuovi oggetti, le \textit{fifo}, che hanno le stesse
caratteristiche delle pipe, ma che invece di essere strutture interne del
kernel, visibili solo attraverso un file descriptor, sono accessibili
-attraverso un \index{inode} inode che risiede sul filesystem, così che i
+attraverso un \itindex{inode} inode che risiede sul filesystem, così che i
processi le possono usare senza dovere per forza essere in una relazione di
\textsl{parentela}.
Utilizzando una \textit{fifo} tutti i dati passeranno, come per le pipe,
attraverso un apposito buffer nel kernel, senza transitare dal filesystem;
-\index{inode} l'inode allocato sul filesystem serve infatti solo a fornire un
+\itindex{inode} l'inode allocato sul filesystem serve infatti solo a fornire un
punto di riferimento per i processi, che permetta loro di accedere alla stessa
fifo; il comportamento delle funzioni di lettura e scrittura è identico a
quello illustrato per le pipe in sez.~\ref{sec:ipc_pipes}.
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 \index{inode} dell'inode del file
+con i 16 bit meno significativi \itindex{inode} 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 dispositivo
su cui è il file. Diventa perciò relativamente facile ottenere delle
Quando l'oggetto viene creato i campi \var{cuid} e \var{uid} di
\struct{ipc\_perm} ed i campi \var{cgid} e \var{gid} vengono impostati
-rispettivamente al valore dell'user-ID e del group-ID effettivo del processo
+rispettivamente al valore dell'\acr{uid} e del \acr{gid} effettivo del processo
che ha chiamato la funzione, ma, mentre i campi \var{uid} e \var{gid} possono
essere cambiati, i campi \var{cuid} e \var{cgid} restano sempre gli stessi.
\begin{itemize*}
\item se il processo ha i privilegi di amministratore l'accesso è sempre
consentito.
-\item se l'user-ID effettivo del processo corrisponde o al valore del campo
+\item se l'\acr{uid} 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 è
impostato il permesso di scrittura per le operazioni di scrittura e quello
di lettura per le operazioni di lettura.} l'accesso è consentito.
-\item se il group-ID effettivo del processo corrisponde o al
+\item se il \acr{gid} 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 se il permesso per gli altri è appropriato l'accesso è consentito.
riceveranno un errore di \errcode{EIDRM}, e tutti processi in attesa su
funzioni di lettura o di scrittura sulla coda saranno svegliati ricevendo
il medesimo errore. Questo comando può essere eseguito solo da un processo
- con user-ID effettivo corrispondente al creatore o al proprietario della
+ con \acr{uid} effettivo corrispondente al creatore o al proprietario della
coda, o all'amministratore.
\item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario
della coda, ed il limite massimo sulle dimensioni del totale dei messaggi in
della risposta, quest'ultima resta nella coda (così come per le fifo si aveva
il problema delle fifo che restavano nel filesystem). In questo caso però il
problemi sono maggiori, sia perché è molto più facile esaurire la memoria
-dedicata ad una coda di messaggi che gli \index{inode} inode di un filesystem,
+dedicata ad una coda di messaggi che gli \itindex{inode} inode di un filesystem,
sia perché, con il riutilizzo dei \acr{pid} da parte dei processi, un client
eseguito in un momento successivo potrebbe ricevere un messaggio non
indirizzato a lui.
\item[\const{IPC\_RMID}] Rimuove l'insieme di semafori e le relative strutture
dati, con effetto immediato. Tutti i processi che erano stato di
\textit{sleep} vengono svegliati, ritornando con un errore di
- \errcode{EIDRM}. L'user-ID effettivo del processo deve corrispondere o al
+ \errcode{EIDRM}. L'\acr{uid} effettivo del processo deve corrispondere o al
creatore o al proprietario dell'insieme, o all'amministratore. L'argomento
\param{semnum} viene ignorato.
\item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario
dell'insieme. I valori devono essere passati in una struttura
\struct{semid\_ds} puntata da \param{arg.buf} di cui saranno usati soltanto i
campi \var{sem\_perm.uid}, \var{sem\_perm.gid} e i nove bit meno
- significativi di \var{sem\_perm.mode}. L'user-ID effettivo del processo deve
+ significativi di \var{sem\_perm.mode}. L'\acr{uid} effettivo del processo deve
corrispondere o al creatore o al proprietario dell'insieme, o
all'amministratore. L'argomento \param{semnum} viene ignorato.
\item[\const{GETALL}] Restituisce il valore corrente di ciascun semaforo
\item[\errcode{EPERM}] si è specificato un comando con \const{IPC\_SET} o
\const{IPC\_RMID} senza i permessi necessari.
\item[\errcode{EOVERFLOW}] si è tentato il comando \const{IPC\_STAT} ma il
- valore del group-ID o dell'user-ID è troppo grande per essere
+ valore del \acr{gid} o dell'\acr{uid} è troppo grande per essere
memorizzato nella struttura puntata da \param{buf}.
\item[\errcode{EFAULT}] l'indirizzo specificato con \param{buf} non è
valido.
\item[\const{IPC\_RMID}] Marca il segmento di memoria condivisa per la
rimozione, questo verrà cancellato effettivamente solo quando l'ultimo
processo ad esso agganciato si sarà staccato. Questo comando può essere
- eseguito solo da un processo con user-ID effettivo corrispondente o al
+ eseguito solo da un processo con \acr{uid} effettivo corrispondente o al
creatore del segmento, o al proprietario del segmento, o all'amministratore.
\item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario
del segmento. Per modificare i valori di \var{shm\_perm.mode},
sez.~\ref{sec:ipc_sysv_access_control}) che viene usata per gli oggetti del
SysV IPC. Per quanto riguarda l'attribuzione dell'utente e del gruppo
proprietari dell'oggetto alla creazione di quest'ultimo essa viene effettuata
-secondo la semantica SysV: corrispondono cioè a user-ID e group-ID effettivi
+secondo la semantica SysV: corrispondono cioè a \acr{uid} e \acr{gid} effettivi
del processo che esegue la creazione.
il flag \const{FD\_CLOEXEC}. Chiamate effettuate da diversi processi usando
lo stesso nome, restituiranno file descriptor associati allo stesso segmento
(così come, nel caso di file di dati, essi sono associati allo stesso
-\index{inode} inode). In questo modo è possibile effettuare una chiamata ad
+\itindex{inode} inode). In questo modo è possibile effettuare una chiamata ad
\func{mmap} sul file descriptor restituito da \func{shm\_open} ed i processi
vedranno lo stesso segmento di memoria condivisa.
usano la semantica standard dei file per quanto riguarda i controlli di
accesso.
-Questo significa che un nuovo semaforo viene sempre creato con l'user-ID ed il
-group-ID effettivo del processo chiamante, e che i permessi indicati con
+Questo significa che un nuovo semaforo viene sempre creato con l'\acr{uid} ed il
+\acr{gid} effettivo del processo chiamante, e che i permessi indicati con
\param{mode} vengono filtrati dal valore della \itindex{umask} \textit{umask}
del processo. Inoltre per poter aprire un semaforo è necessario avere su di
esso sia il permesso di lettura che quello di scrittura.
projects / gapil.git / blobdiff