+\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 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
+ in lettura che in scrittura, è consentito soltanto ai processi 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 dato che esistono
+ diversi oggetti sul filesystem per i quali è normale avere avere il permesso
+ di scrittura aperto a tutti, 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 infatti 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 nessuno è mai stato
+ capace di indicare un uso sensato degli \textit{extended user attributes}
+ per questi oggetti, o per fifo e 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
+ 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 amministratitiv della capability
+ \index{capabilities} \const{CAP\_FOWNER}.