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
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}.
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
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}
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
\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}
projects / gapil.git / blobdiff