\itindex{pathname} \textit{pathname} relativo.
I permessi di accesso (vedi sez.~\ref{sec:file_access_control}) con cui la
-directory viene creata sono specificati dall'argomemto \param{mode}, i cui
+directory viene creata sono specificati dall'argomento \param{mode}, i cui
possibili valori sono riportati in tab.~\ref{tab:file_permission_const}; si
tenga presente che questi sono modificati dalla maschera di creazione dei file
(si veda sez.~\ref{sec:file_perm_management}). La titolarità della nuova
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 a breve, 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.
+ 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
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 della scrittura di queste
+dispense 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{irusted extended attributes}: visibili ed
+ accessibili soltanto a processi privilegiati.
+ Vengono utilizzati per poter realizzare in user space
+ meccanismi che consentano di mantenere delle
+ informazioni sui file che non siano 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}
+
+
+Come accennato gli \textit{Extended Attributes} vengono utilizzati in forme
+diverse ed in particolare anche per la realizzazione di estensioni del
+meccanismo tradizionale dei controlli di accesso. Per questo motivo l'accesso
+agli attributi estesi è revolato in maniera diversa a seconda della loro
+classe; in particolare 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 scruttura 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
+ dotati della \index{capabilities} \textit{capability}
+ \const{CAP\_SYS\_ADMIN}.
+\item[\texttt{system}] \textit{extended system attributes}
+\item[\texttt{trusted}] \textit{trusted extended attributes}
+\item[\texttt{user}] \textit{extended user attributes}
+\end{basedescript}
+
+
+ è regolato dagli ordinari permessi dei file: occorre il
+permesso di lettura per leggerli e quello di scrittura per scriverli o
+modificarli; il permesso di esecuzione viene invece interpretato coma la
+capacità di ottenere la lista degli attributi presenti.
+
+
% sistema è nei pacchetti libxattr1-dev e attr
-\subsection{Le ACL}
+\subsection{Le \textit{Access Control List}}
\label{sec:file_ACL}
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 soddifacente.}
+ si può soddisfare in maniera soddisfacente.}
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}. 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.
+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 POSIX 1003.1e Draft 17, che è
-divenuta la base sulla quale si definiscono quelle che vanno sotto il nome di
-\textit{Posix ACL}.
+del documento, quella che va sotto il nome di \textit{POSIX 1003.1e Draft 17},
+che è divenuta la base sulla quale si definiscono quelle che vanno sotto il
+nome di \textit{Posix ACL}.
A differenza di altri sistemi (ad esempio FreeBSD) nel caso di Linux si è
-scelto di realizzare le ACL attraverso l'interfaccia degli \textit{Extended
- Attributes}, e fornire tutte le relative funzioni di gestione tramite una
-liberia, \texttt{libacl} che nasconde i dettagli implementativi delle stesse e
-presenta ai programmi una interfaccia che fa riferimento allo standard POSIX
-1003.1e.
+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.
+
+
+
+
\itindend{Access~Control~List}
Normalmente la directory radice di un processo coincide anche con la radice
del filesystem usata dal kernel, e dato che il suo valore viene ereditato dal
padre da ogni processo figlio, in generale i processi risolvono i
-\itindsub{pathname}{assoluto}\textit{pathname} assoluti a partire sempre dalla
-stessa directory, che corrisponde alla \file{/} del sistema.
+\itindsub{pathname}{assoluto} \textit{pathname} assoluti a partire sempre
+dalla stessa directory, che corrisponde alla radice del sistema.
In certe situazioni però, per motivi di sicurezza, è utile poter impedire che
un processo possa accedere a tutto il filesystem; per far questo si può
replicare all'interno della \textit{chroot jail} tutti i file (in genere
programmi e librerie) di cui il server potrebbe avere bisogno.
+
+
+
+
+
+
% LocalWords: sez like filesystem unlink MacOS Windows VMS inode kernel unistd
% LocalWords: un'etichetta int const char oldpath newpath errno EXDEV EPERM st
% LocalWords: EEXIST EMLINK EACCES ENAMETOOLONG ENOTDIR EFAULT ENOMEM EROFS ls
% LocalWords: gid Control List patch mandatory control execute group other all
% LocalWords: dell' effective passwd IGID locking swap saved text IRWXU IRWXG
% LocalWords: IRWXO ext reiser capability FSETID mask capabilities chroot jail
-% LocalWords: FTP Di filter reiserfs
+% LocalWords: FTP Di filter reiserfs Attributes Solaris Posix FreeBSD libacl
+% LocalWords: XFS SELinux namespace attribute security trusted Draft
%%% Local Variables:
%%% mode: latex
projects / gapil.git / blobdiff