%% License".
%%
-\chapter{File e directory}
+\chapter{La gestione di file e directory}
\label{cha:files_and_dirs}
In questo capitolo tratteremo in dettaglio le modalità con cui si gestiscono
-file e directory, iniziando dalle funzioni di libreria che si usano per
-copiarli, spostarli e cambiarne i nomi. Esamineremo poi l'interfaccia che
-permette la manipolazione dei vari attributi di file e directory ed alla fine
-prenderemo in esame la struttura di base del sistema delle protezioni e del
-controllo dell'accesso ai file e le successive estensioni (\textit{Extended
- Attributes}, ACL, quote disco, \textit{capabilities}). Tutto quello che
-riguarda invece la manipolazione del contenuto dei file è lasciato ai capitoli
-successivi.
+file e directory, iniziando da un approfondimento dell'architettura del
+sistema illustrata a grandi linee in sez.~\ref{sec:file_arch_overview} ed
+illustrando le principali caratteristiche di un filesystem e le interfacce
+che consentono di controllarne il montaggio e lo smontaggio.
+
+Esamineremo poi le funzioni di libreria che si usano per copiare, spostare e
+cambiare i nomi di file e directory e l'interfaccia che permette la
+manipolazione dei loro attributi. Tratteremo inoltre la struttura di base del
+sistema delle protezioni e del controllo dell'accesso ai file e le successive
+estensioni (\textit{Extended Attributes}, ACL, quote disco,
+\textit{capabilities}). Tutto quello che riguarda invece la gestione dell'I/O
+sui file è lasciato al capitolo successivo.
+
+
+
+\section{L'architettura della gestione dei file}
+\label{sec:file_arch_func}
+
+In questa sezione tratteremo con maggiori dettagli rispetto a quanto visto in
+sez.~\ref{sec:file_arch_overview} il \textit{Virtual File System} di Linux e
+come il kernel può gestire diversi tipi di filesystem, descrivendo prima le
+caratteristiche generali di un filesystem di un sistema unix-like, per poi
+fare una panoramica sul filesystem più usato con Linux, l'\acr{ext2} ed i suoi
+successori.
+
+
+\subsection{Il funzionamento del \textit{Virtual File System} di Linux}
+\label{sec:file_vfs_work}
+
+% NOTE articolo interessante:
+% http://www.ibm.com/developerworks/linux/library/l-virtual-filesystem-switch/index.html?ca=dgr-lnxw97Linux-VFSdth-LXdW&S_TACT=105AGX59&S_CMP=GRlnxw97
+
+\itindbeg{Virtual~File~System}
+
+Come illustrato brevemente in sez.~\ref{sec:file_arch_overview} in Linux il
+concetto di \textit{everything is a file} è stato implementato attraverso il
+\textit{Virtual File System}, la cui struttura generale è illustrata in
+fig.~\ref{fig:file_VFS_scheme}. Il VFS definisce un insieme di funzioni che
+tutti i filesystem devono implementare per l'accesso ai file che contengono e
+l'interfaccia che consente di eseguire l'I/O sui file, che questi siano di
+dati o dispositivi.
+
+\itindbeg{inode}
+
+L'interfaccia fornita dal VFS comprende in sostanza tutte le funzioni che
+riguardano i file, le operazioni implementate dal VFS sono realizzate con una
+astrazione che prevede quattro tipi di oggetti strettamente correlati: i
+filesystem, le \textit{dentry}, gli \textit{inode} ed i file. A questi oggetti
+corrispondono una serie di apposite strutture definite dal kernel che
+contengono come campi le funzioni di gestione e realizzano l'infrastruttura
+del VFS. L'interfaccia è molto complessa, ne faremo pertanto una trattazione
+estremamente semplificata che consenta di comprenderne i principi
+di funzionamento.
+
+Il VFS usa una tabella mantenuta dal kernel che contiene il nome di ciascun
+filesystem supportato, quando si vuole inserire il supporto di un nuovo
+filesystem tutto quello che occorre è chiamare la funzione
+\code{register\_filesystem} passando come argomento la struttura
+\kstruct{file\_system\_type} (la cui definizione è riportata in
+fig.~\ref{fig:kstruct_file_system_type}) relativa a quel filesystem. Questa
+verrà inserita nella tabella, ed il nuovo filesystem comparirà in
+\procfile{/proc/filesystems}.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{\textwidth}
+ \includestruct{listati/file_system_type.h}
+ \end{minipage}
+ \normalsize
+ \caption{Estratto della struttura \kstructd{file\_system\_type} usata dal
+ VFS (da \texttt{include/linux/fs.h}).}
+ \label{fig:kstruct_file_system_type}
+\end{figure}
+
+La struttura \kstruct{file\_system\_type}, oltre ad una serie di dati interni,
+come il nome del tipo di filesystem nel campo \var{name},\footnote{quello che
+ viene riportato in \procfile{/proc/filesystems} e che viene usato come
+ valore del parametro dell'opzione \texttt{-t} del comando \texttt{mount} che
+ indica il tipo di filesystem.} contiene i riferimenti alle funzioni di base
+che consentono l'utilizzo di quel filesystem. In particolare la funzione
+\code{mount} del quarto campo è quella che verrà invocata tutte le volte che
+si dovrà effettuare il montaggio di un filesystem di quel tipo. Per ogni nuovo
+filesystem si dovrà allocare una di queste strutture ed inizializzare i
+relativi campi con i dati specifici di quel filesystem, ed in particolare si
+dovrà creare anche la relativa versione della funzione \code{mount}.
+
+\itindbeg{pathname}
+
+Come illustrato in fig.~\ref{fig:kstruct_file_system_type} questa funzione
+restituisce una \textit{dentry}, abbreviazione che sta per \textit{directory
+ entry}. Le \textit{dentry} sono gli oggetti che il kernel usa per eseguire
+la \textit{pathname resolution}, ciascuna di esse corrisponde ad un
+\textit{pathname} e contiene il riferimento ad un \textit{inode}, che come
+vedremo a breve è l'oggetto usato dal kernel per identificare un un
+file.\footnote{in questo caso si parla di file come di un qualunque oggetto
+ generico che sta sul filesystem e non dell'oggetto file del VFS cui
+ accennavamo prima.} La \textit{dentry} ottenuta dalla chiamata alla funzione
+\code{mount} sarà inserita in corrispondenza al \textit{pathname} della
+directory in cui il filesystem è stato montato.
+
+% NOTA: struct dentry è dichiarata in include/linux/dcache.h
+
+Le \textit{dentry} sono oggetti del VFS che vivono esclusivamente in memoria,
+nella cosiddetta \textit{directory entry cache} (spesso chiamata in breve
+\textit{dcache}). Ogni volta che una \textit{system call} specifica un
+\textit{pathname} viene effettuata una ricerca nella \textit{dcache} per
+ottenere immediatamente la \textit{dentry} corrispondente,\footnote{il buon
+ funzionamento della \textit{dcache} è in effetti di una delle parti più
+ critiche per le prestazioni del sistema.} che a sua volta ci darà, tramite
+l'\textit{inode}, il riferimento al file.
+
+Dato che normalmente non è possibile mantenere nella \textit{dcache} le
+informazioni relative a tutto l'albero dei file la procedura della
+\textit{pathname resolution} richiede un meccanismo con cui riempire gli
+eventuali vuoti. Il meccanismo prevede che tutte le volte che si arriva ad una
+\textit{dentry} mancante venga invocata la funzione \texttt{lookup}
+dell'\textit{inode} associato alla \textit{dentry} precedente nella
+risoluzione del \textit{pathname},\footnote{che a questo punto è una
+ directory, per cui si può cercare al suo interno il nome di un file.} il cui
+scopo è risolvere il nome mancante e fornire la sua \textit{dentry} che a
+questo punto verrà inserita nella cache.
+
+Dato che tutte le volte che si monta un filesystem la funzione \texttt{mount}
+della corrispondente \kstruct{file\_system\_type} inserisce la \textit{dentry}
+iniziale nel \itindex{mount~point} \textit{mount point} dello stesso si avrà
+comunque un punto di partenza. Inoltre essendo questa \textit{dentry} relativa
+a quel tipo di filesystem essa farà riferimento ad un \textit{inode} di quel
+filesystem, e come vedremo questo farà sì che venga eseguita una
+\texttt{lookup} adatta per effettuare la risoluzione dei nomi per quel
+filesystem.
+
+\itindend{pathname}
+
+% Un secondo effetto della chiamata funzione \texttt{mount} di
+% \kstruct{file\_system\_type} è quello di allocare una struttura
+% \kstruct{super\_block} per ciascuna istanza montata, che contiene le
+% informazioni generali di un qualunque filesystem montato, come le opzioni di
+% montaggio, le dimensioni dei blocchi, quando il filesystem è stato montato
+% ecc. Fra queste però viene pure inserta, nel campo \var{s\_op}, una ulteriore
+% struttura \kstruct{super\_operations}, il cui contenuto sono i puntatori
+% alle funzioni di gestione di un filesystem, anche inizializzata in modo da
+% utilizzare le versioni specifiche di quel filesystem.
+
+L'oggetto più importante per il funzionamento del VFS è probabilmente
+l'\textit{inode}, ma con questo nome si può fare riferimento a due cose
+diverse. La prima è la struttura su disco (su cui torneremo anche in
+sez.~\ref{sec:file_filesystem}) che fa parte della organizzazione dei dati
+realizzata dal filesystem e che contiene le informazioni relative alle
+proprietà (i cosiddetti \textsl{metadati}) di ogni oggetto presente su di esso
+(si intende al solito uno qualunque dei tipi di file di
+tab.~\ref{tab:file_file_types}).
+
+La seconda è la corrispondente struttura \kstruct{inode}, della cui
+definizione si è riportato un estratto in
+fig.~\ref{fig:kstruct_inode}.\footnote{l'estratto fa riferimento alla versione
+ del kernel 2.6.37.} Questa struttura viene mantenuta in memoria ed è a
+questa che facevamo riferimento quando parlavamo dell'\textit{inode} associato
+a ciascuna \textit{dentry}. Nella struttura in memoria sono presenti gli
+stessi \textsl{metadati} memorizzati su disco, che vengono letti quando questa
+struttura viene allocata e trascritti all'indietro se modificati.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{\textwidth}
+ \includestruct{listati/inode.h}
+ \end{minipage}
+ \normalsize
+ \caption{Estratto della struttura \kstructd{inode} del kernel (da
+ \texttt{include/linux/fs.h}).}
+ \label{fig:kstruct_inode}
+\end{figure}
+
+Il fatto che la struttura \kstruct{inode} sia mantenuta in memoria,
+direttamente associata ad una \textit{dentry}, rende sostanzialmente immediate
+le operazioni che devono semplicemente effettuare un accesso ai dati in essa
+contenuti: è così ad esempio che viene realizzata la \textit{system call}
+\func{stat} che vedremo in sez.~\ref{sec:file_stat}. Rispetto ai dati salvati
+sul disco questa struttura contiene però anche quanto necessario alla
+implementazione del VFS, ed in particolare è importante il campo \var{i\_op}
+che, come illustrato in fig.~\ref{fig:kstruct_inode}, contiene il puntatore ad
+una struttura di tipo \kstruct{inode\_operation}, la cui definizione si può
+trovare nel file \texttt{include/kernel/fs.h} dei sorgenti del kernel.
+
+Questa struttura non è altro che una tabella di funzioni, ogni suo membro cioè
+è un puntatore ad una funzione e, come suggerisce il nome della struttura
+stessa, queste funzioni sono quelle che definiscono le operazioni che il VFS
+può compiere su un \textit{inode}. Si sono riportate in
+tab.~\ref{tab:file_inode_operations} le più rilevanti.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|l|}
+ \hline
+ \textbf{Funzione} & \textbf{Operazione} \\
+ \hline
+ \hline
+ \textsl{\code{create}} & Chiamata per creare un nuovo file (vedi
+ sez.~\ref{sec:file_open}).\\
+ \textsl{\code{link}} & Crea un \textit{hard link} (vedi
+ sez.~\ref{sec:file_link}).\\
+ \textsl{\code{unlink}} & Cancella un \textit{hard link} (vedi
+ sez.~\ref{sec:file_link}).\\
+ \textsl{\code{symlink}}& Crea un link simbolico (vedi
+ sez.~\ref{sec:file_symlink}).\\
+ \textsl{\code{mkdir}} & Crea una directory (vedi
+ sez.~\ref{sec:file_dir_creat_rem}).\\
+ \textsl{\code{rmdir}} & Rimuove una directory (vedi
+ sez.~\ref{sec:file_dir_creat_rem}).\\
+ \textsl{\code{mknod}} & Crea un file speciale (vedi
+ sez.~\ref{sec:file_mknod}).\\
+ \textsl{\code{rename}} & Cambia il nome di un file (vedi
+ sez.~\ref{sec:file_remove}).\\
+ \textsl{\code{lookup}}& Risolve il nome di un file.\\
+ \hline
+ \end{tabular}
+ \caption{Le principali operazioni sugli \textit{inode} definite tramite
+ \kstruct{inode\_operation}.}
+ \label{tab:file_inode_operations}
+\end{table}
+
+Possiamo notare come molte di queste funzioni abbiano nomi sostanzialmente
+identici alle varie \textit{system call} con le quali si gestiscono file e
+directory, che tratteremo nel resto del capitolo. Quello che succede è che
+tutte le volte che deve essere eseguita una \textit{system call}, o una
+qualunque altra operazione su un \textit{inode} (come \texttt{lookup}) il VFS
+andrà ad utilizzare la funzione corrispondente attraverso il puntatore
+\var{i\_op}.
+
+Sarà allora sufficiente che nella realizzazione di un filesystem si crei una
+implementazione di queste funzioni per quel filesystem e si allochi una
+opportuna istanza di \kstruct{inode\_operation} contenente i puntatori a dette
+funzioni. A quel punto le strutture \kstruct{inode} usate per gli oggetti di
+quel filesystem otterranno il puntatore alla relativa istanza di
+\kstruct{inode\_operation} e verranno automaticamente usate le funzioni
+corrette.
+
+Si noti però come in tab.~\ref{tab:file_inode_operations} non sia presente la
+funzione \texttt{open} che invece è citata in
+tab.~\ref{tab:file_file_operations}.\footnote{essa può essere comunque
+ invocata dato che nella struttura \kstruct{inode} è presente anche il
+ puntatore \func{i\_fop} alla struttura \kstruct{file\_operation} che
+ fornisce detta funzione.} Questo avviene perché su Linux l'apertura di un
+file richiede comunque un'altra operazione che mette in gioco l'omonimo
+oggetto del VFS: l'allocazione di una struttura di tipo \kstruct{file} che
+viene associata ad ogni file aperto nel sistema.
+
+I motivi per cui viene usata una struttura a parte sono diversi, anzitutto,
+come illustrato in sez.~\ref{sec:file_fd}, questa è necessaria per le
+operazioni eseguite dai processi con l'interfaccia dei file descriptor; ogni
+processo infatti mantiene il riferimento ad una struttura \kstruct{file} per
+ogni file che ha aperto, ed è tramite essa che esegue le operazioni di I/O.
+
+Inoltre se le operazioni relative agli \textit{inode} fanno riferimento ad
+oggetti posti all'interno di un filesystem e vi si applicano quindi le
+funzioni fornite nell'implementazione di quest'ultimo, quando si apre un file
+questo può essere anche un file di dispositivo, ed in questo caso il VFS
+invece di usare le operazioni fornite dal filesystem (come farebbe per un file
+di dati) dovrà invece ricorrere a quelle fornite dal driver del dispositivo.
+
+\itindend{inode}
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{\textwidth}
+ \includestruct{listati/file.h}
+ \end{minipage}
+ \normalsize
+ \caption{Estratto della struttura \kstructd{file} del kernel (da
+ \texttt{include/linux/fs.h}).}
+ \label{fig:kstruct_file}
+\end{figure}
+
+Come si può notare dall'estratto di fig.~\ref{fig:kstruct_file}, la struttura
+\kstruct{file} contiene, oltre ad alcune informazioni usate dall'interfaccia
+dei file descriptor il cui significato emergerà più avanti, il puntatore
+\struct{f\_op} ad una struttura \kstruct{file\_operation}. Questa è l'analoga
+per i file di \kstruct{inode\_operation}, e definisce le operazioni generiche
+fornite dal VFS per i file. Si sono riportate in
+tab.~\ref{tab:file_file_operations} le più significative.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|p{8cm}|}
+ \hline
+ \textbf{Funzione} & \textbf{Operazione} \\
+ \hline
+ \hline
+ \textsl{\code{open}} & Apre il file (vedi sez.~\ref{sec:file_open}).\\
+ \textsl{\code{read}} & Legge dal file (vedi sez.~\ref{sec:file_read}).\\
+ \textsl{\code{write}} & Scrive sul file (vedi
+ sez.~\ref{sec:file_write}).\\
+ \textsl{\code{llseek}} & Sposta la posizione corrente sul file (vedi
+ sez.~\ref{sec:file_lseek}).\\
+ \textsl{\code{ioctl}} & Accede alle operazioni di controllo
+ (vedi sez.~\ref{sec:file_ioctl}).\\
+ \textsl{\code{readdir}}& Legge il contenuto di una directory (vedi
+ sez.~\ref{sec:file_dir_read}).\\
+ \textsl{\code{poll}} & Usata nell'I/O multiplexing (vedi
+ sez.~\ref{sec:file_multiplexing}).\\
+ \textsl{\code{mmap}} & Mappa il file in memoria (vedi
+ sez.~\ref{sec:file_memory_map}).\\
+ \textsl{\code{release}}& Chiamata quando l'ultimo riferimento a un file
+ aperto è chiuso.\\
+ \textsl{\code{fsync}} & Sincronizza il contenuto del file (vedi
+ sez.~\ref{sec:file_sync}).\\
+ \textsl{\code{fasync}} & Abilita l'I/O asincrono (vedi
+ sez.~\ref{sec:file_asyncronous_io}) sul file.\\
+ \hline
+ \end{tabular}
+ \caption{Operazioni sui file definite tramite \kstruct{file\_operation}.}
+ \label{tab:file_file_operations}
+\end{table}
+
+Anche in questo caso tutte le volte che deve essere eseguita una
+\textit{system call} o una qualunque altra operazione sul file il VFS andrà ad
+utilizzare la funzione corrispondente attraverso il puntatore
+\var{f\_op}. Dato che è cura del VFS quando crea la struttura all'apertura del
+file assegnare a \var{f\_op} il puntatore alla versione di
+\kstruct{file\_operation} corretta per quel file, sarà possibile scrivere allo
+stesso modo sulla porta seriale come su un normale file di dati, e lavorare
+sui file allo stesso modo indipendentemente dal filesystem.
+
+Il VFS realizza la quasi totalità delle operazioni relative ai file grazie
+alle funzioni presenti nelle due strutture \kstruct{inode\_operation} e
+\kstruct{file\_operation}. Ovviamente non è detto che tutte le operazioni
+possibili siano poi disponibili in tutti i casi, ad esempio \code{llseek} non
+sarà presente per un dispositivo come la porta seriale o per una fifo, mentre
+sui file del filesystem \texttt{vfat} non saranno disponibili i permessi, ma
+resta il fatto che grazie al VFS le \textit{system call} per le operazioni sui
+file possono restare sempre le stesse nonostante le enormi differenze che
+possono esserci negli oggetti a cui si applicano.
+
+
+\itindend{Virtual~File~System}
+
+% NOTE: documentazione interessante:
+% * sorgenti del kernel: Documentation/filesystems/vfs.txt
+% * http://thecoffeedesk.com/geocities/rkfs.html
+% * http://www.linux.it/~rubini/docs/vfs/vfs.html
+
+
+
+\subsection{Il funzionamento di un filesystem Unix}
+\label{sec:file_filesystem}
+
+Come già accennato in sez.~\ref{sec:file_arch_overview} Linux (ed ogni sistema
+unix-like) organizza i dati che tiene su disco attraverso l'uso di un
+filesystem. Una delle caratteristiche di Linux rispetto agli altri Unix è
+quella di poter supportare, grazie al VFS, una enorme quantità di filesystem
+diversi, ognuno dei quali avrà una sua particolare struttura e funzionalità
+proprie. Per questo non entreremo nei dettagli di un filesystem specifico, ma
+daremo una descrizione a grandi linee che si adatta alle caratteristiche
+comuni di qualunque filesystem di un sistema unix-like.
+
+Una possibile strutturazione dell'informazione su un disco è riportata in
+fig.~\ref{fig:file_disk_filesys}, dove si hanno tre filesystem su tre
+partizioni. In essa per semplicità si è fatto riferimento alla struttura del
+filesystem \acr{ext2}, che prevede una suddivisione dei dati in \textit{block
+ group}. All'interno di ciascun \textit{block group} viene anzitutto
+replicato il cosiddetto \textit{superblock}, (la struttura che contiene
+l'indice iniziale del filesystem e che consente di accedere a tutti i dati
+sottostanti) e creata una opportuna suddivisione dei dati e delle informazioni
+per accedere agli stessi. Sulle caratteristiche di \acr{ext2} e derivati
+torneremo in sez.~\ref{sec:file_ext2}.
+
+\itindbeg{inode}
+
+È comunque caratteristica comune di tutti i filesystem per Unix,
+indipendentemente da come poi viene strutturata nei dettagli questa
+informazione, prevedere la presenza di due tipi di risorse: gli
+\textit{inode}, cui abbiamo già accennato in sez.~\ref{sec:file_vfs_work}, che
+sono le strutture che identificano i singoli oggetti sul filesystem, e i
+blocchi, che invece attengono allo spazio disco che viene messo a disposizione
+per i dati in essi contenuti.
+
+\begin{figure}[!htb]
+ \centering
+ \includegraphics[width=12cm]{img/disk_struct}
+ \caption{Organizzazione dello spazio su un disco in partizioni e
+ filesystem.}
+ \label{fig:file_disk_filesys}
+\end{figure}
+
+Se si va ad esaminare con maggiore dettaglio la strutturazione
+dell'informazione all'interno del filesystem \textsl{ext2}, tralasciando i
+dettagli relativi al funzionamento del filesystem stesso come la
+strutturazione in gruppi dei blocchi, il \textit{superblock} e tutti i dati di
+gestione possiamo esemplificare la situazione con uno schema come quello
+esposto in fig.~\ref{fig:file_filesys_detail}.
+
+\begin{figure}[!htb]
+ \centering
+ \includegraphics[width=12cm]{img/filesys_struct}
+ \caption{Strutturazione dei dati all'interno di un filesystem.}
+ \label{fig:file_filesys_detail}
+\end{figure}
+
+Da fig.~\ref{fig:file_filesys_detail} si evidenziano alcune delle
+caratteristiche di base di un filesystem, che restano le stesse anche su
+filesystem la cui organizzazione dei dati è totalmente diversa da quella
+illustrata, e sulle quali è bene porre attenzione visto che sono fondamentali
+per capire il funzionamento delle funzioni che manipolano i file e le
+directory che tratteremo nel prosieguo del capitolo. In particolare è
+opportuno tenere sempre presente che:
+
+
+\begin{enumerate}
+
+\item L'\textit{inode} contiene i cosiddetti \textsl{metadati}, vale dire le
+ informazioni riguardanti le proprietà del file come oggetto del filesystem:
+ il tipo di file, i permessi di accesso, le dimensioni, i puntatori ai
+ blocchi fisici che contengono i dati e così via. Le informazioni che la
+ funzione \func{stat} (vedi sez.~\ref{sec:file_stat}) fornisce provengono
+ dall'\textit{inode}. Dentro una directory si troverà solo il nome del file
+ e il numero dell'\textit{inode} ad esso associato; il nome non è una
+ proprietà del file e non viene mantenuto nell'\textit{inode}. Da da qui in
+ poi chiameremo il nome del file contenuto in una directory
+ ``\textsl{voce}'', come traduzione della nomenclatura inglese
+ \textit{directory entry} che non useremo per evitare confusione con le
+ \textit{dentry} del kernel viste in sez.~\ref{sec:file_vfs_work}.
+
+\item Come mostrato in fig.~\ref{fig:file_filesys_detail} per i file
+ \texttt{macro.tex} e \texttt{gapil\_macro.tex}, ci possono avere più voci
+ che fanno riferimento allo stesso \textit{inode}. Fra le proprietà di un
+ file mantenute nell'\textit{inode} c'è anche il contatore con il numero di
+ riferimenti che sono stati fatti ad esso, il cosiddetto \textit{link
+ count}.\footnote{mantenuto anche nel campo \var{i\_nlink} della struttura
+ \kstruct{inode} di fig.~\ref{fig:kstruct_inode}.} Solo quando questo
+ contatore si annulla i dati del file possono essere effettivamente rimossi
+ dal disco. Per questo la funzione per cancellare un file si chiama
+ \func{unlink} (vedi sez.~\ref{sec:file_link}), ed in realtà non cancella
+ affatto i dati del file, ma si limita ad eliminare la relativa voce da una
+ directory e decrementare il numero di riferimenti nell'\textit{inode}.
+
+\item All'interno di ogni filesystem ogni \textit{inode} è identificato da un
+ numero univoco. Il numero di \textit{inode} associato ad una voce in una
+ directory si riferisce ad questo numero e non ci può essere una directory
+ che contiene riferimenti ad \textit{inode} relativi ad altri filesystem.
+ Questa è la ragione che limita l'uso del comando \cmd{ln}, che crea una
+ nuova voce per un file esistente con la funzione \func{link} (vedi
+ sez.~\ref{sec:file_link}) a file nel filesystem corrente.
+
+\item Quando si cambia nome ad un file senza cambiare filesystem il contenuto
+ del file non viene spostato fisicamente, viene semplicemente creata una
+ nuova voce per l'\textit{inode} in questione e rimossa la precedente, questa
+ è la modalità in cui opera normalmente il comando \cmd{mv} attraverso la
+ funzione \func{rename} (vedi sez.~\ref{sec:file_remove}). Questa operazione
+ non modifica minimamente neanche l'\textit{inode} del file, dato che non si
+ opera sul file ma sulla directory che lo contiene.
+
+\item Gli \textit{inode} dei file, che contengono i \textsl{metadati}, ed i
+ blocchi di spazio disco, che contengono i dati, sono risorse indipendenti ed
+ in genere vengono gestite come tali anche dai diversi filesystem; è pertanto
+ possibile esaurire sia lo spazio disco (il caso più comune) che lo spazio
+ per gli \textit{inode}. Nel primo caso non sarà possibile allocare ulteriore
+ spazio, ma si potranno creare file (vuoti), nel secondo non si potranno
+ creare nuovi file, ma si potranno estendere quelli che ci
+ sono.\footnote{questo comportamento non è generale, alcuni filesystem
+ evoluti possono evitare il problema dell'esaurimento degli \textit{inode}
+ riallocando lo spazio disco libero per i blocchi.}
+
+\end{enumerate}
+
+\begin{figure}[!htb]
+ \centering
+ \includegraphics[width=12cm]{img/dir_links}
+ \caption{Organizzazione dei \textit{link} per le directory.}
+ \label{fig:file_dirs_link}
+\end{figure}
+
+Infine tenga presente che, essendo file pure loro, il numero di riferimenti
+esiste anche per le directory. Per questo se a partire dalla situazione
+mostrata in fig.~\ref{fig:file_filesys_detail} creiamo una nuova directory
+\file{img} nella directory \file{gapil}, avremo una situazione come quella
+illustrata in fig.~\ref{fig:file_dirs_link}.
+
+La nuova directory avrà un numero di riferimenti pari a due, in quanto è
+referenziata dalla directory da cui si era partiti (in cui è inserita la nuova
+voce che fa riferimento a \texttt{img}) e dalla voce interna ``\texttt{.}''
+che è presente in ogni directory. Questo è il valore che si troverà sempre
+per ogni directory che non contenga a sua volta altre directory. Al contempo,
+la directory da cui si era partiti avrà un numero di riferimenti di almeno
+tre, in quanto adesso sarà referenziata anche dalla voce ``\texttt{..}'' di
+\texttt{img}. L'aggiunta di una sottodirectory fa cioè crescere di uno il
+\textit{link count} della directory genitrice.
+
+\itindend{inode}
+
+
+\subsection{Alcuni dettagli sul filesystem \textsl{ext2} e successori}
+\label{sec:file_ext2}
+
+
+Benché non esista ``il'' filesystem di Linux, dato che esiste un supporto
+nativo di diversi filesystem che sono in uso da anni, quello che gli avvicina
+di più è la famiglia di filesystem evolutasi a partire dal \textit{second
+ extended filesystem}, o \acr{ext2}. Il filesystem \acr{ext2} ha subito un
+grande sviluppo e diverse evoluzioni, fra cui l'aggiunta del
+\textit{journaling} con \acr{ext3}, probabilmente ancora il filesystem più
+diffuso, ed una serie di ulteriori miglioramento con il successivo \acr{ext4},
+che sta iniziando a sostituirlo gradualmente. In futuro è previsto che questo
+debba essere sostituito da un filesystem completamente diverso, \acr{btrfs},
+che dovrebbe diventare il filesystem standard di Linux, ma questo al momento è
+ancora in fase di sviluppo.\footnote{si fa riferimento al momento dell'ultima
+ revisione di di questo paragrafo, l'inizio del 2012.}
+
+Il filesystem \acr{ext2} nasce come filesystem nativo per Linux a partire
+dalle prime versioni del kernel e supporta tutte le caratteristiche di un
+filesystem standard Unix: è in grado di gestire nomi di file lunghi (256
+caratteri, estensibili a 1012) e supporta una dimensione massima dei file fino
+a 4~Tb. I successivi filesystem \acr{ext3} ed \acr{ext4} sono evoluzioni di
+questo filesystem, e sia pure con molti miglioramenti ed estensioni
+significative ne mantengono le caratteristiche fondamentali.
+
+Oltre alle caratteristiche standard, \acr{ext2} fornisce alcune estensioni che
+non sono presenti su un classico filesystem di tipo Unix; le principali sono
+le seguenti:
+\begin{itemize}
+\item i \textit{file attributes} consentono di modificare il comportamento del
+ kernel quando agisce su gruppi di file. Possono essere impostati su file e
+ directory e in quest'ultimo caso i nuovi file creati nella directory
+ ereditano i suoi attributi.
+\item sono supportate entrambe le semantiche di BSD e SVr4 come opzioni di
+ montaggio. La semantica BSD comporta che i file in una directory sono creati
+ con lo stesso identificatore di gruppo della directory che li contiene. La
+ semantica SVr4 comporta che i file vengono creati con l'identificatore del
+ gruppo primario del processo, eccetto il caso in cui la directory ha il bit
+ di \acr{sgid} impostato (per una descrizione dettagliata del significato di
+ questi termini si veda sez.~\ref{sec:file_access_control}), nel qual caso
+ file e subdirectory ereditano sia il \ids{GID} che lo \acr{sgid}.
+\item l'amministratore può scegliere la dimensione dei blocchi del filesystem
+ in fase di creazione, a seconda delle sue esigenze: blocchi più grandi
+ permettono un accesso più veloce, ma sprecano più spazio disco.
+\item il filesystem implementa link simbolici veloci, in cui il nome del file
+ non è salvato su un blocco, ma tenuto all'interno \itindex{inode}
+ dell'\textit{inode} (evitando letture multiple e spreco di spazio), non
+ tutti i nomi però possono essere gestiti così per limiti di spazio (il
+ limite è 60 caratteri).
+\item vengono supportati i file immutabili (che possono solo essere letti) per
+ la protezione di file di configurazione sensibili, o file
+ \textit{append-only} che possono essere aperti in scrittura solo per
+ aggiungere dati (caratteristica utilizzabile per la protezione dei file di
+ log).
+\end{itemize}
+
+La struttura di \acr{ext2} è stata ispirata a quella del filesystem di BSD: un
+filesystem è composto da un insieme di blocchi, la struttura generale è quella
+riportata in fig.~\ref{fig:file_filesys_detail}, in cui la partizione è divisa
+in gruppi di blocchi.
+
+Ciascun gruppo di blocchi contiene una copia delle informazioni essenziali del
+filesystem (i \textit{superblock} sono quindi ridondati) per una maggiore
+affidabilità e possibilità di recupero in caso di corruzione del
+\textit{superblock} principale. L'utilizzo di raggruppamenti di blocchi ha
+inoltre degli effetti positivi nelle prestazioni dato che viene ridotta la
+distanza fra i dati e la tabella degli \itindex{inode} inode.
+
+\begin{figure}[!htb]
+ \centering
+ \includegraphics[width=9cm]{img/dir_struct}
+ \caption{Struttura delle directory nel \textit{second extended filesystem}.}
+ \label{fig:file_ext2_dirs}
+\end{figure}
+
+Le directory sono implementate come una \itindex{linked~list} \textit{linked
+ list} con voci di dimensione variabile. Ciascuna voce della lista contiene
+il numero di inode \itindex{inode}, la sua lunghezza, il nome del file e la sua
+lunghezza, secondo lo schema in fig.~\ref{fig:file_ext2_dirs}; in questo modo
+è possibile implementare nomi per i file anche molto lunghi (fino a 1024
+caratteri) senza sprecare spazio disco.
+
+Con l'introduzione del filesystem \textit{ext3} sono state introdotte diverse
+modifiche strutturali, la principale di queste è quella che \textit{ext3} è un
+filesystem \textit{journaled}, è cioè in grado di eseguire una registrazione
+delle operazioni di scrittura su un giornale (uno speciale file interno) in
+modo da poter garantire il ripristino della coerenza dei dati del
+filesystem\footnote{si noti bene che si è parlato di dati \textsl{del}
+ filesystem, non di dati \textsl{nel} filesystem, quello di cui viene
+ garantito un veloce ripristino è relativo ai dati della struttura interna
+ del filesystem, non di eventuali dati contenuti nei file che potrebbero
+ essere stati persi.} in brevissimo tempo in caso di interruzione improvvisa
+della corrente o di crollo del sistema che abbia causato una interruzione
+della scrittura dei dati sul disco.
+
+Oltre a questo \textit{ext3} introduce ulteriori modifiche volte a migliorare
+sia le prestazioni che la semplicità di gestione del filesystem, in
+particolare per le directory si è passato all'uso di alberi binari con
+indicizzazione tramite hash al posto delle \textit{linked list} che abbiamo
+illustrato, ottenendo un forte guadagno di prestazioni in caso di directory
+contenenti un gran numero di file.
+
+% TODO portare a ext3, ext4 e btrfs ed illustrare le problematiche che si
+% possono incontrare (in particolare quelle relative alla perdita di contenuti
+% in caso di crash del sistema)
+
+
+\subsection{La gestione dell'uso dei filesystem}
+\label{sec:sys_file_config}
+
+Come accennato in sez.~\ref{sec:file_arch_overview} per poter accedere ai file
+occorre prima rendere disponibile al sistema il filesystem su cui essi sono
+memorizzati; l'operazione di attivazione del filesystem è chiamata
+\textsl{montaggio}, per far questo in Linux si usa la funzione \funcd{mount},
+il cui prototipo è:\footnote{la funzione è una versione specifica di Linux che
+ usa la omonima \textit{system call} e non è portabile.}
+
+\begin{funcproto}{
+\fhead{sys/mount.h}
+\fdecl{mount(const char *source, const char *target, const char
+ *filesystemtype, \\
+\phantom{mount(}unsigned long mountflags, const void *data)}
+\fdesc{Monta un filesystem.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EACCES}] non si ha il permesso di accesso su uno dei
+ componenti del \itindex{pathname} \textit{pathname}, o si è cercato di
+ montare un filesystem disponibile in sola lettura senza aver specificato
+ \const{MS\_RDONLY} o il device \param{source} è su un filesystem montato
+ con l'opzione \const{MS\_NODEV}.
+ \item[\errcode{EBUSY}] \param{source} è già montato, o non può essere
+ rimontato in sola lettura perché ci sono ancora file aperti in scrittura,
+ o non può essere montato su \param{target} perché la directory è ancora in
+ uso.
+ \item[\errcode{EINVAL}] il dispositivo \param{source} presenta un
+ \textit{superblock} non valido, o si è cercato di rimontare un filesystem
+ non ancora montato, o di montarlo senza che \param{target} sia un
+ \itindex{mount~point} \textit{mount point} o di spostarlo
+ quando \param{target} non è un \itindex{mount~point} \textit{mount point}
+ o è la radice.
+ \item[\errcode{EMFILE}] la tabella dei device \textit{dummy} è piena.
+ \item[\errcode{ENODEV}] il tipo \param{filesystemtype} non esiste o non è
+ configurato nel kernel.
+ \item[\errcode{ENOTBLK}] non si è usato un \textit{block device} per
+ \param{source} quando era richiesto.
+ \item[\errcode{ENXIO}] il \itindex{major~number} \textit{major number} del
+ dispositivo \param{source} è sbagliato.
+ \item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
+ \end{errlist}
+ ed inoltre \errval{EFAULT}, \errval{ELOOP}, \errval{ENOMEM},
+ \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOTDIR} nel loro
+ significato generico.}
+\end{funcproto}
+
+La funzione monta sulla directory indicata \param{target}, detta
+\itindex{mount~point} \textit{mount point}, il filesystem contenuto nel file
+di dispositivo indicato \param{source}. In entrambi i casi, come daremo per
+assunto da qui in avanti tutte le volte che si parla di directory o file nel
+passaggio di un argomento di una funzione, si intende che questi devono essere
+indicati con la stringa contenente il loro \itindex{pathname}
+\textit{pathname}.
+
+Normalmente un filesystem è contenuto su un disco o una partizione, ma come
+illustrato in sez.~\ref{sec:file_vfs_work} la struttura del
+\itindex{Virtual~File~System} \textit{Virtual File System} è estremamente
+flessibile e può essere usata anche per oggetti diversi da un disco. Ad
+esempio usando il \textit{loop device} si può montare un file qualunque (come
+l'immagine di un CD-ROM o di un floppy) che contiene l'immagine di un
+filesystem, inoltre alcuni tipi di filesystem, come \texttt{proc} o
+\texttt{sysfs} sono virtuali e non hanno un supporto che ne contenga i dati,
+che invece sono generati al volo ad ogni lettura, e passati indietro al kernel
+ad ogni scrittura.\footnote{costituiscono quindi un meccanismo di
+ comunicazione, attraverso l'ordinaria interfaccia dei file, con il kernel.}
+
+Il tipo di filesystem che si vuole montare è specificato
+dall'argomento \param{filesystemtype}, che deve essere una delle stringhe
+riportate nel file \procfile{/proc/filesystems} che, come accennato in
+sez.~\ref{sec:file_vfs_work}, contiene l'elenco dei filesystem supportati dal
+kernel. Nel caso si sia indicato un filesystem virtuale, che non è associato a
+nessun file di dispositivo, il contenuto di \param{source} viene ignorato.
+
+L'argomento \param{data} viene usato per passare le impostazioni relative alle
+caratteristiche specifiche di ciascun filesystem. Si tratta di una stringa di
+parole chiave (separate da virgole e senza spazi) che indicano le cosiddette
+``\textsl{opzioni}'' del filesystem che devono essere impostate; in genere
+viene usato direttamente il contenuto del parametro dell'opzione \texttt{-o}
+del comando \texttt{mount}. I valori utilizzabili dipendono dal tipo di
+filesystem e ciascuno ha i suoi, pertanto si rimanda alla documentazione della
+pagina di manuale di questo comando e dei singoli filesystem.
+
+Dopo l'esecuzione della funzione il contenuto del filesystem viene resto
+disponibile nella directory specificata come \itindex{mount~point}
+\textit{mount point}, il precedente contenuto di detta directory viene
+mascherato dal contenuto della directory radice del filesystem montato. Fino
+ai kernel della serie 2.2.x non era possibile montare un filesytem se un
+\textit{mount point} era già in uso.
+
+A partire dal kernel 2.4.x inoltre è divenuto possibile sia spostare
+atomicamente un \itindex{mount~point} \textit{mount point} da una directory ad
+un'altra, sia montare lo stesso filesystem in diversi \itindex{mount~point}
+\textit{mount point}, sia montare più filesystem sullo stesso
+\itindex{mount~point} \textit{mount point} impilandoli l'uno sull'altro, nel
+qual caso vale comunque quanto detto in precedenza, e cioè che solo il
+contenuto dell'ultimo filesystem montato sarà visibile.
+
+Oltre alle opzioni specifiche di ciascun filesystem, che si passano nella
+forma delle opzioni indicata con l'argomento \param{data}, esistono pure
+alcune opzioni che si possono applicare in generale, anche se non è detto che
+tutti i filesystem le supportino, che si specificano tramite
+l'argomento \param{mountflags}. L'argomento inoltre può essere utilizzato per
+modificare il comportamento della funzione, facendole compiere una operazione
+diversa (ad esempio un rimontaggio, invece che un montaggio).
+
+In Linux \param{mountflags} deve essere un intero a 32 bit, fino ai kernel
+della serie 2.2.x i 16 più significativi avevano un valore riservato che
+doveva essere specificato obbligatoriamente,\footnote{il valore era il
+ \itindex{magic~number} \textit{magic number} \code{0xC0ED}, si può usare la
+ costante \const{MS\_MGC\_MSK} per ottenere la parte di \param{mountflags}
+ riservata al \textit{magic number}, mentre per specificarlo si può dare un
+ OR aritmetico con la costante \const{MS\_MGC\_VAL}.} oggi invece sono
+ignorati mentre i 16 meno significativi sono usati per specificare le opzioni
+come maschera binaria e vanno impostati con un OR aritmetico dei valori
+riportati nell'elenco seguente:
+
+\begin{basedescript}{\desclabelwidth{2.cm}\desclabelstyle{\nextlinelabel}}
+\itindbeg{bind~mount}
+\item[\const{MS\_BIND}] Effettua un cosiddetto \textit{bind mount}, in cui è
+ possibile montare una directory di un filesystem in un'altra directory. In
+ questo caso verranno presi in considerazione solo gli argomenti
+ \texttt{source}, che stavolta indicherà la directory che si vuole montare (e
+ non un file di dispositivo) e \texttt{target} che indicherà la directory su
+ cui verrà effettuato il \textit{bind mount}. Gli
+ argomenti \param{filesystemtype} e \param{data} vengono ignorati.
+
+ In sostanza quello che avviene è che in corrispondenza del \index{pathname}
+ \textit{pathname} indicato da \texttt{target} viene montato l'\textit{inode}
+ di \texttt{source}, così che la porzione di albero dei file presente sotto
+ \texttt{source} diventi visibile allo stesso modo sotto
+ \texttt{target}. Trattandosi esattamente di dati dello stesso filesystem,
+ ogni modifica fatta in uno qualunque dei due rami di albero sarà visibile
+ nell'altro, visto che entrambi faranno riferimento agli stessi
+ \textit{inode}.
+
+ Dal punto di vista del \itindex{Virtual~File~System} VFS l'operazione è
+ analoga al montaggio di un filesystem proprio nel fatto che anche in questo
+ caso si inserisce in corripondenza della \textit{dentry} di \texttt{target}
+ un diverso \textit{inode}, che stavolta invece di essere quello della radice
+ del filesystem indicato da un file di dispositivo è quello di una directory
+ già montata.
+
+ Si tenga presente che proprio per questo sotto \texttt{target} comparirà il
+ contenuto che è presente sotto \texttt{source} all'interno del filesystem in
+ cui quest'ultima è contenuta. Questo potrebbe non corrispondere alla
+ porzione di albero che sta sotto \texttt{source} qualora in una
+ sottodirectory di quest'ultima si fosse effettuato un altro montaggio. In
+ tal caso infatti nella porzione di albero sotto \texttt{source} si
+ troverebbe il contenuto del nuovo filesystem (o di un altro \textit{bind
+ mount}) mentre sotto \texttt{target} ci sarebbe il contenuto presente nel
+ filesystem originale.\footnote{questo evita anche il problema dei
+ \textit{loop} di fig.~\ref{fig:file_link_loop}, dato che se anche si
+ montasse su \texttt{target} una directory in cui essa è contenuta, il
+ cerchio non potrebbe chiudersi perché ritornati a \texttt{target} dentro
+ il \textit{bind mount} vi si troverebbe solo il contenuto originale e non
+ si potrebbe tornare indietro.}
+
+ Fino al kernel 2.6.26 questo flag doveva essere usato da solo, in quanto il
+ \textit{bind mount} continuava ad utilizzare le stesse opzioni del montaggio
+ originale, dal 2.6.26 è stato introdotto il supporto per il cosiddetto
+ \textit{read-only bind mount} e viene onorata la presenza del flag
+ \const{MS\_RDONLY}. In questo modo si può far sì che l'accesso ai file sotto
+ \texttt{target} possa avvenire soltanto in sola lettura.
+
+ Il supporto per il \textit{bind mount} consente di superare i limiti
+ presenti per gli \textit{hard link} (di cui parleremo in
+ sez.~\ref{sec:file_link}) e di poter far comparire una qualunque porzione
+ dell'albero dei file all'interno di una qualunque directory, anche se questa
+ sta su un filesystem diverso, fornendo una alternativa all'uso dei link
+ simbolici (di cui parleremo in sez.~\ref{sec:file_symlink}) che funziona
+ correttamente anche all'intero di un \textit{chroot} (argomento su cui
+ torneremo in sez.~\ref{sec:file_chroot}.
+
+
+\itindend{bind~mount}
+
+\item[\const{MS\_DIRSYNC}] .
+
+\item[\const{MS\_MANDLOCK}] Consente il \textit{mandatory locking}
+ \itindex{mandatory~locking} (vedi sez.~\ref{sec:file_mand_locking}).
+
+\item[\const{MS\_MOVE}] Sposta atomicamente il punto di montaggio.
+
+\item[\const{MS\_NOATIME}] Non aggiorna gli \textit{access time} (vedi
+ sez.~\ref{sec:file_file_times}).
+
+\item[\const{MS\_NODEV}] Impedisce l'accesso ai file di dispositivo.
+
+\item[\const{MS\_NODIRATIME}] Non aggiorna gli \textit{access time} delle
+ directory.
+\item[\const{MS\_NOEXEC}] Impedisce di eseguire programmi.
+
+\item[\const{MS\_NOSUID}] Ignora i bit \itindex{suid~bit} \acr{suid} e
+ \itindex{sgid~bit} \acr{sgid}.
+
+\item[\const{MS\_RDONLY}] Monta in sola lettura.
+
+\item[\const{MS\_RELATIME}] .
+
+\item[\const{MS\_REMOUNT}] Rimonta il filesystem cambiando le opzioni.
+
+\item[\const{MS\_SILENT}] .
+
+\item[\const{MS\_STRICTATIME}] .
+
+\item[\const{MS\_SYNCHRONOUS}] Abilita la scrittura sincrona.
+
+% TODO aggiornare con i nuovi flag di man mount
+% verificare i readonly mount bind del 2.6.26
+\end{basedescript}
+
+La funzione \func{mount} può essere utilizzata anche per effettuare il
+\textsl{rimontaggio} di un filesystem, cosa che permette di cambiarne al volo
+alcune delle caratteristiche di funzionamento (ad esempio passare da sola
+lettura a lettura/scrittura). Questa operazione è attivata attraverso uno dei
+bit di \param{mountflags}, \const{MS\_REMOUNT}, che se impostato specifica che
+deve essere effettuato il rimontaggio del filesystem (con le opzioni
+specificate dagli altri bit), anche in questo caso il valore di \param{source}
+viene ignorato.
+
+Una volta che non si voglia più utilizzare un certo filesystem è possibile
+\textsl{smontarlo} usando la funzione \funcd{umount}, il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/mount.h}
+\fdecl{umount(const char *target)}
+\fdesc{Smonta un filesystem.}
+}
+{La funzione ritorna $0$ in caso
+ di successo e $-1$ per un errore,
+ nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
+ \item[\errcode{EBUSY}] \param{target} è la directory di lavoro di qualche
+ processo, o contiene dei file aperti, o un altro mount point.
+\end{errlist}ed inoltre \errval{ENOTDIR}, \errval{EFAULT}, \errval{ENOMEM},
+\errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ELOOP} nel loro
+ significato generico.}
+\end{funcproto}
+
+La funzione prende il nome della directory su cui il filesystem è montato e
+non il file o il dispositivo che è stato montato,\footnote{questo è vero a
+ partire dal kernel 2.3.99-pre7, prima esistevano due chiamate separate e la
+ funzione poteva essere usata anche specificando il file di dispositivo.} in
+quanto con il kernel 2.4.x è possibile montare lo stesso dispositivo in più
+punti. Nel caso più di un filesystem sia stato montato sullo stesso
+\itindex{mount~point} \textit{mount point} viene smontato quello che è stato
+montato per ultimo.
+
+Si tenga presente che la funzione fallisce quando il filesystem è
+\textsl{occupato}, questo avviene quando ci sono ancora file aperti sul
+filesystem, se questo contiene la directory di lavoro corrente di un qualunque
+processo o il \itindex{mount~point} \textit{mount point} di un altro
+filesystem; in questo caso l'errore restituito è \errcode{EBUSY}.
+
+Linux provvede inoltre una seconda funzione, \funcd{umount2}, che in alcuni
+casi permette di forzare lo smontaggio di un filesystem, anche quando questo
+risulti occupato; il suo prototipo è:
+\begin{funcproto}{
+\fhead{sys/mount.h}
+\fdecl{umount2(const char *target, int flags)}
+\fdesc{Smonta un filesystem.}
+}
+{La funzione è identica a \func{umount} per valori di ritorno e codici di
+ errore. }
+\end{funcproto}
+
+Il valore di \param{flags} è una maschera binaria, e al momento l'unico valore
+definito è il bit \const{MNT\_FORCE}; gli altri bit devono essere nulli.
+Specificando \const{MNT\_FORCE} la funzione cercherà di liberare il filesystem
+anche se è occupato per via di una delle condizioni descritte in precedenza. A
+seconda del tipo di filesystem alcune (o tutte) possono essere superate,
+evitando l'errore di \errcode{EBUSY}. In tutti i casi prima dello smontaggio
+viene eseguita una sincronizzazione dei dati.
+
+% TODO documentare MNT_DETACH e MNT_EXPIRE ...
+
+Altre due funzioni specifiche di Linux,\footnote{esse si trovano anche su BSD,
+ ma con una struttura diversa.} utili per ottenere in maniera diretta
+informazioni riguardo al filesystem su cui si trova un certo file, sono
+\funcd{statfs} e \funcd{fstatfs}, i cui prototipi sono:
+
+\begin{funcproto}{
+\fhead{sys/vfs.h}
+\fdecl{int statfs(const char *path, struct statfs *buf)}
+\fdecl{int fstatfs(int fd, struct statfs *buf)}
+\fdesc{Restituiscono informazioni relative ad un filesystem.}
+}
+{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore,
+ nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{ENOSYS}] il filesystem su cui si trova il file specificato non
+ \end{errlist} ed inoltre \errval{EFAULT} ed \errval{EIO} per entrambe,
+ \errval{EBADF} per \func{fstatfs}, \errval{ENOTDIR}, \errval{ENAMETOOLONG},
+ \errval{ENOENT}, \errval{EACCES}, \errval{ELOOP} per \func{statfs} nel loro
+ significato generico.}
+\end{funcproto}
+
+
+Queste funzioni permettono di ottenere una serie di informazioni generali
+riguardo al filesystem su cui si trova il file specificato; queste vengono
+restituite all'indirizzo \param{buf} di una struttura \struct{statfs} definita
+come in fig.~\ref{fig:sys_statfs}, ed i campi che sono indefiniti per il
+filesystem in esame sono impostati a zero. I valori del campo \var{f\_type}
+sono definiti per i vari filesystem nei relativi file di header dei sorgenti
+del kernel da costanti del tipo \var{XXX\_SUPER\_MAGIC}, dove \var{XXX} in
+genere è il nome del filesystem stesso.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{\textwidth}
+ \includestruct{listati/statfs.h}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{statfs}.}
+ \label{fig:sys_statfs}
+\end{figure}
+
+
+Le \acr{glibc} provvedono infine una serie di funzioni per la gestione dei due
+file \conffile{/etc/fstab} ed \conffile{/etc/mtab}, che convenzionalmente sono
+usati in quasi tutti i sistemi unix-like per mantenere rispettivamente le
+informazioni riguardo ai filesystem da montare e a quelli correntemente
+montati. Le funzioni servono a leggere il contenuto di questi file in
+opportune strutture \struct{fstab} e \struct{mntent}, e, per
+\conffile{/etc/mtab} per inserire e rimuovere le voci presenti nel file.
+
+In generale si dovrebbero usare queste funzioni (in particolare quelle
+relative a \conffile{/etc/mtab}), quando si debba scrivere un programma che
+effettua il montaggio di un filesystem; in realtà in questi casi è molto più
+semplice invocare direttamente il programma \cmd{mount}, per cui ne
+tralasceremo la trattazione, rimandando al manuale delle \acr{glibc}
+\cite{glibc} per la documentazione completa.
+
+% TODO scrivere relativamente alle varie funzioni (getfsent e getmntent &C)
+% TODO documentare swapon e swapoff (man 2 ...)
+
+
Questo è possibile anche in ambiente Unix, dove tali collegamenti sono
usualmente chiamati \textit{link}; ma data l'architettura del sistema riguardo
-la gestione dei file (ed in particolare quanto trattato in
-sez.~\ref{sec:file_arch_func}) ci sono due metodi sostanzialmente diversi per
-fare questa operazione.
+la gestione dei file ci sono due metodi sostanzialmente diversi per fare
+questa operazione.
Come spiegato in sez.~\ref{sec:file_filesystem} l'accesso al contenuto di un
file su disco avviene passando attraverso il suo \itindex{inode}
errore nel qual caso \var{errno} viene impostata ai valori:
\begin{errlist}
\item[\errcode{EXDEV}] i file \param{oldpath} e \param{newpath} non fanno
- riferimento ad un filesystem montato sullo stesso \textit{mount point}.
+ riferimento ad un filesystem montato sullo stesso \itindex{mount~point}
+ \textit{mount point}.
\item[\errcode{EPERM}] il filesystem che contiene \param{oldpath} e
\param{newpath} non supporta i link diretti o è una directory.
\item[\errcode{EEXIST}] un file (o una directory) di nome \param{newpath}
con il filesystem \acr{vfat} di Windows). In realtà la funzione ha un
ulteriore requisito, e cioè che non solo che i due file siano sullo stesso
filesystem, ma anche che si faccia riferimento ad essi sullo stesso
-\textit{mount point}.\footnote{si tenga presente infatti (vedi
- sez.~\ref{sec:sys_file_config}) che a partire dal kernel 2.4 uno stesso
- filesystem può essere montato più volte su directory diverse.}
+\itindex{mount~point} \textit{mount point}.\footnote{si tenga presente infatti
+ (vedi sez.~\ref{sec:sys_file_config}) che a partire dal kernel 2.4 uno
+ stesso filesystem può essere montato più volte su directory diverse.}
La funzione inoltre opera sia sui file ordinari che sugli altri oggetti del
filesystem, con l'eccezione delle directory. In alcune versioni di Unix solo
programma \cmd{fsck} per riparare il filesystem).
Data la pericolosità di questa operazione e la disponibilità dei link
-simbolici che possono fornire la stessa funzionalità senza questi problemi,
-nel caso di Linux questa capacità è stata completamente disabilitata, e al
-tentativo di creare un link diretto ad una directory la funzione \func{link}
-restituisce l'errore \errcode{EPERM}.
+simbolici (che vedremo in sez.~\ref{sec:file_symlink}) e dei
+\itindex{bind~mount} \textit{bind mount} (già visti in
+sez.~\ref{sec:sys_file_config}) che possono fornire la stessa funzionalità
+senza questi problemi, nel caso di Linux questa capacità è stata completamente
+disabilitata, e al tentativo di creare un link diretto ad una directory la
+funzione \func{link} restituisce l'errore \errcode{EPERM}.
Un ulteriore comportamento peculiare di Linux è quello in cui si crea un
\textit{hard link} ad un link simbolico. In questo caso lo standard POSIX
kernel di sviluppo 1.3.56, ed è stato temporaneamente ripristinato anche
durante lo sviluppo della serie 2.1.x, per poi tornare al comportamento
attuale fino ad oggi (per riferimento si veda
- \href{http://lwn.net/Articles/293902}
- {\texttt{http://lwn.net/Articles/293902}}).} è stato adottato un
-comportamento che non segue più lo standard per cui l'\textit{hard link} viene
-creato rispetto al link simbolico, e non al file cui questo punta.
+ \url{http://lwn.net/Articles/293902}).} è stato adottato un comportamento
+che non segue più lo standard per cui l'\textit{hard link} viene creato
+rispetto al link simbolico, e non al file cui questo punta.
La ragione di questa differenza rispetto allo standard, presente anche in
altri sistemi unix-like, sono dovute al fatto che un link simbolico può fare
non vuota.
\item[\errcode{EBUSY}] o \param{oldpath} o \param{newpath} sono in uso da
parte di qualche processo (come directory di lavoro o come radice) o del
- sistema (come mount point).
+ sistema (come \itindex{mount~point} \textit{mount point}).
\item[\errcode{EINVAL}] \param{newpath} contiene un prefisso di
\param{oldpath} o più in generale si è cercato di creare una directory come
sotto-directory di se stessa.
\begin{errlist}
\item[\errcode{EPERM}] il filesystem non supporta la cancellazione di
directory, oppure la directory che contiene \param{dirname} ha lo
- \itindex{sticky~bit} \textit{sticky bit} impostato e l'user-ID effettivo
+ \itindex{sticky~bit} \textit{sticky bit} impostato e l'\ids{UID} effettivo
del processo non corrisponde al proprietario della directory.
\item[\errcode{EACCES}] non c'è il permesso di scrittura per la directory
che contiene la directory che si vuole cancellare, o non c'è il permesso
\type{dev\_t}, con delle dimensioni passate a 12 bit per il
\itindex{major~number} \textit{major number} e 20 bit per il
\itindex{minor~number} \textit{minor number}. La transizione però ha anche
-comportato il passaggio di \type{dev\_t} a tipo opaco, e la necessità di
-specificare il numero tramite delle opportune macro, così da non avere
-problemi di compatibilità con eventuali ulteriori estensioni.
+comportato il passaggio di \type{dev\_t} a \index{tipo!opaco} tipo opaco, e la
+necessità di specificare il numero tramite delle opportune macro, così da non
+avere problemi di compatibilità con eventuali ulteriori estensioni.
Le macro sono definite nel file \file{sys/sysmacros.h}, che viene
automaticamente incluso quando si include \file{sys/types.h}; si possono
\begin{figure}[!htb]
\footnotesize \centering
- \begin{minipage}[c]{15cm}
+ \begin{minipage}[c]{\textwidth}
\includestruct{listati/dirent.c}
\end{minipage}
\normalsize
ordina i nomi tenendo conto del numero di versione (cioè qualcosa per cui
\texttt{file10} viene comunque dopo \texttt{file4}.)
-\begin{figure}[!htb]
+\begin{figure}[!htbp]
\footnotesize \centering
- \begin{minipage}[c]{15.6cm}
+ \begin{minipage}[c]{\codesamplewidth}
\includecodesample{listati/my_ls.c}
\end{minipage}
\caption{Esempio di codice per eseguire la lista dei file contenuti in una
delle relative dimensioni. Si noti infine come si restituisca sempre 0 come
valore di ritorno per indicare una esecuzione senza errori.
-\begin{figure}[!htb]
+\begin{figure}[!htbp]
\footnotesize \centering
- \begin{minipage}[c]{15.6cm}
+ \begin{minipage}[c]{\codesamplewidth}
\includecodesample{listati/DirScan.c}
\end{minipage}
\caption{Codice della funzione di scansione di una directory contenuta nel
funzione non si può usare una stringa costante. Tutte le avvertenze riguardo
alle possibili \itindex{race~condition} \textit{race condition} date per
\func{tmpnam} continuano a valere; inoltre in alcune vecchie implementazioni
-il valore usato per sostituire le \code{XXXXXX} viene formato con il \acr{pid}
+il valore usato per sostituire le \code{XXXXXX} viene formato con il \ids{PID}
del processo più una lettera, il che mette a disposizione solo 26 possibilità
diverse per il nome del file, e rende il nome temporaneo facile da indovinare.
Per tutti questi motivi la funzione è deprecata e non dovrebbe mai essere
\begin{figure}[!htb]
\footnotesize
\centering
- \begin{minipage}[c]{15cm}
+ \begin{minipage}[c]{\textwidth}
\includestruct{listati/stat.h}
\end{minipage}
\normalsize
\textbf{Macro} & \textbf{Tipo del file} \\
\hline
\hline
- \macro{S\_ISREG(m)} & file normale.\\
- \macro{S\_ISDIR(m)} & directory.\\
- \macro{S\_ISCHR(m)} & dispositivo a caratteri.\\
- \macro{S\_ISBLK(m)} & dispositivo a blocchi.\\
- \macro{S\_ISFIFO(m)} & fifo.\\
- \macro{S\_ISLNK(m)} & link simbolico.\\
- \macro{S\_ISSOCK(m)} & socket.\\
+ \macro{S\_ISREG}\texttt{(m)} & file normale.\\
+ \macro{S\_ISDIR}\texttt{(m)} & directory.\\
+ \macro{S\_ISCHR}\texttt{(m)} & dispositivo a caratteri.\\
+ \macro{S\_ISBLK}\texttt{(m)} & dispositivo a blocchi.\\
+ \macro{S\_ISFIFO}\texttt{(m)} & fifo.\\
+ \macro{S\_ISLNK}\texttt{(m)} & link simbolico.\\
+ \macro{S\_ISSOCK}\texttt{(m)} & socket.\\
\hline
\end{tabular}
\caption{Macro per i tipi di file (definite in \texttt{sys/stat.h}).}
\begin{figure}[!htb]
\footnotesize \centering
- \begin{minipage}[c]{15cm}
+ \begin{minipage}[c]{\textwidth}
\includestruct{listati/utimbuf.h}
\end{minipage}
\normalsize
\begin{figure}[!htb]
\footnotesize \centering
- \begin{minipage}[c]{15cm}
+ \begin{minipage}[c]{\textwidth}
\includestruct{listati/timeval.h}
\end{minipage}
\normalsize
\begin{figure}[!htb]
\footnotesize \centering
- \begin{minipage}[c]{15cm}
+ \begin{minipage}[c]{\textwidth}
\includestruct{listati/timespec.h}
\end{minipage}
\normalsize
Ad ogni file Linux associa sempre l'utente che ne è proprietario (il
cosiddetto \textit{owner}) ed un gruppo di appartenenza, secondo il meccanismo
-degli identificatori di utente e gruppo (\acr{uid} e \acr{gid}). Questi valori
+degli identificatori di utente e gruppo (\ids{UID} e \ids{GID}). Questi valori
sono accessibili da programma tramite la funzione \func{stat}, e sono
mantenuti nei campi \var{st\_uid} e \var{st\_gid} della struttura
\struct{stat} (si veda sez.~\ref{sec:file_stat}).\footnote{questo è vero solo
La procedura con cui il kernel stabilisce se un processo possiede un certo
permesso (di lettura, scrittura o esecuzione) si basa sul confronto fra
l'utente e il gruppo a cui il file appartiene (i valori di \var{st\_uid} e
-\var{st\_gid} accennati in precedenza) e l'user-ID effettivo, il group-ID
-effettivo e gli eventuali group-ID supplementari del processo.\footnote{in
+\var{st\_gid} accennati in precedenza) e l'\ids{UID} effettivo, il \ids{GID}
+effettivo e gli eventuali \ids{GID} supplementari del processo.\footnote{in
realtà Linux, per quanto riguarda l'accesso ai file, utilizza gli
identificatori del gruppo \textit{filesystem} (si ricordi quanto esposto in
sez.~\ref{sec:proc_perms}), ma essendo questi del tutto equivalenti ai primi,
Per una spiegazione dettagliata degli identificatori associati ai processi si
veda sez.~\ref{sec:proc_perms}; normalmente, a parte quanto vedremo in
-sez.~\ref{sec:file_special_perm}, l'user-ID effettivo e il group-ID effettivo
-corrispondono ai valori dell'\acr{uid} e del \acr{gid} dell'utente che ha
-lanciato il processo, mentre i group-ID supplementari sono quelli dei gruppi
+sez.~\ref{sec:file_special_perm}, l'\ids{UID} effettivo e il \ids{GID} effettivo
+corrispondono ai valori dell'\ids{UID} e del \ids{GID} dell'utente che ha
+lanciato il processo, mentre i \ids{GID} supplementari sono quelli dei gruppi
cui l'utente appartiene.
I passi attraverso i quali viene stabilito se il processo possiede il diritto
di accesso sono i seguenti:
\begin{enumerate}
-\item Se l'user-ID effettivo del processo è zero (corrispondente
+\item Se l'\ids{UID} effettivo del processo è zero (corrispondente
all'amministratore) l'accesso è sempre garantito senza nessun ulteriore
controllo. Per questo motivo \textsl{root} ha piena libertà di accesso a
tutti i file.
-\item Se l'user-ID effettivo del processo è uguale all'\acr{uid} del
+\item Se l'\ids{UID} effettivo del processo è uguale all'\ids{UID} del
proprietario del file (nel qual caso si dice che il processo è proprietario
del file) allora:
\begin{itemize*}
impostato, l'accesso è consentito
\item altrimenti l'accesso è negato
\end{itemize*}
-\item Se il group-ID effettivo del processo o uno dei group-ID supplementari
- dei processi corrispondono al \acr{gid} del file allora:
+\item Se il \ids{GID} effettivo del processo o uno dei \ids{GID} supplementari
+ dei processi corrispondono al \ids{GID} del file allora:
\begin{itemize*}
\item se il bit dei permessi d'accesso del gruppo è impostato, l'accesso è
consentito,
Se però il file del programma (che ovviamente deve essere
eseguibile\footnote{per motivi di sicurezza il kernel ignora i bit \acr{suid}
e \acr{sgid} per gli script eseguibili.}) ha il bit \acr{suid} impostato, il
-kernel assegnerà come user-ID effettivo al nuovo processo l'\acr{uid} del
-proprietario del file al posto dell'\acr{uid} del processo originario. Avere
-il bit \acr{sgid} impostato ha lo stesso effetto sul group-ID effettivo del
+kernel assegnerà come \ids{UID} effettivo al nuovo processo l'\ids{UID} del
+proprietario del file al posto dell'\ids{UID} del processo originario. Avere
+il bit \acr{sgid} impostato ha lo stesso effetto sul \ids{GID} effettivo del
processo.
I bit \acr{suid} e \acr{sgid} vengono usati per permettere agli utenti normali
\label{sec:file_perm_management}
Come visto in sez.~\ref{sec:file_access_control} il controllo di accesso ad un
-file viene fatto utilizzando l'user-ID ed il group-ID effettivo del processo;
-ci sono casi però in cui si può voler effettuare il controllo con l'user-ID
-reale ed il group-ID reale, vale a dire usando i valori di \acr{uid} e
-\acr{gid} relativi all'utente che ha lanciato il programma, e che, come
+file viene fatto utilizzando l'\ids{UID} ed il \ids{GID} effettivo del processo;
+ci sono casi però in cui si può voler effettuare il controllo con l'\ids{UID}
+reale ed il \ids{GID} reale, vale a dire usando i valori di \ids{UID} e
+\ids{GID} relativi all'utente che ha lanciato il programma, e che, come
accennato in sez.~\ref{sec:file_special_perm} e spiegato in dettaglio in
sez.~\ref{sec:proc_perms}, non è detto siano uguali a quelli effettivi.
\bodydesc{Le funzioni restituiscono zero in caso di successo e -1 per
un errore, in caso di errore \var{errno} può assumere i valori:
\begin{errlist}
- \item[\errcode{EPERM}] l'user-ID effettivo non corrisponde a quello del
+ \item[\errcode{EPERM}] l'\ids{UID} effettivo non corrisponde a quello del
proprietario del file o non è zero.
\item[\errcode{EROFS}] il file è su un filesystem in sola lettura.
\end{errlist}
Il cambiamento dei permessi di un file eseguito attraverso queste funzioni ha
comunque alcune limitazioni, previste per motivi di sicurezza. L'uso delle
-funzioni infatti è possibile solo se l'user-ID effettivo del processo
+funzioni infatti è possibile solo se l'\ids{UID} effettivo del processo
corrisponde a quello del proprietario del file o dell'amministratore,
altrimenti esse falliranno con un errore di \errcode{EPERM}.
in particolare accade che:
\begin{enumerate}
\item siccome solo l'amministratore può impostare lo \itindex{sticky~bit}
- \textit{sticky bit}, se l'user-ID effettivo del processo non è zero esso
+ \textit{sticky bit}, se l'\ids{UID} effettivo del processo non è zero esso
viene automaticamente cancellato (senza notifica di errore) qualora sia
stato indicato in \param{mode}.
\item per quanto detto in sez.~\ref{sec:file_ownership_management} riguardo la
un file appartenente ad un gruppo per cui non si hanno diritti, questo viene
automaticamente cancellato da \param{mode} (senza notifica di errore)
qualora il gruppo del file non corrisponda a quelli associati al processo
- (la cosa non avviene quando l'user-ID effettivo del processo è zero).
+ (la cosa non avviene quando l'\ids{UID} effettivo del processo è zero).
\end{enumerate}
Per alcuni filesystem\footnote{i filesystem più comuni (\textsl{ext2},
per la creazione di nuove directory (procedimento descritto in
sez.~\ref{sec:file_dir_creat_rem}).
-Lo standard POSIX prescrive che l'\acr{uid} del nuovo file corrisponda
-all'user-ID effettivo del processo che lo crea; per il \acr{gid} invece prevede
-due diverse possibilità:
+Lo standard POSIX prescrive che l'\ids{UID} del nuovo file corrisponda
+all'\ids{UID} effettivo del processo che lo crea; per il \ids{GID} invece
+prevede due diverse possibilità:
\begin{itemize*}
-\item il \acr{gid} del file corrisponde al group-ID effettivo del processo.
-\item il \acr{gid} del file corrisponde al \acr{gid} della directory in cui
+\item il \ids{GID} del file corrisponde al \ids{GID} effettivo del processo.
+\item il \ids{GID} del file corrisponde al \ids{GID} della directory in cui
esso è creato.
\end{itemize*}
in genere BSD usa sempre la seconda possibilità, che viene per questo chiamata
semantica BSD. Linux invece segue quella che viene chiamata semantica SVr4; di
norma cioè il nuovo file viene creato, seguendo la prima opzione, con il
-\acr{gid} del processo, se però la directory in cui viene creato il file ha il
+\ids{GID} del processo, se però la directory in cui viene creato il file ha il
bit \acr{sgid} impostato allora viene usata la seconda opzione.
-Usare la semantica BSD ha il vantaggio che il \acr{gid} viene sempre
+Usare la semantica BSD ha il vantaggio che il \ids{GID} viene sempre
automaticamente propagato, restando coerente a quello della directory di
partenza, in tutte le sotto-directory.
directory venga anche propagato anche il bit \acr{sgid}. Questo è il
comportamento predefinito del comando \cmd{mkdir}, ed è in questo modo ad
esempio che le varie distribuzioni assicurano che le sotto-directory create
-nella home di un utente restino sempre con il \acr{gid} del gruppo primario
+nella home di un utente restino sempre con il \ids{GID} del gruppo primario
dello stesso.
La presenza del bit \acr{sgid} è inoltre molto comoda quando si hanno
\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 per un
errore, nel qual caso caso \var{errno} assumerà i valori:
\begin{errlist}
- \item[\errcode{EPERM}] l'user-ID effettivo non corrisponde a quello del
+ \item[\errcode{EPERM}] l'\ids{UID} effettivo non corrisponde a quello del
proprietario del file o non è zero, o utente e gruppo non sono validi
\end{errlist}
Oltre a questi entrambe restituiscono gli errori \errval{EROFS} e
sez.~\ref{sec:proc_capabilities}.\\
\texttt{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
+ file come le \itindex{Access~Control~List~(ACL)} ACL (vedi
sez.~\ref{sec:file_ACL}) o le \itindex{capabilities}
\textit{capabilities} (vedi
sez.~\ref{sec:proc_capabilities}).\\
Dato che uno degli usi degli \textit{Extended Attributes} è quello che li
-impiega per realizzare delle estensioni (come le \itindex{Access~Control~List}
-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:
+impiega per realizzare delle estensioni (come le
+\itindex{Access~Control~List~(ACL)} 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{1.7cm}\desclabelstyle{\nextlinelabel}}
\item[\texttt{security}] L'accesso agli \textit{extended security attributes}
dipende dalle politiche di sicurezza stabilite da loro stessi tramite
\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 \itindex{Access~Control~List} 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.}
+ delle \itindex{Access~Control~List~(ACL)} 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
% la documentazione di sistema è nei pacchetti libacl1-dev e acl
% vedi anche http://www.suse.de/~agruen/acl/linux-acls/online/
-\itindbeg{Access~Control~List}
+\itindbeg{Access~Control~List~(ACL)}
Il modello classico dei permessi di Unix, per quanto funzionale ed efficiente,
è comunque piuttosto limitato e per quanto possa aver coperto per lunghi anni
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
+\item Se l'\ids{UID} del processo è nullo l'accesso è sempre garantito senza
nessun controllo.
-\item Se l'user-ID del processo corrisponde al proprietario del file allora:
+\item Se l'\ids{UID} 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
+\item Se l'\ids{UID} 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
consentito;
\item altrimenti l'accesso è negato.
\end{itemize*}
-\item Se è il group-ID del processo o uno dei group-ID supplementari
+\item Se è il \ids{GID} del processo o uno dei \ids{GID} supplementari
corrisponde al gruppo proprietario del file allora:
\begin{itemize*}
\item se la voce \const{ACL\_GROUP\_OBJ} e una eventuale voce
l'accesso è consentito;
\item altrimenti l'accesso è negato.
\end{itemize*}
-\item Se è il group-ID del processo o uno dei group-ID supplementari
+\item Se è il \ids{GID} del processo o uno dei \ids{GID} supplementari
corrisponde ad un qualunque qualificatore presente in una voce
\const{ACL\_GROUP} allora:
\begin{itemize*}
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}''.
+Si tenga presente che pur essendo \type{acl\_t} un \index{tipo!opaco} 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
\hline
\const{TEXT\_ABBREVIATE} & stampa le voci in forma abbreviata.\\
\const{TEXT\_NUMERIC\_IDS} & non effettua la risoluzione numerica di
- user-ID e group-ID.\\
+ \ids{UID} e \ids{GID}.\\
\const{TEXT\_SOME\_EFFECTIVE}& per ciascuna voce che contiene permessi che
vengono eliminati dalla \const{ACL\_MASK}
viene generato un commento con i permessi
ad un altra con \funcd{acl\_copy\_entry} o eliminare una voce da una ACL con
\funcd{acl\_delete\_entry}.
-\itindend{Access~Control~List}
+\itindend{Access~Control~List~(ACL)}
\subsection{La gestione delle quote disco}
con il supporto delle quote abilitato; esso deve essere specificato con il
nome del file di dispositivo nell'argomento \param{dev}. Per le operazioni che
lo richiedono inoltre si dovrà indicare con l'argomento \param{id} l'utente o
-il gruppo (specificati rispettivamente per \acr{uid} e \acr{gid}) su cui si
+il gruppo (specificati rispettivamente per \ids{UID} e \ids{GID}) su cui si
vuole operare. Alcune operazioni usano l'argomento \param{addr} per indicare
un indirizzo ad un area di memoria il cui utilizzo dipende dall'operazione
stessa.
\hline
\const{QFMT\_VFS\_OLD}& il vecchio (ed obsoleto) formato delle quote.\\
\const{QFMT\_VFS\_V0} & la versione 0 usata dal VFS di Linux (supporta
- \acr{uid} e \acr{gid} a 32 bit e limiti fino a
+ \ids{UID} e \ids{GID} a 32 bit e limiti fino a
$2^{42}$ byte e $2^{32}$ file.\\
\const{QFMT\_VFS\_V1} & la versione 1 usata dal VFS di Linux (supporta
- \acr{uid} e \acr{GID} a 32 bit e limiti fino a
+ \ids{UID} e \ids{GID} a 32 bit e limiti fino a
$2^{64}$ byte e $2^{64}$ file.\\
\hline
\end{tabular}
\begin{figure}[!htb]
\footnotesize \centering
- \begin{minipage}[c]{15cm}
+ \begin{minipage}[c]{\textwidth}
\includestruct{listati/dqblk.h}
\end{minipage}
\normalsize
\begin{figure}[!htb]
\footnotesize \centering
- \begin{minipage}[c]{15cm}
+ \begin{minipage}[c]{\textwidth}
\includestruct{listati/dqinfo.h}
\end{minipage}
\normalsize
visionabile a partire dall'indirizzo indicato nella sezione
\textit{Repository}.}
-\begin{figure}[!htb]
+\begin{figure}[!htbp]
\footnotesize \centering
- \begin{minipage}[c]{15.6cm}
+ \begin{minipage}[c]{\codesamplewidth}
\includecodesample{listati/get_quota.c}
\end{minipage}
\caption{Esempio di codice per ottenere i dati delle quote.}
\textit{inode}. In caso di errore (\texttt{\small 13--15}) si usa un'altra
funzione dell'interfaccia per passare il valore di \var{errno} come eccezione.
-\begin{figure}[!htb]
+\begin{figure}[!htbp]
\footnotesize \centering
- \begin{minipage}[c]{15.6cm}
+ \begin{minipage}[c]{\codesamplewidth}
\includecodesample{listati/set_block_quota.c}
\end{minipage}
\caption{Esempio di codice per impostare i limiti sullo spazio disco.}
Per i kernel fino al 2.6.25, o se non si attiva il supporto per le
\textit{file capabilities}, il \textit{capabilities bounding set} è un
parametro generale di sistema, il cui valore viene riportato nel file
-\procfile{/proc/sys/kernel/cap-bound}. Il suo valore iniziale è definito in
+\sysctlfile{kernel/cap-bound}. Il suo valore iniziale è definito in
sede di compilazione del kernel, e da sempre ha previsto come default la
presenza di tutte le \textit{capabilities} eccetto \const{CAP\_SETPCAP}. In
questa situazione solo il primo processo eseguito nel sistema (quello con
Con il kernel 2.6.25 e le \textit{file capabilities} il \textit{bounding set}
è diventato una proprietà di ciascun processo, che viene propagata invariata
sia attraverso una \func{fork} che una \func{exec}. In questo caso il file
-\procfile{/proc/sys/kernel/cap-bound} non esiste e \texttt{init} non ha nessun
+\sysctlfile{kernel/cap-bound} non esiste e \texttt{init} non ha nessun
ruolo speciale, inoltre in questo caso all'avvio il valore iniziale prevede la
presenza di tutte le capacità (compresa \const{CAP\_SETPCAP}).
comunque modificato e resta lo stesso sia attraverso una \func{fork} che
attraverso una \func{exec}.
-\begin{figure}[!htb]
+\begin{figure}[!htbp]
\footnotesize \centering
\begin{minipage}[c]{12cm}
\includecodesnip{listati/cap-results.c}
privilegi originali dal processo.
Per questo motivo se un programma senza \textit{capabilities} assegnate viene
-eseguito da un processo con \textit{real user-ID} 0, esso verrà trattato come
+eseguito da un processo con \ids{UID} reale 0, esso verrà trattato come
se tanto il \textit{permitted set} che l'\textit{inheritable set} fossero con
tutte le \textit{capabilities} abilitate, con l'\textit{effective set} attivo,
col risultato di fornire comunque al processo tutte le capacità presenti nel
riesce così a riottenere il comportamento classico di un sistema unix-like.
Una seconda circostanza è quella relativa a cosa succede alle
-\textit{capabilities} di un processo nelle possibili transizioni da
-\textit{user-ID} nullo a \textit{user-ID} non nullo o viceversa (corrispondenti
-rispettivamente a cedere o riottenere i i privilegi di amministratore) che si
-possono effettuare con le varie funzioni viste in
-sez.~\ref{sec:proc_setuid}. In questo caso la casistica è di nuovo alquanto
-complessa, considerata anche la presenza dei diversi gruppi di identificatori
-illustrati in tab.~\ref{tab:proc_uid_gid}, si avrà allora che:
+\textit{capabilities} di un processo nelle possibili transizioni da \ids{UID}
+nullo a \ids{UID} non nullo o viceversa (corrispondenti rispettivamente a
+cedere o riottenere i i privilegi di amministratore) che si possono effettuare
+con le varie funzioni viste in sez.~\ref{sec:proc_setuid}. In questo caso la
+casistica è di nuovo alquanto complessa, considerata anche la presenza dei
+diversi gruppi di identificatori illustrati in tab.~\ref{tab:proc_uid_gid}, si
+avrà allora che:
\begin{enumerate*}
-\item se si passa da \textit{effective user-ID} nullo a non nullo
+\item se si passa da \ids{UID} effettivo nullo a non nullo
l'\textit{effective set} del processo viene totalmente azzerato, se
- viceversa si passa da \textit{effective user-ID} non nullo a nullo il
+ viceversa si passa da \ids{UID} effettivo non nullo a nullo il
\textit{permitted set} viene copiato nell'\textit{effective set};
-\item se si passa da \textit{file system user-ID} nullo a non nullo verranno
+\item se si passa da \textit{file system} \ids{UID} nullo a non nullo verranno
cancellate dall'\textit{effective set} del processo tutte le capacità
attinenti i file, e cioè \const{CAP\_LINUX\_IMMUTABLE}, \const{CAP\_MKNOD},
\const{CAP\_DAC\_OVERRIDE}, \const{CAP\_DAC\_READ\_SEARCH},
Per questo motivo a partire dal kernel 2.6.26, se le \textit{file
capabilities} sono abilitate, ad ogni processo viene stata associata una
-ulteriore maschera binaria, chiamata \textit{securebits flags}, il cui sono
+ulteriore maschera binaria, chiamata \textit{securebits flags}, su cui sono
mantenuti una serie di flag (vedi tab.~\ref{tab:securebits_values}) il cui
valore consente di modificare queste regole speciali che si applicano ai
-processi con \textit{user-ID} nullo. La maschera viene sempre mantenuta
+processi con \ids{UID} nullo. La maschera viene sempre mantenuta
attraverso una \func{fork}, mentre attraverso una \func{exec} viene sempre
cancellato il flag \const{SECURE\_KEEP\_CAPS}.
\hline
\const{SECURE\_KEEP\_CAPS}& Il processo non subisce la cancellazione delle
sue \textit{capabilities} quando tutti i suoi
- \textit{user-ID} passano ad un valore non
+ \ids{UID} passano ad un valore non
nullo (regola di compatibilità per il cambio
- di \textit{user-ID} n. 3 del precedente
+ di \ids{UID} n.~3 del precedente
elenco), sostituisce il precedente uso
dell'operazione \const{PR\_SET\_KEEPCAPS} di
\func{prctl}.\\
\const{SECURE\_NO\_SETUID\_FIXUP}&Il processo non subisce le modifiche
delle sue \textit{capabilities} nel passaggio
- da nullo a non nullo degli \textit{user-ID}
+ da nullo a non nullo degli \ids{UID}
dei gruppi \textit{effective} e
\textit{file system} (regole di compatibilità
- per il cambio di \textit{user-ID} nn. 1 e 2 del
+ per il cambio di \ids{UID} nn.~1 e 2 del
precedente elenco).\\
\const{SECURE\_NOROOT} & Il processo non assume nessuna capacità
aggiuntiva quando esegue un programma, anche
- se ha \textit{user-ID} nullo o il programma ha
+ se ha \ids{UID} nullo o il programma ha
il \acr{suid} bit attivo ed appartiene
all'amministratore (regola di compatibilità
per l'esecuzione di programmi senza
\begin{table}[!h!btp]
\centering
\footnotesize
- \begin{tabular}{|l|p{11.9cm}|}
+ \begin{tabular}{|l|p{10.5cm}|}
\hline
\textbf{Capacità}&\textbf{Descrizione}\\
\hline
intercomunicazione fra processi (vedi
sez.~\ref{sec:ipc_sysv}).\\
\const{CAP\_LEASE} & La capacità di creare dei \textit{file lease}
- \index{file!lease} (vedi
+ \itindex{file~lease} (vedi
sez.~\ref{sec:file_asyncronous_lease})
pur non essendo proprietari del file (dal kernel
2.4).\\
La prima fra le capacità ``\textsl{ampie}'' che occorre dettagliare
maggiormente è \const{CAP\_FOWNER}, che rimuove le restrizioni poste ad un
processo che non ha la proprietà di un file in un vasto campo di
-operazioni;\footnote{vale a dire la richiesta che l'user-ID effettivo del
- processo (o meglio il \textit{filesystem user-ID}, vedi
+operazioni;\footnote{vale a dire la richiesta che l'\ids{UID} effettivo del
+ processo (o meglio l'\ids{UID} di filesystem, vedi
sez.~\ref{sec:proc_setuid}) coincida con quello del proprietario.} queste
comprendono i cambiamenti dei permessi e dei tempi del file (vedi
sez.~\ref{sec:file_perm_management} e sez.~\ref{sec:file_file_times}), le
-impostazioni degli attributi estesi e delle ACL (vedi
-sez.~\ref{sec:file_xattr} e \ref{sec:file_ACL}), poter ignorare lo
+impostazioni degli attributi dei file (vedi sez.~\ref{sec:file_ioctl}) e delle
+ACL (vedi sez.~\ref{sec:file_xattr} e \ref{sec:file_ACL}), poter ignorare lo
\itindex{sticky~bit} \textit{sticky bit} nella cancellazione dei file (vedi
sez.~\ref{sec:file_special_perm}), la possibilità di impostare il flag di
\const{O\_NOATIME} con \func{open} e \func{fcntl} (vedi
sez.~\ref{sec:sys_file_config}), effettuare operazioni di controllo su
qualunque oggetto dell'IPC di SysV (vedi sez.~\ref{sec:ipc_sysv}), operare
sugli attributi estesi dei file di classe \texttt{security} o \texttt{trusted}
-(vedi sez.~\ref{sec:file_xattr}), specificare un \textit{user-ID} arbitrario
+(vedi sez.~\ref{sec:file_xattr}), specificare un \ids{UID} arbitrario
nella trasmissione delle credenziali dei socket (vedi
sez.~\ref{sec:socket_credential_xxx}), assegnare classi privilegiate
(\const{IOPRIO\_CLASS\_RT} e prima del kernel 2.6.25 anche
\const{IOPRIO\_CLASS\_IDLE}) per lo scheduling dell'I/O (vedi
sez.~\ref{sec:io_priority}), superare il limite di sistema sul numero massimo
-di file aperti,\footnote{quello indicato da \procfile{/proc/sys/fs/file-max}.}
+di file aperti,\footnote{quello indicato da \sysctlfile{fs/file-max}.}
effettuare operazioni privilegiate sulle chiavi mantenute dal kernel (vedi
sez.~\ref{sec:keyctl_management}), usare la funzione \func{lookup\_dcookie},
-usare \const{CLONE\_NEWNS} con \func{unshare}, (vedi
+usare \const{CLONE\_NEWNS} con \func{unshare} e \func{clone}, (vedi
sez.~\ref{sec:process_clone}).
Originariamente \const{CAP\_SYS\_NICE} riguardava soltanto la capacità di
numero di processi, ed i limiti sulle dimensioni dei messaggi delle code del
SysV IPC (vedi sez.~\ref{sec:ipc_sysv_mq}).
-
Per la gestione delle \textit{capabilities} il kernel mette a disposizione due
funzioni che permettono rispettivamente di leggere ed impostare i valori dei
tre insiemi illustrati in precedenza. Queste due funzioni sono \funcd{capget}
\end{errlist}
ed inoltre \errval{EFAULT} ed \errval{EINVAL}.
}
-
\end{functions}
Queste due funzioni prendono come argomenti due tipi di dati dedicati,
\begin{figure}[!htb]
\footnotesize
\centering
- \begin{minipage}[c]{15cm}
+ \begin{minipage}[c]{\textwidth}
\includestruct{listati/cap_user_header_t.h}
\end{minipage}
\normalsize
programma le utilizza si dovrà indicare esplicitamente l'uso della suddetta
libreria attraverso l'opzione \texttt{-lcap} del compilatore.
-Le funzioni dell'interfaccia delle bozze di POSIX.1e prevedono l'uso di uno
-tipo di dato opaco, \type{cap\_t}, come puntatore ai dati mantenuti nel
-cosiddetto \textit{capability state},\footnote{si tratta in sostanza di un
- puntatore ad una struttura interna utilizzata dalle librerie, i cui campi
- non devono mai essere acceduti direttamente.} in sono memorizzati tutti i
-dati delle \textit{capabilities}. In questo modo è possibile mascherare i
-dettagli della gestione di basso livello, che potranno essere modificati senza
-dover cambiare le funzioni dell'interfaccia, che faranno riferimento soltanto
-ad oggetti di questo tipo. L'interfaccia pertanto non soltanto fornisce le
-funzioni per modificare e leggere le \textit{capabilities}, ma anche quelle
-per gestire i dati attraverso \type{cap\_t}.
+Le funzioni dell'interfaccia delle bozze di POSIX.1e prevedono l'uso di un
+\index{tipo!opaco} tipo di dato opaco, \type{cap\_t}, come puntatore ai dati
+mantenuti nel cosiddetto \textit{capability state},\footnote{si tratta in
+ sostanza di un puntatore ad una struttura interna utilizzata dalle librerie,
+ i cui campi non devono mai essere acceduti direttamente.} in sono
+memorizzati tutti i dati delle \textit{capabilities}. In questo modo è
+possibile mascherare i dettagli della gestione di basso livello, che potranno
+essere modificati senza dover cambiare le funzioni dell'interfaccia, che
+faranno riferimento soltanto ad oggetti di questo tipo. L'interfaccia
+pertanto non soltanto fornisce le funzioni per modificare e leggere le
+\textit{capabilities}, ma anche quelle per gestire i dati attraverso
+\type{cap\_t}.
La prima funzione dell'interfaccia è quella che permette di inizializzare un
\textit{capability state}, allocando al contempo la memoria necessaria per i
definizione che si trova in \texttt{/usr/include/sys/capability.h}.} uno dei
valori illustrati in tab.~\ref{tab:cap_set_identifier}.
-Si possono inoltre confrontare in maniera diretta due \textit{capability
- state} con la funzione \funcd{cap\_compare}; il suo prototipo è:
+Si possono inoltre confrontare in maniera diretta due diversi
+\textit{capability state} con la funzione \funcd{cap\_compare}; il suo
+prototipo è:
\begin{functions}
\headdecl{sys/capability.h}
\funcdecl{int cap\_compare(cap\_t cap\_a, cap\_t cap\_b)}
Per semplificare la gestione delle \textit{capabilities} l'interfaccia prevede
che sia possibile utilizzare anche una rappresentazione testuale del contenuto
-di un \textit{capability state} e fornisce le opportune funzioni di gestione;
-la prima di queste, che consente di ottenere la rappresentazione testuale, è
-\funcd{cap\_to\_text}, il cui prototipo è:
+di un \textit{capability state} e fornisce le opportune funzioni di
+gestione;\footnote{entrambe erano previste dalla bozza dello standard
+ POSIX.1e.} la prima di queste, che consente di ottenere la rappresentazione
+testuale, è \funcd{cap\_to\_text}, il cui prototipo è:
\begin{functions}
\headdecl{sys/capability.h}
nomi di tab.~\ref{tab:proc_capabilities} separati da virgole, seguito da un
operatore, e dall'indicazione degli insiemi a cui l'operazione si applica. I
nomi delle capacità possono essere scritti sia maiuscoli che minuscoli, viene
-inoltre riconosciuto il nome speciale \texttt{all} che è equivalmente a
+inoltre riconosciuto il nome speciale \texttt{all} che è equivalente a
scrivere la lista completa. Gli insiemi sono identificati dalle tre lettere
iniziali: ``\texttt{p}'' per il \textit{permitted}, ``\texttt{i}'' per
l'\textit{inheritable} ed ``\texttt{e}'' per l'\textit{effective} che devono
anche essere combinati nella stessa proposizione, per aggiungere e togliere le
capacità dell'elenco da insiemi diversi.
-La assegnazione si applica invece su tutti gli insiemi allo stesso tempo,
+L'assegnazione si applica invece su tutti gli insiemi allo stesso tempo,
pertanto l'uso di ``\texttt{=}'' è equivalente alla cancellazione preventiva
di tutte le capacità ed alla impostazione di quelle elencate negli insiemi
-specificati, pertanto in genere lo si usa una sola volta all'inizio della
-stringa. In tal caso l'elenco delle capacità può non essere indicato e viene
-assunto che si stia facendo riferimento a tutte quante senza doverlo scrivere
-esplicitamente.
+specificati, questo significa che in genere lo si usa una sola volta
+all'inizio della stringa. In tal caso l'elenco delle capacità può non essere
+indicato e viene assunto che si stia facendo riferimento a tutte quante senza
+doverlo scrivere esplicitamente.
Come esempi avremo allora che un processo non privilegiato di un utente, che
non ha nessuna capacità attiva, avrà una rappresentazione nella forma
``\texttt{=}'' che corrisponde al fatto che nessuna capacità viene assegnata a
nessun insieme (vale la cancellazione preventiva), mentre un processo con
privilegi di amministratore avrà una rappresentazione nella forma
-``\texttt{=ep}'' in cui tutte le capacità vengono assegnati agli insiemi
-\textit{permitted} ed \textit{effective} (l' \textit{inheritable} è ignorato
+``\texttt{=ep}'' in cui tutte le capacità vengono assegnate agli insiemi
+\textit{permitted} ed \textit{effective} (e l'\textit{inheritable} è ignorato
in quanto per le regole viste a pag.~\ref{sec:capability-uid-transition} le
-capacità verranno attivate attraverso una \func{exec}). Infine, come esempio
-meno banale, otterremo per \texttt{init} una rappresentazione nella forma
-``\texttt{=ep cap\_setpcap-e}'' dato che come accennato tradizionalmente
-\const{CAP\_SETPCAP} è sempre stata rimossa da detto processo.
+capacità verranno comunque attivate attraverso una \func{exec}). Infine, come
+esempio meno banale dei precedenti, otterremo per \texttt{init} una
+rappresentazione nella forma ``\texttt{=ep cap\_setpcap-e}'' dato che come
+accennato tradizionalmente \const{CAP\_SETPCAP} è sempre stata rimossa da
+detto processo.
+
+Viceversa per passare ottenere un \textit{capability state} dalla sua
+rappresentazione testuale si può usare \funcd{cap\_from\_text}, il cui
+prototipo è:
+\begin{functions}
+ \headdecl{sys/capability.h}
+
+ \funcdecl{cap\_t cap\_from\_text(const char *string)}
+
+ Crea un \textit{capability state} dalla sua rappresentazione testuale.
+
+ \bodydesc{La funzione ritorna un puntatore valido in caso di successo e
+ \val{NULL} in caso di errore, nel qual caso \var{errno} può assumere i
+ valori \errval{EINVAL} o \errval{ENOMEM}.}
+\end{functions}
+
+La funzione restituisce il puntatore ad un \textit{capability state}
+inizializzato con i valori indicati nella stringa \param{string} che ne
+contiene la rappresentazione testuale. La memoria per il \textit{capability
+ state} viene allocata automaticamente dalla funzione e dovrà essere liberata
+con \func{cap\_free}.
+
+Alle due funzioni citate se ne aggiungono altre due che consentono di
+convertire i valori delle costanti di tab.~\ref{tab:proc_capabilities} nelle
+stringhe usate nelle rispettive rappresentazioni e viceversa. Le due funzioni,
+\func{cap\_to\_name} e \func{cap\_from\_name}, sono estensioni specifiche di
+Linux ed i rispettivi prototipi sono:
+\begin{functions}
+ \headdecl{sys/capability.h}
+
+ \funcdecl{char * cap\_to\_name(cap\_value\_t cap)}
+ \funcdecl{int cap\_from\_name(const char *name, cap\_value\_t *cap\_p)}
+ Convertono le \textit{capabilities} dalle costanti alla rappresentazione
+ testuale e viceversa.
+
+ \bodydesc{La funzione \func{cap\_to\_name} ritorna un valore diverso da
+ \val{NULL} in caso di successo e \val{NULL} in caso di errore, mentre
+ \func{cap\_to\_name} ritorna rispettivamente 0 e $-1$; per entrambe in
+ caso di errore \var{errno} può assumere i valori \errval{EINVAL} o
+ \errval{ENOMEM}. }
+\end{functions}
+
+La prima funzione restituisce la stringa (allocata automaticamente e che dovrà
+essere liberata con \func{cap\_free}) che corrisponde al valore della
+capacità \param{cap}, mentre la seconda restituisce nella variabile puntata
+da \param{cap\_p} il valore della capacità rappresentata dalla
+stringa \param{name}.
Fin quei abbiamo trattato solo le funzioni di servizio relative alla
-manipolazione dei \textit{capability state}; l'interfaccia di gestione prevede
-però anche le funzioni per la gestione delle \textit{capabilities} stesse. La
-prima di queste è \funcd{cap\_get\_proc} che consente la lettura delle
-\textit{capabilities} del processo corrente, il suo prototipo è:
+manipolazione dei \textit{capability state} come strutture di dati;
+l'interfaccia di gestione prevede però anche le funzioni per trattare le
+\textit{capabilities} presenti nei processi. La prima di queste funzioni è
+\funcd{cap\_get\_proc} che consente la lettura delle \textit{capabilities} del
+processo corrente, il suo prototipo è:
\begin{functions}
\headdecl{sys/capability.h}
dalla riga di comando.} o tramite l'opzione \texttt{-p}, quelle di un
processo qualunque il cui pid viene passato come parametro dell'opzione.
-\begin{figure}[htb]
+\begin{figure}[!htbp]
\footnotesize \centering
- \begin{minipage}[c]{15cm}
+ \begin{minipage}[c]{\codesamplewidth}
\includecodesample{listati/getcap.c}
\end{minipage}
\normalsize
-\subsection{La funzione \func{chroot}}
+\subsection{La gestione dei {chroot}}
\label{sec:file_chroot}
% TODO introdurre nuova sezione sulle funzionalità di sicurezza avanzate, con
programma ad una sezione limitata del filesystem, per cui ne parleremo in
questa sezione.
+% TODO riferimenti ai bind mount, link simbolici ecc.
+
Come accennato in sez.~\ref{sec:proc_fork} ogni processo oltre ad una
directory di lavoro, ha anche una directory \textsl{radice}\footnote{entrambe
sono contenute in due campi (rispettivamente \var{pwd} e \var{root}) di
\struct{fs\_struct}; vedi fig.~\ref{fig:proc_task_struct}.} che, pur essendo
di norma corrispondente alla radice dell'albero di file e directory come visto
-dal kernel (ed illustrato in sez.~\ref{sec:file_organization}), ha per il
-processo il significato specifico di directory rispetto alla quale vengono
-risolti i \itindsub{pathname}{assoluto}\textit{pathname}
-assoluti.\footnote{cioè quando un processo chiede la risoluzione di un
- \textit{pathname}, il kernel usa sempre questa directory come punto di
- partenza.} Il fatto che questo valore sia specificato per ogni processo apre
-allora la possibilità di modificare le modalità di risoluzione dei
-\textit{pathname} assoluti da parte di un processo cambiando questa directory,
-così come si fa coi \itindsub{pathname}{relativo}\textit{pathname} relativi
-cambiando la directory di lavoro.
+dal kernel (ed illustrato in sez.~\ref{sec:file_pathname}), ha per il processo
+il significato specifico di directory rispetto alla quale vengono risolti i
+\itindsub{pathname}{assoluto}\textit{pathname} assoluti.\footnote{cioè quando
+ un processo chiede la risoluzione di un \textit{pathname}, il kernel usa
+ sempre questa directory come punto di partenza.} Il fatto che questo valore
+sia specificato per ogni processo apre allora la possibilità di modificare le
+modalità di risoluzione dei \textit{pathname} assoluti da parte di un processo
+cambiando questa directory, così come si fa coi
+\itindsub{pathname}{relativo}\textit{pathname} relativi cambiando la directory
+di lavoro.
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
\bodydesc{La funzione restituisce zero in caso di successo e -1 per
un errore, in caso di errore \var{errno} può assumere i valori:
\begin{errlist}
- \item[\errcode{EPERM}] l'user-ID effettivo del processo non è zero.
+ \item[\errcode{EPERM}] l'\ids{UID} effettivo del processo non è zero.
\end{errlist}
ed inoltre \errval{EFAULT}, \errval{ENAMETOOLONG}, \errval{ENOENT},
\errval{ENOMEM}, \errval{ENOTDIR}, \errval{EACCES}, \errval{ELOOP};
% LocalWords: ptrace accounting NICE RESOURCE TTY CONFIG hangup vhangup dell'
% LocalWords: LEASE lease SETFCAP AUDIT permitted inherited inheritable AND nn
% LocalWords: bounding execve fork capget capset header hdrp datap ESRCH undef
-% LocalWords: version libcap lcap clear ncap caps pag capgetp CapInh CapPrm
+% LocalWords: version libcap lcap clear ncap caps pag capgetp CapInh CapPrm RT
% LocalWords: fffffeff CapEff getcap scheduling lookup dqinfo SETINFO GETFMT
% LocalWords: NEWNS unshare nice NUMA ioctl journaling close XOPEN fdopendir
% LocalWords: btrfs mkostemp extN ReiserFS JFS Posix usrquota grpquota EDQUOT
% LocalWords: forced allowed sendmail SYSLOG WAKE ALARM CLOCK BOOTTIME dqstats
% LocalWords: REALTIME securebits GETSTATS QFMT curspace curinodes btime itime
% LocalWords: QIF BLIMITS bhardlimit bsoftlimit ILIMITS ihardlimit isoftlimit
-% LocalWords: INODES LIMITS USAGE valid dqi IIF BGRACE bgrace IGRACE igrace
+% LocalWords: INODES LIMITS USAGE valid dqi IIF BGRACE bgrace IGRACE igrace is
% LocalWords: Python Truelite Srl quotamodule Repository who nell' dall' KEEP
-% LocalWords: SECURE KEEPCAPS prctl FIXUP NOROOT LOCKED dell'IPC dell'I
+% LocalWords: SECURE KEEPCAPS prctl FIXUP NOROOT LOCKED dell'IPC dell'I IOPRIO
+% LocalWords: CAPBSET CLASS IDLE dcookie overflow DIFFERS Virtual everything
+% LocalWords: dentry register resolution cache dcache operation llseek poll
+% LocalWords: multiplexing fsync fasync seek block superblock gapil tex img
+% LocalWords: second linked journaled source filesystemtype unsigned device
+% LocalWords: mountflags NODEV ENXIO dummy devfs magic MGC RDONLY NOSUID MOVE
+% LocalWords: NOEXEC SYNCHRONOUS REMOUNT MANDLOCK NODIRATIME umount MNT statfs
+% LocalWords: fstatfs fstab mntent ino bound orig new setpcap metadati sysfs
%%% Local Variables:
%%% mode: latex