%% filedir.tex
%%
-%% Copyright (C) 2000-2011 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2012 Simone Piccardi. Permission is granted to
%% copy, distribute and/or modify this document under the terms of the GNU Free
%% Documentation License, Version 1.1 or any later version published by the
%% Free Software Foundation; with the Invariant Sections being "Un preambolo",
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 ed esamineremo 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 manipolazione del
-contenuto dei file è lasciato ai capitoli successivi.
+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.
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
-trattare in maniera un po' più dettagliata il filesystem più usato con Linux,
-l'\acr{ext2} (e derivati).
+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}
-% articolo interessante:
+% 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}
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. L'interfaccia comprende tutte le
-funzioni che riguardano i file e le operazioni sono suddivise su tre tipi di
-oggetti: \textit{filesystem}, \itindex{inode} \textit{inode} e \textit{file},
-corrispondenti a tre apposite strutture definite nel kernel.
+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 supportato, quando si vuole inserire il supporto di un nuovo
filesystem tutto quello che occorre è chiamare la funzione
-\code{register\_filesystem} passandole un'apposita struttura
-\code{file\_system\_type} che contiene i dettagli per il riferimento
-all'implementazione del medesimo, che sarà aggiunta alla citata tabella.
-
-In questo modo quando viene effettuata la richiesta di montare un nuovo disco
-o di qualunque altro dispositivo che può contenere un filesystem, il VFS può
-ricavare dalla citata tabella il puntatore alle funzioni da chiamare nelle
-operazioni di montaggio. Queste sono responsabili inizializzare tutte le
-variabili interne e restituire uno speciale descrittore dei filesystem montati
-al VFS; attraverso quest'ultimo diventa possibile accedere alle funzioni
-specifiche per l'uso di quel filesystem.
-
-Il primo oggetto usato dal VFS è il descrittore di filesystem (o
-\textit{filesystem descriptor}), un puntatore ad una apposita struttura che
-contiene vari dati come le informazioni comuni ad ogni filesystem, i dati
-privati relativi a quel filesystem specifico, e i puntatori alle funzioni del
-kernel relative al filesystem. Il VFS può così usare le funzioni contenute nel
-\textit{filesystem descriptor} per accedere alle funzioni specifiche di quel
+\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.
-Gli altri due descrittori usati dal VFS sono relativi agli altri due oggetti
-su cui è strutturata l'interfaccia. Ciascuno di essi contiene le informazioni
-relative al file in uso, insieme ai puntatori alle funzioni dello specifico
-filesystem usate per l'accesso dal VFS. In particolare il descrittore
-\itindex{inode} dell'\textit{inode} contiene i puntatori alle funzioni che
-possono essere usate su qualunque file (come \func{link}, \func{stat} e
-\func{open}), mentre il descrittore di file contiene i puntatori alle funzioni
-che vengono usate sui file già aperti.
-
-La funzione più importante implementata dal VFS è la \textit{system call}
-\func{open} che permette di aprire un file. Dato un \itindex{pathname}
-\textit{pathname} viene eseguita una ricerca dentro la \textit{directory entry
- cache} (in breve \textit{dcache}), una tabella che contiene tutte le
-\textit{directory entry} (in breve \textit{dentry}) che permette di associare
-in maniera rapida ed efficiente il \textit{pathname} a una specifica
-\textit{dentry}.
-
-Una singola \textit{dentry} contiene in genere il puntatore ad un
-\itindex{inode} \textit{inode}; quest'ultimo è la struttura base che sta sul
-disco e che identifica un singolo oggetto del VFS sia esso un file ordinario,
-una directory, un link simbolico, una FIFO, un file di
-\index{file!di~dispositivo} dispositivo, o una qualsiasi altra cosa che possa
-essere rappresentata dal VFS (i tipi di file riportati in
-tab.~\ref{tab:file_file_types}). A ciascuno di essi è associata pure una
-struttura che sta in memoria, e che, oltre alle informazioni sullo specifico
-file, contiene anche il riferimento alle funzioni (i \textsl{metodi} del VFS)
-da usare per poterlo manipolare.
-
-Le \textit{dentry} ``vivono'' in memoria e non vengono mai salvate su disco,
-vengono usate per motivi di velocità, gli \itindex{inode} \textit{inode} invece
-stanno su disco e vengono copiati in memoria quando serve, ed ogni cambiamento
-viene copiato all'indietro sul disco (aggiornando i cosiddetti
-\textsl{metadati} del file), gli \itindex{inode} inode che stanno in memoria
-sono \itindex{inode} inode del VFS ed è ad essi che puntano le singole
-\textit{dentry}.
-
-La \textit{dcache} costituisce perciò una sorta di vista completa di tutto
-l'albero dei file, ovviamente per non riempire tutta la memoria questa vista è
-parziale (la \textit{dcache} cioè contiene solo le \textit{dentry} per i file
-per i quali è stato richiesto l'accesso), quando si vuole risolvere un nuovo
-\itindex{pathname} \textit{pathname} il VFS deve creare una nuova
-\textit{dentry} e caricare \itindex{inode} l'inode corrispondente in memoria.
-
-Questo procedimento viene eseguito dal metodo \code{lookup()} \itindex{inode}
-dell'inode della directory che contiene il file; questo viene installato nelle
-relative strutture in memoria quando si effettua il montaggio lo specifico
-filesystem su cui l'inode va a vivere.
-
-Una volta che il VFS ha a disposizione la \textit{dentry} (ed il relativo
-\textit{inode}) diventa possibile accedere alle varie operazioni sul file come
-la \func{open} per aprire il file o la \func{stat} per leggere i dati
-\itindex{inode} dell'inode e passarli in user space.
-
-L'apertura di un file richiede comunque un'altra operazione, l'allocazione di
-una struttura di tipo \struct{file} in cui viene inserito un puntatore alla
-\textit{dentry} e una struttura \struct{f\_ops} che contiene i puntatori ai
-metodi che implementano le operazioni disponibili sul file. In questo modo i
-processi in \textit{user space} possono accedere alle operazioni attraverso
-detti metodi, che saranno diversi a seconda del tipo di file (o dispositivo)
-aperto (su questo torneremo in dettaglio in sez.~\ref{sec:file_fd}). Un elenco
-delle operazioni previste dal kernel è riportato in
-tab.~\ref{tab:file_file_operations}.
+\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
sez.~\ref{sec:file_asyncronous_io}) sul file.\\
\hline
\end{tabular}
- \caption{Operazioni sui file definite nel VFS.}
+ \caption{Operazioni sui file definite tramite \kstruct{file\_operation}.}
\label{tab:file_file_operations}
\end{table}
-In questo modo per ciascun file diventano possibili una serie di operazioni
-(non è detto che tutte siano disponibili), che costituiscono l'interfaccia
-astratta del VFS. Qualora se ne voglia eseguire una, il kernel andrà ad
-utilizzare l'opportuna funzione dichiarata in \struct{f\_ops} appropriata al
-tipo di file in questione.
-
-Pertanto è possibile scrivere allo stesso modo sulla porta seriale come su un
-normale file di dati; ovviamente certe operazioni (nel caso della seriale ad
-esempio la \code{seek}) non saranno disponibili, però con questo sistema
-l'utilizzo di diversi filesystem (come quelli usati da Windows o MacOS) è
-immediato e relativamente trasparente per l'utente ed il programmatore.
+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}
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 ha una sua particolare struttura e funzionalità
-proprie. Per questo per il momento 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.
-
-Lo spazio fisico di un disco viene usualmente diviso in partizioni; ogni
-partizione può contenere un filesystem. La strutturazione tipica
-dell'informazione su un disco è riportata in fig.~\ref{fig:file_disk_filesys},
-in essa si fa riferimento alla struttura del filesystem \acr{ext2}, che
-prevede una separazione dei dati in \textit{block group} che replicano il
-cosiddetto \textit{superblock} (ma sulle caratteristiche di \acr{ext2} e
-derivati torneremo in sez.~\ref{sec:file_ext2}). È comunque caratteristica
-comune di tutti i filesystem per Unix, indipendentemente da come poi viene
-strutturata nei dettagli questa informazione, prevedere una divisione fra la
-lista degli \itindex{inode} inode e lo spazio a disposizione per i dati e le
-directory.
+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 \itindex{superblock} \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=14cm]{img/disk_struct}
+ \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 singolo filesystem (tralasciando i dettagli
-relativi al funzionamento del filesystem stesso come la strutturazione in
-gruppi dei blocchi, il superblock e tutti i dati di gestione) possiamo
-esemplificare la situazione con uno schema come quello esposto in
+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 \itindex{superblock}
+\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=14cm]{img/filesys_struct}
+ \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, 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 prossimo capitolo; in
-particolare è opportuno ricordare sempre che:
+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} \itindex{inode} contiene tutte le informazioni (i
- cosiddetti \textsl{metadati}) riguardanti il file: 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}
- fornisce provengono dall'\textit{inode}; dentro una directory si troverà
- solo il nome del file e il numero \itindex{inode} dell'\textit{inode} ad esso
- associato, cioè quella che da qui in poi chiameremo una \textsl{voce} (come
- traduzione dell'inglese \textit{directory entry}, che non useremo anche per
- evitare confusione con le \textit{dentry} del kernel di cui si parlava in
- sez.~\ref{sec:file_vfs_work}).
+\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} si possono avere più
- voci che puntano allo stesso \textit{inode}. Ogni \textit{inode} ha un
- contatore che contiene il numero di riferimenti che sono stati fatti ad esso
- (il cosiddetto \textit{link count}); solo quando questo contatore si annulla
- i dati del file vengono effettivamente rimossi dal disco. Per questo la
- funzione per cancellare un file si chiama \func{unlink}, 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 \itindex{inode}
- nell'\textit{inode}.
+\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 Il numero di \textit{inode} nella voce si riferisce ad un \textit{inode}
- nello stesso filesystem e non ci può essere una directory che contiene
- riferimenti ad \itindex{inode} \textit{inode} relativi ad altri filesystem.
- Questo limita l'uso del comando \cmd{ln} (che crea una nuova voce per un
- file esistente con la funzione \func{link}) al filesystem corrente.
+\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
+\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 \itindex{inode} l'\textit{inode} in questione e rimossa la
- vecchia (questa è la modalità in cui opera normalmente il comando \cmd{mv}
- attraverso la funzione \func{rename}). Questa operazione non modifica
- minimamente neanche l'\textit{inode} del file dato che non si opera su
- questo ma sulla directory che lo contiene.
+ 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
+\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 sia esaurire lo spazio disco (caso più comune) che lo spazio per
- gli \textit{inode}, nel primo caso non sarà possibile allocare ulteriore
+ 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.
+ 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}
-Infine si noti che, essendo file pure loro, il numero di riferimenti esiste
-anche per le directory; per cui, 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 in
-fig.~\ref{fig:file_dirs_link}, dove per chiarezza abbiamo aggiunto dei numeri
-di \itindex{inode} inode.
-
\begin{figure}[!htb]
\centering
- \includegraphics[width=14cm]{img/dir_links}
+ \includegraphics[width=12cm]{img/dir_links}
\caption{Organizzazione dei \textit{link} per le directory.}
\label{fig:file_dirs_link}
\end{figure}
-La nuova directory avrà allora 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 ``\texttt{.}'' che
-è sempre inserita in ogni directory; questo vale 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}.
+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.
-\subsection{I filesystem di uso comune}
+\itindend{inode}
+
+
+\subsection{Alcuni dettagli sul filesystem \textsl{ext2} e successori}
\label{sec:file_ext2}
-Il filesystem standard più usato con Linux è il cosiddetto \textit{third
- extended filesystem}, identificato dalla sigla \acr{ext3}.\footnote{si fa
- riferimento al momento della stesura di questo paragrafo, l'inizio del
- 2010.} Esso nasce come evoluzione del precedente \textit{second extended
- filesystem}, o \acr{ext2}, di cui eredita gran parte delle caratteristiche
-di base, per questo motivo parleremo anzitutto di questo, dato che molto di
-quanto diremo si applica anche ad \acr{ext3}. A partire dal kernel 2.6.XX è
-stato dichiarato stabile il nuovo filsesystem \textit{ext4}, ulteriore
-evoluzione di \textit{ext3} dotato di molte caratteristiche avanzate, che sta
-iniziando a sostituirlo gradualmente.
-
-Il filesystem \acr{ext2} nasce come filesystem nativo di 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 in sostanza le caratteristiche fondamentali.
+
+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
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 \acr{gid} che lo \acr{sgid}.
+ 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).
+ 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'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).
+ 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
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.\footnote{non si confonda questa definizione con
- quella riportata in fig.~\ref{fig:file_dirent_struct}; in quel caso si fa
- riferimento alla struttura usata in user space per riportare i dati
- contenuti in una directory generica, questa fa riferimento alla struttura
- usata dal kernel per un filesystem \acr{ext2}, definita nel file
- \texttt{ext2\_fs.h} nella directory \texttt{include/linux} dei sorgenti del
- kernel.}
+in gruppi di blocchi.
Ciascun gruppo di blocchi contiene una copia delle informazioni essenziali del
-filesystem (superblock e descrittore del filesystem sono quindi ridondati) per
-una maggiore affidabilità e possibilità di recupero in caso di corruzione del
-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.
+filesystem (i \itindex{superblock} \textit{superblock} sono quindi ridondati)
+per una maggiore affidabilità e possibilità di recupero in caso di corruzione
+del \itindex{superblock} \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 extented filesystem}.}
+ \caption{Struttura delle directory nel \textit{second extended filesystem}.}
\label{fig:file_ext2_dirs}
\end{figure}
è 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 anche
-alcune modifiche strutturali, la principale di queste è quella che
-\textit{ext3} è un filesystem \textit{jounrnaled}, è 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}
+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
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}, ottenendo un
-forte guadagno di prestazioni in caso di directory contenenti un gran numero
-di file.
+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 dei filesystem}
+\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\footnote{la funzione è specifica
- di Linux e non è portabile.} si usa la funzione \funcd{mount} il cui
-prototipo è:
-\begin{prototype}{sys/mount.h}
-{mount(const char *source, const char *target, const char *filesystemtype,
- unsigned long mountflags, const void *data)}
+\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.}
+}
-Monta il filesystem di tipo \param{filesystemtype} contenuto in \param{source}
-sulla directory \param{target}.
-
- \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di
- fallimento, nel qual caso gli errori comuni a tutti i filesystem che possono
- essere restituiti in \var{errno} sono:
+{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{ENODEV}] \param{filesystemtype} non esiste o non è configurato
- nel kernel.
+ \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
+ \itindex{superblock} \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{ELOOP}] si è cercato di spostare un \itindex{mount~point}
+ \textit{mount point} su una sottodirectory di \param{source} o si sono
+ incontrati troppi link simolici nella risoluzione di un nome.
+ \item[\errcode{EMFILE}] in caso di filesystem virtuale, la tabella dei
+ dispositivi fittizi (chiamati \textit{dummy} nella documentazione inglese)
+ è 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{EBUSY}] \param{source} è già montato, o non può essere
- rimontato in read-only perché ci sono ancora file aperti in scrittura, o
- \param{target} è ancora in uso.
- \item[\errcode{EINVAL}] il device \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
- \textit{mount point} o di spostarlo quando \param{target} non è un
- \textit{mount point} o è \file{/}.
- \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 averlo
- specificato o il device \param{source} è su un filesystem montato con
- l'opzione \const{MS\_NODEV}.
\item[\errcode{ENXIO}] il \itindex{major~number} \textit{major number} del
- device \param{source} è sbagliato.
- \item[\errcode{EMFILE}] la tabella dei device \textit{dummy} è piena.
- \end{errlist}
- ed inoltre \errval{ENOTDIR}, \errval{EFAULT}, \errval{ENOMEM},
- \errval{ENAMETOOLONG}, \errval{ENOENT} o \errval{ELOOP}.}
-\end{prototype}
-
-La funzione monta sulla directory \param{target}, detta \textit{mount point},
-il filesystem contenuto in \param{source}. In generale un filesystem è
-contenuto su un disco, e l'operazione di montaggio corrisponde a rendere
-visibile al sistema il contenuto del suddetto disco, identificato attraverso
-il file di dispositivo ad esso associato.
-
-Ma la struttura del \textit{Virtual File System} vista in
-sez.~\ref{sec:file_vfs_work} è molto più 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 un filesystem, inoltre alcuni filesystem, come \file{proc} o
-\file{devfs} sono del tutto virtuali, i loro dati sono generati al volo ad
-ogni lettura, e passati al kernel ad ogni scrittura.
-
-Il tipo di filesystem è specificato da \param{filesystemtype}, che deve essere
-una delle stringhe riportate nel file \procfile{/proc/filesystems}, che
-contiene l'elenco dei filesystem supportati dal kernel; nel caso si sia
-indicato uno dei filesystem virtuali, il contenuto di \param{source} viene
-ignorato.
+ dispositivo \param{source} è sbagliato.
+ \item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
+ \end{errlist}
+ ed inoltre \errval{EFAULT}, \errval{ENOMEM}, \errval{ENAMETOOLONG},
+ \errval{ENOENT}, \errval{ENOTDIR} nel loro significato generico.}
+\end{funcproto}
+
+La funzione monta sulla directory indicata da \param{target}, detta
+\itindex{mount~point} \textit{mount point}, il filesystem contenuto nel file
+di dispositivo indicato da \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 \textit{mount point}, il
-precedente contenuto di detta directory viene mascherato dal contenuto della
-directory radice del filesystem montato.
-
-Dal kernel 2.4.x inoltre è divenuto possibile sia spostare atomicamente un
-\textit{mount point} da una directory ad un'altra, sia montare in diversi
-\textit{mount point} lo stesso filesystem, sia montare più filesystem sullo
-stesso \textit{mount point} (nel qual caso vale quanto appena detto, e solo il
-contenuto dell'ultimo filesystem montato sarà visibile).
-
-Ciascun filesystem è dotato di caratteristiche specifiche che possono essere
-attivate o meno, alcune di queste sono generali (anche se non è detto siano
-disponibili in ogni filesystem), e vengono specificate come opzioni di
-montaggio con l'argomento \param{mountflags}.
-
-In Linux \param{mountflags} deve essere un intero a 32 bit i cui 16 più
-significativi sono un \textit{magic number}\footnote{cioè un numero speciale
- usato come identificativo, che nel caso è \code{0xC0ED}; si può usare la
+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 della lista di parole chiave 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 i 16 meno significativi sono
-usati per specificare le opzioni; essi sono usati come maschera binaria e
-vanno impostati con un OR aritmetico della costante \const{MS\_MGC\_VAL} con i
-valori riportati in tab.~\ref{tab:sys_mount_flags}.
+ riservata al \textit{magic number}, mentre per specificarlo si può dare un
+ OR aritmetico con la costante \const{MS\_MGC\_VAL}.} e si potevano usare
+solo i 16 meno significativi. Oggi invece, con un numero di opzioni superiore,
+sono utilizzati tutti e 32 i bit, ma qualora nei 16 più significativi sia
+presente detto valore, che non esprime una combinazione valida, esso viene
+ignorato. Il valore dell'argomento deve essere espresso come maschera binaria
+e i vari bit devono essere impostati con un OR aritmetico dei rispettivi flag,
+identificati dalle costanti riportate 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,
+ l'opzione è disponibile a partire dai kernel della serie 2.4. In questo caso
+ verranno presi in considerazione solo gli argomenti \param{source}, che
+ stavolta indicherà la directory che si vuole montare (e non un file di
+ dispositivo) e \param{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 \param{target} viene montato l'\textit{inode}
+ di \param{source}, così che la porzione di albero dei file presente sotto
+ \param{source} diventi visibile allo stesso modo sotto
+ \param{target}. Trattandosi esattamente dei 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 \param{target} comparirà il
+ contenuto che è presente sotto \param{source} all'interno del filesystem in
+ cui quest'ultima è contenuta. Questo potrebbe non corrispondere alla
+ porzione di albero che sta sotto \param{source} qualora in una
+ sottodirectory di quest'ultima si fosse effettuato un altro montaggio. In
+ tal caso infatti nella porzione di albero sotto \param{source} si troverebbe
+ il contenuto del nuovo filesystem (o di un altro \textit{bind mount}) mentre
+ sotto \param{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
+ \param{target} una directory in cui essa è contenuta, il cerchio non
+ potrebbe chiudersi perché ritornati a \param{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 ottiene che l'accesso ai file sotto
+ \param{target} sia effettuabile esclusivamente 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}) ottenendo un qualcosa di analogo in cui si può
+ fare riferimento alla porzione dell'albero dei file di un filesystem
+ presente a partire da una certa directory utilizzando una qualunque altra
+ directory, anche se questa sta su un filesystem diverso. Si può così fornire
+ 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}] Richiede che ogni modifica al contenuto di una
+ directory venga immediatamente registrata su disco in maniera sincrona
+ (introdotta a partire dai kernel della serie 2.6). L'opzione si applica a
+ tutte le directory del filesystem, ma su alcuni filesystem è possibile
+ impostarla a livello di singole directory o per i sottorami di una directory
+ con il comando \cmd{lsattr}.\footnote{questo avviene tramite delle opportune
+ \texttt{ioctl} (vedi sez.~\ref{sec:file_ioctl}).}
+
+ Questo consente di ridurre al minimo il rischio di perdita dei dati delle
+ directory in caso di crollo improvviso del sistema, al costo di una certa
+ perdita di prestazioni dato che le funzioni di scrittura relative ad
+ operazioni sulle directory non saranno più bufferizzate e si bloccheranno
+ fino all'arrivo dei dati sul disco prima che un programma possa proseguire.
+
+\item[\const{MS\_MANDLOCK}] Consente l'uso del \textit{mandatory locking}
+ \itindex{mandatory~locking} (vedi sez.~\ref{sec:file_mand_locking}) sui file
+ del filesystem. Per poterlo utilizzare effettivamente però esso dovrà essere
+ comunque attivato esplicitamente per i singoli file impostando i permessi
+ come illustrato in sez.~\ref{sec:file_mand_locking}.
+
+\item[\const{MS\_MOVE}] Effettua uno del spostamento del \itindex{mount~point}
+ \textit{mount point} di un filesystem. La directory del
+ \itindex{mount~point} \textit{mount point} originale deve essere indicata
+ nell'argomento \param{source}, e la sua nuova posizione
+ nell'argomento \param{target}. Tutti gli altri argomenti della funzione
+ vengono ignorati.
+
+ Lo spostamento avviene atomicamente, ed il ramo di albero presente
+ sotto \param{source} sarà immediatamante visibile sotto \param{target}. Non
+ esiste cioè nessun momento in cui il filesystem non risulti montato in una o
+ nell'altra directory e pertanto è garantito che la risoluzione di
+ \textit{pathname} relativi all'interno del filesystem non possa fallire.
+
+\item[\const{MS\_NOATIME}] Viene disabilitato sul filesystem l'aggiornamento
+ degli \textit{access time} (vedi sez.~\ref{sec:file_file_times}) per
+ qualunque tipo di file. Dato che l'aggiornamento degli \textit{access time}
+ è una funzionalità la cui utilità è spesso irrilevante ma comporta un costo
+ elevato visto che una qualunque lettura comporta comunque una scrittura su
+ disco,\footnote{e questo ad esempio ha conseguenze molto pesanti nell'uso
+ della batteria sui portatili.} questa opzione consente di disabilitarla
+ completamente. La soluzione può risultare troppo drastica dato che
+ l'informazione viene comunque utilizzata da alcuni programmi, per cui nello
+ sviluppo del kernel sono state introdotte altre opzioni che forniscono
+ soluzioni più appropriate e meno radicali.
+
+\item[\const{MS\_NODEV}] Viene disabilitato sul filesystem l'accesso ai file
+ di dispositivo eventualmente presenti su di esso. L'opzione viene usata come
+ misura di precauzione per rendere inutile la presenza di eventuali file di
+ dispositivo su filesystem che non dovrebbero contenerne.\footnote{si ricordi
+ che le convenzioni del \itindex{Filesystem~Hierarchy~Standard~(FHS)}
+ \textit{Linux Filesystem Hierarchy Standard} richiedono che questi siano
+ mantenuti esclusivamente sotto \texttt{/dev}.}
+
+ Viene utilizzata, assieme a \const{MS\_NOEXEC} e \const{MS\_NOSUID}, per
+ fornire un accesso più controllato a quei filesystem di cui gli utenti hanno
+ il controllo dei contenuti, in particolar modo quelli posti su dispositivi
+ rimuovibili. In questo modo si evitano alla radice possibili situazioni in
+ cui un utente malizioso inserisce su uno di questi filesystem dei file di
+ dispositivo con permessi ``opportunamente'' ampliati che gli consentano di
+ accedere anche a risorse cui non dovrebbe.
+
+\item[\const{MS\_NODIRATIME}] Viene disabilitato sul filesystem
+ l'aggiornamento degli \textit{access time} (vedi
+ sez.~\ref{sec:file_file_times}), ma soltanto per le directory. Costituisce
+ una alternativa per \const{MS\_NOATIME}, che elimina l'informazione per le
+ directory, che in pratica che non viene mai utilizzata, mantenendola per i
+ file in cui invece ha un impiego, sia pur limitato.
+
+\item[\const{MS\_NOEXEC}] Viene disabilitata sul filesystem l'esecuzione di un
+ qualunque file eseguibile eventualmente presente su di esso. L'opzione viene
+ usata come misura di precauzione per rendere impossibile l'uso di programmi
+ posti su filesystem che non dovrebbero contenerne.
+
+ Anche in questo caso viene utilizzata per fornire un accesso più controllato
+ a quei filesystem di cui gli utenti hanno il controllo dei contenuti. Da
+ questo punto di vista l'opzione è meno importante delle analoghe
+ \const{MS\_NODEV} e \const{MS\_NOSUID} in quanto l'esecuzione di un
+ programma creato dall'utente pone un livello di rischio nettamente
+ inferiore, ed è in genere consentita per i file contenuti nella sua home
+ directory.\footnote{cosa che renderebbe superfluo l'attivazione di questa
+ opzione, il cui uso ha senso solo per ambienti molto controllati in cui si
+ vuole che gli utenti eseguano solo i programmi forniti
+ dall'amministratore.}
+
+\item[\const{MS\_NOSUID}] Viene disabilitato sul filesystem l'effetto dei bit
+ dei permessi \itindex{suid~bit} \acr{suid} e \itindex{sgid~bit} \acr{sgid}
+ (vedi sez.~\ref{sec:file_special_perm}) eventualmente presenti sui file in
+ esso contenuti. L'opzione viene usata come misura di precauzione per rendere
+ inefficace l'effetto di questi bit per filesystem in cui non ci dovrebbero
+ essere file dotati di questi permessi.
+
+ Di nuovo viene utilizzata, analogamente a \const{MS\_NOEXEC} e
+ \const{MS\_NODEV}, per fornire un accesso più controllato a quei filesystem
+ di cui gli utenti hanno il controllo dei contenuti. In questo caso si evita
+ che un utente malizioso possa inserire su uno di questi filesystem un
+ eseguibile con il bit \itindex{suid~bit} \acr{suid} attivo e di proprietà
+ dell'amministratore o di un altro utente, che gli consentirebbe di eseguirlo
+ per conto di quest'ultimo.
+
+\item[\const{MS\_PRIVATE}] Marca un \itindex{mount~point} \textit{mount point}
+ come privato. Si tratta di una delle nuove opzioni (insieme a
+ \const{MS\_SHARED}, \const{MS\_SLAVE} e \const{MS\_UNBINDABLE}) facenti
+ parte dell'infrastruttura degli \itindex{shared~subtree} \textit{shared
+ subtree} introdotta a partire dal kernel 2.6.15, che estendono le
+ funzionalità dei \itindex{bind~mount} \textit{bind mount}. In questo caso
+ \param{target} dovrà fare riferimento al \textit{mount point} che si intende
+ marcare, e tutti gli altri argomenti verranno ignorati.
+
+ Di default, finché non lo si marca altrimenti con una delle altre opzioni
+ dell'interfaccia \itindex{shared~subtree} \textit{shared subtree}, ogni
+ \textit{mount point} è privato. Ogni \textit{bind mount} ottenuto da un
+ \itindex{mount~point} \textit{mount point} di tipo \textit{private} si
+ comporta come descritto nella trattazione di \const{MS\_BIND}. Si usa questo
+ flag principalmente per revocare gli effetti delle altre opzioni e riportare
+ il comportamento a quello ordinario.
+
+\item[\const{MS\_RDONLY}] Esegue il montaggio del filesystem in sola lettura,
+ non sarà possibile nessuna modifica ai suoi contenuti. Viene usato tutte le
+ volte che si deve accedere ai contenuti di un filesystem con la certezza che
+ questo non venga modificato (ad esempio per ispezionare un filesystem
+ corrotto). All'avvio di default il kernel monta la radice in questa
+ modalità.
+
+\item[\const{MS\_REC}] Applica ricorsivamente a tutti i \itindex{mount~point}
+ \textit{mount point} presenti al di sotto del \textit{mount point} indicato
+ gli effetti della opzione degli \itindex{shared~subtree} \textit{shared
+ subtree} associata. Anche questo caso l'argomento \param{target} deve fare
+ riferimento ad un \itindex{mount~point} \textit{mount point} e tutti gli
+ altri argomenti sono ignorati, ed il flag deve essere indicato assieme ad
+ una fra \const{MS\_PRIVATE}, \const{MS\_SHARED}, \const{MS\_SLAVE} e
+ \const{MS\_UNBINDABLE}.
+
+\item[\const{MS\_RELATIME}] Indica di effettuare l'aggiornamento degli
+ \textit{access time} sul filesystem soltanto quando questo risulti
+ antecendente il valore corrente del \textit{modification time} o del
+ \textit{change time} (per i tempi dei file si veda
+ sez.~\ref{sec:file_file_times}). L'opzione è disponibile a partire dal
+ kernel 2.6.20, mentre dal 2.6.30 questo è diventato il comportamento di
+ default del sistema, che può essere riportato a quello tradizionale con
+ l'uso di \const{MS\_STRICTATIME}. Sempre dal 2.6.30 il comportamento è stato
+ anche modificato e l'\textit{access time} viene comunque aggiornato se è più
+ vecchio di un giorno.
+
+ L'opzione consente di evitare i problemi di prestazioni relativi
+ all'aggiornamento dell'\textit{access time} senza avere impatti negativi
+ riguardo le funzionalità, il comportamento adottato infatti consente di
+ rendere evidente che vi è stato un accesso dopo la scrittura, ed evitando al
+ contempo ulteriori operazioni su disco negli accessi successivi. In questo
+ modo l'informazione relativa al fatto che un file sia stato letto resta
+ disponibile, ed i programmi che ne fanno uso continuano a funzionare. Con
+ l'introduzione di questo comportamento l'uso delle alternative
+ \const{MS\_NOATIME} e \const{MS\_NODIRATIME} è sostanzialmente inutile.
+
+\item[\const{MS\_REMOUNT}] Consente di rimontare un filesystem già montato
+ cambiandone le opzioni di montaggio in maniera atomica. In questo modo si
+ possono modificare le opzioni del filesystem anche se questo è in uso. Gli
+ argomenti \param{source} e \param{target} devono essere gli stessi usati per
+ il montaggio originale, mentre \param{data} che \param{mountflags}
+ conterranno le nuove opzioni, \param{filesystemtype} viene ignorato.
+
+ Qualunque opzione specifica del filesystem indicata con \param{data} può
+ essere modificata, mentre con \param{mountflags} possono essere modificate
+ solo alcune opzioni generiche. Con i kernel più recenti queste sono soltanto
+ \const{MS\_MANDLOCK}, \const{MS\_RDONLY} e \const{MS\_SYNCHRONOUS}, prima
+ del kernel 2.6.16 potevano essere modificate anche le ulteriori
+ \const{MS\_NOATIME} e \const{MS\_NODIRATIME}, ed infine prima del kernel
+ 2.4.10 anche \const{MS\_NODEV}, \const{MS\_NOEXEC} e \const{MS\_NOSUID}.
+
+\item[\const{MS\_SHARED}] Marca un \itindex{mount~point} \textit{mount point}
+ come \textit{shared mount}. Si tratta di una delle nuove opzioni (insieme a
+ \const{MS\_PRIVATE}, \const{MS\_SLAVE} e \const{MS\_UNBINDABLE}) facenti
+ parte dell'infrastruttura degli \itindex{shared~subtree} \textit{shared
+ subtree} introdotta a partire dal kernel 2.6.15, che estendono le
+ funzionalità dei \itindex{bind~mount} \textit{bind mount}. In questo caso
+ \param{target} dovrà fare riferimento al \itindex{mount~point} \textit{mount
+ point} che si intende marcare, e tutti gli altri argomenti verranno
+ ignorati.
+
+ Lo scopo dell'opzione è ottenere che tutti i successivi \textit{bind mount}
+ effettuati da un \textit{mount point} marcato da essa siano di tipo
+ \textit{shared}, cioè ``\textsl{condividano}'' con l'originale e fra di loro
+ ogni ulteriore operazione di montaggio o smontaggio che avviene su una
+ directory al di sotto di uno qualunque di essi. Le operazioni di montaggio e
+ smontaggio cioè vengono ``\textsl{propagate}'' a tutti i \textit{mount
+ point} della stessa condivisione, e la sezione di albero di file vista al
+ di sotto di ciascuno di essi sarà sempre identica.
+
+\item[\const{MS\_SILENT}] Richiede la soppressione di alcuni messaggi di
+ avvertimento nei log del kernel (vedi sez.~\ref{sec:sess_daemon}). L'opzione
+ è presente a partire dal kernel 2.6.17 e sostituisce, utilizzando un nome
+ non fuorviante, la precedente \const{MS\_VERBOSE}, introdotta nel kernel
+ 2.6.12, che aveva lo stesso effetto.
+
+\item[\const{MS\_SLAVE}] Marca un \itindex{mount~point} \textit{mount point}
+ come \textit{slave mount}. Si tratta di una delle nuove opzioni (insieme a
+ \const{MS\_PRIVATE}, \const{MS\_SHARED} e \const{MS\_UNBINDABLE}) facenti
+ parte dell'infrastruttura degli \itindex{shared~subtree} \textit{shared
+ subtree} introdotta a partire dal kernel 2.6.15, che estendono le
+ funzionalità dei \itindex{bind~mount} \textit{bind mount}. In questo caso
+ \param{target} dovrà fare riferimento al \textit{mount point} che si intende
+ marcare, e tutti gli altri argomenti verranno ignorati.
+
+ Lo scopo dell'opzione è ottenere che tutti i successivi \textit{bind mount}
+ effettuati da un \textit{mount point} marcato da essa siano di tipo
+ \textit{slave}, cioè ``\textsl{condividano}'' ogni ulteriore operazione di
+ montaggio o smontaggio che avviene su una directory al di sotto del
+ \textit{mount point} originale. Le operazioni di montaggio e smontaggio in
+ questo caso vengono ``\textsl{propagate}'' soltanto dal \textit{mount point}
+ originale (detto anche \textit{master}) verso gli \textit{slave}, mentre
+ essi potranno eseguire al loro interno ulteriori montaggi che non saranno
+ propagati né negli altri né nel \itindex{mount~point} \textit{mount point}
+ originale.
+
+\item[\const{MS\_STRICTATIME}] Ripristina il comportamento tradizionale per
+ cui l'\textit{access time} viene aggiornato ad ogni accesso al
+ file. L'opzione è disponibile solo a partire dal kernel 2.6.30 quando il
+ comportamento di default del kernel è diventato quello fornito da
+ \const{MS\_RELATIME}.
+
+\item[\const{MS\_SYNCHRONOUS}] Abilita la scrittura sincrona richiedendo che
+ ogni modifica al contenuto del filesystem venga immediatamente registrata su
+ disco. Lo stesso comportamento può essere ottenuto con il flag
+ \const{O\_SYNC} di \func{open} (vedi sez.~\ref{sec:file_open}).
+
+ Questa opzione consente di ridurre al minimo il rischio di perdita dei dati
+ in caso di crollo improvviso del sistema, al costo di una pesante perdita di
+ prestazioni dato che tutte le funzioni di scrittura non saranno più
+ bufferizzate e si bloccheranno fino all'arrivo dei dati sul disco. Per un
+ compromesso in cui questo comportamento avviene solo per le directory, ed ha
+ quindi una incidenza nettamente minore, si può usare \const{MS\_DIRSYNC}.
+
+\item[\const{MS\_UNBINDABLE}] Marca un \itindex{mount~point} \textit{mount
+ point} come \textit{unbindable mount}. Si tratta di una delle nuove
+ opzioni (insieme a \const{MS\_PRIVATE}, \const{MS\_SHARED} e
+ \const{MS\_SLAVE}) facenti parte dell'infrastruttura degli
+ \itindex{shared~subtree} \textit{shared subtree} introdotta a partire dal
+ kernel 2.6.15, che estendono le funzionalità dei \itindex{bind~mount}
+ \textit{bind mount}. In questo caso
+ \param{target} dovrà fare riferimento al \textit{mount point} che si intende
+ marcare, e tutti gli altri argomenti verranno ignorati.
+
+ Un \textit{mount point} marcato in questo modo disabilità la capacità di
+ eseguire dei \itindex{bind~mount} \textit{bind mount}. Si comporta cioè come
+ allo stesso modo di un \itindex{mount~point} \textit{mount point} ordinario
+ di tipo \textit{private} con in più la restrizione che nessuna sua
+ sottodirectory (anche se relativa ad un ulteriore montaggio) possa essere
+ utilizzata per un come sorgente di un \itindex{bind~mount} \textit{bind
+ mount}.
-\begin{table}[htb]
- \footnotesize
- \centering
- \begin{tabular}[c]{|l|r|l|}
- \hline
- \textbf{Parametro} & \textbf{Valore}&\textbf{Significato}\\
- \hline
- \hline
- \const{MS\_RDONLY} & 1 & Monta in sola lettura.\\
- \const{MS\_NOSUID} & 2 & Ignora i bit \itindex{suid~bit} \acr{suid} e
- \itindex{sgid~bit} \acr{sgid}.\\
- \const{MS\_NODEV} & 4 & Impedisce l'accesso ai file di dispositivo.\\
- \const{MS\_NOEXEC} & 8 & Impedisce di eseguire programmi.\\
- \const{MS\_SYNCHRONOUS}& 16 & Abilita la scrittura sincrona.\\
- \const{MS\_REMOUNT} & 32 & Rimonta il filesystem cambiando le opzioni.\\
- \const{MS\_MANDLOCK} & 64 & Consente il \textit{mandatory locking}
- \itindex{mandatory~locking} (vedi
- sez.~\ref{sec:file_mand_locking}).\\
- \const{S\_WRITE} & 128 & Scrive normalmente.\\
- \const{S\_APPEND} & 256 & Consente la scrittura solo in
- \itindex{append~mode} \textit{append mode}
- (vedi sez.~\ref{sec:file_sharing}).\\
- \const{S\_IMMUTABLE} & 512 & Impedisce che si possano modificare i file.\\
- \const{MS\_NOATIME} &1024 & Non aggiorna gli \textit{access time} (vedi
- sez.~\ref{sec:file_file_times}).\\
- \const{MS\_NODIRATIME}&2048 & Non aggiorna gli \textit{access time} delle
- directory.\\
- \const{MS\_BIND} &4096 & Monta il filesystem altrove.\\
- \const{MS\_MOVE} &8192 & Sposta atomicamente il punto di montaggio.\\
- \hline
- \end{tabular}
- \caption{Tabella dei codici dei flag di montaggio di un filesystem.}
- \label{tab:sys_mount_flags}
-\end{table}
+\end{basedescript}
-% TODO aggiornare con i nuovi flag di man mount
-% gli S_* non esistono più come segnalato da Alessio...
-% verificare i readonly mount bind del 2.6.26
+% NOTE per \const{MS\_SLAVE},\const{MS\_SHARE}, \const{MS\_PRIVATE} e
+% \const{MS\_UNBINDABLE} dal 2.6.15 vedi shared subtrees, in particolare
+% * http://lwn.net/Articles/159077/ e
+% * Documentation/filesystems/sharedsubtree.txt
-Per l'impostazione delle caratteristiche particolari di ciascun filesystem si
-usa invece l'argomento \param{data} che serve per passare le ulteriori
-informazioni necessarie, che ovviamente variano da filesystem a filesystem.
+% TODO: (bassa priorità) non documentati ma presenti in sys/mount.h:
+% * MS_POSIXACL
+% * MS_KERNMOUNT
+% * MS_I_VERSION
+% * MS_ACTIVE
+% * MS_NOUSER
-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{prototype}{sys/mount.h}{umount(const char *target)}
-
- Smonta il filesystem montato sulla directory \param{target}.
-
- \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di
- fallimento, nel qual caso \var{errno} assumerà uno dei valori:
+
+\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} o \errval{ELOOP}.}
-\end{prototype}
-\noindent 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
+ \item[\errcode{EBUSY}] \param{target} è la \index{directory~di~lavoro}
+ 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 a partire dai kernel della serie 2.4.x è possibile montare lo stesso
dispositivo in più punti. Nel caso più di un filesystem sia stato montato
-sullo stesso \textit{mount point} viene smontato quello che è stato montato
-per ultimo.
+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 mount point di un altro filesystem; in questo caso l'errore
-restituito è \errcode{EBUSY}.
+\textsl{occupato}, cioè quando ci sono ancora dei file aperti sul filesystem,
+se questo contiene la \index{directory~di~lavoro} 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{prototype}{sys/mount.h}{umount2(const char *target, int flags)}
-
- La funzione è identica a \func{umount} per comportamento e codici di errore,
- ma con \param{flags} si può specificare se forzare lo smontaggio.
-\end{prototype}
+\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.
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{functions}
- \headdecl{sys/vfs.h}
- \funcdecl{int statfs(const char *path, struct statfs *buf)}
- \funcdecl{int fstatfs(int fd, struct statfs *buf)}
-
- Restituisce in \param{buf} le informazioni relative al filesystem su cui è
- posto il file specificato.
-
- \bodydesc{Le funzioni ritornano 0 in caso di successo e -1 in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori:
+\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
- supporta la funzione.
- \end{errlist}
- e \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}.}
-\end{functions}
+ \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
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
\item[\errcode{ENOTEMPTY}] \param{newpath} è una directory già esistente e
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).
+ parte di qualche processo (come \index{directory~di~lavoro} directory di
+ lavoro o come radice) o del 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'\acr{uid} 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
di attraversare (esecuzione) una delle directory specificate in
\param{dirname}.
- \item[\errcode{EBUSY}] la directory specificata è la directory di lavoro o la
- radice di qualche processo.
+ \item[\errcode{EBUSY}] la directory specificata è la
+ \index{directory~di~lavoro} directory di lavoro o la radice di qualche
+ processo.
\item[\errcode{ENOTEMPTY}] la directory non è vuota.
\end{errlist}
ed inoltre anche \errval{EFAULT}, \errval{ENAMETOOLONG}, \errval{ENOENT},
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
+Le macro sono definite nel file \headfile{sys/sysmacros.h}, che viene
+automaticamente incluso quando si include \headfile{sys/types.h}; si possono
pertanto ottenere i valori del \itindex{major~number} \textit{major number} e
\itindex{minor~number} \textit{minor number} di un dispositivo rispettivamente
con le macro \macro{major} e \macro{minor}:
stream} \param{dir}. Di solito si utilizza questa funzione in abbinamento a
funzioni che operano sui file descriptor, ad esempio si potrà usare
\func{fstat} per ottenere le proprietà della directory, o \func{fchdir} per
-spostare su di essa la directory di lavoro (vedi
+spostare su di essa la \index{directory~di~lavoro} directory di lavoro (vedi
sez.~\ref{sec:file_work_dir}).
Viceversa se si è aperto un file descriptor corrispondente ad una directory è
stream sulla directory passata come primo argomento, stampando un messaggio in
caso di errore.
-Il passo successivo (\texttt{\small 23--24}) è cambiare directory di lavoro
-(vedi sez.~\ref{sec:file_work_dir}), usando in sequenza le funzioni
-\func{dirfd} e \func{fchdir} (in realtà si sarebbe potuto usare direttamente
-\func{chdir} su \var{dirname}), in modo che durante il successivo ciclo
-(\texttt{\small 26--30}) sulle singole voci dello stream ci si trovi
-all'interno della directory.\footnote{questo è essenziale al funzionamento
- della funzione \code{do\_ls}, e ad ogni funzione che debba usare il campo
- \var{d\_name}, in quanto i nomi dei file memorizzati all'interno di una
- struttura \struct{dirent} sono sempre relativi alla directory in questione,
- e senza questo posizionamento non si sarebbe potuto usare \func{stat} per
- ottenere le dimensioni.}
+Il passo successivo (\texttt{\small 23--24}) è cambiare
+\index{directory~di~lavoro} directory di lavoro (vedi
+sez.~\ref{sec:file_work_dir}), usando in sequenza le funzioni \func{dirfd} e
+\func{fchdir} (in realtà si sarebbe potuto usare direttamente \func{chdir} su
+\var{dirname}), in modo che durante il successivo ciclo (\texttt{\small
+ 26--30}) sulle singole voci dello stream ci si trovi all'interno della
+directory.\footnote{questo è essenziale al funzionamento della funzione
+ \code{do\_ls}, e ad ogni funzione che debba usare il campo \var{d\_name}, in
+ quanto i nomi dei file memorizzati all'interno di una struttura
+ \struct{dirent} sono sempre relativi alla directory in questione, e senza
+ questo posizionamento non si sarebbe potuto usare \func{stat} per ottenere
+ le dimensioni.}
Avendo usato lo stratagemma di fare eseguire tutte le manipolazioni necessarie
alla funzione passata come secondo argomento, il ciclo di scansione della
\label{sec:file_work_dir}
\itindbeg{pathname}
-
+\index{directory~di~lavoro|(}
Come accennato in sez.~\ref{sec:proc_fork} a ciascun processo è associata una
directory nel filesystem,\footnote{questa viene mantenuta all'interno dei dati
della sua \struct{task\_struct} (vedi fig.~\ref{fig:proc_task_struct}), più
Una seconda usata per ottenere la directory di lavoro è \code{char
*get\_current\_dir\_name(void)} che è sostanzialmente equivalente ad una
\code{getcwd(NULL, 0)}, con la sola differenza che essa ritorna il valore
-della variabile di ambiente \val{PWD}, che essendo costruita dalla shell può
-contenere un \textit{pathname} comprendente anche dei link simbolici. Usando
-\func{getcwd} infatti, essendo il \textit{pathname} ricavato risalendo
-all'indietro l'albero della directory, si perderebbe traccia di ogni passaggio
-attraverso eventuali link simbolici.
+della variabile di ambiente \envvar{PWD}, che essendo costruita dalla shell
+può contenere un \textit{pathname} comprendente anche dei link
+simbolici. Usando \func{getcwd} infatti, essendo il \textit{pathname} ricavato
+risalendo all'indietro l'albero della directory, si perderebbe traccia di ogni
+passaggio attraverso eventuali link simbolici.
Per cambiare la directory di lavoro si può usare la funzione \funcd{chdir}
(equivalente del comando di shell \cmd{cd}) il cui nome sta appunto per
specificata da \param{fd}.
\itindend{pathname}
-
+\index{directory~di~lavoro|)}
\subsection{I file temporanei}
indefinito. Al nome viene automaticamente aggiunto come prefisso la directory
specificata dalla costante \const{P\_tmpdir}.\footnote{le costanti
\const{L\_tmpnam}, \const{P\_tmpdir} e \const{TMP\_MAX} sono definite in
- \file{stdio.h}.}
+ \headfile{stdio.h}.}
Di questa funzione esiste una versione \index{funzioni!rientranti} rientrante,
\func{tmpnam\_r}, che non fa nulla quando si passa \val{NULL} come argomento.
nome provvisorio. La funzione assegna come directory per il file temporaneo,
verificando che esista e sia accessibile, la prima valida fra le seguenti:
\begin{itemize*}
-\item La variabile di ambiente \const{TMPDIR} (non ha effetto se non è
+\item La variabile di ambiente \envvar{TMPDIR} (non ha effetto se non è
definita o se il programma chiamante è \itindex{suid~bit} \acr{suid} o
\itindex{sgid~bit} \acr{sgid}, vedi sez.~\ref{sec:file_special_perm}).
\item il valore dell'argomento \param{dir} (se diverso da \val{NULL}).
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
questa funzione esiste una variante \funcd{mkostemp}, introdotta
specificamente dalla \acr{glibc},\footnote{la funzione è stata introdotta
nella versione 2.7 delle librerie e richiede che sia definita la macro
- \const{\_GNU\_SOURCE}.} il cui prototipo è:
+ \macro{\_GNU\_SOURCE}.} il cui prototipo è:
\begin{prototype}{stlib.h}{int mkostemp(char *template, int flags)}
Genera un file temporaneo.
aperto, specificato tramite il suo file descriptor \param{filedes}.
La struttura \struct{stat} usata da queste funzioni è definita nell'header
-\file{sys/stat.h} e in generale dipende dall'implementazione; la versione
+\headfile{sys/stat.h} e in generale dipende dall'implementazione; la versione
usata da Linux è mostrata in fig.~\ref{fig:file_stat_struct}, così come
riportata dalla pagina di manuale di \func{stat}; in realtà la definizione
effettivamente usata nel kernel dipende dall'architettura e ha altri campi
Si noti come i vari membri della struttura siano specificati come tipi
primitivi del sistema (di quelli definiti in
-tab.~\ref{tab:intro_primitive_types}, e dichiarati in \file{sys/types.h}).
+tab.~\ref{tab:intro_primitive_types}, e dichiarati in \headfile{sys/types.h}).
\subsection{I tipi di file}
\label{sec:file_types}
\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}).}
+ \caption{Macro per i tipi di file (definite in \headfile{sys/stat.h}).}
\label{tab:file_type_macro}
\end{table}
Oltre alle macro di tab.~\ref{tab:file_type_macro} è possibile usare
direttamente il valore di \var{st\_mode} per ricavare il tipo di file
controllando direttamente i vari bit in esso memorizzati. Per questo sempre in
-\file{sys/stat.h} sono definite le costanti numeriche riportate in
+\headfile{sys/stat.h} sono definite le costanti numeriche riportate in
tab.~\ref{tab:file_mode_flags}.
Il primo valore dell'elenco di tab.~\ref{tab:file_mode_flags} è la maschera
\hline
\end{tabular}
\caption{Costanti per l'identificazione dei vari bit che compongono il campo
- \var{st\_mode} (definite in \file{sys/stat.h}).}
+ \var{st\_mode} (definite in \headfile{sys/stat.h}).}
\label{tab:file_mode_flags}
\end{table}
in termini di prestazioni, che di consumo di risorse come la batteria per i
portatili, o cicli di riscrittura per i dischi su memorie riscrivibili.
+% TODO aggiustare per il contenuto duplicato con le analoghe MS_*
+
Per questo motivo, onde evitare di mantenere una informazione che nella
maggior parte dei casi non interessa, è sempre stato possibile disabilitare
l'aggiornamento del tempo di ultimo accesso con l'opzione di montaggio
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'\acr{uid} effettivo, il \acr{gid}
-effettivo e gli eventuali \acr{gid} 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'\acr{uid} effettivo e il \acr{gid} effettivo
-corrispondono ai valori dell'\acr{uid} e del \acr{gid} dell'utente che ha
-lanciato il processo, mentre i \acr{gid} 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'\acr{uid} 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'\acr{uid} 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 \acr{gid} effettivo del processo o uno dei \acr{gid} 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 \acr{uid} 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 \acr{gid} 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'\acr{uid} ed il \acr{gid} effettivo del processo;
-ci sono casi però in cui si può voler effettuare il controllo con l'\acr{uid}
-reale ed il \acr{gid} 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'\acr{uid} 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'\acr{uid} 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'\acr{uid} 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'\acr{uid} 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'\acr{uid} 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 \acr{gid} 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'\acr{uid} 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
ACL i passi attraverso i quali viene stabilito se esso ha diritto di accesso
sono i seguenti:
\begin{enumerate*}
-\item Se l'\acr{uid} 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'\acr{uid} 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'\acr{uid} 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 \acr{gid} del processo o uno dei \acr{gid} 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 \acr{gid} del processo o uno dei \acr{gid} 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*}
\hline
\const{TEXT\_ABBREVIATE} & stampa le voci in forma abbreviata.\\
\const{TEXT\_NUMERIC\_IDS} & non effettua la risoluzione numerica di
- \acr{uid} e \acr{gid}.\\
+ \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
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}
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}).
privilegi originali dal processo.
Per questo motivo se un programma senza \textit{capabilities} assegnate viene
-eseguito da un processo con \acr{uid} reale 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 \acr{uid}
-nullo a \acr{uid} non nullo o viceversa (corrispondenti rispettivamente a
+\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 \acr{uid} effettivo 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 \acr{uid} effettivo 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} \acr{uid} 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},
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 \acr{uid} 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
- \acr{uid} passano ad un valore non
+ \ids{UID} passano ad un valore non
nullo (regola di compatibilità per il cambio
- di \acr{uid} 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 \acr{uid}
+ da nullo a non nullo degli \ids{UID}
dei gruppi \textit{effective} e
\textit{file system} (regole di compatibilità
- per il cambio di \acr{uid} 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 \acr{uid} 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
breve descrizione ed il nome delle costanti che le identificano, è riportato
in tab.~\ref{tab:proc_capabilities};\footnote{l'elenco presentato questa
tabella, ripreso dalla pagina di manuale (accessibile con \texttt{man
- capabilities}) e dalle definizioni in \texttt{linux/capabilities.h}, è
- aggiornato al kernel 2.6.26.} la tabella è divisa in due parti, la prima
-riporta le \textit{capabilities} previste anche nella bozza dello standard
-POSIX1.e, la seconda quelle specifiche di Linux. Come si può notare dalla
-tabella alcune \textit{capabilities} attengono a singole funzionalità e sono
-molto specializzate, mentre altre hanno un campo di applicazione molto vasto,
-che è opportuno dettagliare maggiormente.
+ capabilities}) e dalle definizioni in
+ \texttt{include/linux/capabilities.h}, è aggiornato al kernel 2.6.26.} la
+tabella è divisa in due parti, la prima riporta le \textit{capabilities}
+previste anche nella bozza dello standard POSIX1.e, la seconda quelle
+specifiche di Linux. Come si può notare dalla tabella alcune
+\textit{capabilities} attengono a singole funzionalità e sono molto
+specializzate, mentre altre hanno un campo di applicazione molto vasto, che è
+opportuno dettagliare maggiormente.
\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'\acr{uid} effettivo del
- processo (o meglio l'\acr{uid} di filesystem, 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
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 \acr{uid} 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} e \func{clone}, (vedi
indicato che per poterle utilizzare fosse necessario che la macro
\macro{\_POSIX\_SOURCE} risultasse non definita (ed era richiesto di inserire
una istruzione \texttt{\#undef \_POSIX\_SOURCE} prima di includere
-\texttt{sys/capability.h}) requisito che non risulta più presente.\footnote{e
- non è chiaro neanche quanto sia mai stato davvero necessario.}
+\headfile{sys/capability.h}) requisito che non risulta più
+presente.\footnote{e non è chiaro neanche quanto sia mai stato davvero
+ necessario.}
Si tenga presente che le strutture di fig.~\ref{fig:cap_kernel_struct}, come i
prototipi delle due funzioni \func{capget} e \func{capset}, sono soggette ad
con l'argomento \param{flag}. Questo deve essere specificato con una variabile
di tipo \type{cap\_flag\_t} che può assumere esclusivamente\footnote{si tratta
in effetti di un tipo enumerato, come si può verificare dalla sua
- definizione che si trova in \texttt{/usr/include/sys/capability.h}.} uno dei
-valori illustrati in tab.~\ref{tab:cap_set_identifier}.
+ definizione che si trova in \headfile{sys/capability.h}.} uno dei valori
+illustrati in tab.~\ref{tab:cap_set_identifier}.
Si possono inoltre confrontare in maniera diretta due diversi
\textit{capability state} con la funzione \funcd{cap\_compare}; il suo
tab.~\ref{tab:proc_capabilities}, in questo caso però non è possibile
combinare diversi valori in una maschera binaria, una variabile di tipo
\type{cap\_value\_t} può indicare una sola capacità.\footnote{in
- \texttt{sys/capability.h} il tipo \type{cap\_value\_t} è definito come
+ \headfile{sys/capability.h} il tipo \type{cap\_value\_t} è definito come
\ctyp{int}, ma i valori validi sono soltanto quelli di
tab.~\ref{tab:proc_capabilities}.}
prototipo\footnote{su alcune pagine di manuale la funzione è descritta con un
prototipo sbagliato, che prevede un valore di ritorno di tipo \type{cap\_t},
ma il valore di ritorno è intero, come si può verificare anche dalla
- dichiarazione della stessa in \texttt{sys/capability.h}.} è:
+ dichiarazione della stessa in \headfile{sys/capability.h}.} è:
\begin{functions}
\headdecl{sys/capability.h}
-\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_pathname}), ha per il processo
-il significato specifico di directory rispetto alla quale vengono risolti i
+\index{directory~di~lavoro} 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_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
+\itindsub{pathname}{relativo}\textit{pathname} relativi cambiando la \index{directory~di~lavoro} directory
di lavoro.
Normalmente la directory radice di un processo coincide anche con la radice
\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'\acr{uid} 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};
Questo è il motivo per cui la funzione è efficace solo se dopo averla eseguita
si cedono i privilegi di root. Infatti se per un qualche motivo il processo
-resta con la directory di lavoro fuori dalla \textit{chroot jail}, potrà
-comunque accedere a tutto il resto del filesystem usando
-\itindsub{pathname}{relativo}\textit{pathname} relativi, i quali, partendo
-dalla directory di lavoro che è fuori della \textit{chroot jail}, potranno
-(con l'uso di ``\texttt{..}'') risalire fino alla radice effettiva del
-filesystem.
+resta con \index{directory~di~lavoro} la directory di lavoro fuori dalla
+\textit{chroot jail}, potrà comunque accedere a tutto il resto del filesystem
+usando \itindsub{pathname}{relativo}\textit{pathname} relativi, i quali,
+partendo dalla directory di lavoro che è fuori della \textit{chroot jail},
+potranno (con l'uso di ``\texttt{..}'') risalire fino alla radice effettiva
+del filesystem.
Ma se ad un processo restano i privilegi di amministratore esso potrà comunque
-portare la sua directory di lavoro fuori dalla \textit{chroot jail} in cui si
-trova. Basta infatti creare una nuova \textit{chroot jail} con l'uso di
-\func{chroot} su una qualunque directory contenuta nell'attuale directory di
-lavoro. Per questo motivo l'uso di questa funzione non ha molto senso quando
-un processo necessita dei privilegi di root per le sue normali operazioni.
+portare la sua \index{directory~di~lavoro} directory di lavoro fuori dalla
+\textit{chroot jail} in cui si trova. Basta infatti creare una nuova
+\textit{chroot jail} con l'uso di \func{chroot} su una qualunque directory
+contenuta nell'attuale directory di lavoro. Per questo motivo l'uso di questa
+funzione non ha molto senso quando un processo necessita dei privilegi di root
+per le sue normali operazioni.
Un caso tipico di uso di \func{chroot} è quello di un server FTP anonimo, in
questo caso infatti si vuole che il server veda solo i file che deve
% 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 IOPRIO
-% LocalWords: CAPBSET CLASS IDLE dcookie overflow DIFFERS
+% 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