X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=blobdiff_plain;f=filedir.tex;h=2ca508fd36d222356e6536dff9734594232127bd;hb=260bf7cea27648dc1d5a81b55b996fc4f710e507;hp=e0cd67da97fd80036d0a6d92a7d13f3ed4d20947;hpb=0e21ff1145b4f9a21c582fac348c87319133f79f;p=gapil.git

diff --git a/filedir.tex b/filedir.tex
index e0cd67d..2ca508f 100644
--- a/filedir.tex
+++ b/filedir.tex
@@ -2310,17 +2310,20 @@ 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
-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 è:
@@ -2617,7 +2620,7 @@ classi di attributi riportate in tab.~\ref{tab:extended_attribute_class}.
 \begin{table}[htb]
   \centering
   \footnotesize
-  \begin{tabular}{|c|p{8cm}|}
+  \begin{tabular}{|c|p{10cm}|}
     \hline
     \textbf{Nome} & \textbf{Descrizione} \\
     \hline
@@ -3064,9 +3067,80 @@ 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. 
+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{per permessi ordinari si
+  intende quelli mantenuti nell'\textit{inode}, che devono restare dato che un
+  filesystem può esseere montato senza abilitare le ACL.} 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,\footnote{o oggetti sul
+  filesystem, il comportamento discusso vale per le funzioni \func{open} e
+  \func{creat} (vedi sez.~\ref{sec:file_open}), \func{mkdir} (vedi
+  sez.~\ref{sec:file_dir_creat_rem}), \func{mknod} e \func{mkfifo} (vedi
+  sez.~\ref{sec:file_mknod}).} 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}
+per cui essi sono determinati dalla \itindex{umask} \textit{umask} del
+processo, e la sola differenza è che i permessi ordinari da esse risultanti
+vengono automaticamente rimappati su una ACL di accesso assegnata al nuovo
+file che contiene solo le tre voci di tipo \const{ACL\_USER\_OBJ},
+\const{ACL\_GROUP\_OBJ} e \const{ACL\_OTHER}.
+
+Se invece è presente una ACL di default sulla directory che contiene il nuovo
+file questa diventerà la sua ACL di accesso, a meno di non aver indicato nelle
+funzioni di creazione che lo consentono uno specifico insieme di
+permessi.\footnote{tutte le funzioni citate in precedenza supportano un
+  argomento \var{mode} che indichi un insieme di permssi iniziale.} In tal
+caso quelli non presenti in tale insieme saranno eliminati dalle voci
+corrispondenti nella ACL.
+
+Ovviamente la presenza della ACL modifica anche le regole del controllo di
+accesso ai file illustrate in sez.~\ref{sec:file_perm_overview}; per il
+controllo vengono sempre utilizzati gli identificatori del gruppo
+\textit{effective} del processo, ed i passi attraverso i quali viene stabilito
+se esso ha diritto di accesso sono i seguenti:
+\begin{enumerate}
+\item Se l'user-ID del processo è nullo l'accesso è sempre garantito senza
+  nessun ulteriore controllo.
+\item Se l'user-ID del processo corrisponde al proprietario del file allora:
+  \begin{itemize*}
+  \item se la voce \const{ACL\_USER\_OBJ} contiene il permesso richiesto,
+    l'accesso è consentito
+  \item altrimenti l'accesso è negato
+  \end{itemize*}
+\item Se l'user-ID del processo corrisponde ad un qualunque qualificatore
+  presente in una voce \const{ACL\_USER} allora:
+  \begin{itemize*}
+  \item se la voce \const{ACL\_USER} corrispondente e la voce
+    \const{ACL\_MASK} contengono entrambe il permesso richiesto, l'accesso è
+    consentito
+  \item altrimenti l'accesso è negato
+  \end{itemize*}
+\item Se il group-ID del processo o uno dei group-ID supplementari corrisponde
+  al gruppo proprietario del file o a un qualunque qualificatore di una voce
+  di tipo  allora:
+  \begin{itemize*}
+  \item se il bit dei permessi d'accesso del gruppo è impostato, l'accesso è
+    consentito, 
+  \item altrimenti l'accesso è negato
+  \end{itemize*}
+\item Se il bit dei permessi d'accesso per tutti gli altri è impostato,
+  l'accesso è consentito, altrimenti l'accesso è negato.
+\end{enumerate}
+
 
 
 \itindend{Access~Control~List}