-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
+
+
+