Aggiornamento copyright, trattazione degli shared subtree per mount e
[gapil.git] / filedir.tex
index 9cd3f899b0918211007e63bb589573863ebd8c10..73cc8e6d0e42695bf12683115f50988272cf4f53 100644 (file)
@@ -1,6 +1,6 @@
 %% filedir.tex
 %%
 %% 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",
 %% 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",
@@ -287,12 +287,12 @@ di dati) dovrà invece ricorrere a quelle fornite dal driver del dispositivo.
 \end{figure}
 
 Come si può notare dall'estratto di fig.~\ref{fig:kstruct_file}, la struttura
 \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
 
 \begin{table}[htb]
   \centering
@@ -332,7 +332,7 @@ 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
 \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.
 \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.
@@ -340,12 +340,12 @@ 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
 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}
  
 
 \itindend{Virtual~File~System}
@@ -355,6 +355,8 @@ esserci negli oggetti a cui si applicano.
 %       * http://thecoffeedesk.com/geocities/rkfs.html
 %       * http://www.linux.it/~rubini/docs/vfs/vfs.html
 
 %       * 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}
 
 \subsection{Il funzionamento di un filesystem Unix}
 \label{sec:file_filesystem}
 
@@ -461,17 +463,17 @@ opportuno tenere sempre presente che:
   è 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
   è 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.
+  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 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
   blocchi di spazio disco, che contengono i dati, sono risorse indipendenti ed
   in genere vengono gestite come tali anche dai diversi filesystem; è pertanto
   possibile esaurire sia lo spazio disco (il caso più comune) che lo spazio
   per gli \textit{inode}. Nel primo caso non sarà possibile allocare ulteriore
   spazio, ma si potranno creare file (vuoti), nel secondo non si potranno
   creare nuovi file, ma si potranno estendere quelli che ci
-  sono.\footnote{questo comportamento non è generale, alcuni filesystem evoluti
-    possono evitare il problema dell'esaurimento degli \textit{inode}
+  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}
     riallocando lo spazio disco libero per i blocchi.}
 
 \end{enumerate}
@@ -506,19 +508,18 @@ tre, in quanto adesso sarà referenziata anche dalla voce ``\texttt{..}'' di
 \label{sec:file_ext2}
 
 
 \label{sec:file_ext2}
 
 
-Benché non esista il filesystem di Linux, dato che esiste un supporto nativo
-di diversi filesystem che sono in uso da anni, quello che gli avvicina di più
-è la famiglia di filesystem evolutasi a partire dal \textit{second extended
-  filesystem}, o \acr{ext2}, che nonostante il nome è stato il primo ad essere
-usato in maniera estensiva. 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.}
+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
 
 Il filesystem \acr{ext2} nasce come filesystem nativo per Linux a partire
 dalle prime versioni del kernel e supporta tutte le caratteristiche di un
@@ -543,7 +544,7 @@ le seguenti:
   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
   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.
 \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.
@@ -610,15 +611,15 @@ contenenti un gran numero di file.
 % in caso di crash del sistema)
 
 
 % 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
 \label{sec:sys_file_config}
 
 Come accennato in sez.~\ref{sec:file_arch_overview} per poter accedere ai file
 occorre prima rendere disponibile al sistema il filesystem su cui essi sono
 memorizzati; l'operazione di attivazione del filesystem è chiamata
