Alcuni indici e materiale sulle ACL

diff --git a/filedir.tex b/filedir.tex
index 8afa6a38df23057caa5b027e7ed89799d57f6209..e0cd67da97fd80036d0a6d92a7d13f3ed4d20947 100644 (file)
--- a/filedir.tex
+++ b/filedir.tex
@@ -612,7 +612,7 @@ creare file regolari e fifo; l'argomento \param{mode} specifica il tipo di
 file che si vuole creare ed i relativi permessi, secondo i valori riportati in
 tab.~\ref{tab:file_mode_flags}, che vanno combinati con un OR binario. I
 permessi sono comunque modificati nella maniera usuale dal valore di
 file che si vuole creare ed i relativi permessi, secondo i valori riportati in
 tab.~\ref{tab:file_mode_flags}, che vanno combinati con un OR binario. I
 permessi sono comunque modificati nella maniera usuale dal valore di

-\var{umask} (si veda sez.~\ref{sec:file_perm_management}).
+\itindex{umask} \textit{umask} (si veda sez.~\ref{sec:file_perm_management}).

 
 Per il tipo di file può essere specificato solo uno fra: \const{S\_IFREG} per
 un file regolare (che sarà creato vuoto), \const{S\_IFBLK} per un dispositivo
 
 Per il tipo di file può essere specificato solo uno fra: \const{S\_IFREG} per
 un file regolare (che sarà creato vuoto), \const{S\_IFBLK} per un dispositivo


@@ -652,7 +652,7 @@ sez.~\ref{sec:ipc_named_pipe}) lo standard POSIX specifica l'uso della funzione
 La funzione crea la fifo \param{pathname} con i permessi \param{mode}. Come
 per \func{mknod} il file \param{pathname} non deve esistere (neanche come link
 simbolico); al solito i permessi specificati da \param{mode} vengono
 La funzione crea la fifo \param{pathname} con i permessi \param{mode}. Come
 per \func{mknod} il file \param{pathname} non deve esistere (neanche come link
 simbolico); al solito i permessi specificati da \param{mode} vengono

-modificati dal valore di \var{umask}.
+modificati dal valore di \itindex{umask} \textit{umask}.

 
 
 
 
 
 


@@ -2308,6 +2308,8 @@ dell'interfaccia standard ANSI C che non prevede l'esistenza di utenti e
 gruppi, ed inoltre il problema si pone anche per l'interfaccia nativa quando i
 permessi non vengono indicati esplicitamente. 
 
 gruppi, ed inoltre il problema si pone anche per l'interfaccia nativa quando i
 permessi non vengono indicati esplicitamente. 
 

+\itindbeg{umask} 
+

 In tutti questi casi l'unico riferimento possibile è quello della modalità di
 apertura del nuovo file (lettura/scrittura o sola lettura), che però può
 fornire un valore che è lo stesso per tutti e tre i permessi di
 In tutti questi casi l'unico riferimento possibile è quello della modalità di
 apertura del nuovo file (lettura/scrittura o sola lettura), che però può
 fornire un valore che è lo stesso per tutti e tre i permessi di


@@ -2339,6 +2341,7 @@ $022$).  In questo modo 
 voluti.  Di norma questo valore viene impostato una volta per tutte al login a
 $022$, e gli utenti non hanno motivi per modificarlo.
 
 voluti.  Di norma questo valore viene impostato una volta per tutte al login a
 $022$, e gli utenti non hanno motivi per modificarlo.
 

+\itindend{umask} 

 
 
 \subsection{La gestione della titolarità dei file}
 
 
 \subsection{La gestione della titolarità dei file}


@@ -2954,7 +2957,7 @@ le esigenze pi
 rispondere in maniera adeguata a situazioni che richiedono una gestione
 complessa dei permessi di accesso.\footnote{già un requisito come quello di
   dare accesso in scrittura ad alcune persone ed in sola lettura ad altre non
 rispondere in maniera adeguata a situazioni che richiedono una gestione
 complessa dei permessi di accesso.\footnote{già un requisito come quello di
   dare accesso in scrittura ad alcune persone ed in sola lettura ad altre non

-  si può soddisfare in maniera soddisfacente.}
+  si può soddisfare in maniera semplice.}

 
 Per questo motivo erano state progressivamente introdotte nelle varie versioni
 di Unix dei meccanismi di gestione dei permessi dei file più flessibili, nella
 
 Per questo motivo erano state progressivamente introdotte nelle varie versioni
 di Unix dei meccanismi di gestione dei permessi dei file più flessibili, nella


