\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
-sez.~\ref{sec:file_perm_overview} (cioè $666$ nel primo caso e $222$ nel
-secondo). Per questo motivo il sistema associa ad ogni processo\footnote{è
- infatti contenuta nel campo \var{umask} della struttura \struct{fs\_struct},
- vedi fig.~\ref{fig:proc_task_struct}.} una maschera di bit, la cosiddetta
-\textit{umask}, che viene utilizzata per impedire che alcuni permessi possano
-essere assegnati ai nuovi file in sede di creazione. I bit indicati nella
-maschera vengono infatti cancellati dai permessi quando un nuovo file viene
-creato.
+Per le funzioni dell'interfaccia standard ANSI C 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 sez.~\ref{sec:file_perm_overview} (cioè $666$ nel primo caso e
+$222$ nel secondo). Per questo motivo il sistema associa ad ogni
+processo\footnote{è infatti contenuta nel campo \var{umask} della struttura
+ \struct{fs\_struct}, vedi fig.~\ref{fig:proc_task_struct}.} una maschera di
+bit, la cosiddetta \textit{umask}, che viene utilizzata per impedire che
+alcuni permessi possano essere assegnati ai nuovi file in sede di creazione. I
+bit indicati nella maschera vengono infatti cancellati dai permessi quando un
+nuovo file viene creato.\footnote{l'operazione viene fatta sempre: anche
+ qualora si indichi esplicitamente un valore dei permessi nelle funzioni di
+ creazione che lo consentono, i permessi contenuti nella \textit{umask}
+ verranno tolti.}
La funzione che permette di impostare il valore di questa maschera di
controllo è \funcd{umask}, ed il suo prototipo è:
\begin{table}[htb]
\centering
\footnotesize
- \begin{tabular}{|c|p{8cm}|}
+ \begin{tabular}{|c|p{10cm}|}
\hline
\textbf{Nome} & \textbf{Descrizione} \\
\hline
\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.
+Dato che le ACL vengono a costituire una estensione dei permess ordinari, uno
+dei problemi che si erano posti nella loro standardizzazione era appunto
+quello della corrispondenza fra questi e le ACL. Come accennato i permessi
+ordinari vengono mappati le tre voci di tipo \const{ACL\_USER\_OBJ},
+\const{ACL\_GROUP\_OBJ} e \const{ACL\_OTHER} che devono essere presenti in
+qualunque ACL; un cambiamento ad una di queste voci viene automaticamente
+riflesso sui permessi ordinari dei file\footnote{quelli mantenuti
+ nell'\textit{inode}.} e viceversa. In realtà la mappatura è diretta solo per
+le voci \const{ACL\_USER\_OBJ} e \const{ACL\_OTHER}, nel caso di
+\const{ACL\_GROUP\_OBJ} questo vale fintanto che non è presente una voce di
+tipo \const{ACL\_MASK}, nel qual caso valgono invece i permessi in essa
+specificati.\footnote{questo diverso comportamento a seconda delle condizioni
+ è stato introdotto dalla standardizzazione \textit{POSIX 1003.1e Draft 17}
+ per mantenere il comportamento invariato sui sistemi dotati di ACL per tutte
+ quelle applicazioni che sono conformi soltanto all'ordinario standard
+ \textit{POSIX 1003.1}.}
+
+Un secondo aspetto dell'incidenza delle ACL sul comportamento del sistema è
+quello relativo alla creazione di nuovi file, che come accennato può essere
+modificato dalla presenza di una default ACL sulla directory che contiene quel
+file. Se questa non c'è valgono le regole illustrate in
+sez.~\ref{sec:file_perm_management}, altrimen
+
+
+
\itindend{Access~Control~List}