-\textsl{montaggio}, per far questo in Linux si usa la funzione \funcd{mount}
-il cui prototipo è:\footnote{la funzione è una versione specifica di Linux e
-  non è portabile.}
+\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} 
 
 \begin{funcproto}{ 
 \fhead{sys/mount.h} 
@@ -646,7 +647,12 @@ il cui prototipo è:\footnote{la funzione è una versione specifica di Linux e
     \itindex{mount~point} \textit{mount point} o di spostarlo
     quando \param{target} non è un \itindex{mount~point} \textit{mount point}
     o è la radice.
     \itindex{mount~point} \textit{mount point} o di spostarlo
     quando \param{target} non è un \itindex{mount~point} \textit{mount point}
     o è la radice.
-  \item[\errcode{EMFILE}] la tabella dei device \textit{dummy} è piena.
+  \item[\errcode{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
   \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
@@ -655,113 +661,403 @@ il cui prototipo è:\footnote{la funzione è una versione specifica di Linux e
     dispositivo \param{source} è sbagliato.
   \item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
   \end{errlist} 
     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.}
+  ed inoltre \errval{EFAULT}, \errval{ENOMEM}, \errval{ENAMETOOLONG},
+  \errval{ENOENT}, \errval{ENOTDIR} nel loro significato generico.}
 \end{funcproto}
 
 \end{funcproto}
 
-La funzione monta sulla directory indicata \param{target}, detta
+La funzione monta sulla directory indicata da \param{target}, detta
 \itindex{mount~point} \textit{mount point}, il filesystem contenuto nel file
 \itindex{mount~point} \textit{mount point}, il filesystem contenuto nel file
-di dispositivo indicato \param{source}. In entrambi i casi, come daremo per
+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}.
 
 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}.
 
-In generale un filesystem è contenuto su un disco, e come illustrato in
-sez.~\ref{sec:file_vfs_work} l'operazione di montaggio corrisponde a rendere
-visibile il contenuto del suddetto disco, identificato attraverso il file di
-dispositivo ad esso associato, all'interno di una directory dell'albero dei
-file. 
-
-Ma la struttura del \textit{Virtual File System} vista in
-sez.~\ref{sec:file_vfs_work} è 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 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 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 uno dei filesystem virtuali, che non è
-associato a nessun file di dispositivo, il contenuto di \param{source} viene
-ignorato.
+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
 
 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 opzioni del
-filesytem 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. 
+parole chiave (separate da virgole e senza spazi) che indicano le cosiddette
+``\textsl{opzioni}'' del filesystem che devono essere impostate; in genere
+viene usato direttamente il contenuto del parametro dell'opzione \texttt{-o}
+del comando \texttt{mount}. I valori utilizzabili dipendono dal tipo di
+filesystem e ciascuno ha i suoi, pertanto si rimanda alla documentazione della
+pagina di manuale di questo comando e dei singoli filesystem.
 
 Dopo l'esecuzione della funzione il contenuto del filesystem viene resto
 disponibile nella directory specificata come \itindex{mount~point}
 \textit{mount point}, il precedente contenuto di detta directory viene
 
 Dopo l'esecuzione della funzione il contenuto del filesystem viene resto
 disponibile nella directory specificata come \itindex{mount~point}
 \textit{mount point}, il precedente contenuto di detta directory viene
-mascherato dal contenuto della directory radice del filesystem montato.
-
-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 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
+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.
 
 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}.  
+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 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 \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
+  \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 \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 \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 \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 \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 \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 \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 \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 \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}.
 
 
-In Linux \param{mountflags} deve essere un intero a 32 bit i cui 16 più
-significativi sono un \itindex{magic~number} \textit{magic
-  number}\footnote{che nel caso è \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}.
+\end{basedescript}
 
 
-\begin{table}[htb]
-  \footnotesize
-  \centering
-  \begin{tabular}[c]{|l|r|p{8cm}|}
-    \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}
 
 
-% 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
+
+% 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
 
 La funzione \func{mount} può essere utilizzata anche per effettuare il
 \textsl{rimontaggio} di un filesystem, cosa che permette di cambiarne al volo
@@ -994,10 +1290,12 @@ complicata (in genere per questo tipo di errori occorre far girare il
 programma \cmd{fsck} per riparare il filesystem).
 
 Data la pericolosità di questa operazione e la disponibilità dei link
 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
 
 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
@@ -1009,10 +1307,9 @@ iniziale di Linux ma a partire dai kernel della serie 2.0.x\footnote{per la
   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
   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
 
 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
@@ -1453,7 +1750,7 @@ La funzione che permette la cancellazione di una directory è invece
   \begin{errlist}
   \item[\errcode{EPERM}] il filesystem non supporta la cancellazione di
     directory, oppure la directory che contiene \param{dirname} ha lo
   \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
     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
@@ -2358,7 +2655,7 @@ La funzionane genera un nome univoco sostituendo le \code{XXXXXX} finali di
 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
 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
 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
@@ -2743,6 +3040,8 @@ accesso in lettura sui dati bufferizzati. Questo comporta un ovvio costo sia
 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.
 
 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
 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
@@ -3077,7 +3376,7 @@ concetti essenziali e le funzioni usate per gestirne i vari aspetti.
 
 Ad ogni file Linux associa sempre l'utente che ne è proprietario (il
 cosiddetto \textit{owner}) ed un gruppo di appartenenza, secondo il meccanismo
 
 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
 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