@@ -2984,13 +2987,86 @@ Anche in questo caso le funzioni di questa libreria non fanno parte delle
 \acr{glibc} e devono essere installate a parte;\footnote{la versione corrente
   della libreria è \texttt{libacl1}, e nel caso si usi Debian la si può
   installare con il pacchetto omonimo e con il collegato \texttt{libacl1-dev}
 \acr{glibc} e devono essere installate a parte;\footnote{la versione corrente
   della libreria è \texttt{libacl1}, e nel caso si usi Debian la si può
   installare con il pacchetto omonimo e con il collegato \texttt{libacl1-dev}

-  per il file di sviluppo.}
-pertanto se un programma le utilizza si dovrà indicare esplicitamente l'uso
-della libreria \texttt{libacl} invocando il compilatore con l'opzione
-\texttt{-lacl}.
-
+  per i file di sviluppo.}  pertanto se un programma le utilizza si dovrà
+indicare esplicitamente l'uso della libreria \texttt{libacl} invocando il
+compilatore con l'opzione \texttt{-lacl}. Si tenga presente inoltre che per
+poterle utilizzare le ACL devono essere attivate esplicitamente montando il
+filesystem\footnote{che deve supportarle, ma questo è ormai vero per
+  praticamente tutti i filesystem più comuni, con l'eccezione di NFS per il
+  quale esiste però un supporto sperimentale.} su cui le si vogliono
+utilizzare con l'opzione \texttt{acl} attiva. Dato che si tratta di una
+estensione è infatti opportuno utilizzarle soltanto laddove siano necessarie.
+
+Una ACL è composta da un insieme di voci, e ciascuna voce è a sua volta
+costituita da un \textsl{tipo}, da un eventuale
+\textsl{qualificatore},\footnote{deve essere presente soltanto per le voci di
+  tipo \const{ACL\_USER} e \const{ACL\_GROUP}.} e da un insieme di permessi.
+Ad ogni oggetto sul filesystem si può associare una ACL che ne governa i
+permessi di accesso, detta \textit{access ACL}.  Inoltre per le directory si
+può impostare una ACL aggiuntiva, detta \textit{default ACL}, che serve ad
+indicare quale dovrà essere la ACL assegnata di default nella creazione di un
+file all'interno della directory stessa. Come avviene per i permessi le ACL
+possono essere impostate solo del proprietario del file, o da un processo con
+la capability \index{capabilities} \const{CAP\_FOWNER}.

 
 

+\begin{table}[htb]
+  \centering
+  \footnotesize
+  \begin{tabular}{|l|p{8cm}|}
+    \hline
+    \textbf{Tipo} & \textbf{Descrizione} \\
+    \hline
+    \hline
+    \const{ACL\_USER\_OBJ} & voce che contiene i diritti di accesso del
+                             proprietario del file.\\
+    \const{ACL\_USER}      & voce che contiene i diritti di accesso per
+                             l'utente indicato dal rispettivo
+                             qualificatore.\\  
+    \const{ACL\_GROUP\_OBJ}& voce che contiene i diritti di accesso del
+                             gruppo proprietario del file.\\
+    \const{ACL\_GROUP}     & voce che contiene i diritti di accesso per
+                             il gruppo indicato dal rispettivo
+                             qualificatore.\\
+    \const{ACL\_MASK}      & voce che contiene la maschera dei massimi
+                             permessi di accesso che possono essere garantiti
+                             da voci del tipo \const{ACL\_USER},
+                             \const{ACL\_GROUP} e \const{ACL\_GROUP\_OBJ}.\\
+    \const{ACL\_OTHER}     & voce che contiene i diritti di accesso di chi
+                             non corrisponde a nessuna altra voce dell'ACL.\\
+    \hline
+  \end{tabular}
+  \caption{Le costanti che identificano i tipi delle voci di una ACL.}
+  \label{tab:acl_tag_types}
+\end{table}

 
 

