\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}
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
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
-difunzionamento.
+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
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
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'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.
+\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}
\texttt{lookup} adatta per effettuare la risoluzione dei nomi per quel
filesystem.
+\itindend{pathname}
+
% Un secondo effetto della chiamata funzione \texttt{mount} di
% \kstruct{file\_system\_type} è quello di allocare una struttura
% \kstruct{super\_block} per ciascuna istanza montata, che contiene le
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}
\end{figure}
Come si può notare dall'estratto di fig.~\ref{fig:kstruct_file}, la struttura
-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.
+\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
\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
+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 una \code{seek}
-non è realizzabile per un dispositivo come la porta seriale o per una fifo,
-mentre sui file del filesystem \texttt{vfat} non sono disponibili i permessi,
-ma resta il fatto che grazie al VFS le \textit{system call} per le operazioni
-sui file restano sempre le stesse nonostante le enormi differenze che possono
-esserci negli oggetti a cui si applicano.
+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}
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
-\itindex{inode} \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.
+\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
\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}
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}
- (vedi sez.~\ref{sec:file_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}, che abbiamo scelto 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} (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 \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 All'interno di ogni filesystem ogni \textit{inode} è identificato da un
- numero univoco. Il numero di \textit{inode} nella voce si riferisce ad un
- \textit{inode} a questo numero 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.
+ 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}, vedi
- sez.~\ref{sec:file_remove}). Questa operazione non modifica minimamente
- neanche l'\textit{inode} del file dato che non si opera su questo ma sulla
- directory che lo contiene.
-
-\item Gli \textit{inode} dei file, che contengono i \textsl{metadati} ed i
+ nuova voce per l'\textit{inode} in questione e rimossa la precedente, questa
+ è la modalità in cui opera normalmente il comando \cmd{mv} attraverso la
+ funzione \func{rename} (vedi sez.~\ref{sec:file_remove}). Questa operazione
+ non modifica minimamente neanche l'\textit{inode} del file, dato che non si
+ opera sul file ma sulla directory che lo contiene.
+
+\item Gli \textit{inode} dei file, che contengono i \textsl{metadati}, ed i
blocchi di spazio disco, che contengono i dati, sono risorse indipendenti ed
in genere vengono gestite come tali anche dai diversi filesystem; è pertanto
- possibile 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.
+\itindend{inode}
-\subsection{I filesystem di uso comune}
+
+\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 \textit{superblock} sono quindi ridondati) per una maggiore
+affidabilità e possibilità di recupero in caso di corruzione del
+\textit{superblock} principale. L'utilizzo di raggruppamenti di blocchi ha
+inoltre degli effetti positivi nelle prestazioni dato che viene ridotta la
+distanza fra i dati e la tabella degli \itindex{inode} inode.
\begin{figure}[!htb]
\centering
\includegraphics[width=9cm]{img/dir_struct}
- \caption{Struttura delle directory nel \textit{second 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{ENOTBLK}] non si è usato un \textit{block device} per
- \param{source} quando era richiesto.
+ \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 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
+ rimontato in sola lettura perché ci sono ancora file aperti in scrittura,
+ o non può essere montato su \param{target} perché la directory è ancora in
+ uso.
+ \item[\errcode{EINVAL}] il dispositivo \param{source} presenta un
\textit{superblock} non valido, o si è cercato di rimontare un filesystem
non ancora montato, o di montarlo senza che \param{target} sia un
\itindex{mount~point} \textit{mount point} o di spostarlo
quando \param{target} non è un \itindex{mount~point} \textit{mount point}
- o è \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.
+ o è la radice.
\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 \itindex{mount~point}
-\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.
+ \item[\errcode{ENODEV}] il tipo \param{filesystemtype} non esiste o non è
+ configurato nel kernel.
+ \item[\errcode{ENOTBLK}] non si è usato un \textit{block device} per
+ \param{source} quando era richiesto.
+ \item[\errcode{ENXIO}] il \itindex{major~number} \textit{major number} del
+ dispositivo \param{source} è sbagliato.
+ \item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
+ \end{errlist}
+ ed inoltre \errval{EFAULT}, \errval{ELOOP}, \errval{ENOMEM},
+ \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOTDIR} nel loro
+ significato generico.}
+\end{funcproto}
+
+La funzione monta sulla directory indicata \param{target}, detta
+\itindex{mount~point} \textit{mount point}, il filesystem contenuto nel file
+di dispositivo indicato \param{source}. In entrambi i casi, come daremo per
+assunto da qui in avanti tutte le volte che si parla di directory o file nel
+passaggio di un argomento di una funzione, si intende che questi devono essere
+indicati con la stringa contenente il loro \itindex{pathname}
+\textit{pathname}.
+
+Normalmente un filesystem è contenuto su un disco o una partizione, ma come
+illustrato in sez.~\ref{sec:file_vfs_work} la struttura del \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
+opzioni del filesystem che devono essere impostate, in sostanza viene usato 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.
Dopo l'esecuzione della funzione il contenuto del filesystem viene resto
disponibile nella directory specificata come \itindex{mount~point}
\itindex{mount~point} \textit{mount point} da una directory ad un'altra, sia
montare in diversi \itindex{mount~point} \textit{mount point} lo stesso
filesystem, sia montare più filesystem sullo stesso \itindex{mount~point}
-\textit{mount point} (nel qual caso vale quanto appena detto, e solo il
-contenuto dell'ultimo filesystem montato sarà visibile).
+\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
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}.
+valori riportati nell'elenco seguente:
-\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}
+\begin{basedescript}{\desclabelstyle{\pushlabel}}
+
+\item[\const{MS\_BIND}] Effettua un cosiddetto \textit{bind mount}, in
+ sostanza .
+
+\item[\const{MS\_DIRSYNC}] .
+
+\item[\const{MS\_MANDLOCK}] Consente il \textit{mandatory locking}
+ \itindex{mandatory~locking} (vedi
+ sez.~\ref{sec:file_mand_locking}).
+
+\item[\const{MS\_MOVE}] Sposta atomicamente il punto di montaggio.
+
+\item[\const{MS\_NOATIME}] Non aggiorna gli \textit{access time} (vedi
+ sez.~\ref{sec:file_file_times}).
+
+\item[\const{MS\_NODEV}] Impedisce l'accesso ai file di dispositivo.
+
+\item[\const{MS\_NODIRATIME}] Non aggiorna gli \textit{access time} delle
+ directory.
+\item[\const{MS\_NOEXEC}] Impedisce di eseguire programmi.
+
+\item[\const{MS\_NOSUID}] Ignora i bit \itindex{suid~bit} \acr{suid} e
+ \itindex{sgid~bit} \acr{sgid}.
+
+\item[\const{MS\_RDONLY}] Monta in sola lettura.
+
+\item[\const{MS\_RELATIME}] .
+
+\item[\const{MS\_REMOUNT}] Rimonta il filesystem cambiando le opzioni.
+
+\item[\const{MS\_SILENT}] .
+
+\item[\const{MS\_STRICTATIME}] .
+
+\item[\const{MS\_SYNCHRONOUS}] Abilita la scrittura sincrona.
% TODO aggiornare con i nuovi flag di man mount
-% gli S_* non esistono più come segnalato da Alessio...
% verificare i readonly mount bind del 2.6.26
-
-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.
+\end{basedescript}
La funzione \func{mount} può essere utilizzata anche per effettuare il
\textsl{rimontaggio} di un filesystem, cosa che permette di cambiarne al volo
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
-dispositivo in più punti. Nel caso più di un filesystem sia stato montato
-sullo stesso \itindex{mount~point} \textit{mount point} viene smontato quello
-che è stato montato per ultimo.
+\end{errlist}ed inoltre \errval{ENOTDIR}, \errval{EFAULT}, \errval{ENOMEM},
+\errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ELOOP} nel loro
+ significato generico.}
+\end{funcproto}
+
+La funzione prende il nome della directory su cui il filesystem è montato e
+non il file o il dispositivo che è stato montato,\footnote{questo è vero a
+ partire dal kernel 2.3.99-pre7, prima esistevano due chiamate separate e la
+ funzione poteva essere usata anche specificando il file di dispositivo.} in
+quanto con il kernel 2.4.x è possibile montare lo stesso dispositivo in più
+punti. Nel caso più di un filesystem sia stato montato sullo stesso
+\itindex{mount~point} \textit{mount point} viene smontato quello che è stato
+montato per ultimo.
Si tenga presente che la funzione fallisce quando il filesystem è
\textsl{occupato}, questo avviene quando ci sono ancora file aperti sul
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
\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
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
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}
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
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
\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};
% 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
projects / gapil.git / blobdiff