@@ -3224,8 +3523,8 @@ veda sez.~\ref{sec:file_special_perm}).
 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
 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,
   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,
@@ -3234,19 +3533,19 @@ effettivo e gli eventuali \acr{gid} supplementari del processo.\footnote{in
 
 Per una spiegazione dettagliata degli identificatori associati ai processi si
 veda sez.~\ref{sec:proc_perms}; normalmente, a parte quanto vedremo in
 
 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}
 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.
   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*}
   proprietario del file (nel qual caso si dice che il processo è proprietario
   del file) allora:
   \begin{itemize*}
@@ -3256,8 +3555,8 @@ di accesso sono i seguenti:
     impostato, l'accesso è consentito
   \item altrimenti l'accesso è negato
   \end{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, 
   \begin{itemize*}
   \item se il bit dei permessi d'accesso del gruppo è impostato, l'accesso è
     consentito, 
@@ -3298,9 +3597,9 @@ corrispondono a quelli dell'utente con cui si è entrati nel sistema.
 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
 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
 processo.
 
 I bit \acr{suid} e \acr{sgid} vengono usati per permettere agli utenti normali
@@ -3397,10 +3696,10 @@ consapevolmente, cancellare i file temporanei creati degli altri utenti.
 \label{sec:file_perm_management}
 
 Come visto in sez.~\ref{sec:file_access_control} il controllo di accesso ad un
 \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.
 
 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.
 
@@ -3490,7 +3789,7 @@ filename e su un file descriptor, i loro prototipi sono:
   \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}
   \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}
     proprietario del file o non è zero.
     \item[\errcode{EROFS}] il file è su un filesystem in sola lettura.
   \end{errlist}
@@ -3554,7 +3853,7 @@ bit \itindex{suid~bit} \acr{suid} il valore da fornire sarebbe $4755$.
 
 Il cambiamento dei permessi di un file eseguito attraverso queste funzioni ha
 comunque alcune limitazioni, previste per motivi di sicurezza. L'uso delle
 
 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}.
 
 corrisponde a quello del proprietario del file o dell'amministratore,
 altrimenti esse falliranno con un errore di \errcode{EPERM}.
 
@@ -3564,7 +3863,7 @@ non tutti i valori possibili di \param{mode} sono permessi o hanno effetto;
 in particolare accade che:
 \begin{enumerate}
 \item siccome solo l'amministratore può impostare lo \itindex{sticky~bit}
 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
   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
@@ -3574,7 +3873,7 @@ in particolare accade che:
   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
   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},
 \end{enumerate}
 
 Per alcuni filesystem\footnote{i filesystem più comuni (\textsl{ext2},
@@ -3647,21 +3946,21 @@ quale utente e gruppo esso deve appartenere.  Lo stesso problema si presenta
 per la creazione di nuove directory (procedimento descritto in
 sez.~\ref{sec:file_dir_creat_rem}).
 
 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*}
 \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
   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.
 
 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. 
 
 automaticamente propagato, restando coerente a quello della directory di
 partenza, in tutte le sotto-directory. 
 
@@ -3670,7 +3969,7 @@ risultato di coerenza che si ha con BSD necessita che quando si creano nuove
 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
 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
 dello stesso.
 
 La presenza del bit \acr{sgid} è inoltre molto comoda quando si hanno
@@ -3702,7 +4001,7 @@ l'utente che il gruppo a cui un file appartiene; i rispettivi prototipi sono:
   \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}
   \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
     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
@@ -4413,15 +4712,15 @@ identificatori del gruppo \textit{effective} del processo, ma in presenza di
 ACL i passi attraverso i quali viene stabilito se esso ha diritto di accesso
 sono i seguenti:
 \begin{enumerate*}
 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.
   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*}
   \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
   presente in una voce \const{ACL\_USER} allora:
   \begin{itemize*}
   \item se la voce \const{ACL\_USER} corrispondente e la voce
@@ -4429,7 +4728,7 @@ sono i seguenti:
     consentito;
   \item altrimenti l'accesso è negato.
   \end{itemize*}
     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
   corrisponde al gruppo proprietario del file allora: 
   \begin{itemize*}
   \item se la voce \const{ACL\_GROUP\_OBJ} e una eventuale voce