+L'elenco dei vari tipi di voci presenti in una ACL, con una breve descrizione
+del relativo significato, è riportato in tab.~\ref{tab:acl_tag_types}. Tre di
+questi tipi, \const{ACL\_USER\_OBJ}, \const{ACL\_GROUP\_OBJ} e
+\const{ACL\_OTHER}, corrispondono direttamente ai tre permessi ordinari dei
+file (proprietario, gruppo proprietario e tutti gli altri) e una ACL valida
+deve sempre contenere una ed una sola voce per ciascuno di questi tipi.
+
+Una ACL può poi contenere un numero arbitrario di voci di tipo
+\const{ACL\_USER} e \const{ACL\_GROUP}, ciascuna delle quali indicherà i
+permessi assegnati all'utente e al gruppo indicato dal relativo qualificatore;
+ovviamente un utente o gruppo potranno essere indicati una sola volta
+all'interno di una ACL. Inoltre se in una ACL esiste una voce di uno di questi
+due tipi è obbligatoria anche la presenza di una ed una sola voce di tipo
+\const{ACL\_MASK}, che negli altri casi è opzionale.
+
+Quest'ultimo tipo di voce contiene la maschera dei permessi che possono essere
+assegnati tramite voci di tipo \const{ACL\_USER}, \const{ACL\_GROUP} e
+\const{ACL\_GROUP\_OBJ}, se in una di queste voci si fosse specificato un
+permesso non presente in \const{ACL\_MASK} questo verrebbe ignorato. L'uso di
+\const{ACL\_MASK} è di particolare utilità quando associata ad una
+\textit{default ACL} di una directory in quanto i permessi così specificati
+vengono ereditati da tutti i file creati nella stessa, ottenendo una sorta di
+\itindex{umask} \textit{umask} associata ad un oggetto sul filesystem
+piuttosto che a un processo.
+
+Dato che le ACL vengono a costituire una estensione dei permess ordinari, ed
+uno dei problemi che si erano posti nella loro standardizzazione era appunto
+quello della corrispondenza fra questi e le ACL. 

 
 
 \itindend{Access~Control~List}
 
 
 \itindend{Access~Control~List}

diff --git a/filestd.tex b/filestd.tex
index 0bb202fcf9fea252325bbd68371d585d26e2d613..32e2fd804616c00503967cd832ecaf73ebaf3733 100644 (file)
--- a/filestd.tex
+++ b/filestd.tex
@@ -332,8 +332,8 @@ I nuovi file saranno creati secondo quanto visto in
 sez.~\ref{sec:file_ownership_management} ed avranno i permessi di accesso
 impostati al valore
 \code{S\_IRUSR|S\_IWUSR|S\_IRGRP|S\_IWGRP|S\_IROTH|S\_IWOTH} (pari a
 sez.~\ref{sec:file_ownership_management} ed avranno i permessi di accesso
 impostati al valore
 \code{S\_IRUSR|S\_IWUSR|S\_IRGRP|S\_IWGRP|S\_IROTH|S\_IWOTH} (pari a

-\val{0666}) modificato secondo il valore di \acr{umask} per il processo (si
-veda sez.~\ref{sec:file_perm_management}).
+\val{0666}) modificato secondo il valore di \itindex{umask} \textit{umask} per
+il processo (si veda sez.~\ref{sec:file_perm_management}).

 
 In caso di file aperti in lettura e scrittura occorre ricordarsi che c'è
 di mezzo una bufferizzazione; per questo motivo lo standard ANSI C
 
 In caso di file aperti in lettura e scrittura occorre ricordarsi che c'è
 di mezzo una bufferizzazione; per questo motivo lo standard ANSI C

diff --git a/fileunix.tex b/fileunix.tex
index 7aeda51690367bb3c2f12412b5f704f213c0f486..b501790bb521577fcd0209eff5c3c4f243b3ad43 100644 (file)
--- a/fileunix.tex
+++ b/fileunix.tex
@@ -399,10 +399,11 @@ sez.~\ref{sec:file_sharing}) ed 
 all'inizio del file.
 
 L'argomento \param{mode} indica i permessi con cui il file viene creato; i
 all'inizio del file.
 
 L'argomento \param{mode} indica i permessi con cui il file viene creato; i

-valori possibili sono gli stessi già visti in sez.~\ref{sec:file_perm_overview}
-e possono essere specificati come OR binario delle costanti descritte in
-tab.~\ref{tab:file_bit_perm}. Questi permessi sono filtrati dal valore di
-\var{umask} (vedi sez.~\ref{sec:file_perm_management}) per il processo.
+valori possibili sono gli stessi già visti in
+sez.~\ref{sec:file_perm_overview} e possono essere specificati come OR binario
+delle costanti descritte in tab.~\ref{tab:file_bit_perm}. Questi permessi sono
+filtrati dal valore di \itindex{umask} \textit{umask} (vedi
+sez.~\ref{sec:file_perm_management}) per il processo.

 
 La funzione prevede diverse opzioni, che vengono specificate usando vari bit
 dell'argomento \param{flags}.  Alcuni di questi bit vanno anche a costituire
 
 La funzione prevede diverse opzioni, che vengono specificate usando vari bit
 dell'argomento \param{flags}.  Alcuni di questi bit vanno anche a costituire

