Alcuni indici e materiale sulle ACL

[gapil.git] / filedir.tex

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}