%% 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",
dovrà creare anche la relativa versione della funzione \code{mount}.
\itindbeg{pathname}
+\itindbeg{pathname~resolution}
Come illustrato in fig.~\ref{fig:kstruct_file_system_type} questa funzione
restituisce una \textit{dentry}, abbreviazione che sta per \textit{directory
filesystem.
\itindend{pathname}
+\itindend{pathname~resolution}
% Un secondo effetto della chiamata funzione \texttt{mount} di
% \kstruct{file\_system\_type} è quello di allocare una struttura
funzione \texttt{open} che invece è citata in
tab.~\ref{tab:file_file_operations}.\footnote{essa può essere comunque
invocata dato che nella struttura \kstruct{inode} è presente anche il
- puntatore \func{i\_fop} alla struttura \kstruct{file\_operation} che
- fornisce detta funzione.} Questo avviene perché su Linux l'apertura di un
-file richiede comunque un'altra operazione che mette in gioco l'omonimo
-oggetto del VFS: l'allocazione di una struttura di tipo \kstruct{file} che
-viene associata ad ogni file aperto nel sistema.
+ puntatore \var{i\_fop} alla struttura \kstruct{file\_operation} che fornisce
+ detta funzione.} Questo avviene perché su Linux l'apertura di un file
+richiede comunque un'altra operazione che mette in gioco l'omonimo oggetto del
+VFS: l'allocazione di una struttura di tipo \kstruct{file} che viene associata
+ad ogni file aperto nel sistema.
I motivi per cui viene usata una struttura a parte sono diversi, anzitutto,
come illustrato in sez.~\ref{sec:file_fd}, questa è necessaria per le
Come si può notare dall'estratto di fig.~\ref{fig:kstruct_file}, la struttura
\kstruct{file} contiene, oltre ad alcune informazioni usate dall'interfaccia
dei file descriptor il cui significato emergerà più avanti, il puntatore
-\struct{f\_op} ad una struttura \kstruct{file\_operation}. Questa è l'analoga
-per i file di \kstruct{inode\_operation}, e definisce le operazioni generiche
+\var{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.
partizioni. In essa per semplicità si è fatto riferimento alla struttura del
filesystem \acr{ext2}, che prevede una suddivisione dei dati in \textit{block
group}. All'interno di ciascun \textit{block group} viene anzitutto
-replicato il cosiddetto \textit{superblock}, (la struttura che contiene
-l'indice iniziale del filesystem e che consente di accedere a tutti i dati
-sottostanti) e creata una opportuna suddivisione dei dati e delle informazioni
-per accedere agli stessi. Sulle caratteristiche di \acr{ext2} e derivati
-torneremo in sez.~\ref{sec:file_ext2}.
+replicato il cosiddetto \itindex{superblock} \textit{superblock}, (la
+struttura che contiene l'indice iniziale del filesystem e che consente di
+accedere a tutti i dati sottostanti) e creata una opportuna suddivisione dei
+dati e delle informazioni per accedere agli stessi. Sulle caratteristiche di
+\acr{ext2} e derivati torneremo in sez.~\ref{sec:file_ext2}.
\itindbeg{inode}
Se si va ad esaminare con maggiore dettaglio la strutturazione
dell'informazione all'interno del filesystem \textsl{ext2}, tralasciando i
dettagli relativi al funzionamento del filesystem stesso come la
-strutturazione in gruppi dei blocchi, il \textit{superblock} e tutti i dati di
-gestione possiamo esemplificare la situazione con uno schema come quello
-esposto in fig.~\ref{fig:file_filesys_detail}.
+strutturazione in gruppi dei blocchi, il \itindex{superblock}
+\textit{superblock} e tutti i dati di gestione possiamo esemplificare la
+situazione con uno schema come quello esposto in
+fig.~\ref{fig:file_filesys_detail}.
\begin{figure}[!htb]
\centering
in gruppi di blocchi.
Ciascun gruppo di blocchi contiene una copia delle informazioni essenziali del
-filesystem (i \textit{superblock} sono quindi ridondati) per una maggiore
-affidabilità e possibilità di recupero in caso di corruzione del
-\textit{superblock} principale. L'utilizzo di raggruppamenti di blocchi ha
-inoltre degli effetti positivi nelle prestazioni dato che viene ridotta la
-distanza fra i dati e la tabella degli \itindex{inode} inode.
+filesystem (i \itindex{superblock} \textit{superblock} sono quindi ridondati)
+per una maggiore affidabilità e possibilità di recupero in caso di corruzione
+del \itindex{superblock} \textit{superblock} principale. L'utilizzo di
+raggruppamenti di blocchi ha inoltre degli effetti positivi nelle prestazioni
+dato che viene ridotta la distanza fra i dati e la tabella degli
+\itindex{inode} inode.
\begin{figure}[!htb]
\centering
illustrato, ottenendo un forte guadagno di prestazioni in caso di directory
contenenti un gran numero di file.
-% TODO portare a ext3, ext4 e btrfs ed illustrare le problematiche che si
-% possono incontrare (in particolare quelle relative alla perdita di contenuti
-% in caso di crash del sistema)
+% TODO (bassa priorità) portare a ext3, ext4 e btrfs ed illustrare le
+% problematiche che si possono incontrare (in particolare quelle relative alla
+% perdita di contenuti in caso di crash del sistema)
+% TODO (media priorità) trattare btrfs quando sarà usato come stabile
\subsection{La gestione dell'uso dei filesystem}
caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EACCES}] non si ha il permesso di accesso su uno dei
- componenti del \itindex{pathname} \textit{pathname}, o si è cercato di
- montare un filesystem disponibile in sola lettura senza aver specificato
- \const{MS\_RDONLY} o il device \param{source} è su un filesystem montato
- con l'opzione \const{MS\_NODEV}.
+ componenti del \textit{pathname}, o si è cercato di montare un filesystem
+ disponibile in sola lettura senza aver specificato \const{MS\_RDONLY} o il
+ device \param{source} è su un filesystem montato con l'opzione
+ \const{MS\_NODEV}.
\item[\errcode{EBUSY}] \param{source} è già montato, o non può essere
rimontato in sola lettura perché ci sono ancora file aperti in scrittura,
o non può essere montato su \param{target} perché la directory è ancora in
uso.
\item[\errcode{EINVAL}] il dispositivo \param{source} presenta un
- \textit{superblock} non valido, o si è cercato di rimontare un filesystem
- non ancora montato, o di montarlo senza che \param{target} sia un
- \itindex{mount~point} \textit{mount point} o di spostarlo
- quando \param{target} non è un \itindex{mount~point} \textit{mount point}
- o è la radice.
- \item[\errcode{EMFILE}] la tabella dei device \textit{dummy} è piena.
+ \itindex{superblock} \textit{superblock} non valido, o si è cercato di
+ rimontare un filesystem non ancora montato, o di montarlo senza
+ che \param{target} sia un \itindex{mount~point} \textit{mount point} o di
+ spostarlo quando \param{target} non è un \itindex{mount~point}
+ \textit{mount point} o è la radice.
+ \item[\errcode{ELOOP}] si è cercato di spostare un \itindex{mount~point}
+ \textit{mount point} su una sottodirectory di \param{source} o si sono
+ incontrati troppi link simbolici 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
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}
La funzione monta sulla directory indicata da \param{target}, detta
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}.
+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
disponibile nella directory specificata come \itindex{mount~point}
\textit{mount point}, il precedente contenuto di detta directory viene
mascherato dal contenuto della directory radice del filesystem montato. Fino
-ai kernel della serie 2.2.x non era possibile montare un filesytem se un
+ai kernel della serie 2.2.x non era possibile montare un filesystem se un
\textit{mount point} era già in uso.
A partire dal kernel 2.4.x inoltre è divenuto possibile sia spostare
\itindex{magic~number} \textit{magic number} \code{0xC0ED}, si può usare la
costante \const{MS\_MGC\_MSK} per ottenere la parte di \param{mountflags}
riservata al \textit{magic number}, mentre per specificarlo si può dare un
- OR aritmetico con la costante \const{MS\_MGC\_VAL}.} oggi invece sono
-ignorati mentre i 16 meno significativi sono usati per specificare le opzioni
-come maschera binaria e vanno impostati con un OR aritmetico dei valori
-riportati nell'elenco seguente:
+ 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 \texttt{source}, che
+ 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 \texttt{target} che indicherà la directory su cui verrà
+ 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 \texttt{target} viene montato l'\textit{inode}
- di \texttt{source}, così che la porzione di albero dei file presente sotto
- \texttt{source} diventi visibile allo stesso modo sotto
- \texttt{target}. Trattandosi esattamente di dati dello stesso filesystem,
+ In sostanza quello che avviene è che in corrispondenza del \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.
+ caso si inserisce in corrispondenza della \textit{dentry} di \texttt{target}
+ un diverso \textit{inode}, che stavolta, invece di essere quello della
+ radice del filesystem indicato da un file di dispositivo, è quello di una
+ directory già montata.
- Si tenga presente che proprio per questo sotto \texttt{target} comparirà il
- contenuto che è presente sotto \texttt{source} all'interno del filesystem in
+ 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 \texttt{source} qualora in una
+ 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 \texttt{source} si
- troverebbe il contenuto del nuovo filesystem (o di un altro \textit{bind
- mount}) mentre sotto \texttt{target} ci sarebbe il contenuto presente nel
- filesystem originale.\footnote{questo evita anche il problema dei
- \textit{loop} di fig.~\ref{fig:file_link_loop}, dato che se anche si
- montasse su \texttt{target} una directory in cui essa è contenuta, il
- cerchio non potrebbe chiudersi perché ritornati a \texttt{target} dentro
- il \textit{bind mount} vi si troverebbe solo il contenuto originale e non
- si potrebbe tornare indietro.}
+ 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
- \texttt{target} sia effettuabile esclusivamente in sola lettura.
+ \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
\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). Questo significa che la
- bufferizzazione effettuata dal
-
-\item[\const{MS\_MANDLOCK}] Consente il \textit{mandatory locking}
- \itindex{mandatory~locking} (vedi sez.~\ref{sec:file_mand_locking}).
-
-\item[\const{MS\_MOVE}] Sposta atomicamente il punto di montaggio.
-
-\item[\const{MS\_NOATIME}] Non aggiorna gli \textit{access time} (vedi
- sez.~\ref{sec:file_file_times}).
-
-\item[\const{MS\_NODEV}] Impedisce l'accesso ai file di dispositivo.
-
-\item[\const{MS\_NODIRATIME}] Non aggiorna gli \textit{access time} delle
- directory.
-\item[\const{MS\_NOEXEC}] Impedisce di eseguire programmi.
-
-\item[\const{MS\_NOSUID}] Ignora i bit \itindex{suid~bit} \acr{suid} e
- \itindex{sgid~bit} \acr{sgid}.
-
-\item[\const{MS\_PRIVATE}] (non documentato).
-
-\item[\const{MS\_RDONLY}] Monta in sola lettura.
-
-\item[\const{MS\_RELATIME}] .
-
-\item[\const{MS\_REMOUNT}] Rimonta il filesystem cambiando le opzioni.
-
-\item[\const{MS\_SHARE}] Shared mount (non documentato).
-
-\item[\const{MS\_SILENT}] .
+ (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à immediatamente 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
+ \itindsub{pathname}{relativo} \textit{pathname} relativi all'interno del
+ filesystem non possa fallire.
+
+\item[\const{MS\_NOATIME}] Viene disabilitato sul filesystem l'aggiornamento
+ degli \textit{access time} (vedi sez.~\ref{sec:file_file_times}) per
+ qualunque tipo di file. Dato che l'aggiornamento degli \textit{access time}
+ è una funzionalità la cui utilità è spesso irrilevante ma comporta un costo
+ elevato visto che una qualunque lettura comporta comunque una scrittura su
+ disco,\footnote{e questo ad esempio ha conseguenze molto pesanti nell'uso
+ della batteria sui portatili.} questa opzione consente di disabilitarla
+ completamente. La soluzione può risultare troppo drastica dato che
+ l'informazione viene comunque utilizzata da alcuni programmi, per cui nello
+ sviluppo del kernel sono state introdotte altre opzioni che forniscono
+ soluzioni più appropriate e meno radicali.
+
+\item[\const{MS\_NODEV}] Viene disabilitato sul filesystem l'accesso ai file
+ di dispositivo eventualmente presenti su di esso. L'opzione viene usata come
+ misura di precauzione per rendere inutile la presenza di eventuali file di
+ dispositivo su filesystem che non dovrebbero contenerne.\footnote{si ricordi
+ che le convenzioni del \itindex{Filesystem~Hierarchy~Standard~(FHS)}
+ \textit{Linux Filesystem Hierarchy Standard} richiedono che questi siano
+ mantenuti esclusivamente sotto \texttt{/dev}.}
+
+ Viene utilizzata, assieme a \const{MS\_NOEXEC} e \const{MS\_NOSUID}, per
+ fornire un accesso più controllato a quei filesystem di cui gli utenti hanno
+ il controllo dei contenuti, in particolar modo quelli posti su dispositivi
+ rimuovibili. In questo modo si evitano alla radice possibili situazioni in
+ cui un utente malizioso inserisce su uno di questi filesystem dei file di
+ dispositivo con permessi ``opportunamente'' ampliati che gli consentano di
+ accedere anche a risorse cui non dovrebbe.
+
+\item[\const{MS\_NODIRATIME}] Viene disabilitato sul filesystem
+ l'aggiornamento degli \textit{access time} (vedi
+ sez.~\ref{sec:file_file_times}), ma soltanto per le directory. Costituisce
+ una alternativa per \const{MS\_NOATIME}, che elimina l'informazione per le
+ directory, che in pratica che non viene mai utilizzata, mantenendola per i
+ file in cui invece ha un impiego, sia pur limitato.
+
+\item[\const{MS\_NOEXEC}] Viene disabilitata sul filesystem l'esecuzione di un
+ qualunque file eseguibile eventualmente presente su di esso. L'opzione viene
+ usata come misura di precauzione per rendere impossibile l'uso di programmi
+ posti su filesystem che non dovrebbero contenerne.
+
+ Anche in questo caso viene utilizzata per fornire un accesso più controllato
+ a quei filesystem di cui gli utenti hanno il controllo dei contenuti. Da
+ questo punto di vista l'opzione è meno importante delle analoghe
+ \const{MS\_NODEV} e \const{MS\_NOSUID} in quanto l'esecuzione di un
+ programma creato dall'utente pone un livello di rischio nettamente
+ inferiore, ed è in genere consentita per i file contenuti nella sua home
+ directory.\footnote{cosa che renderebbe superfluo l'attivazione di questa
+ opzione, il cui uso ha senso solo per ambienti molto controllati in cui si
+ vuole che gli utenti eseguano solo i programmi forniti
+ dall'amministratore.}
+
+\item[\const{MS\_NOSUID}] Viene disabilitato sul filesystem l'effetto dei bit
+ dei permessi \itindex{suid~bit} \acr{suid} e \itindex{sgid~bit} \acr{sgid}
+ (vedi sez.~\ref{sec:file_special_perm}) eventualmente presenti sui file in
+ esso contenuti. L'opzione viene usata come misura di precauzione per rendere
+ inefficace l'effetto di questi bit per filesystem in cui non ci dovrebbero
+ essere file dotati di questi permessi.
+
+ Di nuovo viene utilizzata, analogamente a \const{MS\_NOEXEC} e
+ \const{MS\_NODEV}, per fornire un accesso più controllato a quei filesystem
+ di cui gli utenti hanno il controllo dei contenuti. In questo caso si evita
+ che un utente malizioso possa inserire su uno di questi filesystem un
+ eseguibile con il bit \itindex{suid~bit} \acr{suid} attivo e di proprietà
+ dell'amministratore o di un altro utente, che gli consentirebbe di eseguirlo
+ per conto di quest'ultimo.
+
+\item[\const{MS\_PRIVATE}] Marca un \itindex{mount~point} \textit{mount point}
+ come privato. Si tratta di una delle nuove opzioni (insieme a
+ \const{MS\_SHARED}, \const{MS\_SLAVE} e \const{MS\_UNBINDABLE}) facenti
+ parte dell'infrastruttura degli \itindex{shared~subtree} \textit{shared
+ subtree} introdotta a partire dal kernel 2.6.15, che estendono le
+ funzionalità dei \itindex{bind~mount} \textit{bind mount}. In questo caso
+ \param{target} dovrà fare riferimento al \textit{mount point} che si intende
+ marcare, e tutti gli altri argomenti verranno ignorati.
+
+ Di default, finché non lo si marca altrimenti con una delle altre opzioni
+ dell'interfaccia \itindex{shared~subtree} \textit{shared subtree}, ogni
+ \textit{mount point} è privato. Ogni \textit{bind mount} ottenuto da un
+ \itindex{mount~point} \textit{mount point} di tipo \textit{private} si
+ comporta come descritto nella trattazione di \const{MS\_BIND}. Si usa questo
+ flag principalmente per revocare gli effetti delle altre opzioni e riportare
+ il comportamento a quello ordinario.
+
+\item[\const{MS\_RDONLY}] Esegue il montaggio del filesystem in sola lettura,
+ non sarà possibile nessuna modifica ai suoi contenuti. Viene usato tutte le
+ volte che si deve accedere ai contenuti di un filesystem con la certezza che
+ questo non venga modificato (ad esempio per ispezionare un filesystem
+ corrotto). All'avvio di default il kernel monta la radice in questa
+ modalità.
+
+\item[\const{MS\_REC}] Applica ricorsivamente a tutti i \itindex{mount~point}
+ \textit{mount point} presenti al di sotto del \textit{mount point} indicato
+ gli effetti della opzione degli \itindex{shared~subtree} \textit{shared
+ subtree} associata. Anche questo caso l'argomento \param{target} deve fare
+ riferimento ad un \itindex{mount~point} \textit{mount point} e tutti gli
+ altri argomenti sono ignorati, ed il flag deve essere indicato assieme ad
+ una fra \const{MS\_PRIVATE}, \const{MS\_SHARED}, \const{MS\_SLAVE} e
+ \const{MS\_UNBINDABLE}.
+
+\item[\const{MS\_RELATIME}] Indica di effettuare l'aggiornamento degli
+ \textit{access time} sul filesystem soltanto quando questo risulti
+ antecedente il valore corrente del \textit{modification time} o del
+ \textit{change time} (per i tempi dei file si veda
+ sez.~\ref{sec:file_file_times}). L'opzione è disponibile a partire dal
+ kernel 2.6.20, mentre dal 2.6.30 questo è diventato il comportamento di
+ default del sistema, che può essere riportato a quello tradizionale con
+ l'uso di \const{MS\_STRICTATIME}. Sempre dal 2.6.30 il comportamento è stato
+ anche modificato e l'\textit{access time} viene comunque aggiornato se è più
+ vecchio di un giorno.
+
+ L'opzione consente di evitare i problemi di prestazioni relativi
+ all'aggiornamento dell'\textit{access time} senza avere impatti negativi
+ riguardo le funzionalità, il comportamento adottato infatti consente di
+ rendere evidente che vi è stato un accesso dopo la scrittura, ed evitando al
+ contempo ulteriori operazioni su disco negli accessi successivi. In questo
+ modo l'informazione relativa al fatto che un file sia stato letto resta
+ disponibile, ed i programmi che ne fanno uso continuano a funzionare. Con
+ l'introduzione di questo comportamento l'uso delle alternative
+ \const{MS\_NOATIME} e \const{MS\_NODIRATIME} è sostanzialmente inutile.
+
+\item[\const{MS\_REMOUNT}] Consente di rimontare un filesystem già montato
+ cambiandone le opzioni di montaggio in maniera atomica. In questo modo si
+ possono modificare le opzioni del filesystem anche se questo è in uso. Gli
+ argomenti \param{source} e \param{target} devono essere gli stessi usati per
+ il montaggio originale, mentre \param{data} che \param{mountflags}
+ conterranno le nuove opzioni, \param{filesystemtype} viene ignorato.
+
+ Qualunque opzione specifica del filesystem indicata con \param{data} può
+ essere modificata, mentre con \param{mountflags} possono essere modificate
+ solo alcune opzioni generiche. Con i kernel più recenti queste sono soltanto
+ \const{MS\_MANDLOCK}, \const{MS\_RDONLY} e \const{MS\_SYNCHRONOUS}, prima
+ del kernel 2.6.16 potevano essere modificate anche le ulteriori
+ \const{MS\_NOATIME} e \const{MS\_NODIRATIME}, ed infine prima del kernel
+ 2.4.10 anche \const{MS\_NODEV}, \const{MS\_NOEXEC} e \const{MS\_NOSUID}.
+
+\item[\const{MS\_SHARED}] Marca un \itindex{mount~point} \textit{mount point}
+ come \textit{shared mount}. Si tratta di una delle nuove opzioni (insieme a
+ \const{MS\_PRIVATE}, \const{MS\_SLAVE} e \const{MS\_UNBINDABLE}) facenti
+ parte dell'infrastruttura degli \itindex{shared~subtree} \textit{shared
+ subtree} introdotta a partire dal kernel 2.6.15, che estendono le
+ funzionalità dei \itindex{bind~mount} \textit{bind mount}. In questo caso
+ \param{target} dovrà fare riferimento al \itindex{mount~point} \textit{mount
+ point} che si intende marcare, e tutti gli altri argomenti verranno
+ ignorati.
+
+ Lo scopo dell'opzione è ottenere che tutti i successivi \textit{bind mount}
+ effettuati da un \textit{mount point} marcato da essa siano di tipo
+ \textit{shared}, cioè ``\textsl{condividano}'' con l'originale e fra di loro
+ ogni ulteriore operazione di montaggio o smontaggio che avviene su una
+ directory al di sotto di uno qualunque di essi. Le operazioni di montaggio e
+ smontaggio cioè vengono ``\textsl{propagate}'' a tutti i \textit{mount
+ point} della stessa condivisione, e la sezione di albero di file vista al
+ di sotto di ciascuno di essi sarà sempre identica.
+
+\item[\const{MS\_SILENT}] Richiede la soppressione di alcuni messaggi di
+ avvertimento nei log del kernel (vedi sez.~\ref{sec:sess_daemon}). L'opzione
+ è presente a partire dal kernel 2.6.17 e sostituisce, utilizzando un nome
+ non fuorviante, la precedente \const{MS\_VERBOSE}, introdotta nel kernel
+ 2.6.12, che aveva lo stesso effetto.
+
+\item[\const{MS\_SLAVE}] Marca un \itindex{mount~point} \textit{mount point}
+ come \textit{slave mount}. Si tratta di una delle nuove opzioni (insieme a
+ \const{MS\_PRIVATE}, \const{MS\_SHARED} e \const{MS\_UNBINDABLE}) facenti
+ parte dell'infrastruttura degli \itindex{shared~subtree} \textit{shared
+ subtree} introdotta a partire dal kernel 2.6.15, che estendono le
+ funzionalità dei \itindex{bind~mount} \textit{bind mount}. In questo caso
+ \param{target} dovrà fare riferimento al \textit{mount point} che si intende
+ marcare, e tutti gli altri argomenti verranno ignorati.
+
+ Lo scopo dell'opzione è ottenere che tutti i successivi \textit{bind mount}
+ effettuati da un \textit{mount point} marcato da essa siano di tipo
+ \textit{slave}, cioè ``\textsl{condividano}'' ogni ulteriore operazione di
+ montaggio o smontaggio che avviene su una directory al di sotto del
+ \textit{mount point} originale. Le operazioni di montaggio e smontaggio in
+ questo caso vengono ``\textsl{propagate}'' soltanto dal \textit{mount point}
+ originale (detto anche \textit{master}) verso gli \textit{slave}, mentre
+ essi potranno eseguire al loro interno ulteriori montaggi che non saranno
+ propagati né negli altri né nel \itindex{mount~point} \textit{mount point}
+ originale.
+
+\item[\const{MS\_STRICTATIME}] Ripristina il comportamento tradizionale per
+ cui l'\textit{access time} viene aggiornato ad ogni accesso al
+ file. L'opzione è disponibile solo a partire dal kernel 2.6.30 quando il
+ comportamento di default del kernel è diventato quello fornito da
+ \const{MS\_RELATIME}.
+
+\item[\const{MS\_SYNCHRONOUS}] Abilita la scrittura sincrona richiedendo che
+ ogni modifica al contenuto del filesystem venga immediatamente registrata su
+ disco. Lo stesso comportamento può essere ottenuto con il flag
+ \const{O\_SYNC} di \func{open} (vedi sez.~\ref{sec:file_open}).
+
+ Questa opzione consente di ridurre al minimo il rischio di perdita dei dati
+ in caso di crollo improvviso del sistema, al costo di una pesante perdita di
+ prestazioni dato che tutte le funzioni di scrittura non saranno più
+ bufferizzate e si bloccheranno fino all'arrivo dei dati sul disco. Per un
+ compromesso in cui questo comportamento avviene solo per le directory, ed ha
+ quindi una incidenza nettamente minore, si può usare \const{MS\_DIRSYNC}.
+
+\item[\const{MS\_UNBINDABLE}] Marca un \itindex{mount~point} \textit{mount
+ point} come \textit{unbindable mount}. Si tratta di una delle nuove
+ opzioni (insieme a \const{MS\_PRIVATE}, \const{MS\_SHARED} e
+ \const{MS\_SLAVE}) facenti parte dell'infrastruttura degli
+ \itindex{shared~subtree} \textit{shared subtree} introdotta a partire dal
+ kernel 2.6.15, che estendono le funzionalità dei \itindex{bind~mount}
+ \textit{bind mount}. In questo caso
+ \param{target} dovrà fare riferimento al \textit{mount point} che si intende
+ marcare, e tutti gli altri argomenti verranno ignorati.
+
+ Un \textit{mount point} marcato in questo modo disabilità la capacità di
+ eseguire dei \itindex{bind~mount} \textit{bind mount}. Si comporta cioè come
+ allo stesso modo di un \itindex{mount~point} \textit{mount point} ordinario
+ di tipo \textit{private} con in più la restrizione che nessuna sua
+ sottodirectory (anche se relativa ad un ulteriore montaggio) possa essere
+ utilizzata per un come sorgente di un \itindex{bind~mount} \textit{bind
+ mount}.
-\item[\const{MS\_SLAVE}] Slave mount (non documentato).
-
-\item[\const{MS\_STRICTATIME}] .
-
-\item[\const{MS\_SYNCHRONOUS}] Abilita la scrittura sincrona.
-
-\item[\const{MS\_UNBINDABLE}] (non documentato).
-
-% TODO aggiornare con i nuovi flag di man mount
-% per \const{MS\_SLAVE},\const{MS\_SHARE}, \const{MS\_PRIVATE},
-% \const{MS\_UNBINDABLE} dal 2.6.15 vedi shared subtrees,
-% http://lwn.net/Articles/159077/ e
-% Documentation/filesystems/sharedsubtree.txt
+\end{basedescript}
-% TODO: non documentati ma presenti in sys/mount.h:
-% MS_REC
-% MS_POSIXACL
-% MS_KERNMOUNT
-% MS_I_VERSION
-% MS_ACTIVE
-% MS_NOUSER
+% 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
-\end{basedescript}
+% TODO: (bassa priorità) non documentati ma presenti in sys/mount.h:
+% * MS_POSIXACL
+% * MS_KERNMOUNT
+% * MS_I_VERSION
+% * MS_ACTIVE
+% * MS_NOUSER
-La funzione \func{mount} può essere utilizzata anche per effettuare il
-\textsl{rimontaggio} di un filesystem, cosa che permette di cambiarne al volo
-alcune delle caratteristiche di funzionamento (ad esempio passare da sola
-lettura a lettura/scrittura). Questa operazione è attivata attraverso uno dei
-bit di \param{mountflags}, \const{MS\_REMOUNT}, che se impostato specifica che
-deve essere effettuato il rimontaggio del filesystem (con le opzioni
-specificate dagli altri bit), anche in questo caso il valore di \param{source}
-viene ignorato.
Una volta che non si voglia più utilizzare un certo filesystem è possibile
-\textsl{smontarlo} usando la funzione \funcd{umount}, il cui prototipo è:
+``\textsl{smontarlo}'' usando la funzione \funcd{umount}, il cui prototipo è:
\begin{funcproto}{
\fhead{sys/mount.h}
\fdecl{umount(const char *target)}
\fdesc{Smonta un filesystem.}
}
-{La funzione ritorna $0$ in caso
- di successo e $-1$ per un errore,
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
- \item[\errcode{EBUSY}] \param{target} è la directory di lavoro di qualche
- processo, o contiene dei file aperti, o un altro mount point.
-\end{errlist}ed inoltre \errval{ENOTDIR}, \errval{EFAULT}, \errval{ENOMEM},
-\errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ELOOP} nel loro
- significato generico.}
+ \item[\errcode{EBUSY}] il filesystem è occupato.
+ \item[\errcode{EINVAL}] \param{target} non è un \textit{mount point}.
+ \item[\errcode{EPERM}] il processo non ha i privilegi di
+ amministratore.\footnotemark
+ \end{errlist}
+ ed inoltre \errval{EFAULT}, \errval{ELOOP}, \errval{ENAMETOOLONG},
+ \errval{ENOENT}, \errval{ENOMEM} nel loro significato generico. }
\end{funcproto}
+\footnotetext{più precisamente la \itindex{capabilities} capacità
+ \texttt{CAP\_SYS\_ADMIN}.}
+
La funzione prende il nome della directory su cui il filesystem è montato e
non il file o il dispositivo che è stato montato,\footnote{questo è vero a
partire dal kernel 2.3.99-pre7, prima esistevano due chiamate separate e la
funzione poteva essere usata anche specificando il file di dispositivo.} in
-quanto con il kernel 2.4.x è possibile montare lo stesso dispositivo in più
-punti. Nel caso più di un filesystem sia stato montato sullo stesso
-\itindex{mount~point} \textit{mount point} viene smontato quello che è stato
-montato per ultimo.
-
-Si tenga presente che la funzione fallisce quando il filesystem è
-\textsl{occupato}, questo avviene quando ci sono ancora file aperti sul
-filesystem, se questo contiene la directory di lavoro corrente di un qualunque
-processo o il \itindex{mount~point} \textit{mount point} di un altro
-filesystem; in questo caso l'errore restituito è \errcode{EBUSY}.
-
-Linux provvede inoltre una seconda funzione, \funcd{umount2}, che in alcuni
-casi permette di forzare lo smontaggio di un filesystem, anche quando questo
-risulti occupato; il suo prototipo è:
+quanto a partire dai kernel della serie 2.4.x è possibile montare lo stesso
+dispositivo in più punti. Nel caso più di un filesystem sia stato montato
+sullo stesso \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.
+
+Linux provvede inoltre una seconda funzione, \funcd{umount2}, che consente un
+maggior controllo delle operazioni, come forzare lo smontaggio di un
+filesystem anche quando questo risulti occupato; il suo prototipo è:
+
\begin{funcproto}{
\fhead{sys/mount.h}
\fdecl{umount2(const char *target, int flags)}
\fdesc{Smonta un filesystem.}
}
-{La funzione è identica a \func{umount} per valori di ritorno e codici di
- errore. }
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
+ nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{BUSY}] \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{EAGAIN}] si è chiamata la funzione con \const{MNT\_EXPIRE}
+ ed il filesystem non era occupato.
+ \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.
+ \end{errlist}
+ e tutti gli altri valori visti per \func{umount} con lo stesso significato.}
\end{funcproto}
-Il valore di \param{flags} è una maschera binaria, e al momento l'unico valore
-definito è il bit \const{MNT\_FORCE}; gli altri bit devono essere nulli.
-Specificando \const{MNT\_FORCE} la funzione cercherà di liberare il filesystem
-anche se è occupato per via di una delle condizioni descritte in precedenza. A
-seconda del tipo di filesystem alcune (o tutte) possono essere superate,
-evitando l'errore di \errcode{EBUSY}. In tutti i casi prima dello smontaggio
-viene eseguita una sincronizzazione dei dati.
+Il valore di \param{flags} è una maschera binaria dei flag che controllano le
+modalità di smontaggio, che deve essere specificato con un OR aritmetico delle
+costanti illustrate in tab.~\ref{tab:umount2_flags}. Specificando
+\const{MNT\_FORCE} la funzione cercherà di liberare il filesystem anche se è
+occupato per via di una delle condizioni descritte in precedenza. A seconda
+del tipo di filesystem alcune (o tutte) possono essere superate, evitando
+l'errore di \errcode{EBUSY}. In tutti i casi prima dello smontaggio viene
+eseguita una sincronizzazione dei dati.
+
+\begin{table}[!htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|p{8cm}|}
+ \hline
+ \textbf{Costante} & \textbf{Descrizione}\\
+ \hline
+ \hline
+ \const{MNT\_FORCE} & forza lo smontaggio del filesystem anche se questo è
+ occupato (presente dai kernel della serie 2.2).\\
+ \const{MNT\_DETACH} & esegue uno smontaggio ``\textsl{pigro}'', in cui si
+ blocca l'accesso ma si aspetta che il filesystem si
+ liberi (presente dal kernel 2.4.11 e dalla
+ \acr{glibc} 2.11).\\
+ \const{MNT\_EXPIRE} & se non occupato marca un \itindex{mount~point}
+ \textit{mount point} come ``\textsl{in scadenza}'' in
+ modo che ad una successiva chiamata senza utilizzo
+ del filesystem questo venga smontato (presente dal
+ kernel 2.6.8 e dalla \acr{glibc} 2.11).\\
+ \const{UMOUNT\_NOFOLLOW}& non dereferenzia \param{target} se questo è un
+ link simbolico (vedi sez.~\ref{sec:file_symlink})
+ evitando problemi di sicurezza (presente dal kernel
+ 2.6.34).\\
+ \hline
+ \end{tabular}
+ \caption{Costanti che identificano i bit dell'argomento \param{flags}
+ della funzione \func{umount2}.}
+ \label{tab:umount2_flags}
+\end{table}
-% TODO documentare MNT_DETACH e MNT_EXPIRE ...
+Con l'opzione \const{MNT\_DETACH} si richiede invece uno smontaggio
+``\textsl{pigro}'' (o \textit{lazy umount}) in cui il filesystem diventa
+inaccessibile per i nuovi processi subito dopo la chiamata della funzione, ma
+resta accessibile per quelli che lo hanno ancora in uso e non viene smontato
+fintanto che resta occupato.
+
+Con \const{MNT\_EXPIRE}, che non può essere specificato insieme agli altri
+due, si marca il \itindex{mount~point} \textit{mount point} di un filesystem
+non occupato come ``\textsl{in scadenza}'', in tal caso \func{umount2} ritorna
+con un errore di \errcode{EAGAIN}, mentre in caso di filesystem occupato si
+sarebbe ricevuto \errcode{BUSY}. Una volta marcato, se nel frattempo non
+viene fatto nessun uso del filesystem, ad una successiva chiamata con
+\const{MNT\_EXPIRE} questo verrà smontato. Questo flag consente di realizzare
+un meccanismo che smonti automaticamente i filesystem che restano inutilizzato
+per un certo periodo di tempo.
+
+% Infine il flag \const{UMOUNT\_NOFOLLOW} impedisce l'uso di un link simbolico
+% per \param{target} evitando così che si possano passare ai programmi che
+% effettuano lo smontaggio dei filesystem per i quali è previsto la possibilità
+% di gestione da parte degli utenti con uno programma \acr{sgid}
Altre due funzioni specifiche di Linux,\footnote{esse si trovano anche su BSD,
ma con una struttura diversa.} utili per ottenere in maniera diretta
{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore,
nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{ENOSYS}] il filesystem su cui si trova il file specificato non
+ \item[\errcode{ENOSYS}] il filesystem su cui si trova il file specificato
+ non supporta la funzione.
\end{errlist} ed inoltre \errval{EFAULT} ed \errval{EIO} per entrambe,
\errval{EBADF} per \func{fstatfs}, \errval{ENOTDIR}, \errval{ENAMETOOLONG},
\errval{ENOENT}, \errval{EACCES}, \errval{ELOOP} per \func{statfs} nel loro
significato generico.}
\end{funcproto}
-
Queste funzioni permettono di ottenere una serie di informazioni generali
-riguardo al filesystem su cui si trova il file specificato; queste vengono
+riguardo al filesystem su cui si trova il file specificato con un ; queste vengono
restituite all'indirizzo \param{buf} di una struttura \struct{statfs} definita
come in fig.~\ref{fig:sys_statfs}, ed i campi che sono indefiniti per il
filesystem in esame sono impostati a zero. I valori del campo \var{f\_type}
\label{fig:sys_statfs}
\end{figure}
-
Le \acr{glibc} provvedono infine una serie di funzioni per la gestione dei due
file \conffile{/etc/fstab} ed \conffile{/etc/mtab}, che convenzionalmente sono
usati in quasi tutti i sistemi unix-like per mantenere rispettivamente le
tralasceremo la trattazione, rimandando al manuale delle \acr{glibc}
\cite{glibc} per la documentazione completa.
-% TODO scrivere relativamente alle varie funzioni (getfsent e getmntent &C)
-% TODO documentare swapon e swapoff (man 2 ...)
-
-
-
-
+% TODO (bassa priorità) scrivere delle funzioni (getfsent e getmntent &C)
+% TODO (bassa priorità) documentare ? swapon e swapoff (man 2 ...)
\section{La gestione di file e directory}
\label{sec:file_dir}
Per aggiungere ad una directory una voce che faccia riferimento ad un
\itindex{inode} \textit{inode} già esistente si utilizza la funzione
-\func{link}; si suole chiamare questo tipo di associazione un collegamento
+\funcd{link}; si suole chiamare questo tipo di associazione un collegamento
diretto, o \textit{hard link}. Il prototipo della funzione è il seguente:
-\begin{prototype}{unistd.h}
-{int link(const char *oldpath, const char *newpath)}
- Crea un nuovo collegamento diretto.
-
- \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
- errore nel qual caso \var{errno} viene impostata ai valori:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{int link(const char *oldpath, const char *newpath)}
+\fdesc{Crea un nuovo collegamento diretto (\textit{hard link}).}
+}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
+ nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EXDEV}] i file \param{oldpath} e \param{newpath} non fanno
riferimento ad un filesystem montato sullo stesso \itindex{mount~point}
\item[\errcode{EMLINK}] ci sono troppi link al file \param{oldpath} (il
numero massimo è specificato dalla variabile \const{LINK\_MAX}, vedi
sez.~\ref{sec:sys_limits}).
- \end{errlist}
- ed inoltre \errval{EACCES}, \errval{ENAMETOOLONG}, \errval{ENOTDIR},
- \errval{EFAULT}, \errval{ENOMEM}, \errval{EROFS}, \errval{ELOOP},
- \errval{ENOSPC}, \errval{EIO}.}
-\end{prototype}
+ \end{errlist} ed inoltre \errval{EACCES}, \errval{ENAMETOOLONG},
+ \errval{ENOTDIR}, \errval{EFAULT}, \errval{ENOMEM}, \errval{EROFS},
+ \errval{ELOOP}, \errval{ENOSPC}, \errval{EIO} nel loro significato
+ generico.}
+\end{funcproto}
-La funzione crea sul \itindex{pathname} \textit{pathname} \param{newpath} un
-collegamento diretto al file indicato da \param{oldpath}. Per quanto detto la
-creazione di un nuovo collegamento diretto non copia il contenuto del file, ma
-si limita a creare una voce nella directory specificata da \param{newpath} e
-ad aumentare di uno il numero di riferimenti al file (riportato nel campo
-\var{st\_nlink} della struttura \struct{stat}, vedi sez.~\ref{sec:file_stat})
-aggiungendo il nuovo nome ai precedenti. Si noti che uno stesso file può
-essere così chiamato con vari nomi in diverse directory.
+
+La funzione crea sul \textit{pathname} \param{newpath} un collegamento diretto
+al file indicato da \param{oldpath}. Per quanto detto la creazione di un
+nuovo collegamento diretto non copia il contenuto del file, ma si limita a
+creare una voce nella directory specificata da \param{newpath} e ad aumentare
+di uno il numero di riferimenti al file (riportato nel campo \var{st\_nlink}
+della struttura \struct{stat}, vedi sez.~\ref{sec:file_stat}) aggiungendo il
+nuovo nome ai precedenti. Si noti che uno stesso file può essere così chiamato
+con vari nomi in diverse directory.
Per quanto dicevamo in sez.~\ref{sec:file_filesystem} la creazione di un
-collegamento diretto è possibile solo se entrambi i \itindex{pathname}
-\textit{pathname} sono nello stesso filesystem; inoltre il filesystem deve
-supportare i collegamenti diretti (il meccanismo non è disponibile ad esempio
-con il filesystem \acr{vfat} di Windows). In realtà la funzione ha un
-ulteriore requisito, e cioè che non solo che i due file siano sullo stesso
-filesystem, ma anche che si faccia riferimento ad essi sullo stesso
-\itindex{mount~point} \textit{mount point}.\footnote{si tenga presente infatti
- (vedi sez.~\ref{sec:sys_file_config}) che a partire dal kernel 2.4 uno
- stesso filesystem può essere montato più volte su directory diverse.}
+collegamento diretto è possibile solo se entrambi i \textit{pathname} sono
+nello stesso filesystem; inoltre il filesystem deve supportare i collegamenti
+diretti (il meccanismo non è disponibile ad esempio con il filesystem
+\acr{vfat} di Windows). In realtà la funzione ha un ulteriore requisito, e
+cioè che non solo che i due file siano sullo stesso filesystem, ma anche che
+si faccia riferimento ad essi sullo stesso \itindex{mount~point} \textit{mount
+ point}.\footnote{si tenga presente infatti (vedi
+ sez.~\ref{sec:sys_file_config}) che a partire dal kernel 2.4 uno stesso
+ filesystem può essere montato più volte su directory diverse.}
La funzione inoltre opera sia sui file ordinari che sugli altri oggetti del
filesystem, con l'eccezione delle directory. In alcune versioni di Unix solo
La rimozione di un file (o più precisamente della voce che lo referenzia
all'interno di una directory) si effettua con la funzione \funcd{unlink}; il
suo prototipo è il seguente:
-\begin{prototype}{unistd.h}{int unlink(const char *pathname)}
- Cancella un file.
-
- \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
- errore, nel qual caso il file non viene toccato. La variabile
- \var{errno} viene impostata secondo i seguenti codici di errore:
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{int unlink(const char *pathname)}
+\fdesc{Cancella un file.}
+}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
+ nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EISDIR}] \param{pathname} si riferisce ad una directory.
- \footnotemark
+ \item[\errcode{EISDIR}] \param{pathname} si riferisce ad una
+ directory.\footnotemark
\item[\errcode{EROFS}] \param{pathname} è su un filesystem montato in sola
lettura.
\item[\errcode{EISDIR}] \param{pathname} fa riferimento a una directory.
- \end{errlist}
- ed inoltre: \errval{EACCES}, \errval{EFAULT}, \errval{ENOENT},
+ \end{errlist} ed inoltre \errval{EACCES}, \errval{EFAULT}, \errval{ENOENT},
\errval{ENOTDIR}, \errval{ENOMEM}, \errval{EROFS}, \errval{ELOOP},
- \errval{EIO}.}
-\end{prototype}
+ \errval{EIO} nel loro significato generico.}
+\end{funcproto}
\footnotetext{questo è un valore specifico ritornato da Linux che non consente
l'uso di \func{unlink} con le directory (vedi sez.~\ref{sec:file_remove}).
una directory (e funziona anche per i sistemi che non supportano i link
diretti). Per i file è identica a \func{unlink} e per le directory è identica
a \func{rmdir}; il suo prototipo è:
-\begin{prototype}{stdio.h}{int remove(const char *pathname)}
- Cancella un nome dal filesystem.
-
- \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
- errore, nel qual caso il file non viene toccato.
-
- I codici di errore riportati in \var{errno} sono quelli della chiamata
- utilizzata, pertanto si può fare riferimento a quanto illustrato nelle
- descrizioni di \func{unlink} e \func{rmdir}.}
-\end{prototype}
+
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{int remove(const char *pathname)}
+\fdesc{Cancella un nome dal filesystem.}
+}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori relativi alla chiamata utilizzata,
+ pertanto si può fare riferimento a quanto illustrato nelle descrizioni di
+ \func{unlink} e \func{rmdir}.}
+\end{funcproto}
La funzione utilizza la funzione \func{unlink}\footnote{questo vale usando le
\acr{glibc}; nelle libc4 e nelle libc5 la funzione \func{remove} è un
funzione è definita dallo standard ANSI C, ma si applica solo per i file, lo
standard POSIX estende la funzione anche alle directory.} il cui prototipo
è:
-\begin{prototype}{stdio.h}
- {int rename(const char *oldpath, const char *newpath)}
-
- Rinomina un file.
-
- \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
- errore, nel qual caso il file non viene toccato. La variabile
- \var{errno} viene impostata secondo i seguenti codici di errore:
- \begin{errlist}
+
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{int rename(const char *oldpath, const char *newpath)}
+\fdesc{Rinomina un file.}
+}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
+ nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
\item[\errcode{EISDIR}] \param{newpath} è una directory mentre
\param{oldpath} non è una directory.
\item[\errcode{EXDEV}] \param{oldpath} e \param{newpath} non sono sullo
\item[\errcode{ENOTEMPTY}] \param{newpath} è una directory già esistente e
non vuota.
\item[\errcode{EBUSY}] o \param{oldpath} o \param{newpath} sono in uso da
- parte di qualche processo (come directory di lavoro o come radice) o del
- sistema (come \itindex{mount~point} \textit{mount point}).
+ parte di qualche processo (come \index{directory~di~lavoro} directory di
+ lavoro o come radice) o del sistema (come \itindex{mount~point}
+ \textit{mount point}).
\item[\errcode{EINVAL}] \param{newpath} contiene un prefisso di
\param{oldpath} o più in generale si è cercato di creare una directory come
sotto-directory di se stessa.
- \item[\errcode{ENOTDIR}] uno dei componenti dei \itindex{pathname}
- \textit{pathname} non è una directory o \param{oldpath} è una directory e
+ \item[\errcode{ENOTDIR}] uno dei componenti dei \textit{pathname} non è una
+ directory o \param{oldpath} è una directory e
\param{newpath} esiste e non è una directory.
- \end{errlist}
- ed inoltre \errval{EACCES}, \errval{EPERM}, \errval{EMLINK},
+ \end{errlist} ed inoltre \errval{EACCES}, \errval{EPERM}, \errval{EMLINK},
\errval{ENOENT}, \errval{ENOMEM}, \errval{EROFS}, \errval{ELOOP} e
- \errval{ENOSPC}.}
-\end{prototype}
+ \errval{ENOSPC} nel loro significato generico.}
+\end{funcproto}
La funzione rinomina il file \param{oldpath} in \param{newpath}, eseguendo se
necessario lo spostamento di un file fra directory diverse. Eventuali altri
come argomento un link simbolico vengono automaticamente applicate al file da
esso specificato. La funzione che permette di creare un nuovo link simbolico
è \funcd{symlink}, ed il suo prototipo è:
-\begin{prototype}{unistd.h}
- {int symlink(const char *oldpath, const char *newpath)}
- Crea un nuovo link simbolico di nome \param{newpath} il cui contenuto è
- \param{oldpath}.
-
- \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
- errore, nel qual caso la variabile \var{errno} assumerà i valori:
+
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{int symlink(const char *oldpath, const char *newpath)}
+\fdesc{Crea un nuovo link simbolico.}
+}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
+ nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EPERM}] il filesystem che contiene \param{newpath} non
supporta i link simbolici.
\item[\errcode{EEXIST}] esiste già un file \param{newpath}.
\item[\errcode{EROFS}] \param{newpath} è su un filesystem montato in sola
lettura.
- \end{errlist}
- ed inoltre \errval{EFAULT}, \errval{EACCES}, \errval{ENAMETOOLONG},
- \errval{ENOTDIR}, \errval{ENOMEM}, \errval{ELOOP}, \errval{ENOSPC} e
- \errval{EIO}.}
-\end{prototype}
+ \end{errlist} ed inoltre \errval{EFAULT}, \errval{EACCES},
+ \errval{ENAMETOOLONG}, \errval{ENOTDIR}, \errval{ENOMEM}, \errval{ELOOP},
+ \errval{ENOSPC} e \errval{EIO} nel loro significato generico.}
+\end{funcproto}
-Si tenga presente che la funzione non effettua nessun controllo sull'esistenza
-di un file di nome \param{oldpath}, ma si limita ad inserire quella stringa
-nel link simbolico. Pertanto un link simbolico può anche riferirsi ad un file
-che non esiste: in questo caso si ha quello che viene chiamato un
-\textit{dangling link}, letteralmente un \textsl{link ciondolante}.
+La funzione crea un nuovo link simbolico con \textit{pathname} \param{newpath}
+che fa riferimento ad \param{oldpath}. Si tenga presente che la funzione non
+effettua nessun controllo sull'esistenza di un file di nome \param{oldpath},
+ma si limita ad inserire il \textit{pathname} nel link simbolico. Pertanto un
+link simbolico può anche riferirsi ad un file che non esiste: in questo caso
+si ha quello che viene chiamato un \textit{dangling link}, letteralmente un
+\textsl{link ciondolante}.
Come accennato i link simbolici sono risolti automaticamente dal kernel
all'invocazione delle varie system call; in tab.~\ref{tab:file_symb_effect} si
\file{/boot/boot/boot} e così via.
Per questo motivo il kernel e le librerie prevedono che nella risoluzione di
-un \itindex{pathname} \textit{pathname} possano essere seguiti un numero
-limitato di link simbolici, il cui valore limite è specificato dalla costante
+un \textit{pathname} possano essere seguiti un numero limitato di link
+simbolici, il cui valore limite è specificato dalla costante
\const{MAXSYMLINKS}. Qualora questo limite venga superato viene generato un
errore ed \var{errno} viene impostata al valore \errcode{ELOOP}.
La funzione crea una nuova directory vuota, che contiene cioè solo le due voci
standard presenti in ogni directory (cioè ``\file{.}'' e ``\file{..}''), con
il nome indicato dall'argomento \param{dirname}. Il nome può essere indicato
-sia come \itindex{pathname} \textit{pathname} assoluto che come
-\itindex{pathname} \textit{pathname} relativo.
+sia come \itindsub{pathname}{assoluto} \textit{pathname} assoluto che come
+\itindsub{pathname}{relativo} \textit{pathname} relativo.
I permessi di accesso (vedi sez.~\ref{sec:file_access_control}) con cui la
directory viene creata sono specificati dall'argomento \param{mode}, i cui
che contiene la directory che si vuole cancellare, o non c'è il permesso
di attraversare (esecuzione) una delle directory specificate in
\param{dirname}.
- \item[\errcode{EBUSY}] la directory specificata è la directory di lavoro o la
- radice di qualche processo.
+ \item[\errcode{EBUSY}] la directory specificata è la
+ \index{directory~di~lavoro} directory di lavoro o la radice di qualche
+ processo.
\item[\errcode{ENOTEMPTY}] la directory non è vuota.
\end{errlist}
ed inoltre anche \errval{EFAULT}, \errval{ENAMETOOLONG}, \errval{ENOENT},
La funzione cancella la directory \param{dirname}, che deve essere vuota (la
directory deve cioè contenere soltanto le due voci standard ``\file{.}'' e
-``\file{..}''). Il nome può essere indicato con il \itindex{pathname}
-\textit{pathname} assoluto o relativo.
+``\file{..}''). Il nome può essere indicato con il \textit{pathname} assoluto
+o relativo.
La modalità con cui avviene la cancellazione è analoga a quella di
\func{unlink}: fintanto che il numero di link \itindex{inode}
necessità di specificare il numero tramite delle opportune macro, così da non
avere problemi di compatibilità con eventuali ulteriori estensioni.
-Le macro sono definite nel file \file{sys/sysmacros.h}, che viene
-automaticamente incluso quando si include \file{sys/types.h}; si possono
+Le macro sono definite nel file \headfile{sys/sysmacros.h}, che viene
+automaticamente incluso quando si include \headfile{sys/types.h}; si possono
pertanto ottenere i valori del \itindex{major~number} \textit{major number} e
\itindex{minor~number} \textit{minor number} di un dispositivo rispettivamente
con le macro \macro{major} e \macro{minor}:
stream} \param{dir}. Di solito si utilizza questa funzione in abbinamento a
funzioni che operano sui file descriptor, ad esempio si potrà usare
\func{fstat} per ottenere le proprietà della directory, o \func{fchdir} per
-spostare su di essa la directory di lavoro (vedi
+spostare su di essa la \index{directory~di~lavoro} directory di lavoro (vedi
sez.~\ref{sec:file_work_dir}).
Viceversa se si è aperto un file descriptor corrispondente ad una directory è
stream}.
Di questa funzione esiste anche una versione \index{funzioni!rientranti}
-rientrante, \func{readdir\_r},\footnote{per usarla è necessario definire una
+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
\struct{dirent}) come argomento della funzione di selezione specificata da
\param{filter}; se questa ritorna un valore diverso da zero il puntatore viene
inserito in un vettore che viene allocato dinamicamente con \func{malloc}.
-Qualora si specifichi un valore \val{NULL} per l'argomento \func{filter} non
+Qualora si specifichi un valore \val{NULL} per l'argomento \param{filter} non
viene fatta nessuna selezione e si ottengono tutte le voci presenti.
-Le voci selezionate possono essere riordinate tramite \func{qsort}, le modalità
-del riordinamento possono essere personalizzate usando la funzione
-\param{compar} come criterio di ordinamento di \func{qsort}, la funzione
+Le voci selezionate possono essere riordinate tramite \funcm{qsort}, le
+modalità del riordinamento possono essere personalizzate usando la funzione
+\param{compar} come criterio di ordinamento di \funcm{qsort}, la funzione
prende come argomenti le due strutture \struct{dirent} da confrontare
restituendo un valore positivo, nullo o negativo per indicarne l'ordinamento;
alla fine l'indirizzo della lista ordinata dei puntatori alle strutture
campo \var{d\_name} delle varie voci). Le \acr{glibc} prevedono come
estensione\footnote{le glibc, a partire dalla versione 2.1, effettuano anche
l'ordinamento alfabetico tenendo conto delle varie localizzazioni, usando
- \func{strcoll} al posto di \func{strcmp}.} anche \func{versionsort}, che
+ \funcm{strcoll} al posto di \funcm{strcmp}.} anche \func{versionsort}, che
ordina i nomi tenendo conto del numero di versione (cioè qualcosa per cui
\texttt{file10} viene comunque dopo \texttt{file4}.)
stream sulla directory passata come primo argomento, stampando un messaggio in
caso di errore.
-Il passo successivo (\texttt{\small 23--24}) è cambiare directory di lavoro
-(vedi sez.~\ref{sec:file_work_dir}), usando in sequenza le funzioni
-\func{dirfd} e \func{fchdir} (in realtà si sarebbe potuto usare direttamente
-\func{chdir} su \var{dirname}), in modo che durante il successivo ciclo
-(\texttt{\small 26--30}) sulle singole voci dello stream ci si trovi
-all'interno della directory.\footnote{questo è essenziale al funzionamento
- della funzione \code{do\_ls}, e ad ogni funzione che debba usare il campo
- \var{d\_name}, in quanto i nomi dei file memorizzati all'interno di una
- struttura \struct{dirent} sono sempre relativi alla directory in questione,
- e senza questo posizionamento non si sarebbe potuto usare \func{stat} per
- ottenere le dimensioni.}
+Il passo successivo (\texttt{\small 23--24}) è cambiare
+\index{directory~di~lavoro} directory di lavoro (vedi
+sez.~\ref{sec:file_work_dir}), usando in sequenza le funzioni \func{dirfd} e
+\func{fchdir} (in realtà si sarebbe potuto usare direttamente \func{chdir} su
+\var{dirname}), in modo che durante il successivo ciclo (\texttt{\small
+ 26--30}) sulle singole voci dello stream ci si trovi all'interno della
+directory.\footnote{questo è essenziale al funzionamento della funzione
+ \code{do\_ls}, e ad ogni funzione che debba usare il campo \var{d\_name}, in
+ quanto i nomi dei file memorizzati all'interno di una struttura
+ \struct{dirent} sono sempre relativi alla directory in questione, e senza
+ questo posizionamento non si sarebbe potuto usare \func{stat} per ottenere
+ le dimensioni.}
Avendo usato lo stratagemma di fare eseguire tutte le manipolazioni necessarie
alla funzione passata come secondo argomento, il ciclo di scansione della
\subsection{La directory di lavoro}
\label{sec:file_work_dir}
-\itindbeg{pathname}
+\index{directory~di~lavoro|(}
Come accennato in sez.~\ref{sec:proc_fork} a ciascun processo è associata una
directory nel filesystem,\footnote{questa viene mantenuta all'interno dei dati
- della sua \struct{task\_struct} (vedi fig.~\ref{fig:proc_task_struct}), più
+ della sua \kstruct{task\_struct} (vedi fig.~\ref{fig:proc_task_struct}), più
precisamente nel campo \texttt{pwd} della sotto-struttura
- \struct{fs\_struct}.} che è chiamata \textsl{directory corrente} o
+ \kstruct{fs\_struct}.} che è chiamata \textsl{directory corrente} o
\textsl{directory di lavoro} (in inglese \textit{current working directory}).
La directory di lavoro è quella da cui si parte quando un
\itindsub{pathname}{relativo} \textit{pathname} è espresso in forma relativa,
Una seconda usata per ottenere la directory di lavoro è \code{char
*get\_current\_dir\_name(void)} che è sostanzialmente equivalente ad una
\code{getcwd(NULL, 0)}, con la sola differenza che essa ritorna il valore
-della variabile di ambiente \val{PWD}, che essendo costruita dalla shell può
-contenere un \textit{pathname} comprendente anche dei link simbolici. Usando
-\func{getcwd} infatti, essendo il \textit{pathname} ricavato risalendo
-all'indietro l'albero della directory, si perderebbe traccia di ogni passaggio
-attraverso eventuali link simbolici.
+della variabile di ambiente \envvar{PWD}, che essendo costruita dalla shell
+può contenere un \textit{pathname} comprendente anche dei link
+simbolici. Usando \func{getcwd} infatti, essendo il \textit{pathname} ricavato
+risalendo all'indietro l'albero della directory, si perderebbe traccia di ogni
+passaggio attraverso eventuali link simbolici.
Per cambiare la directory di lavoro si può usare la funzione \funcd{chdir}
(equivalente del comando di shell \cmd{cd}) il cui nome sta appunto per
quello in cui il processo non ha il permesso di accesso alla directory
specificata da \param{fd}.
-\itindend{pathname}
-
+\index{directory~di~lavoro|)}
\subsection{I file temporanei}
indefinito. Al nome viene automaticamente aggiunto come prefisso la directory
specificata dalla costante \const{P\_tmpdir}.\footnote{le costanti
\const{L\_tmpnam}, \const{P\_tmpdir} e \const{TMP\_MAX} sono definite in
- \file{stdio.h}.}
+ \headfile{stdio.h}.}
Di questa funzione esiste una versione \index{funzioni!rientranti} rientrante,
-\func{tmpnam\_r}, che non fa nulla quando si passa \val{NULL} come argomento.
+\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 è:
\begin{prototype}{stdio.h}{char *tempnam(const char *dir, const char *pfx)}
nome provvisorio. La funzione assegna come directory per il file temporaneo,
verificando che esista e sia accessibile, la prima valida fra le seguenti:
\begin{itemize*}
-\item La variabile di ambiente \const{TMPDIR} (non ha effetto se non è
+\item La variabile di ambiente \envvar{TMPDIR} (non ha effetto se non è
definita o se il programma chiamante è \itindex{suid~bit} \acr{suid} o
\itindex{sgid~bit} \acr{sgid}, vedi sez.~\ref{sec:file_special_perm}).
\item il valore dell'argomento \param{dir} (se diverso da \val{NULL}).
questa funzione esiste una variante \funcd{mkostemp}, introdotta
specificamente dalla \acr{glibc},\footnote{la funzione è stata introdotta
nella versione 2.7 delle librerie e richiede che sia definita la macro
- \const{\_GNU\_SOURCE}.} il cui prototipo è:
+ \macro{\_GNU\_SOURCE}.} il cui prototipo è:
\begin{prototype}{stlib.h}{int mkostemp(char *template, int flags)}
Genera un file temporaneo.
\errval{EACCES}, \errval{ENOMEM}, \errval{ENAMETOOLONG}.}
\end{functions}
-La funzione \func{stat} legge le informazioni del file il cui pathname è
-specificato dalla stringa puntata da \param{file\_name} e le inserisce nel
-buffer puntato dall'argomento \param{buf}; la funzione \func{lstat} è identica
-a \func{stat} eccetto che se \param{file\_name} è un link simbolico vengono
-lette le informazioni relative ad esso e non al file a cui fa
-riferimento. Infine \func{fstat} esegue la stessa operazione su un file già
-aperto, specificato tramite il suo file descriptor \param{filedes}.
+La funzione \func{stat} legge le informazioni del file il cui
+\textit{pathname} è specificato dalla stringa puntata da \param{file\_name} e
+le inserisce nel buffer puntato dall'argomento \param{buf}; la funzione
+\func{lstat} è identica a \func{stat} eccetto che se \param{file\_name} è un
+link simbolico vengono lette le informazioni relative ad esso e non al file a
+cui fa riferimento. Infine \func{fstat} esegue la stessa operazione su un file
+già aperto, specificato tramite il suo file descriptor \param{filedes}.
La struttura \struct{stat} usata da queste funzioni è definita nell'header
-\file{sys/stat.h} e in generale dipende dall'implementazione; la versione
+\headfile{sys/stat.h} e in generale dipende dall'implementazione; la versione
usata da Linux è mostrata in fig.~\ref{fig:file_stat_struct}, così come
riportata dalla pagina di manuale di \func{stat}; in realtà la definizione
effettivamente usata nel kernel dipende dall'architettura e ha altri campi
Si noti come i vari membri della struttura siano specificati come tipi
primitivi del sistema (di quelli definiti in
-tab.~\ref{tab:intro_primitive_types}, e dichiarati in \file{sys/types.h}).
+tab.~\ref{tab:intro_primitive_types}, e dichiarati in \headfile{sys/types.h}).
\subsection{I tipi di file}
\label{sec:file_types}
\macro{S\_ISSOCK}\texttt{(m)} & socket.\\
\hline
\end{tabular}
- \caption{Macro per i tipi di file (definite in \texttt{sys/stat.h}).}
+ \caption{Macro per i tipi di file (definite in \headfile{sys/stat.h}).}
\label{tab:file_type_macro}
\end{table}
Oltre alle macro di tab.~\ref{tab:file_type_macro} è possibile usare
direttamente il valore di \var{st\_mode} per ricavare il tipo di file
controllando direttamente i vari bit in esso memorizzati. Per questo sempre in
-\file{sys/stat.h} sono definite le costanti numeriche riportate in
+\headfile{sys/stat.h} sono definite le costanti numeriche riportate in
tab.~\ref{tab:file_mode_flags}.
Il primo valore dell'elenco di tab.~\ref{tab:file_mode_flags} è la maschera
\hline
\end{tabular}
\caption{Costanti per l'identificazione dei vari bit che compongono il campo
- \var{st\_mode} (definite in \file{sys/stat.h}).}
+ \var{st\_mode} (definite in \headfile{sys/stat.h}).}
\label{tab:file_mode_flags}
\end{table}
Il campo \var{st\_size} di una struttura \struct{stat} contiene la dimensione
del file in byte, se si tratta di un file regolare. Nel caso di un link
-simbolico la dimensione è quella del \itindex{pathname} \textit{pathname} che
-il link stesso contiene; per le fifo questo campo è sempre nullo.
+simbolico la dimensione è quella del \textit{pathname} che il link stesso
+contiene; per le fifo questo campo è sempre nullo.
Il campo \var{st\_blocks} definisce la lunghezza del file in blocchi di 512
byte. Il campo \var{st\_blksize} infine definisce la dimensione preferita per
per \func{truncate} si hanno:
\begin{errlist}
\item[\errcode{EACCES}] il file non ha permesso di scrittura o non si ha il
- permesso di esecuzione una delle directory del \itindex{pathname}
- \textit{pathname}.
+ permesso di esecuzione una delle directory del \textit{pathname}.
\item[\errcode{ETXTBSY}] il file è un programma in esecuzione.
\end{errlist}
ed anche \errval{ENOTDIR}, \errval{ENAMETOOLONG}, \errval{ENOENT},
Entrambe le funzioni fan sì che la dimensione del file sia troncata ad un
valore massimo specificato da \param{length}, e si distinguono solo per il
-fatto che il file viene indicato con il pathname \param{file\_name} per
-\func{truncate} e con il file descriptor \param{fd} per \funcd{ftruncate}; se
-il file è più lungo della lunghezza specificata i dati in eccesso saranno
+fatto che il file viene indicato con il \textit{pathname} \param{file\_name}
+per \func{truncate} e con il file descriptor \param{fd} per \funcd{ftruncate};
+se il file è più lungo della lunghezza specificata i dati in eccesso saranno
perduti.
Il comportamento in caso di lunghezza inferiore non è specificato e dipende
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
dello standard POSIX (la POSIX.1-2008); sono state introdotte a partire dal
kernel 2.6.22, e supportate dalle \acr{glibc} a partire dalla versione
2.6.\footnote{in precedenza, a partire dal kernel 2.6.16, era stata introdotta
- la funzione \func{futimesat} seguendo una bozza della revisione dello
+ la funzione \funcm{futimesat} seguendo una bozza della revisione dello
standard poi modificata, questa funzione, sostituita da \func{utimensat}, è
stata dichiarata obsoleta, non è supportata da nessuno standard e non deve
essere più utilizzata: pertanto non la tratteremo.} La prima è
tempi con precisione maggiore, la seconda supporta invece, rispetto ad
\func{utimes}, una sintassi più complessa che, come vedremo in
sez.~\ref{sec:file_openat} consente una indicazione sicura dei
-\textit{pathname relativi} specificando la directory da usare come riferimento
-in \param{dirfd} e la possibilità di usare \param{flags} per indicare alla
-funzione di dereferenziare o meno i link simbolici; si rimanda pertanto la
-spiegazione del significato degli argomenti aggiuntivi alla trattazione
-generica delle varie funzioni che usano la stessa sintassi, effettuata in
-sez.~\ref{sec:file_openat}.
+\itindsub{pathname}{relativo} \textit{pathname relativi} specificando la
+directory da usare come riferimento in \param{dirfd} e la possibilità di
+usare \param{flags} per indicare alla funzione di dereferenziare o meno i link
+simbolici; si rimanda pertanto la spiegazione del significato degli argomenti
+aggiuntivi alla trattazione generica delle varie funzioni che usano la stessa
+sintassi, effettuata in sez.~\ref{sec:file_openat}.
\section{Il controllo di accesso ai file}
avanti.
La prima regola è che per poter accedere ad un file attraverso il suo
-\itindex{pathname} \textit{pathname} occorre il permesso di esecuzione in
-ciascuna delle directory che compongono il \textit{pathname}; lo stesso vale
-per aprire un file nella directory corrente (per la quale appunto serve il
-diritto di esecuzione).
+\textit{pathname} occorre il permesso di esecuzione in ciascuna delle
+directory che compongono il \textit{pathname}; lo stesso vale per aprire un
+file nella directory corrente (per la quale appunto serve il diritto di
+esecuzione).
Per una directory infatti il permesso di esecuzione significa che essa può
-essere attraversata nella risoluzione del \itindex{pathname}
-\textit{pathname}, ed è distinto dal permesso di lettura che invece implica
-che si può leggere il contenuto della directory.
+essere attraversata nella risoluzione del \textit{pathname}, ed è distinto dal
+permesso di lettura che invece implica che si può leggere il contenuto della
+directory.
Questo significa che se si ha il permesso di esecuzione senza permesso di
lettura si potrà lo stesso aprire un file in una directory (se si hanno i
permessi di sez.~\ref{sec:file_perm_overview} (cioè $666$ nel primo caso e
$222$ nel secondo). Per questo motivo il sistema associa ad ogni
processo\footnote{è infatti contenuta nel campo \var{umask} della struttura
- \struct{fs\_struct}, vedi fig.~\ref{fig:proc_task_struct}.} una maschera di
-bit, la cosiddetta \textit{umask}, che viene utilizzata per impedire che
+ \kstruct{fs\_struct}, vedi fig.~\ref{fig:proc_task_struct}.} una maschera
+di bit, la cosiddetta \textit{umask}, che viene utilizzata per impedire che
alcuni permessi possano essere assegnati ai nuovi file in sede di creazione. I
bit indicati nella maschera vengono infatti cancellati dai permessi quando un
nuovo file viene creato.\footnote{l'operazione viene fatta sempre: anche
sicurezza che si sta utilizzando al momento (ciascuno avrà le sue). Se non è
stato caricato nessun modulo di sicurezza l'accesso in lettura sarà
consentito a tutti i processi, mentre quello in scrittura solo ai processi
- con privilegi amministrativi dotati della \index{capabilities}
+ con privilegi amministrativi dotati della \itindex{capabilities}
\textit{capability} \const{CAP\_SYS\_ADMIN}.
\item[\texttt{system}] Anche l'accesso agli \textit{extended system
lettura ai processi che hanno la capacità di eseguire una ricerca sul file
(cioè hanno il permesso di lettura sulla directory che contiene il file) ed
in scrittura al proprietario del file o ai processi dotati della
- \textit{capability} \index{capabilities} \const{CAP\_FOWNER}.\footnote{vale
- a dire una politica di accesso analoga a quella impiegata per gli ordinari
- permessi dei file.}
+ \textit{capability} \itindex{capabilities}
+ \const{CAP\_FOWNER}.\footnote{vale a dire una politica di accesso analoga a
+ quella impiegata per gli ordinari permessi dei file.}
\item[\texttt{trusted}] L'accesso ai \textit{trusted extended attributes}, sia
per la lettura che per la scrittura, è consentito soltanto ai processi con
- privilegi amministrativi dotati della \index{capabilities}
+ privilegi amministrativi dotati della \itindex{capabilities}
\textit{capability} \const{CAP\_SYS\_ADMIN}. In questo modo si possono
utilizzare questi attributi per realizzare in user space dei meccanismi di
controllo che accedono ad informazioni non disponibili ai processi ordinari.
per evitare eventuali abusi, se una directory ha lo \itindex{sticky~bit}
\textit{sticky bit} attivo sarà consentito scrivere i suoi \textit{extended
user attributes} soltanto se si è proprietari della stessa, o si hanno i
- privilegi amministrativi della capability \index{capabilities}
+ privilegi amministrativi della capability \itindex{capabilities}
\const{CAP\_FOWNER}.
\end{basedescript}
\end{functions}
Le funzioni \func{getxattr} e \func{lgetxattr} prendono come primo argomento
-un pathname che indica il file di cui si vuole richiedere un attributo, la
-sola differenza è che la seconda, se il pathname indica un link simbolico,
-restituisce gli attributi di quest'ultimo e non quelli del file a cui esso fa
-riferimento. La funzione \func{fgetxattr} prende invece come primo argomento
-un numero di file descriptor, e richiede gli attributi del file ad esso
-associato.
+un \textit{pathname} che indica il file di cui si vuole richiedere un
+attributo, la sola differenza è che la seconda, se il \textit{pathname} indica
+un link simbolico, restituisce gli attributi di quest'ultimo e non quelli del
+file a cui esso fa riferimento. La funzione \func{fgetxattr} prende invece
+come primo argomento un numero di file descriptor, e richiede gli attributi
+del file ad esso associato.
Tutte e tre le funzioni richiedono di specificare nell'argomento \param{name}
il nome dell'attributo di cui si vuole ottenere il valore. Il nome deve essere
indicare quale dovrà essere la ACL assegnata di default nella creazione di un
file all'interno della directory stessa. Come avviene per i permessi le ACL
possono essere impostate solo del proprietario del file, o da un processo con
-la capability \index{capabilities} \const{CAP\_FOWNER}.
+la capability \itindex{capabilities} \const{CAP\_FOWNER}.
\begin{table}[htb]
\centering
Le due funzioni ritornano, con un oggetto di tipo \type{acl\_t}, il valore
della ACL correntemente associata ad un file, che può essere identificato
-tramite un file descriptor usando \func{acl\_get\_fd} o con un pathname usando
-\func{acl\_get\_file}. Nel caso di quest'ultima funzione, che può richiedere
-anche la ACL relativa ad una directory, il secondo argomento \param{type}
-consente di specificare se si vuole ottenere la ACL di default o quella di
-accesso. Questo argomento deve essere di tipo \type{acl\_type\_t} e può
-assumere solo i due valori riportati in tab.~\ref{tab:acl_type}.
+tramite un file descriptor usando \func{acl\_get\_fd} o con un
+\textit{pathname} usando \func{acl\_get\_file}. Nel caso di quest'ultima
+funzione, che può richiedere anche la ACL relativa ad una directory, il
+secondo argomento \param{type} consente di specificare se si vuole ottenere la
+ACL di default o quella di accesso. Questo argomento deve essere di tipo
+\type{acl\_type\_t} e può assumere solo i due valori riportati in
+tab.~\ref{tab:acl_type}.
\begin{table}[htb]
\centering
\end{functions}
La funzione consente di assegnare la ACL contenuta in \param{acl} al file o
-alla directory indicate dal pathname \param{path}, mentre con \param{type} si
-indica il tipo di ACL utilizzando le costanti di tab.~\ref{tab:acl_type}, ma
-si tenga presente che le ACL di default possono essere solo impostate
-qualora \param{path} indichi una directory. Inoltre perché la funzione abbia
-successo la ACL dovrà essere valida, e contenere tutti le voci necessarie,
-unica eccezione è quella in cui si specifica una ACL vuota per cancellare la
-ACL di default associata a \func{path}.\footnote{questo però è una estensione
- della implementazione delle ACL di Linux, la bozza di standard POSIX.1e
- prevedeva l'uso della apposita funzione \funcd{acl\_delete\_def\_file}, che
- prende come unico argomento il pathname della directory di cui si vuole
- cancellare l'ACL di default, per i dettagli si ricorra alla pagina di
- manuale.} La seconda funzione che consente di impostare una ACL è
-\funcd{acl\_set\_fd}, ed il suo prototipo è:
+alla directory indicate dal \textit{pathname} \param{path}, mentre
+con \param{type} si indica il tipo di ACL utilizzando le costanti di
+tab.~\ref{tab:acl_type}, ma si tenga presente che le ACL di default possono
+essere solo impostate qualora \param{path} indichi una directory. Inoltre
+perché la funzione abbia successo la ACL dovrà essere valida, e contenere
+tutti le voci necessarie, unica eccezione è quella in cui si specifica una ACL
+vuota per cancellare la ACL di default associata a
+\param{path}.\footnote{questo però è una estensione della implementazione delle
+ ACL di Linux, la bozza di standard POSIX.1e prevedeva l'uso della apposita
+ funzione \funcd{acl\_delete\_def\_file}, che prende come unico argomento il
+ \textit{pathname} della directory di cui si vuole cancellare l'ACL di
+ default, per i dettagli si ricorra alla pagina di manuale.} La seconda
+funzione che consente di impostare una ACL è \funcd{acl\_set\_fd}, ed il suo
+prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/acl.h}
\hline
\const{Q\_QUOTAON} & Attiva l'applicazione delle quote disco per il
filesystem indicato da \param{dev}, si deve passare
- in \param{addr} il pathname al file che mantiene le
- quote, che deve esistere, e \param{id} deve indicare
- la versione del formato con uno dei valori di
- tab.~\ref{tab:quotactl_id_format}; l'operazione
- richiede i privilegi di amministratore.\\
+ in \param{addr} il \textit{pathname} al file che
+ mantiene le quote, che deve esistere, e \param{id}
+ deve indicare la versione del formato con uno dei
+ valori di tab.~\ref{tab:quotactl_id_format};
+ l'operazione richiede i privilegi di
+ amministratore.\\
\const{Q\_QUOTAOFF} & Disattiva l'applicazione delle quote disco per il
filesystem indicato da \param{dev}, \param{id}
e \param{addr} vengono ignorati; l'operazione
breve descrizione ed il nome delle costanti che le identificano, è riportato
in tab.~\ref{tab:proc_capabilities};\footnote{l'elenco presentato questa
tabella, ripreso dalla pagina di manuale (accessibile con \texttt{man
- capabilities}) e dalle definizioni in \texttt{linux/capabilities.h}, è
- aggiornato al kernel 2.6.26.} la tabella è divisa in due parti, la prima
-riporta le \textit{capabilities} previste anche nella bozza dello standard
-POSIX1.e, la seconda quelle specifiche di Linux. Come si può notare dalla
-tabella alcune \textit{capabilities} attengono a singole funzionalità e sono
-molto specializzate, mentre altre hanno un campo di applicazione molto vasto,
-che è opportuno dettagliare maggiormente.
+ capabilities}) e dalle definizioni in
+ \texttt{include/linux/capabilities.h}, è aggiornato al kernel 2.6.26.} la
+tabella è divisa in due parti, la prima riporta le \textit{capabilities}
+previste anche nella bozza dello standard POSIX1.e, la seconda quelle
+specifiche di Linux. Come si può notare dalla tabella alcune
+\textit{capabilities} attengono a singole funzionalità e sono molto
+specializzate, mentre altre hanno un campo di applicazione molto vasto, che è
+opportuno dettagliare maggiormente.
\begin{table}[!h!btp]
\centering
indicato che per poterle utilizzare fosse necessario che la macro
\macro{\_POSIX\_SOURCE} risultasse non definita (ed era richiesto di inserire
una istruzione \texttt{\#undef \_POSIX\_SOURCE} prima di includere
-\texttt{sys/capability.h}) requisito che non risulta più presente.\footnote{e
- non è chiaro neanche quanto sia mai stato davvero necessario.}
+\headfile{sys/capability.h}) requisito che non risulta più
+presente.\footnote{e non è chiaro neanche quanto sia mai stato davvero
+ necessario.}
Si tenga presente che le strutture di fig.~\ref{fig:cap_kernel_struct}, come i
prototipi delle due funzioni \func{capget} e \func{capset}, sono soggette ad
con l'argomento \param{flag}. Questo deve essere specificato con una variabile
di tipo \type{cap\_flag\_t} che può assumere esclusivamente\footnote{si tratta
in effetti di un tipo enumerato, come si può verificare dalla sua
- definizione che si trova in \texttt{/usr/include/sys/capability.h}.} uno dei
-valori illustrati in tab.~\ref{tab:cap_set_identifier}.
+ definizione che si trova in \headfile{sys/capability.h}.} uno dei valori
+illustrati in tab.~\ref{tab:cap_set_identifier}.
Si possono inoltre confrontare in maniera diretta due diversi
\textit{capability state} con la funzione \funcd{cap\_compare}; il suo
tab.~\ref{tab:proc_capabilities}, in questo caso però non è possibile
combinare diversi valori in una maschera binaria, una variabile di tipo
\type{cap\_value\_t} può indicare una sola capacità.\footnote{in
- \texttt{sys/capability.h} il tipo \type{cap\_value\_t} è definito come
+ \headfile{sys/capability.h} il tipo \type{cap\_value\_t} è definito come
\ctyp{int}, ma i valori validi sono soltanto quelli di
tab.~\ref{tab:proc_capabilities}.}
Alle due funzioni citate se ne aggiungono altre due che consentono di
convertire i valori delle costanti di tab.~\ref{tab:proc_capabilities} nelle
stringhe usate nelle rispettive rappresentazioni e viceversa. Le due funzioni,
-\func{cap\_to\_name} e \func{cap\_from\_name}, sono estensioni specifiche di
+\funcd{cap\_to\_name} e \funcd{cap\_from\_name}, sono estensioni specifiche di
Linux ed i rispettivi prototipi sono:
\begin{functions}
\headdecl{sys/capability.h}
prototipo\footnote{su alcune pagine di manuale la funzione è descritta con un
prototipo sbagliato, che prevede un valore di ritorno di tipo \type{cap\_t},
ma il valore di ritorno è intero, come si può verificare anche dalla
- dichiarazione della stessa in \texttt{sys/capability.h}.} è:
+ dichiarazione della stessa in \headfile{sys/capability.h}.} è:
\begin{functions}
\headdecl{sys/capability.h}
% TODO riferimenti ai bind mount, link simbolici ecc.
Come accennato in sez.~\ref{sec:proc_fork} ogni processo oltre ad una
-directory di lavoro, ha anche una directory \textsl{radice}\footnote{entrambe
- sono contenute in due campi (rispettivamente \var{pwd} e \var{root}) di
- \struct{fs\_struct}; vedi fig.~\ref{fig:proc_task_struct}.} che, pur essendo
-di norma corrispondente alla radice dell'albero di file e directory come visto
-dal kernel (ed illustrato in sez.~\ref{sec:file_pathname}), ha per il processo
-il significato specifico di directory rispetto alla quale vengono risolti i
+\index{directory~di~lavoro} directory di lavoro, ha anche una directory
+\textsl{radice}\footnote{entrambe sono contenute in due campi (rispettivamente
+ \var{pwd} e \var{root}) di \kstruct{fs\_struct}; vedi
+ fig.~\ref{fig:proc_task_struct}.} che, pur essendo di norma corrispondente
+alla radice dell'albero di file e directory come visto dal kernel (ed
+illustrato in sez.~\ref{sec:file_pathname}), ha per il processo il significato
+specifico di directory rispetto alla quale vengono risolti i
\itindsub{pathname}{assoluto}\textit{pathname} assoluti.\footnote{cioè quando
un processo chiede la risoluzione di un \textit{pathname}, il kernel usa
sempre questa directory come punto di partenza.} Il fatto che questo valore
sia specificato per ogni processo apre allora la possibilità di modificare le
modalità di risoluzione dei \textit{pathname} assoluti da parte di un processo
cambiando questa directory, così come si fa coi
-\itindsub{pathname}{relativo}\textit{pathname} relativi cambiando la directory
-di lavoro.
+\itindsub{pathname}{relativo}\textit{pathname} relativi cambiando la
+\index{directory~di~lavoro} directory di lavoro.
Normalmente la directory radice di un processo coincide anche con la radice
del filesystem usata dal kernel, e dato che il suo valore viene ereditato dal
Questo è il motivo per cui la funzione è efficace solo se dopo averla eseguita
si cedono i privilegi di root. Infatti se per un qualche motivo il processo
-resta con la directory di lavoro fuori dalla \textit{chroot jail}, potrà
-comunque accedere a tutto il resto del filesystem usando
-\itindsub{pathname}{relativo}\textit{pathname} relativi, i quali, partendo
-dalla directory di lavoro che è fuori della \textit{chroot jail}, potranno
-(con l'uso di ``\texttt{..}'') risalire fino alla radice effettiva del
-filesystem.
+resta con \index{directory~di~lavoro} la directory di lavoro fuori dalla
+\textit{chroot jail}, potrà comunque accedere a tutto il resto del filesystem
+usando \itindsub{pathname}{relativo}\textit{pathname} relativi, i quali,
+partendo dalla directory di lavoro che è fuori della \textit{chroot jail},
+potranno (con l'uso di ``\texttt{..}'') risalire fino alla radice effettiva
+del filesystem.
Ma se ad un processo restano i privilegi di amministratore esso potrà comunque
-portare la sua directory di lavoro fuori dalla \textit{chroot jail} in cui si
-trova. Basta infatti creare una nuova \textit{chroot jail} con l'uso di
-\func{chroot} su una qualunque directory contenuta nell'attuale directory di
-lavoro. Per questo motivo l'uso di questa funzione non ha molto senso quando
-un processo necessita dei privilegi di root per le sue normali operazioni.
+portare la sua \index{directory~di~lavoro} directory di lavoro fuori dalla
+\textit{chroot jail} in cui si trova. Basta infatti creare una nuova
+\textit{chroot jail} con l'uso di \func{chroot} su una qualunque directory
+contenuta nell'attuale directory di lavoro. Per questo motivo l'uso di questa
+funzione non ha molto senso quando un processo necessita dei privilegi di root
+per le sue normali operazioni.
Un caso tipico di uso di \func{chroot} è quello di un server FTP anonimo, in
questo caso infatti si vuole che il server veda solo i file che deve
% LocalWords: Python Truelite Srl quotamodule Repository who nell' dall' KEEP
% LocalWords: SECURE KEEPCAPS prctl FIXUP NOROOT LOCKED dell'IPC dell'I IOPRIO
% LocalWords: CAPBSET CLASS IDLE dcookie overflow DIFFERS Virtual everything
-% LocalWords: dentry register resolution cache dcache operation llseek poll
-% LocalWords: multiplexing fsync fasync seek block superblock gapil tex img
+% LocalWords: dentry register resolution cache dcache operation llseek poll ln
+% LocalWords: multiplexing fsync fasync seek block superblock gapil tex img du
% 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
%%% mode: latex
%%% TeX-master: "gapil"
%%% End:
+% LocalWords: bind DIRSYNC lsattr Hierarchy FHS SHARED UNBINDABLE shared REC
+% LocalWords: subtree SILENT log unbindable BUSY EAGAIN EXPIRE DETACH NOFOLLOW
+% LocalWords: lazy
projects / gapil.git / blobdiff