@@ -4438,7 +4737,7 @@ sono i seguenti:
     l'accesso è consentito;
   \item altrimenti l'accesso è negato.
   \end{itemize*}
     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*}
   corrisponde ad un qualunque qualificatore presente in una voce
   \const{ACL\_GROUP} allora:
   \begin{itemize*}
@@ -4782,7 +5081,7 @@ tab.~\ref{tab:acl_to_text_options}.
     \hline
     \const{TEXT\_ABBREVIATE}     & stampa le voci in forma abbreviata.\\
     \const{TEXT\_NUMERIC\_IDS}   & non effettua la risoluzione numerica di
     \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 
     \const{TEXT\_SOME\_EFFECTIVE}& per ciascuna voce che contiene permessi che
                                    vengono eliminati dalla \const{ACL\_MASK}
                                    viene generato un commento con i permessi 
@@ -5108,7 +5407,7 @@ La funzione richiede che il filesystem sul quale si vuole operare sia montato
 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
 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.
 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.
@@ -5217,10 +5516,10 @@ l'amministratore può ottenere i dati di tutti.
     \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
     \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
                             $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}
                             $2^{64}$ byte e $2^{64}$ file.\\
     \hline
   \end{tabular}
@@ -5688,7 +5987,7 @@ nell'esecuzione di un qualunque programma l'amministratore perderebbe tutti i
 privilegi originali dal processo.
 
 Per questo motivo se un programma senza \textit{capabilities} assegnate viene
 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
 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
@@ -5697,19 +5996,19 @@ il \acr{suid} bit ed appartiene all'amministratore, in entrambi i casi si
 riesce così a riottenere il comportamento classico di un sistema unix-like.
 
 Una seconda circostanza è quella relativa a cosa succede alle
 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*}
 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
   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};
   \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},
   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},
@@ -5744,7 +6043,7 @@ Per questo motivo a partire dal kernel 2.6.26, se le \textit{file
 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
 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}.
 
 attraverso una \func{fork}, mentre attraverso una \func{exec} viene sempre
 cancellato il flag \const{SECURE\_KEEP\_CAPS}.
 
@@ -5758,22 +6057,22 @@ 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
     \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
                                 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
                                 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à
                                 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
                                 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
                                 il \acr{suid} bit attivo ed appartiene
                                 all'amministratore (regola di compatibilità
                                 per l'esecuzione di programmi senza
@@ -6009,8 +6308,8 @@ capacità), o di impostare i \textit{securebits} delle \textit{capabilities}.
 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
 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: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
@@ -6035,7 +6334,7 @@ disattivare la swap, montare, rimontare e smontare filesystem (vedi
 sez.~\ref{sec:sys_file_config}), effettuare operazioni di controllo su
 qualunque oggetto dell'IPC di SysV (vedi sez.~\ref{sec:ipc_sysv}), operare
 sugli attributi estesi dei file di classe \texttt{security} o \texttt{trusted}
 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
 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
@@ -6658,7 +6957,7 @@ funzione.
 
 
 
 
 
 
-\subsection{La funzione \func{chroot}}
+\subsection{La gestione dei {chroot}}
 \label{sec:file_chroot}
 
 % TODO introdurre nuova sezione sulle funzionalità di sicurezza avanzate, con
 \label{sec:file_chroot}
 
 % TODO introdurre nuova sezione sulle funzionalità di sicurezza avanzate, con
@@ -6672,6 +6971,8 @@ Benché non abbia niente a che fare con permessi, utenti e gruppi, la funzione
 programma ad una sezione limitata del filesystem, per cui ne parleremo in
 questa sezione.
 
 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
 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
@@ -6704,7 +7005,7 @@ con la funzione \funcd{chroot}, il cui prototipo è:
 \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}
 \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};
   \end{errlist}
   ed inoltre \errval{EFAULT}, \errval{ENAMETOOLONG}, \errval{ENOENT},
   \errval{ENOMEM}, \errval{ENOTDIR}, \errval{EACCES}, \errval{ELOOP};
@@ -6823,7 +7124,7 @@ programmi e librerie) di cui il server potrebbe avere bisogno.
 % 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:  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
+% LocalWords:  fstatfs fstab mntent ino bound orig new setpcap metadati sysfs
 
 %%% Local Variables: 
 %%% mode: latex
 
 %%% Local Variables: 
 %%% mode: latex