diff --git a/ipc.tex b/ipc.tex
index e17fe6decb0dac0bffd05c22f8e2effcbb1dbda4..ff728dc5bc047812d3e8b4c2e28d3aa1101fd209 100644 (file)
--- a/ipc.tex
+++ b/ipc.tex
@@ -978,7 +978,7 @@ solo se tutti i controlli elencati falliscono l'accesso 
 a differenza di quanto avviene per i permessi dei file, fallire in uno dei
 passi elencati non comporta il fallimento dell'accesso. Un'ulteriore
 differenza rispetto a quanto avviene per i file è che per gli oggetti di IPC
 a differenza di quanto avviene per i permessi dei file, fallire in uno dei
 passi elencati non comporta il fallimento dell'accesso. Un'ulteriore
 differenza rispetto a quanto avviene per i file è che per gli oggetti di IPC

-il valore di \var{umask} (si ricordi quanto esposto in
+il valore di \itindex{umask} \textit{umask} (si ricordi quanto esposto in

 sez.~\ref{sec:file_perm_management}) non ha alcun significato.
 
 
 sez.~\ref{sec:file_perm_management}) non ha alcun significato.
 
 


@@ -4041,9 +4041,9 @@ 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'user-ID ed il
 group-ID effettivo del processo chiamante, e che i permessi indicati con

-\param{mode} vengono filtrati dal valore della \textit{umask} del processo.
-Inoltre per poter aprire un semaforo è necessario avere su di esso sia il
-permesso di lettura che quello di scrittura.
+\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.

 
 Una volta che si sia ottenuto l'indirizzo di un semaforo, sarà possibile
 utilizzarlo; se si ricorda quanto detto all'inizio di
 
 Una volta che si sia ottenuto l'indirizzo di un semaforo, sarà possibile
 utilizzarlo; se si ricorda quanto detto all'inizio di

diff --git a/prochand.tex b/prochand.tex
index 3810e41304717abde3a19c34b0484a334ad06ae7..76bd1bc1979e66f4a99d8b6f16640a59c36fdfc4 100644 (file)
--- a/prochand.tex
+++ b/prochand.tex
@@ -1442,7 +1442,7 @@ la lista completa 
 \item il tempo restante ad un allarme (vedi sez.~\ref{sec:sig_alarm_abort});
 \item la directory radice e la directory di lavoro corrente (vedi
   sez.~\ref{sec:file_work_dir});
 \item il tempo restante ad un allarme (vedi sez.~\ref{sec:sig_alarm_abort});
 \item la directory radice e la directory di lavoro corrente (vedi
   sez.~\ref{sec:file_work_dir});

-\item la maschera di creazione dei file (\var{umask}, vedi
+\item la maschera di creazione dei file \itindex{umask} (\textit{umask}, vedi

   sez.~\ref{sec:file_perm_management}) ed i \textit{lock} sui file (vedi
   sez.~\ref{sec:file_locking});
 \item i segnali sospesi (\textit{pending}) e la maschera dei segnali (si veda
   sez.~\ref{sec:file_perm_management}) ed i \textit{lock} sui file (vedi
   sez.~\ref{sec:file_locking});
 \item i segnali sospesi (\textit{pending}) e la maschera dei segnali (si veda

diff --git a/session.tex b/session.tex
index 5c62d918010e988c68ed98eaa18de967cd0eb265..78b60ecb9cf2475500e13dbdf7e3518e034ba815 100644 (file)
--- a/session.tex
+++ b/session.tex
@@ -645,9 +645,9 @@ occorrer
   il programma), per evitare che la directory da cui si è lanciato il processo
   resti in uso e non sia possibile rimuoverla o smontare il filesystem che la
   contiene.
   il programma), per evitare che la directory da cui si è lanciato il processo
   resti in uso e non sia possibile rimuoverla o smontare il filesystem che la
   contiene.

-\item Impostare la maschera dei permessi (di solito con \code{umask(0)}) in
-  modo da non essere dipendenti dal valore ereditato da chi ha lanciato
-  originariamente il processo. 
+\item Impostare la \itindex{umask} maschera dei permessi (di solito con
+  \code{umask(0)}) in modo da non essere dipendenti dal valore ereditato da
+  chi ha lanciato originariamente il processo.

 \item Chiudere tutti i file aperti che non servono più (in generale tutti); in
   particolare vanno chiusi i file standard che di norma sono ancora associati
   al terminale (un'altra opzione è quella di redirigerli verso
 \item Chiudere tutti i file aperti che non servono più (in generale tutti); in
   particolare vanno chiusi i file standard che di norma sono ancora associati
   al terminale (un'altra opzione è quella di redirigerli verso