X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=filedir.tex;h=e0cd67da97fd80036d0a6d92a7d13f3ed4d20947;hp=8afa6a38df23057caa5b027e7ed89799d57f6209;hb=0e21ff1145b4f9a21c582fac348c87319133f79f;hpb=06a2f2c7718cebc7cc4ccb894999028a62b6256d

diff --git a/filedir.tex b/filedir.tex
index 8afa6a3..e0cd67d 100644
--- 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}