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
-\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
@@ -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
-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. 
 
+\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
@@ -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.
 
+\itindend{umask} 
 
 
 \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
-  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
@@ -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}
-  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}

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
-\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

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
-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

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
-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.
 
 
@@ -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
-\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

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 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

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.
-\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