% 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}
+\itindbeg{Virtual~File~System~(VFS)}
Come illustrato brevemente in sez.~\ref{sec:file_arch_overview} in Linux il
concetto di \textit{everything is a file} è stato implementato attraverso il
sez.~\ref{sec:file_dir_creat_rem}).\\
\textsl{\code{rmdir}} & Rimuove una directory (vedi
sez.~\ref{sec:file_dir_creat_rem}).\\
- \textsl{\code{mknod}} & Crea un \index{file!speciali} file speciale (vedi
+ \textsl{\code{mknod}} & Crea un file speciale (vedi
sez.~\ref{sec:file_mknod}).\\
\textsl{\code{rename}} & Cambia il nome di un file (vedi
sez.~\ref{sec:link_symlink_rename}).\\
possono esserci negli oggetti a cui si applicano.
-\itindend{Virtual~File~System}
+\itindend{Virtual~File~System~(VFS)}
% NOTE: documentazione interessante:
% * sorgenti del kernel: Documentation/filesystems/vfs.txt
indicati con la stringa contenente il loro \textit{pathname}.
Normalmente un filesystem è contenuto su un disco o una partizione, ma come
-illustrato in sez.~\ref{sec:file_vfs_work} la struttura del
-\itindex{Virtual~File~System} \textit{Virtual File System} è estremamente
-flessibile e può essere usata anche per oggetti diversi da un disco. Ad
-esempio usando il \textit{loop device} si può montare un file qualunque (come
-l'immagine di un CD-ROM o di un floppy) che contiene l'immagine di un
-filesystem, inoltre alcuni tipi di filesystem, come \texttt{proc} o
-\texttt{sysfs} sono virtuali e non hanno un supporto che ne contenga i dati,
-che invece sono generati al volo ad ogni lettura, e passati indietro al kernel
-ad ogni scrittura.\footnote{costituiscono quindi un meccanismo di
- comunicazione, attraverso l'ordinaria interfaccia dei file, con il kernel.}
+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
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 che lo compongono, detti anche \textit{mount flags}, devono
-essere impostati con un OR aritmetico dei valori dalle costanti riportate
-nell'elenco seguente:
+ \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
+che lo compongono, detti anche \textit{mount flags}, devono essere impostati
+con un OR aritmetico dei valori dalle costanti riportate nell'elenco seguente:
\begin{basedescript}{\desclabelwidth{2.cm}\desclabelstyle{\nextlinelabel}}
\itindbeg{bind~mount}
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 corrispondenza della \textit{dentry} di \texttt{target}
- un diverso \itindex{inode} \textit{inode}, che stavolta, invece di essere
- quello della radice del filesystem indicato da un file di dispositivo, è
- quello di una directory già montata.
+ Dal punto di vista del VFS l'operazione è analoga al montaggio di un
+ filesystem proprio nel fatto che anche in questo caso si inserisce in
+ corrispondenza della \textit{dentry} di \texttt{target} un diverso
+ \itindex{inode} \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
una fra \const{MS\_PRIVATE}, \const{MS\_SHARED}, \const{MS\_SLAVE} e
\const{MS\_UNBINDABLE}.
+ % TODO trattare l'opzione \texttt{lazytime} introdotta con il kernel 4.0,
+ % vedi http://lwn.net/Articles/621046/
+
\item[\const{MS\_RELATIME}] Indica di effettuare l'aggiornamento degli
\textit{access time} sul filesystem soltanto quando questo risulti
antecedente il valore corrente del \textit{modification time} o del
sullo stesso \itindex{mount~point} \textit{mount point} viene smontato quello
che è stato montato per ultimo. Si tenga presente che la funzione fallisce se
il filesystem è ``\textsl{occupato}'', cioè quando ci sono ancora dei file
-aperti sul filesystem, se questo contiene la \index{directory~di~lavoro}
-directory di lavoro di un qualunque processo o il \itindex{mount~point}
-\textit{mount point} di un altro filesystem.
+aperti sul filesystem, se questo contiene la directory di lavoro (vedi
+sez.~\ref{sec:file_work_dir}) di un qualunque processo o il
+\itindex{mount~point} \textit{mount point} di un altro filesystem.
Linux provvede inoltre una seconda funzione di sistema, \funcd{umount2}, che
consente un maggior controllo delle operazioni, come forzare lo smontaggio di
\begin{errlist}
\item[\errcode{EAGAIN}] si è chiamata la funzione con \const{MNT\_EXPIRE}
ed il filesystem non era occupato.
- \item[\errcode{EBUSY}] \param{target} è la \index{directory~di~lavoro}
- directory di lavoro di qualche processo, o contiene dei file aperti, o un
- altro mount point.
- \item[\errcode{EINVAL}] \param{target} non è un \itindex{mount~point}
- \textit{mount point} o si è usato \const{MNT\_EXPIRE} con
- \const{MNT\_FORCE} o \const{MNT\_DETACH} o si è specificato un flag non
- esistente.
+ \item[\errcode{EBUSY}] \param{target} è la directory di lavoro di qualche
+ processo, o contiene dei file aperti, o un altro \textit{mount point}.
+ \item[\errcode{EINVAL}] \param{target} non è un \textit{mount point} o si
+ è usato \const{MNT\_EXPIRE} con \const{MNT\_FORCE} o
+ \const{MNT\_DETACH} o si è specificato un flag non esistente.
\end{errlist}
e tutti gli altri valori visti per \func{umount} con lo stesso significato.}
\end{funcproto}
introdotta per evitare, per quei filesystem per il quale è prevista una
gestione diretta da parte degli utenti, come quelli basati su
FUSE,\footnote{il \textit{Filesystem in USEr space} (FUSE) è una delle più
- interessanti applicazioni del \itindex{Virtual~File~System} VFS che
- consente, tramite un opportuno modulo, di implementarne le funzioni in
- \textit{user space}, così da rendere possibile l'implementazione di un
- qualunque filesystem (con applicazioni di grande interesse come il
- filesystem cifrato \textit{encfs} o il filesystem di rete \textit{sshfs})
- che possa essere usato direttamente per conto degli utenti.} che si possano
-passare ai programmi che effettuano lo smontaggio dei filesystem, che in
-genere sono privilegiati ma consentono di agire solo sui propri \textit{mount
- point}, dei collegamenti simbolici che puntano ad altri \textit{mount
- point}, ottenendo così la possibilità di smontare qualunque filesystem.
+ interessanti applicazioni del VFS che consente, tramite un opportuno modulo,
+ di implementarne le funzioni in \textit{user space}, così da rendere
+ possibile l'implementazione di un qualunque filesystem (con applicazioni di
+ grande interesse come il filesystem cifrato \textit{encfs} o il filesystem
+ di rete \textit{sshfs}) che possa essere usato direttamente per conto degli
+ utenti.} che si possano passare ai programmi che effettuano lo smontaggio
+dei filesystem, che in genere sono privilegiati ma consentono di agire solo
+sui propri \textit{mount point}, dei collegamenti simbolici che puntano ad
+altri \textit{mount point}, ottenendo così la possibilità di smontare
+qualunque filesystem.
Altre due funzioni di sistema specifiche di Linux,\footnote{esse si trovano
non si potrebbe più rimuoverla.}
Data la pericolosità di questa operazione e la disponibilità dei collegamenti
-simbolici (che vedremo a breve) e dei \itindex{bind~mount} \textit{bind mount}
+simbolici (che vedremo a breve) e dei \textit{bind mount}
(già visti in sez.~\ref{sec:filesystem_mounting}) che possono fornire la
stessa funzionalità senza questi problemi, nel caso di Linux questa capacità è
stata completamente disabilitata, e al tentativo di creare un collegamento
directory che lo contiene e decrementa il numero di riferimenti nel relativo
\itindex{inode} \textit{inode}.\footnote{come per \func{link} queste due
operazioni sono effettuate all'interno della \textit{system call} in maniera
- atomica.} Nel caso di socket, fifo o file di dispositivo
-\index{file!di~dispositivo} rimuove il nome, ma come per i file normali i
-processi che hanno aperto uno di questi oggetti possono continuare ad
-utilizzarli. Nel caso di cancellazione di un collegamento simbolico, che
-consiste solo nel rimando ad un altro file, questo viene immediatamente
-eliminato.
+ atomica.} Nel caso di socket, fifo o file di dispositivo rimuove il nome, ma
+come per i file normali i processi che hanno aperto uno di questi oggetti
+possono continuare ad utilizzarli. Nel caso di cancellazione di un
+collegamento simbolico, che consiste solo nel rimando ad un altro file, questo
+viene immediatamente eliminato.
Per cancellare una voce in una directory è necessario avere il permesso di
scrittura su di essa, dato che si va a rimuovere una voce dal suo contenuto, e
quelle dei loro \textit{pathname} o di scrivere su \param{newpath}
se questa è una directory.
\item[\errcode{EBUSY}] o \param{oldpath} o \param{newpath} sono in uso da
- parte di qualche processo (come \index{directory~di~lavoro} directory di
- lavoro o come radice) o del sistema (come \itindex{mount~point}
- \textit{mount point}) ed il sistema non riesce a risolvere la situazione.
+ parte di qualche processo (come directory di lavoro o come radice) o del
+ sistema (come \textit{mount point}) ed il sistema non riesce a risolvere
+ la situazione.
\item[\errcode{EEXIST}] \param{newpath} è una directory già esistente e
non è vuota (anche \errcode{ENOTEMPTY}).
\item[\errcode{EINVAL}] \param{newpath} contiene un prefisso di
non è possibile trattarle come file ordinari e devono essere create
direttamente dal kernel attraverso una opportuna \textit{system
call}.\footnote{questo è quello che permette anche, attraverso l'uso del
- \itindex{Virtual~File~System} VFS, l'utilizzo di diversi formati per la
- gestione dei suddetti elenchi, dalle semplici liste a strutture complesse
- come alberi binari, hash, ecc. che consentono una ricerca veloce quando il
- numero di file è molto grande.} La funzione di sistema usata per creare una
-directory è \funcd{mkdir}, ed il suo prototipo è:
+ VFS, l'utilizzo di diversi formati per la gestione dei suddetti elenchi,
+ dalle semplici liste a strutture complesse come alberi binari, hash,
+ ecc. che consentono una ricerca veloce quando il numero di file è molto
+ grande.} La funzione di sistema usata per creare una directory è
+\funcd{mkdir}, ed il suo prototipo è:
\begin{funcproto}{
\fhead{sys/stat.h}
che contiene la directory che si vuole cancellare, o non c'è il permesso
di attraversare (esecuzione) una delle directory specificate in
\param{dirname}.
- \item[\errcode{EBUSY}] la directory specificata è la
- \index{directory~di~lavoro} directory di lavoro o la radice di qualche
- processo o un \itindex{mount~point} \textit{mount point}.
+ \item[\errcode{EBUSY}] la directory specificata è la directory di lavoro o
+ la radice di qualche processo o un \textit{mount point}.
\item[\errcode{EINVAL}] si è usato ``\texttt{.}'' come ultimo componente
di \param{dirname}.
\item[\errcode{EPERM}] il filesystem non supporta la cancellazione di
in sez.~\ref{sec:file_open_close} che è possibile aprire una directory come se
fosse un file, anche se solo in sola lettura) in generale il formato con cui
esse sono scritte può dipendere dal tipo di filesystem, tanto che, come
-riportato in tab.~\ref{tab:file_file_operations}, il
-\itindex{Virtual~File~System} VFS prevede una apposita funzione per la lettura
-delle directory.
+riportato in tab.~\ref{tab:file_file_operations}, il VFS prevede una apposita
+funzione per la lettura delle directory.
\itindbeg{directory~stream}
Si tenga presente che comunque la funzione opera associando il
\textit{directory stream} ad un opportuno file descriptor sottostante, sul
quale vengono compiute le operazioni. Questo viene sempre aperto impostando il
-flag di \itindex{close-on-exec} \textit{close-on-exec} (si ricordi quanto
-detto in sez.~\ref{sec:proc_exec}), così da evitare che resti aperto in caso
-di esecuzione di un altro programma.
+flag di \textit{close-on-exec} (si ricordi quanto detto in
+sez.~\ref{sec:proc_exec}), così da evitare che resti aperto in caso di
+esecuzione di un altro programma.
Nel caso in cui sia necessario conoscere il \textit{file descriptor} associato
ad un \textit{directory stream} si può usare la funzione
stream} \param{dir}. Di solito si utilizza questa funzione in abbinamento a
funzioni che operano sui file descriptor, ad esempio si potrà usare
\func{fstat} per ottenere le proprietà della directory, o \func{fchdir} per
-spostare su di essa la \index{directory~di~lavoro} directory di lavoro (vedi
+spostare su di essa la directory di lavoro (vedi
sez.~\ref{sec:file_work_dir}).
Viceversa se si è aperto un file descriptor corrispondente ad una directory è
utilizzato all'interno del proprio programma. In particolare dovrà essere
chiuso attraverso il \textit{directory stream} con \func{closedir} e non
direttamente. Si tenga presente inoltre che \func{fdopendir} non modifica lo
-stato di un eventuale flag di \itindex{close-on-exec} \textit{close-on-exec},
-che pertanto dovrà essere impostato esplicitamente in fase di apertura del
-file descriptor.
+stato di un eventuale flag di \textit{close-on-exec}, che pertanto dovrà
+essere impostato esplicitamente in fase di apertura del file descriptor.
Una volta che si sia aperto un \textit{directory stream} la lettura del
contenuto della directory viene effettuata attraverso la funzione
una struttura allocata staticamente, che viene sovrascritta tutte le volte che
si ripete la lettura di una voce sullo stesso \textit{directory stream}.
-Di questa funzione esiste anche una versione \index{funzioni!rientranti}
-rientrante, \funcd{readdir\_r},\footnote{per usarla è necessario definire una
- qualunque delle macro \texttt{\macro{\_POSIX\_C\_SOURCE} >= 1},
+Di questa funzione esiste anche una versione rientrante,
+\funcd{readdir\_r},\footnote{per usarla è necessario definire una qualunque
+ delle macro \texttt{\macro{\_POSIX\_C\_SOURCE} >= 1},
\macro{\_XOPEN\_SOURCE}, \macro{\_BSD\_SOURCE}, \macro{\_SVID\_SOURCE},
\macro{\_POSIX\_SOURCE}.} che non usa una struttura allocata staticamente, e
può essere utilizzata anche con i \itindex{thread} \textit{thread}, il suo
18-22}) uno \textit{stream} sulla directory passata come primo argomento,
stampando un messaggio in caso di errore.
-Il passo successivo (\texttt{\small 23-24}) è cambiare
-\index{directory~di~lavoro} directory di lavoro (vedi
-sez.~\ref{sec:file_work_dir}), usando in sequenza le funzioni \func{dirfd} e
-\func{fchdir} (in realtà si sarebbe potuto usare direttamente \func{chdir} su
-\var{dirname}), in modo che durante il successivo ciclo (\texttt{\small
- 26-30}) sulle singole voci dello \textit{stream} ci si trovi all'interno
-della directory.\footnote{questo è essenziale al funzionamento della funzione
- \code{do\_ls}, e ad ogni funzione che debba usare il campo \var{d\_name}, in
- quanto i nomi dei file memorizzati all'interno di una struttura
- \struct{dirent} sono sempre relativi alla directory in questione, e senza
- questo posizionamento non si sarebbe potuto usare \func{stat} per ottenere
- le dimensioni.}
+Il passo successivo (\texttt{\small 23-24}) è cambiare directory di lavoro
+(vedi sez.~\ref{sec:file_work_dir}), usando in sequenza le funzioni
+\func{dirfd} e \func{fchdir} (in realtà si sarebbe potuto usare direttamente
+\func{chdir} su \var{dirname}), in modo che durante il successivo ciclo
+(\texttt{\small 26-30}) sulle singole voci dello \textit{stream} ci si trovi
+all'interno della directory.\footnote{questo è essenziale al funzionamento
+ della funzione \code{do\_ls}, e ad ogni funzione che debba usare il campo
+ \var{d\_name}, in quanto i nomi dei file memorizzati all'interno di una
+ struttura \struct{dirent} sono sempre relativi alla directory in questione,
+ e senza questo posizionamento non si sarebbe potuto usare \func{stat} per
+ ottenere le dimensioni.}
Avendo usato lo stratagemma di fare eseguire tutte le manipolazioni necessarie
alla funzione passata come secondo argomento, il ciclo di scansione della
\const{L\_tmpnam}, \const{P\_tmpdir} e \const{TMP\_MAX} sono definite in
\headfile{stdio.h}.}
-Di questa funzione esiste una versione \index{funzioni!rientranti} rientrante,
+Di questa funzione esiste una versione \ rientrante,
\funcm{tmpnam\_r}, che non fa nulla quando si passa \val{NULL} come argomento.
Una funzione simile, \funcd{tempnam}, permette di specificare un prefisso per
il file esplicitamente, il suo prototipo è:
\end{funcproto}
La funzione alloca con \code{malloc} la stringa in cui restituisce il nome,
-per cui è sempre \index{funzioni!rientranti} rientrante, occorre però
+per cui è sempre \ rientrante, occorre però
ricordarsi di disallocare con \code{free} il puntatore che restituisce.
L'argomento \param{pfx} specifica un prefisso di massimo 5 caratteri per il
nome provvisorio. La funzione assegna come directory per il file temporaneo,
che viene automaticamente cancellato alla sua chiusura o all'uscita dal
programma. Lo standard non specifica in quale directory verrà aperto il file,
ma la \acr{glibc} prima tenta con \const{P\_tmpdir} e poi con
-\file{/tmp}. Questa funzione è \index{funzioni!rientranti} rientrante e non
-soffre di problemi di \itindex{race~condition} \textit{race condition}.
+\file{/tmp}. Questa funzione è rientrante e non soffre di problemi di
+\itindex{race~condition} \textit{race condition}.
Alcune versioni meno recenti di Unix non supportano queste funzioni; in questo
caso si possono usare le vecchie funzioni \funcd{mktemp} e \func{mkstemp} che
\var{st\_size} non è detto che corrisponda all'occupazione dello spazio su
disco, e non solo perché la parte finale del file potrebbe riempire
parzialmente un blocco. In un sistema unix-like infatti è possibile
-l'esistenza dei cosiddetti \itindex{sparse~file} \textit{sparse file}, cioè
-file in cui sono presenti dei ``\textsl{buchi}'' \index{file!\textit{hole}}
-(\textit{holes} nella nomenclatura inglese) che si formano tutte le volte che
-si va a scrivere su un file dopo aver eseguito uno spostamento oltre la sua
-fine (tratteremo in dettaglio l'argomento in sez.~\ref{sec:file_lseek}).
+l'esistenza dei cosiddetti \textit{sparse file}, cioè file in cui sono
+presenti dei ``\textsl{buchi}'' (\textit{holes} nella nomenclatura inglese)
+che si formano tutte le volte che si va a scrivere su un file dopo aver
+eseguito uno spostamento oltre la sua fine (tratteremo in dettaglio
+l'argomento in sez.~\ref{sec:file_lseek}).
In questo caso si avranno risultati differenti a seconda del modo in cui si
calcola la lunghezza del file, ad esempio il comando \cmd{du}, (che riporta il
numero di blocchi occupati) potrà dare una dimensione inferiore, mentre se si
legge dal file (ad esempio usando il comando \cmd{wc -c}), dato che in tal
-caso per i ``\textsl{buchi}'' \index{file!\textit{hole}} vengono restituiti
-degli zeri, si avrà lo stesso risultato di \cmd{ls}.
+caso per i ``\textsl{buchi}'' vengono restituiti degli zeri, si avrà lo stesso
+risultato di \cmd{ls}.
Se è sempre possibile allargare un file, scrivendoci sopra o usando la
funzione \func{lseek} (vedi sez.~\ref{sec:file_lseek}) per spostarsi oltre la
Il comportamento in caso di lunghezza del file inferiore a \param{length} non
è specificato e dipende dall'implementazione: il file può essere lasciato
invariato o esteso fino alla lunghezza scelta. Nel caso di Linux viene esteso
-con la creazione di un \index{file!\textit{hole}} \textsl{buco} nel
-\itindex{sparse~file} file e ad una lettura si otterranno degli zeri, si tenga
-presente però che questo comportamento è supportato solo per filesystem
-nativi, ad esempio su un filesystem non nativo come il VFAT di Windows questo
-non è possibile.
+con la creazione di un \textsl{buco} nel file e ad una lettura si otterranno
+degli zeri, si tenga presente però che questo comportamento è supportato solo
+per filesystem nativi, ad esempio su un filesystem non nativo come il VFAT di
+Windows questo non è possibile.
\subsection{I tempi dei file}
campi della struttura \struct{stat} è illustrato nello schema di
tab.~\ref{tab:file_file_times}, dove è anche riportato un esempio delle
funzioni che effettuano cambiamenti su di essi. Il valore del tempo è espresso
-nel cosiddetto \itindex{calendar~time} \textit{calendar time}, su cui
-torneremo in dettaglio in sez.~\ref{sec:sys_time}.
+nel cosiddetto \textit{calendar time}, su cui torneremo in dettaglio in
+sez.~\ref{sec:sys_time}.
\begin{table}[htb]
\centering
anche alla chiamata di \func{utime}. Questo serve anche come misura di
sicurezza per evitare che si possa modificare un file nascondendo
completamente le proprie tracce. In realtà la cosa resta possibile se si è in
-grado di accedere al \index{file!di~dispositivo} file di dispositivo,
-scrivendo direttamente sul disco senza passare attraverso il filesystem, ma
-ovviamente in questo modo la cosa è più complicata da
-realizzare.\footnote{esistono comunque molti programmi che consentono di farlo
- con relativa semplicità per cui non si dia per scontato che il valore sia
- credibile in caso di macchina compromessa.}
+grado di accedere al file di dispositivo, scrivendo direttamente sul disco
+senza passare attraverso il filesystem, ma ovviamente in questo modo la cosa è
+più complicata da realizzare.\footnote{esistono comunque molti programmi che
+ consentono di farlo con relativa semplicità per cui non si dia per scontato
+ che il valore sia credibile in caso di macchina compromessa.}
A partire dal kernel 2.6 la risoluzione dei tempi dei file, che nei campi di
tab.~\ref{tab:file_file_times} è espressa in secondi, è stata portata ai
Torneremo su questa sintassi e sulla sua motivazione in
sez.~\ref{sec:file_openat}, quando tratteremo tutte le altre funzioni (le
-cosiddette \itindex{at-functions} \textit{at-functions}) che la utilizzano;
-essa prevede comunque anche la presenza dell'argomento \param{flags} con cui
-attivare flag di controllo che modificano il comportamento della funzione, nel
-caso specifico l'unico valore consentito è \const{AT\_SYMLINK\_NOFOLLOW} che
-indica alla funzione di non dereferenziare i collegamenti simbolici, cosa che
-le permette di riprodurre le funzionalità di \func{lutimes}.
+cosiddette \textit{at-functions}) che la utilizzano; essa prevede comunque
+anche la presenza dell'argomento \param{flags} con cui attivare flag di
+controllo che modificano il comportamento della funzione, nel caso specifico
+l'unico valore consentito è \const{AT\_SYMLINK\_NOFOLLOW} che indica alla
+funzione di non dereferenziare i collegamenti simbolici, cosa che le permette
+di riprodurre le funzionalità di \func{lutimes}.
\itindex{race~condition} \textit{race condition} che apre ad un possibile
\itindex{symlink~attack} \textit{symlink attack} fra il controllo e l'apertura
del file. In questo caso è sempre opportuno usare invece la funzione
-\func{faccessat} che tratteremo insieme alle altre \itindex{at-functions}
-\textit{at-functions} in sez.~\ref{sec:file_openat}.
+\func{faccessat} che tratteremo insieme alle altre \textit{at-functions} in
+sez.~\ref{sec:file_openat}.
Del tutto analoghe a \func{access} sono le due funzioni \funcm{euidaccess} e
\funcm{eaccess} che ripetono lo stesso controllo usando però gli
notazione illustrata in fig.~\ref{fig:file_perm_bit}.
Si ricordi infine che i permessi non hanno alcun significato per i
-collegamenti simbolici, mentre per i \index{file!di~dispositivo} file di
-dispositivo hanno senso soltanto i permessi di lettura e scrittura, che si
-riflettono sulla possibilità di compiere dette operazioni sul dispositivo
-stesso.
+collegamenti simbolici, mentre per i file di dispositivo hanno senso soltanto
+i permessi di lettura e scrittura, che si riflettono sulla possibilità di
+compiere dette operazioni sul dispositivo stesso.
Nella tabella si è indicato con il carattere ``-'' il fatto che il valore del
bit in questione non è influente rispetto a quanto indicato nella riga della
directory ordinarie, se valesse in generale infatti si avrebbe un serio
problema di sicurezza dato che esistono diversi oggetti sul filesystem per i
quali è normale avere avere il permesso di scrittura consentito a tutti gli
- utenti, come i collegamenti simbolici, o alcuni \index{file!di~dispositivo}
- file di dispositivo come \texttt{/dev/null}. Se fosse possibile usare su di
- essi gli \textit{extended user attributes} un utente qualunque potrebbe
- inserirvi dati a piacere.\footnote{la cosa è stata notata su XFS, dove
- questo comportamento permetteva, non essendovi limiti sullo spazio
- occupabile dagli \textit{Extended Attributes}, di bloccare il sistema
- riempiendo il disco.}
+ utenti, come i collegamenti simbolici, o alcuni file di dispositivo come
+ \texttt{/dev/null}. Se fosse possibile usare su di essi gli \textit{extended
+ user attributes} un utente qualunque potrebbe inserirvi dati a
+ piacere.\footnote{la cosa è stata notata su XFS, dove questo comportamento
+ permetteva, non essendovi limiti sullo spazio occupabile dagli
+ \textit{Extended Attributes}, di bloccare il sistema riempiendo il disco.}
La semantica del controllo di accesso indicata inoltre non avrebbe alcun
senso al di fuori di file e directory: i permessi di lettura e scrittura per
- un \index{file!di~dispositivo} file di dispositivo attengono alle capacità
- di accesso al dispositivo sottostante,\footnote{motivo per cui si può
- formattare un disco anche se \texttt{/dev} è su un filesystem in sola
- lettura.} mentre per i collegamenti simbolici questi vengono semplicemente
- ignorati: in nessuno dei due casi hanno a che fare con il contenuto del
- file, e nella discussione relativa all'uso degli \textit{extended user
- attributes} nessuno è mai stato capace di indicare una qualche forma
- sensata di utilizzo degli stessi per collegamenti simbolici o
- \index{file!di~dispositivo} file di dispositivo, e neanche per le fifo o i
+ un file di dispositivo attengono alle capacità di accesso al dispositivo
+ sottostante,\footnote{motivo per cui si può formattare un disco anche se
+ \texttt{/dev} è su un filesystem in sola lettura.} mentre per i
+ collegamenti simbolici questi vengono semplicemente ignorati: in nessuno dei
+ due casi hanno a che fare con il contenuto del file, e nella discussione
+ relativa all'uso degli \textit{extended user attributes} nessuno è mai stato
+ capace di indicare una qualche forma sensata di utilizzo degli stessi per
+ collegamenti simbolici o file di dispositivo, e neanche per le fifo o i
socket. Per questo motivo essi sono stati completamente disabilitati per
tutto ciò che non sia un file regolare o una directory.\footnote{si può
verificare la semantica adottata consultando il file \texttt{fs/xattr.c}
rivoluzionato, rendendolo più aderente alle intenzioni originali dello
standard POSIX, rimuovendo il significato che fino ad allora aveva avuto la
capacità \const{CAP\_SETPCAP} e cambiando le modalità di funzionamento del
-cosiddetto \itindex{capabilities~bounding~set} \textit{capabilities bounding
- set}. Ulteriori modifiche sono state apportate con il kernel 2.6.26 per
-consentire la rimozione non ripristinabile dei privilegi di
-amministratore. Questo fa sì che il significato ed il comportamento del kernel
-finisca per dipendere dalla versione dello stesso e dal fatto che le nuove
-\textit{file capabilities} siano abilitate o meno. Per capire meglio la
-situazione e cosa è cambiato conviene allora spiegare con maggiori dettagli
-come funziona il meccanismo delle \textit{capabilities}.
+cosiddetto \textit{capabilities bounding set}. Ulteriori modifiche sono state
+apportate con il kernel 2.6.26 per consentire la rimozione non ripristinabile
+dei privilegi di amministratore. Questo fa sì che il significato ed il
+comportamento del kernel finisca per dipendere dalla versione dello stesso e
+dal fatto che le nuove \textit{file capabilities} siano abilitate o meno. Per
+capire meglio la situazione e cosa è cambiato conviene allora spiegare con
+maggiori dettagli come funziona il meccanismo delle \textit{capabilities}.
Il primo passo per frazionare i privilegi garantiti all'amministratore,
supportato fin dalla introduzione iniziale del kernel 2.2, è stato quello in
\textit{immutable} e \textit{append-only} (vedi
sez.~\ref{sec:file_perm_overview}) se
supportati.\\
- \const{CAP\_MKNOD} & Creare \index{file!di~dispositivo} file di
- dispositivo con \func{mknod} (vedi
+ \const{CAP\_MKNOD} & Creare file di dispositivo con \func{mknod} (vedi
sez.~\ref{sec:file_mknod}) (dal kernel 2.4).\\
\const{CAP\_NET\_ADMIN} & Eseguire alcune operazioni
privilegiate sulla rete.\\
% informazioni su setns qui: http://lwn.net/Articles/532748/
% http://lwn.net/Articles/531498/
-
% TODO: spostare chroot e le funzioni affini relative ai container da qualche
% parte diversa se è il caso.
+% TODO Inheriting capabilities vedi http://lwn.net/Articles/632520/ eambient
+% capabilities introdotte con il kernel 4.3, vedi
+% http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=58319057b7847667f0c9585b9de0e8932b0fdb08
Benché non abbia niente a che fare con permessi, utenti e gruppi, la funzione
\func{chroot} viene usata spesso per restringere le capacità di accesso di un
questa sezione.
Come accennato in sez.~\ref{sec:proc_fork} ogni processo oltre ad una
-\index{directory~di~lavoro} directory di lavoro, ha anche una directory
-\textsl{radice}\footnote{entrambe sono contenute in due campi (rispettivamente
- \var{pwd} e \var{root}) di \kstruct{fs\_struct}; vedi
- fig.~\ref{fig:proc_task_struct}.} che, pur essendo di norma corrispondente
-alla radice dell'albero dei file dell'intero sistema, ha per il processo il
-significato specifico di directory rispetto alla quale vengono risolti i
-\itindsub{pathname}{assoluto}\textit{pathname} assoluti.\footnote{cioè quando
- un processo chiede la risoluzione di un \textit{pathname}, il kernel usa
- sempre questa directory come punto di partenza.} Il fatto che questo valore
-sia specificato per ogni processo apre allora la possibilità di modificare le
-modalità di risoluzione dei \itindsub{pathname}{assoluto} \textit{pathname}
-assoluti da parte di un processo cambiando questa directory, così come si fa
-coi \itindsub{pathname}{relativo} \textit{pathname} relativi cambiando la
-\index{directory~di~lavoro} directory di lavoro.
+directory di lavoro, ha anche una directory \textsl{radice}\footnote{entrambe
+ sono contenute in due campi (rispettivamente \var{pwd} e \var{root}) di
+ \kstruct{fs\_struct}; vedi fig.~\ref{fig:proc_task_struct}.} che, pur
+essendo di norma corrispondente alla radice dell'albero dei file dell'intero
+sistema, ha per il processo il significato specifico di directory rispetto
+alla quale vengono risolti i \itindsub{pathname}{assoluto}\textit{pathname}
+assoluti.\footnote{cioè quando un processo chiede la risoluzione di un
+ \textit{pathname}, il kernel usa sempre questa directory come punto di
+ partenza.} Il fatto che questo valore sia specificato per ogni processo apre
+allora la possibilità di modificare le modalità di risoluzione dei
+\itindsub{pathname}{assoluto} \textit{pathname} assoluti da parte di un
+processo cambiando questa directory, così come si fa coi
+\itindsub{pathname}{relativo} \textit{pathname} relativi cambiando la
+directory di lavoro.
Normalmente la directory radice di un processo coincide con la radice generica
dell'albero dei file, che è la directory che viene montata direttamente dal
Questo è il motivo per cui la funzione è efficace nel restringere un processo
ad un ramo di albero solo se dopo averla eseguita si cedono i privilegi di
amministratore. Infatti se per un qualunque motivo il processo resta con la
-sua \index{directory~di~lavoro} directory di lavoro al di fuori dalla
-\textit{chroot jail}, potrà accedere a tutto il resto del filesystem usando
-\itindsub{pathname}{relativo} dei \textit{pathname} relativi, dato che in tal
-caso è possibile, grazie all'uso di ``\texttt{..}'', risalire all'indietro
-fino alla radice effettiva dell'albero dei file.
+sua directory di lavoro al di fuori dalla \textit{chroot jail}, potrà accedere
+a tutto il resto del filesystem usando \itindsub{pathname}{relativo} dei
+\textit{pathname} relativi, dato che in tal caso è possibile, grazie all'uso
+di ``\texttt{..}'', risalire all'indietro fino alla radice effettiva
+dell'albero dei file.
Potrebbe sembrare che per risolvere il problema sia sufficiente ricordarsi di
eseguire preventivamente anche una \func{chdir} sulla directory su cui si
andrà ad eseguire \func{chroot}, così da assicurarsi che le directory di
lavoro sia all'interno della \textit{chroot jail}. Ma se ad un processo
restano i privilegi di amministratore esso potrà comunque portare la sua
-\index{directory~di~lavoro} directory di lavoro fuori dalla \textit{chroot
- jail} in cui si trova. Basterà infatti eseguire di nuovo \func{chroot} su
-una qualunque directory contenuta nell'attuale directory di lavoro perché
-quest'ultima risulti al di fuori della nuova \textit{chroot jail}. Per questo
-motivo l'uso di questa funzione non ha molto senso quando un processo di cui
-si vuole limitare l'accesso necessita comunque dei privilegi di amministratore
-per le sue normali operazioni.
+directory di lavoro fuori dalla \textit{chroot jail} in cui si trova. Basterà
+infatti eseguire di nuovo \func{chroot} su una qualunque directory contenuta
+nell'attuale directory di lavoro perché quest'ultima risulti al di fuori della
+nuova \textit{chroot jail}. Per questo motivo l'uso di questa funzione non ha
+molto senso quando un processo di cui si vuole limitare l'accesso necessita
+comunque dei privilegi di amministratore per le sue normali operazioni.
Nonostante queste limitazioni la funzione risulta utile qualora la si possa
applicare correttamente cedendo completamente i privilegi di amministratore
projects / gapil.git / blobdiff