'70, quando le risorse di calcolo e di spazio disco erano minime. Con il venir
meno di queste restrizioni è incominciata ad emergere l'esigenza di poter
associare ai file delle ulteriori informazioni astratte (quelli che vengono
-chiamati i \textsl{meta-dati}) che però non potevano trovar spazio nei dati
+chiamati i \textsl{meta-dati}) che però non potevano trovare spazio nei dati
classici mantenuti negli inode.
Per risolvere questo problema alcuni sistemi unix-like (e fra questi anche
\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, uno
+Dato che le ACL vengono a costituire una estensione dei permessi 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}.}
+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ò essere 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, 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
-
-
+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 permessi 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}
\subsection{La funzione \func{chroot}}
\label{sec:file_chroot}
-% TODO intrudurre nuova sezione sulle funzionalità di sicurezza avanzate, con
+% TODO introdurre nuova sezione sulle funzionalità di sicurezza avanzate, con
% dentro chroot SELinux e AppArmor ???
Benché non abbia niente a che fare con permessi, utenti e gruppi, la funzione
% LocalWords: IRWXO ext reiser capability FSETID mask capabilities chroot jail
% LocalWords: FTP Di filter reiserfs Attributes Solaris Posix FreeBSD libacl
% LocalWords: XFS SELinux namespace attribute security trusted Draft Modules
-% LocalWords: attributes mime ADMIN FOWNER libattr lattr getxattr lgetxattr
+% LocalWords: attributes mime ADMIN FOWNER libattr lattr getxattr lgetxattr of
% LocalWords: fgetxattr attr ssize ENOATTR ENOTSUP NUL setxattr lsetxattr list
-% LocalWords: fsetxattr flags XATTR REPLACE listxattr llistxattr flistxattr
-% LocalWords: removexattr lremovexattr fremovexattr attributename lacl
+% LocalWords: fsetxattr flags XATTR REPLACE listxattr llistxattr flistxattr by
+% LocalWords: removexattr lremovexattr fremovexattr attributename lacl acl
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "gapil"
%%% End:
+% LocalWords: OBJ