+privilegi di root entrambi i bit \itindex{suid~bit} \acr{suid} e
+\itindex{sgid~bit} \acr{sgid} vengono cancellati. Questo non avviene per il
+bit \acr{sgid} nel caso in cui esso sia usato (in assenza del corrispondente
+permesso di esecuzione) per indicare che per il file è attivo il
+\itindex{mandatory~locking} \textit{mandatory locking}.
+
+
+\subsection{Un quadro d'insieme sui permessi}
+\label{sec:file_riepilogo}
+
+Avendo affrontato in maniera separata il comportamento delle varie funzioni ed
+il significato dei singoli bit dei permessi sui file, vale la pena fare un
+riepilogo in cui si riassumono le caratteristiche di ciascuno di essi, in modo
+da poter fornire un quadro d'insieme.
+
+In tab.~\ref{tab:file_fileperm_bits} si sono riassunti gli effetti dei vari
+bit dei permessi per un file; per quanto riguarda l'applicazione dei permessi
+per proprietario, gruppo ed altri si ricordi quanto illustrato in
+sez.~\ref{sec:file_perm_overview}. Per compattezza, nella tabelle si sono
+specificati i bit di \itindex{suid~bit} \textit{suid}, \itindex{sgid~bit}
+\textit{sgid} e \textit{sticky} \itindex{sticky~bit} con la notazione
+illustrata anche in fig.~\ref{fig:file_perm_bit}.
+
+\begin{table}[!htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|c|c|c|c|c|c|c|c|c|c|c|c|l|}
+ \hline
+ \multicolumn{3}{|c|}{special}&
+ \multicolumn{3}{|c|}{user}&
+ \multicolumn{3}{|c|}{group}&
+ \multicolumn{3}{|c|}{other}&
+ \multirow{2}{*}{\textbf{Operazioni possibili}} \\
+ \cline{1-12}
+ \acr{s}&\acr{s}&\acr{t}&r&w&x&r&w&x&r&w&x& \\
+ \hline
+ \hline
+ 1&-&-&-&-&-&-&-&-&-&-&-&Se eseguito ha i permessi del proprietario.\\
+ -&1&-&-&-&1&-&-&-&-&-&-&Se eseguito ha i permessi del gruppo proprietario.\\
+ -&1&-&-&-&0&-&-&-&-&-&-&Il \itindex{mandatory~locking}
+ \textit{mandatory locking} è abilitato.\\
+ -&-&1&-&-&-&-&-&-&-&-&-&Non utilizzato.\\
+ -&-&-&1&-&-&-&-&-&-&-&-&Permesso di lettura per il proprietario.\\
+ -&-&-&-&1&-&-&-&-&-&-&-&Permesso di scrittura per il proprietario.\\
+ -&-&-&-&-&1&-&-&-&-&-&-&Permesso di esecuzione per il proprietario.\\
+ -&-&-&-&-&-&1&-&-&-&-&-&Permesso di lettura per il gruppo proprietario.\\
+ -&-&-&-&-&-&-&1&-&-&-&-&Permesso di scrittura per il gruppo proprietario.\\
+ -&-&-&-&-&-&-&-&1&-&-&-&Permesso di esecuzione per il gruppo proprietario.\\
+ -&-&-&-&-&-&-&-&-&1&-&-&Permesso di lettura per tutti gli altri.\\
+ -&-&-&-&-&-&-&-&-&-&1&-&Permesso di scrittura per tutti gli altri.\\
+ -&-&-&-&-&-&-&-&-&-&-&1&Permesso di esecuzione per tutti gli altri.\\
+ \hline
+ \end{tabular}
+ \caption{Tabella riassuntiva del significato dei bit dei permessi per un
+ file.}
+ \label{tab:file_fileperm_bits}
+\end{table}
+
+In tab.~\ref{tab:file_dirperm_bits} si sono invece riassunti gli effetti dei
+vari bit dei permessi per una directory; anche in questo caso si sono
+specificati i bit di \itindex{suid~bit} \textit{suid}, \itindex{sgid~bit}
+\textit{sgid} e \textit{sticky} \itindex{sticky~bit} con la notazione compatta
+illustrata in fig.~\ref{fig:file_perm_bit}.
+
+\begin{table}[!htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|c|c|c|c|c|c|c|c|c|c|c|c|l|}
+ \hline
+ \multicolumn{3}{|c|}{special}&
+ \multicolumn{3}{|c|}{user}&
+ \multicolumn{3}{|c|}{group}&
+ \multicolumn{3}{|c|}{other}&
+ \multirow{2}{*}{\textbf{Operazioni possibili}} \\
+ \cline{1-12}
+ \acr{s}&\acr{s}&\acr{t}&r&w&x&r&w&x&r&w&x& \\
+ \hline
+ \hline
+ 1&-&-&-&-&-&-&-&-&-&-&-&Non utilizzato.\\
+ -&1&-&-&-&-&-&-&-&-&-&-&Propaga il gruppo proprietario ai nuovi file
+ creati.\\
+ -&-&1&-&-&-&-&-&-&-&-&-&Limita l'accesso in scrittura dei file nella
+ directory.\\
+ -&-&-&1&-&-&-&-&-&-&-&-&Permesso di visualizzazione per il proprietario.\\
+ -&-&-&-&1&-&-&-&-&-&-&-&Permesso di aggiornamento per il proprietario.\\
+ -&-&-&-&-&1&-&-&-&-&-&-&Permesso di attraversamento per il proprietario.\\
+ -&-&-&-&-&-&1&-&-&-&-&-&Permesso di visualizzazione per il gruppo
+ proprietario.\\
+ -&-&-&-&-&-&-&1&-&-&-&-&Permesso di aggiornamento per il gruppo
+ proprietario.\\
+ -&-&-&-&-&-&-&-&1&-&-&-&Permesso di attraversamento per il gruppo
+ proprietario.\\
+ -&-&-&-&-&-&-&-&-&1&-&-&Permesso di visualizzazione per tutti gli altri.\\
+ -&-&-&-&-&-&-&-&-&-&1&-&Permesso di aggiornamento per tutti gli altri.\\
+ -&-&-&-&-&-&-&-&-&-&-&1&Permesso di attraversamento per tutti gli altri.\\
+ \hline
+ \end{tabular}
+ \caption{Tabella riassuntiva del significato dei bit dei permessi per una
+ directory.}
+ \label{tab:file_dirperm_bits}
+\end{table}
+
+Nelle tabelle si è indicato con il carattere ``-'' il fatto che il valore del
+bit in questione non è influente rispetto a quanto indicato nella riga della
+tabella; la descrizione dell'operazione fa riferimento soltanto alla
+combinazione di bit per i quali è stato riportato esplicitamente un valore.
+Si rammenti infine che il valore dei bit dei permessi non ha alcun effetto
+qualora il processo possieda i privilegi di amministratore.
+
+
+
+\section{Caratteristiche e funzionalità avanzate}
+\label{sec:file_dir_advances}
+
+Tratteremo qui alcune caratteristiche e funzionalità avanzate della gestione
+di file e directory, affrontando anche una serie di estensioni
+dell'interfaccia classica dei sistemi unix-like, principalmente utilizzate a
+scopi di sicurezza, che sono state introdotte nelle versioni più recenti di
+Linux.
+
+
+\subsection{Gli attributi estesi}
+\label{sec:file_xattr}
+
+\itindbeg{Extended~Attributes}
+
+Nelle sezioni precedenti abbiamo trattato in dettaglio le varie informazioni
+che il sistema mantiene negli inode, e le varie funzioni che permettono di
+modificarle. Si sarà notato come in realtà queste informazioni siano
+estremamente ridotte. Questo è dovuto al fatto che Unix origina negli anni
+'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 trovare spazio nei dati
+classici mantenuti negli inode.
+
+Per risolvere questo problema alcuni sistemi unix-like (e fra questi anche
+Linux) hanno introdotto un meccanismo generico che consenta di associare delle
+informazioni ai singoli file,\footnote{l'uso più comune è quello della ACL,
+ che tratteremo nella prossima sezione, ma si possono inserire anche altre
+ informazioni.} detto \textit{Extended Attributes}. Gli \textsl{attributi
+ estesi} non sono altro che delle coppie nome/valore che sono associate
+permanentemente ad un oggetto sul filesystem, analoghi di quello che sono le
+variabili di ambiente (vedi sez.~\ref{sec:proc_environ}) per un processo.
+
+Altri sistemi (come Solaris, MacOS e Windows) hanno adottato un meccanismo
+diverso in cui ad un file sono associati diversi flussi di dati, su cui
+possono essere mantenute ulteriori informazioni, che possono essere accedute
+con le normali operazioni di lettura e scrittura. Questi non vanno confusi con
+gli \textit{Extended Attributes} (anche se su Solaris hanno lo stesso nome),
+che sono un meccanismo molto più semplice, che pur essendo limitato (potendo
+contenere solo una quantità limitata di informazione) hanno il grande
+vantaggio di essere molto più semplici da realizzare, più
+efficienti,\footnote{cosa molto importante, specie per le applicazioni che
+ richiedono una gran numero di accessi, come le ACL.} e di garantire
+l'atomicità di tutte le operazioni.
+
+In Linux gli attributi estesi sono sempre associati al singolo inode e
+l'accesso viene sempre eseguito in forma atomica, in lettura il valore
+corrente viene scritto su un buffer in memoria, mentre la scrittura prevede
+che ogni valore precedente sia sovrascritto.
+
+Si tenga presente che non tutti i filesystem supportano gli \textit{Extended
+ Attributes}, in particolare al momento della scrittura di queste dispense
+essi sono presenti solo su \textsl{ext2}, \textsl{ext3} e \textsl{XFS}.
+Inoltre a seconda della implementazione ci possono essere dei limiti sulla
+quantità di attributi che si possono utilizzare.\footnote{ad esempio nel caso
+ di \textsl{ext2} ed \textsl{ext3} è richiesto che essi siano contenuti
+ all'interno di un singolo blocco (pertanto con dimensioni massime pari a
+ 1024, 2048 o 4096 byte a seconda delle dimensioni di quest'ultimo impostate
+ in fase di creazione del filesystem), mentre con \textsl{XFS} non ci sono
+ limiti ed i dati vengono memorizzati in maniera diversa (nell'inode stesso,
+ in un blocco a parte, o in una struttura ad albero dedicata) per mantenerne
+ la scalabilità.} Infine lo spazio utilizzato per mantenere gli attributi
+estesi viene tenuto in conto per il calcolo delle quote di utente e gruppo
+proprietari del file.
+
+Come meccanismo per mantenere informazioni aggiuntive associate al singolo
+file, gli \textit{Extended Attributes} possono avere usi anche molto diversi
+fra loro. Per poterli distinguere allora sono stati suddivisi in
+\textsl{classi}, a cui poter applicare requisiti diversi per l'accesso e la
+gestione. Per questo motivo il nome di un attributo deve essere sempre
+specificato nella forma \texttt{namespace.attribute}, dove \texttt{namespace}
+fa riferimento alla classe a cui l'attributo appartiene, mentre
+\texttt{attribute} è il nome ad esso assegnato. In tale forma il nome di un
+attributo esteso deve essere univoco. Al momento\footnote{della scrittura di
+ questa sezione, kernel 2.6.23, ottobre 2007.} sono state definite le quattro
+classi di attributi riportate in tab.~\ref{tab:extended_attribute_class}.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}{|c|p{10cm}|}
+ \hline
+ \textbf{Nome} & \textbf{Descrizione} \\
+ \hline
+ \hline
+ \const{security}& Gli \textit{extended security attributes}: vengono
+ utilizzati dalle estensioni di sicurezza del kernel (i
+ \itindex{Linux~Security~Modules} \textit{Linux
+ Security Modules}), per le realizzazione di meccanismi
+ evoluti di controllo di accesso come \index{SELinux}
+ SELinux.\\
+ \const{system} & Gli \textit{extended security attributes}: sono usati
+ dal kernel per memorizzare dati di sistema associati ai
+ file come le \itindex{Access~Control~List} ACL (vedi
+ sez.~\ref{sec:file_ACL}) o le \itindex{capabilities}
+ \textit{capabilities} (vedi
+ sez.~\ref{sec:proc_capabilities}).\\
+ \const{trusted} & I \textit{trusted extended attributes}: vengono
+ utilizzati per poter realizzare in user space
+ meccanismi che consentano di mantenere delle
+ informazioni sui file che non devono essere accessibili
+ ai processi ordinari.\\
+ \const{user} & Gli \textit{extended user attributes}: utilizzati per
+ mantenere informazioni aggiuntive sui file (come il
+ \textit{mime-type}, la codifica dei caratteri o del
+ file) accessibili dagli utenti.\\
+ \hline
+ \end{tabular}
+ \caption{I nomi utilizzati valore di \texttt{namespace} per distinguere le
+ varie classi di \textit{Extended Attributes}.}
+ \label{tab:extended_attribute_class}
+\end{table}
+
+
+Dato che uno degli usi degli \textit{Extended Attributes} è quello che li
+impiega per realizzare delle estensioni (come le ACL, \index{SELinux} SELinux,
+ecc.) al tradizionale meccanismo dei controlli di accesso di Unix, l'accesso
+ai loro valori viene regolato in maniera diversa a seconda sia della loro
+classe sia di quali, fra le estensioni che li utilizzano, sono poste in uso.
+In particolare, per ciascuna delle classi riportate in
+tab.~\ref{tab:extended_attribute_class}, si hanno i seguenti casi:
+\begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}}
+\item[\texttt{security}] L'accesso agli \textit{extended security attributes}
+ dipende dalle politiche di sicurezza stabilite da loro stessi tramite
+ l'utilizzo di un sistema di controllo basato sui
+ \itindex{Linux~Security~Modules} \textit{Linux Security Modules} (ad esempio
+ \index{SELinux} SELinux). Pertanto l'accesso in lettura o scrittura dipende
+ dalle politiche di sicurezza implementate all'interno dal modulo di
+ sicurezza che si sta utilizzando al momento (ciascuno avrà le sue). Se non è
+ stato caricato nessun modulo di sicurezza l'accesso in lettura sarà
+ consentito a tutti i processi, mentre quello in scrittura solo ai processi
+ con privilegi amministrativi dotati della \index{capabilities}
+ \textit{capability} \const{CAP\_SYS\_ADMIN}.
+
+\item[\texttt{system}] Anche l'accesso agli \textit{extended system
+ attributes} dipende dalle politiche di accesso che il kernel realizza
+ anche utilizzando gli stessi valori in essi contenuti. Ad esempio nel caso
+ delle ACL l'accesso è consentito in lettura ai processi che hanno la
+ capacità di eseguire una ricerca sul file (cioè hanno il permesso di lettura
+ sulla directory che contiene il file) ed in scrittura al proprietario del
+ file o ai processi dotati della \textit{capability} \index{capabilities}
+ \const{CAP\_FOWNER}.\footnote{vale a dire una politica di accesso analoga a
+ quella impiegata per gli ordinari permessi dei file.}
+
+\item[\texttt{trusted}] L'accesso ai \textit{trusted extended attributes}, sia
+ per la lettura che per la scrittura, è consentito soltanto ai processi con
+ privilegi amministrativi dotati della \index{capabilities}
+ \textit{capability} \const{CAP\_SYS\_ADMIN}. In questo modo si possono
+ utilizzare questi attributi per realizzare in user space dei meccanismi di
+ controllo che accedono ad informazioni non disponibili ai processi ordinari.
+
+\item[\texttt{user}] L'accesso agli \textit{extended user attributes} è
+ regolato dagli ordinari permessi dei file a cui essi fanno riferimento:
+ occorre avere il permesso di lettura per leggerli e quello di scrittura per
+ scriverli o modificarli. Dato l'uso di questi attributi, si è scelto cioè di
+ applicare per il loro accesso gli stessi criteri che si usano per l'accesso
+ al contenuto dei file (o delle directory) cui essi fanno riferimento.
+
+ Questa scelta vale però soltanto per i file e le directory ordinarie, se
+ valesse in generale infatti si avrebbe un serio problema di sicurezza dato
+ che esistono diversi oggetti sul filesystem per i quali è normale avere
+ avere il permesso di scrittura consentito a tutti gli utenti, come i link
+ simbolici, o alcuni file di dispositivo come \texttt{/dev/null}. Se fosse
+ possibile usare su di essi gli \textit{extended user attributes} un utente
+ qualunque potrebbe inserirvi dati a piacere.\footnote{la cosa è stata notata
+ su XFS, dove questo comportamento permetteva, non essendovi limiti sullo
+ spazio occupabile dagli \textit{Extended Attributes}, di bloccare il
+ sistema riempiendo il disco.}
+
+ La semantica del controllo di accesso che abbiamo indicato inoltre non
+ avrebbe alcun senso al di fuori di file e directory: i permessi di lettura e
+ scrittura per un file di dispositivo attengono alle capacità di accesso al
+ dispositivo sottostante,\footnote{motivo per cui si può formattare un disco
+ anche se \texttt{/dev} è su un filesystem in sola lettura.} mentre per i
+ link simbolici questi vengono semplicemente ignorati: in nessuno dei due
+ casi hanno a che fare con il contenuto del file, e nella discussione
+ relativa all'uso degli \textit{extended user attributes} nessuno è mai stato
+ capace di indicare una qualche forma sensata di utilizzo degli stessi per
+ link simbolici o file di dispositivo, e neanche per le fifo o i socket.
+
+ Per questo motivo gli \textit{extended user attributes} sono stati
+ completamente disabilitati per tutto ciò che non sia un file regolare o una
+ directory.\footnote{si può verificare la semantica adottata consultando il
+ file \texttt{fs/xattr.c} dei sorgenti del kernel.} Inoltre per le
+ directory è stata introdotta una ulteriore restrizione, dovuta di nuovo alla
+ presenza ordinaria di permessi di scrittura completi su directory come
+ \texttt{/tmp}. Questo è un altro caso particolare, in cui il premesso di
+ scrittura viene usato, unito alla presenza dello \itindex{sticky~bit}
+ \textit{sticky bit}, per garantire il permesso di creazione di nuovi file.
+ Per questo motivo, per evitare eventuali abusi, se una directory ha lo
+ \itindex{sticky~bit} \textit{sticky bit} attivo sarà consentito scrivere i
+ suoi \textit{extended user attributes} soltanto se si è proprietari della
+ stessa, o si hanno i privilegi amministrativi della capability
+ \index{capabilities} \const{CAP\_FOWNER}.
+\end{basedescript}
+
+Le funzioni per la gestione degli attributi estesi, come altre funzioni di
+gestione avanzate specifiche di Linux, non fanno parte delle \acr{glibc}, e
+sono fornite da una apposita libreria, \texttt{libattr}, che deve essere
+installata a parte;\footnote{la versione corrente della libreria è
+ \texttt{libattr1}, e nel caso si usi Debian la si può installare con il
+ pacchetto omonimo ed il collegato \texttt{libattr1-dev}.} pertanto se un
+programma le utilizza si dovrà indicare esplicitamente l'uso della suddetta
+libreria invocando il compilatore con l'opzione \texttt{-lattr}.
+
+Per poter leggere gli attributi estesi sono disponibili tre diverse funzioni,
+\funcd{getxattr}, \funcd{lgetxattr} e \funcd{fgetxattr}, che consentono
+rispettivamente di richiedere gli attributi relativi a un file, a un link
+simbolico e ad un file descriptor; i rispettivi prototipi sono:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{attr/xattr.h}
+
+ \funcdecl{ssize\_t getxattr(const char *path, const char *name, void
+ *value, size\_t size)}
+
+ \funcdecl{ssize\_t lgetxattr(const char *path, const char *name, void
+ *value, size\_t size)}
+
+ \funcdecl{ssize\_t fgetxattr(int filedes, const char *name, void *value,
+ size\_t size)}
+
+ Le funzioni leggono il valore di un attributo esteso.
+
+ \bodydesc{Le funzioni restituiscono un intero positivo che indica la
+ dimensione dell'attributo richiesto in caso di successo, e $-1$ in caso di
+ errore, nel qual caso \var{errno} assumerà i valori:
+ \begin{errlist}
+ \item[\errcode{ENOATTR}] l'attributo richiesto non esiste.
+ \item[\errcode{ERANGE}] la dimensione \param{size} del buffer \param{value}
+ non è sufficiente per contenere il risultato.
+ \item[\errcode{ENOTSUP}] gli attributi estesi non sono supportati dal
+ filesystem o sono disabilitati.
+ \end{errlist}
+ Oltre a questi potranno essere restituiti tutti gli errori di \func{stat},
+ ed in particolare \errcode{EPERM} se non si hanno i permessi di accesso
+ all'attributo. }
+\end{functions}
+
+Le funzioni \func{getxattr} e \func{lgetxattr} prendono come primo argomento
+un pathname che indica il file di cui si vuole richiedere un attributo, la
+sola differenza è che la seconda, se il pathname indica un link simbolico,
+restituisce gli attributi di quest'ultimo e non quelli del file a cui esso fa
+riferimento. La funzione \func{fgetxattr} prende invece come primo argomento
+un numero di file descriptor, e richiede gli attributi del file ad esso
+associato.
+
+Tutte e tre le funzioni richiedono di specificare nell'argomento \param{name}
+il nome dell'attributo di cui si vuole ottenere il valore. Il nome deve essere
+indicato comprensivo di prefisso del \textit{namespace} cui appartiene (uno
+dei valori di tab.~\ref{tab:extended_attribute_class}) nella forma
+\texttt{namespace.attributename}, come stringa terminata da un carattere NUL.
+Il suo valore verrà restituito nel buffer puntato dall'argomento \param{value}
+per una dimensione massima di \param{size} byte;\footnote{gli attributi estesi
+ possono essere costituiti arbitrariamente da dati testuali o binari.} se
+quest'ultima non è sufficiente si avrà un errore di \errcode{ERANGE}.
+
+Per evitare di dover indovinare la dimensione di un attributo per tentativi si
+può eseguire una interrogazione utilizzando un valore nullo per \param{size};
+in questo caso non verrà letto nessun dato, ma verrà restituito come valore di
+ritorno della funzione chiamata la dimensione totale dell'attributo esteso
+richiesto, che si potrà usare come stima per allocare un buffer di dimensioni
+sufficienti.\footnote{si parla di stima perché anche se le funzioni
+ restituiscono la dimensione esatta dell'attributo al momento in cui sono
+ eseguite, questa potrebbe essere modificata in qualunque momento da un
+ successivo accesso eseguito da un altro processo.}
+
+Un secondo gruppo di funzioni è quello che consente di impostare il valore di
+un attributo esteso, queste sono \funcd{setxattr}, \funcd{lsetxattr} e
+\funcd{fsetxattr}, e consentono di operare rispettivamente su un file, su un
+link simbolico o specificando un file descriptor; i loro prototipi sono:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{attr/xattr.h}
+
+ \funcdecl{int setxattr(const char *path, const char *name, const void
+ *value, size\_t size, int flags)}
+
+ \funcdecl{int lsetxattr(const char *path, const char *name, const void
+ *value, size\_t size, int flags)}
+
+ \funcdecl{int fsetxattr(int filedes, const char *name, const void *value,
+ size\_t size, int flags)}
+
+ Impostano il valore di un attributo esteso.
+
+ \bodydesc{Le funzioni restituiscono 0 in caso di successo, e $-1$ in caso di
+ errore, nel qual caso \var{errno} assumerà i valori:
+ \begin{errlist}
+ \item[\errcode{ENOATTR}] si è usato il flag \const{XATTR\_REPLACE} e
+ l'attributo richiesto non esiste.
+ \item[\errcode{EEXIST}] si è usato il flag \const{XATTR\_CREATE} ma
+ l'attributo esiste già.
+ \item[\errcode{ENOTSUP}] gli attributi estesi non sono supportati dal
+ filesystem o sono disabilitati.
+ \end{errlist}
+ Oltre a questi potranno essere restituiti tutti gli errori di \func{stat},
+ ed in particolare \errcode{EPERM} se non si hanno i permessi di accesso
+ all'attributo.
+}
+\end{functions}
+
+Le tre funzioni prendono come primo argomento un valore adeguato al loro
+scopo, usato in maniera del tutto identica a quanto visto in precedenza per le
+analoghe che leggono gli attributi estesi. Il secondo argomento \param{name}
+deve indicare, anche in questo caso con gli stessi criteri appena visti per le
+analoghe \func{getxattr}, \func{lgetxattr} e \func{fgetxattr}, il nome
+(completo di suffisso) dell'attributo su cui si vuole operare.
+
+Il valore che verrà assegnato all'attributo dovrà essere preparato nel buffer
+puntato da \param{value}, e la sua dimensione totale (in byte) sarà indicata
+dall'argomento \param{size}. Infine l'argomento \param{flag} consente di
+controllare le modalità di sovrascrittura dell'attributo esteso, esso può
+prendere due valori: con \const{XATTR\_REPLACE} si richiede che l'attributo
+esista, nel qual caso verrà sovrascritto, altrimenti si avrà errore, mentre
+con \const{XATTR\_CREATE} si richiede che l'attributo non esista, nel qual
+caso verrà creato, altrimenti si avrà errore ed il valore attuale non sarà
+modificato. Utilizzando per \param{flag} un valore nullo l'attributo verrà
+modificato se è già presente, o creato se non c'è.
+
+Le funzioni finora illustrate permettono di leggere o scrivere gli attributi
+estesi, ma sarebbe altrettanto utile poter vedere quali sono gli attributi
+presenti; a questo provvedono le funzioni \funcd{listxattr},
+\funcd{llistxattr} e \funcd{flistxattr} i cui prototipi sono:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{attr/xattr.h}
+
+ \funcdecl{ssize\_t listxattr(const char *path, char *list, size\_t size)}
+
+ \funcdecl{ssize\_t llistxattr(const char *path, char *list, size\_t size)}
+
+ \funcdecl{ssize\_t flistxattr(int filedes, char *list, size\_t size)}
+
+ Leggono la lista degli attributi estesi di un file.
+
+ \bodydesc{Le funzioni restituiscono un intero positivo che indica la
+ dimensione della lista in caso di successo, e $-1$ in caso di errore, nel
+ qual caso \var{errno} assumerà i valori:
+ \begin{errlist}
+ \item[\errcode{ERANGE}] la dimensione \param{size} del buffer \param{value}
+ non è sufficiente per contenere il risultato.
+ \item[\errcode{ENOTSUP}] gli attributi estesi non sono supportati dal
+ filesystem o sono disabilitati.
+ \end{errlist}
+ Oltre a questi potranno essere restituiti tutti gli errori di \func{stat},
+ ed in particolare \errcode{EPERM} se non si hanno i permessi di accesso
+ all'attributo.
+}
+\end{functions}
+
+Come per le precedenti le tre funzioni leggono gli attributi rispettivamente
+di un file, un link simbolico o specificando un file descriptor, da
+specificare con il loro primo argomento. Gli altri due argomenti, identici per
+tutte e tre, indicano rispettivamente il puntatore \param{list} al buffer dove
+deve essere letta la lista e la dimensione \param{size} di quest'ultimo.
+
+La lista viene fornita come sequenza non ordinata dei nomi dei singoli
+attributi estesi (sempre comprensivi del prefisso della loro classe) ciascuno
+dei quali è terminato da un carattere nullo. I nomi sono inseriti nel buffer
+uno di seguito all'altro. Il valore di ritorno della funzione indica la
+dimensione totale della lista in byte.
+
+Come per le funzioni di lettura dei singoli attributi se le dimensioni del
+buffer non sono sufficienti si avrà un errore, ma è possibile ottenere dal
+valore di ritorno della funzione una stima della dimensione totale della lista
+usando per \param{size} un valore nullo.
+
+Infine per rimuovere semplicemente un attributo esteso, si ha a disposizione
+un ultimo gruppo di funzioni: \funcd{removexattr}, \funcd{lremovexattr} e
+\funcd{fremovexattr}; i rispettivi prototipi sono:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{attr/xattr.h}
+
+ \funcdecl{int removexattr(const char *path, const char *name)}
+
+ \funcdecl{int lremovexattr(const char *path, const char *name)}
+
+ \funcdecl{int fremovexattr(int filedes, const char *name)}
+
+
+ Rimuovono un attributo esteso di un file.
+
+ \bodydesc{Le funzioni restituiscono 0 in caso di successo, e $-1$ in caso di
+ errore, nel qual caso \var{errno} assumerà i valori:
+ \begin{errlist}
+ \item[\errcode{ENOATTR}] l'attributo richiesto non esiste.
+ \item[\errcode{ENOTSUP}] gli attributi estesi non sono supportati dal
+ filesystem o sono disabilitati.
+ \end{errlist}
+ ed inoltre tutti gli errori di \func{stat}.
+}
+\end{functions}
+
+Le tre funzioni rimuovono l'attributo esteso indicato dall'argomento
+\param{name} rispettivamente di un file, un link simbolico o specificando un
+file descriptor, da specificare con il loro primo argomento. Anche in questo
+caso l'argomento \param{name} deve essere specificato con le modalità già
+illustrate in precedenza per le altre funzioni relative agli attributi estesi.
+
+
+\itindend{Extended~Attributes}
+
+% TODO trattare gli attributi estesi e le funzioni la documentazione di
+% sistema è nei pacchetti libxattr1-dev e attr
+
+
+\subsection{Le \textit{Access Control List}}
+\label{sec:file_ACL}
+
+
+\itindbeg{Access~Control~List}
+
+Il modello classico dei permessi di Unix, per quanto funzionale ed efficiente,
+è comunque piuttosto limitato e per quanto possa aver coperto per lunghi anni
+le esigenze più comuni con un meccanismo semplice e potente, non è in grado di
+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 semplice.}
+
+Per questo motivo erano state progressivamente introdotte nelle varie versioni
+di Unix dei meccanismi di gestione dei permessi dei file più flessibili, nella
+forma delle cosiddette \textit{Access Control List} (indicate usualmente con
+la sigla ACL). Nello sforzo di standardizzare queste funzionalità era stato
+creato un gruppo di lavoro il cui scopo era estendere lo standard POSIX 1003
+attraverso due nuovi insiemi di specifiche, la POSIX 1003.1e per l'interfaccia
+di programmazione e la POSIX 1003.2c per i comandi di shell.
+
+Gli obiettivi erano però forse troppo ambizioni, e nel gennaio del 1998 i
+finanziamenti vennero ritirati senza che si fosse arrivati alla definizione di
+uno standard, dato però che una parte della documentazione prodotta era di
+alta qualità venne deciso di rilasciare al pubblico la diciassettesima bozza
+del documento, quella che va sotto il nome di \textit{POSIX 1003.1e Draft 17},
+che è divenuta la base sulla quale si definiscono le cosiddette \textit{Posix
+ ACL}.
+
+A differenza di altri sistemi (ad esempio FreeBSD) nel caso di Linux si è
+scelto di realizzare le ACL attraverso l'uso degli
+\itindex{Extended~Attributes} \textit{Extended Attributes} (appena trattati in
+sez.~\ref{sec:file_xattr}), e fornire tutte le relative funzioni di gestione
+tramite una libreria, \texttt{libacl} che nasconde i dettagli implementativi
+delle ACL e presenta ai programmi una interfaccia che fa riferimento allo
+standard POSIX 1003.1e.
+
+Anche in questo caso le funzioni di questa libreria non fanno parte delle
+\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 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 per questo 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 ciascuna di queste voci dovrà fare riferimento ad un utente o ad un
+gruppo diverso, e non corrispondenti a quelli proprietari del file. 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
+una ACL di tipo \const{ACL\_MASK} è di particolare utilità quando essa
+associata ad una \textit{default ACL} su una directory, in quanto i permessi
+così specificati verranno ereditati da tutti i file creati nella stessa
+directory. Si ottiene così 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 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{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 soltanto
+se non è presente una voce di tipo \const{ACL\_MASK}, se invece questa è
+presente verranno tolti dai permessi di \const{ACL\_GROUP\_OBJ} tutti quelli
+non presenti in \const{ACL\_MASK}.\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 \textit{default ACL} sulla directory che contiene quel file.
+Se questa non c'è valgono le regole usuali 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 anche
+su una ACL di accesso assegnata automaticamente al nuovo file, che contiene
+soltanto le tre corrispondenti 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à automaticamente la sua ACL di accesso, a meno di non
+aver indicato, nelle funzioni di creazione che lo consentono, uno specifico
+valore per i permessi ordinari;\footnote{tutte le funzioni citate in
+ precedenza supportano un argomento \var{mode} che indichi un insieme di
+ permessi iniziale.} in tal caso saranno eliminati dalle voci corrispondenti
+nella ACL tutti quelli non presenti in tale indicazione.
+
+Dato che questa è la ragione che ha portato alla loro creazione, la pricipale
+modifica introdotta con la presenza della ACL è quella alle regole del
+controllo di accesso ai file illustrate in sez.~\ref{sec:file_perm_overview}.
+Come nel caso ordinario per il controllo vengono sempre utilizzati gli
+identificatori del gruppo \textit{effective} del processo, ma in presenza di
+ACL 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 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 allora:
+ \begin{itemize*}
+ \item se la voce \const{ACL\_GROUP\_OBJ} e una eventuale voce
+ \const{ACL\_MASK} (se non vi sono voci di tipo \const{ACL\_GROUP} questa
+ può non essere presente) 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 ad un qualunque qualificatore presente in una voce
+ \const{ACL\_GROUP} allora:
+ \begin{itemize*}
+ \item se la voce \const{ACL\_GROUP} corrispondente e la voce
+ \const{ACL\_MASK} contengono entrambe il permesso richiesto, l'accesso è
+ consentito;
+ \item altrimenti l'accesso è negato.
+ \end{itemize*}
+\item Se la voce \const{ACL\_USER\_OBJ} contiene il permesso richiesto,
+ l'accesso è consentito, altrimenti l'accesso è negato.
+\end{enumerate*}
+
+I passi di controllo vengono eseguiti esattamente in questa sequenza, e la
+decisione viene presa non appena viene trovata una corrispondenza con gli
+identificatori del processo. Questo significa che i permessi presenti in una
+voce di tipo \const{ACL\_USER} hanno la precedenza sui permessi ordinari
+associati al gruppo proprietario del file (vale a dire su
+\const{ACL\_GROUP\_OBJ}).
+
+Per la gestione delle ACL lo standard \textit{POSIX 1003.1e Draft 17} ha
+previsto delle apposite funzioni ed tutta una serie di tipi di dati
+dedicati;\footnote{fino a definire un tipo di dato e delle costanti apposite
+ per identificare i permessi standard di lettura, scrittura ed esecuzione.}
+tutte le operazioni devono essere effettuate attraverso tramite questi tipi di
+dati, che incapsulano tutte le informazioni contenute nelle ACL. La prima di
+queste funzioni che prendiamo in esame è \funcd{acl\_init}, il cui prototipo
+è:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/acl.h}
+
+ \funcdecl{acl\_t acl\_init(int count)}
+
+ Inizializza un'area di lavoro per una ACL di \param{count} voci.
+
+ \bodydesc{La funzione restituisce un puntatore all'area di lavoro in caso di
+ successo e \const{NULL} in caso di errore, nel qual caso \var{errno}
+ assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] il valore di \param{count} è negativo.
+ \item[\errcode{ENOMEM}] non c'è sufficiente memoria disponibile.
+ \end{errlist}
+}
+\end{functions}
+
+La funzione alloca ed inizializza un'area di memoria che verrà usata per
+mantenere i dati di una ACL contenente fino ad un massimo di \const{count}
+voci. La funzione ritorna un valore di tipo \type{acl\_t}, da usare in tutte
+le altre funzioni che operano sulla ACL. La funzione si limita alla
+allocazione iniziale e non inserisce nessun valore nella ACL che resta vuota.
+Si tenga presente che pur essendo \type{acl\_t} un tipo opaco che identifica
+``\textsl{l'oggetto}'' ACL, il valore restituito dalla funzione non è altro
+che un puntatore all'area di memoria allocata per i dati richiesti; pertanto
+in caso di fallimento verrà restituito un puntatore nullo e si dovrà
+confrontare il valore di ritorno della funzione con ``\code{(acl\_t) NULL}''.
+
+Una volta che si siano completate le operazioni sui dati di una ACL la memoria
+allocata dovrà essere liberata esplicitamente attraverso una chiamata alla
+funzione \funcd{acl\_free}, il cui protipo è:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/acl.h}
+
+ \funcdecl{int acl\_free(void * obj\_p)}
+
+ Disalloca la memoria riservata per i dati di una ACL.
+
+ \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ se
+ \param{obj\_p} non è un puntatore valido, nel qual caso \var{errno}
+ assumerà il valore \errcode{EINVAL}
+}
+\end{functions}