X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=blobdiff_plain;f=filedir.tex;h=999c5eeab9b9e9d6950d6522bcee5faf986af17e;hb=8088f2df8bef63d425b42fa72f1f863345ec7ac8;hp=281f8180be103417987806f1fac5a754aed3aeae;hpb=2414addb7861eb72315a3de58b6f2cb5c83ab6ed;p=gapil.git diff --git a/filedir.tex b/filedir.tex index 281f818..999c5ee 100644 --- a/filedir.tex +++ b/filedir.tex @@ -19,12 +19,12 @@ illustrando le principali caratteristiche di un filesystem e le interfacce che consentono di controllarne il montaggio e lo smontaggio. Esamineremo poi le funzioni di libreria che si usano per copiare, spostare e -cambiare i nomi di file e directory ed esamineremo l'interfaccia che permette -la manipolazione dei loro attributi. Tratteremo inoltre la struttura di base -del sistema delle protezioni e del controllo dell'accesso ai file e le -successive estensioni (\textit{Extended Attributes}, ACL, quote disco, -\textit{capabilities}). Tutto quello che riguarda invece la manipolazione del -contenuto dei file è lasciato ai capitoli successivi. +cambiare i nomi di file e directory e l'interfaccia che permette la +manipolazione dei loro attributi. Tratteremo inoltre la struttura di base del +sistema delle protezioni e del controllo dell'accesso ai file e le successive +estensioni (\textit{Extended Attributes}, ACL, quote disco, +\textit{capabilities}). Tutto quello che riguarda invece la gestione dell'I/O +sui file è lasciato al capitolo successivo. @@ -35,14 +35,14 @@ In questa sezione tratteremo con maggiori dettagli rispetto a quanto visto in sez.~\ref{sec:file_arch_overview} il \textit{Virtual File System} di Linux e come il kernel può gestire diversi tipi di filesystem, descrivendo prima le caratteristiche generali di un filesystem di un sistema unix-like, per poi -trattare in maniera un po' più dettagliata il filesystem più usato con Linux, -l'\acr{ext2} (e derivati). +fare una panoramica sul filesystem più usato con Linux, l'\acr{ext2} ed i suoi +successori. \subsection{Il funzionamento del \textit{Virtual File System} di Linux} \label{sec:file_vfs_work} -% articolo interessante: +% NOTE articolo interessante: % http://www.ibm.com/developerworks/linux/library/l-virtual-filesystem-switch/index.html?ca=dgr-lnxw97Linux-VFSdth-LXdW&S_TACT=105AGX59&S_CMP=GRlnxw97 \itindbeg{Virtual~File~System} @@ -51,96 +51,248 @@ Come illustrato brevemente in sez.~\ref{sec:file_arch_overview} in Linux il concetto di \textit{everything is a file} è stato implementato attraverso il \textit{Virtual File System}, la cui struttura generale è illustrata in fig.~\ref{fig:file_VFS_scheme}. Il VFS definisce un insieme di funzioni che -tutti i filesystem devono implementare. L'interfaccia comprende tutte le -funzioni che riguardano i file e le operazioni sono suddivise su tre tipi di -oggetti: \textit{filesystem}, \itindex{inode} \textit{inode} e \textit{file}, -corrispondenti a tre apposite strutture definite nel kernel. +tutti i filesystem devono implementare per l'accesso ai file che contengono e +l'interfaccia che consente di eseguire l'I/O sui file, che questi siano di +dati o dispositivi. + +\itindbeg{inode} + +L'interfaccia fornita dal VFS comprende in sostanza tutte le funzioni che +riguardano i file, le operazioni implementate dal VFS sono realizzate con una +astrazione che prevede quattro tipi di oggetti strettamente correlati: i +filesystem, le \textit{dentry}, gli \textit{inode} ed i file. A questi oggetti +corrispondono una serie di apposite strutture definite dal kernel che +contengono come campi le funzioni di gestione e realizzano l'infrastruttura +del VFS. L'interfaccia è molto complessa, ne faremo pertanto una trattazione +estremamente semplificata che consenta di comprenderne i principi +di funzionamento. Il VFS usa una tabella mantenuta dal kernel che contiene il nome di ciascun -filesystem supportato: quando si vuole inserire il supporto di un nuovo +filesystem supportato, quando si vuole inserire il supporto di un nuovo filesystem tutto quello che occorre è chiamare la funzione -\code{register\_filesystem} passandole un'apposita struttura -\code{file\_system\_type} che contiene i dettagli per il riferimento -all'implementazione del medesimo, che sarà aggiunta alla citata tabella. - -In questo modo quando viene effettuata la richiesta di montare un nuovo disco -o di qualunque altro dispositivo che può contenere un filesystem, il VFS può -ricavare dalla citata tabella il puntatore alle funzioni da chiamare nelle -operazioni di montaggio. Queste sono responsabili inizializzare tutte le -variabili interne e restituire uno speciale descrittore dei filesystem montati -al VFS; attraverso quest'ultimo diventa possibile accedere alle funzioni -specifiche per l'uso di quel filesystem. - -Il primo oggetto usato dal VFS è il descrittore di filesystem (o -\textit{filesystem descriptor}), un puntatore ad una apposita struttura che -contiene vari dati come le informazioni comuni ad ogni filesystem, i dati -privati relativi a quel filesystem specifico, e i puntatori alle funzioni del -kernel relative al filesystem. Il VFS può così usare le funzioni contenute nel -\textit{filesystem descriptor} per accedere alle funzioni specifiche di quel +\code{register\_filesystem} passando come argomento la struttura +\kstruct{file\_system\_type} (la cui definizione è riportata in +fig.~\ref{fig:kstruct_file_system_type}) relativa a quel filesystem. Questa +verrà inserita nella tabella, ed il nuovo filesystem comparirà in +\procfile{/proc/filesystems}. + +\begin{figure}[!htb] + \footnotesize \centering + \begin{minipage}[c]{\textwidth} + \includestruct{listati/file_system_type.h} + \end{minipage} + \normalsize + \caption{Estratto della struttura \kstructd{file\_system\_type} usata dal + VFS (da \texttt{include/linux/fs.h}).} + \label{fig:kstruct_file_system_type} +\end{figure} + +La struttura \kstruct{file\_system\_type}, oltre ad una serie di dati interni, +come il nome del tipo di filesystem nel campo \var{name},\footnote{quello che + viene riportato in \procfile{/proc/filesystems} e che viene usato come + valore del parametro dell'opzione \texttt{-t} del comando \texttt{mount} che + indica il tipo di filesystem.} contiene i riferimenti alle funzioni di base +che consentono l'utilizzo di quel filesystem. In particolare la funzione +\code{mount} del quarto campo è quella che verrà invocata tutte le volte che +si dovrà effettuare il montaggio di un filesystem di quel tipo. Per ogni nuovo +filesystem si dovrà allocare una di queste strutture ed inizializzare i +relativi campi con i dati specifici di quel filesystem, ed in particolare si +dovrà creare anche la relativa versione della funzione \code{mount}. + +\itindbeg{pathname} + +Come illustrato in fig.~\ref{fig:kstruct_file_system_type} questa funzione +restituisce una \textit{dentry}, abbreviazione che sta per \textit{directory + entry}. Le \textit{dentry} sono gli oggetti che il kernel usa per eseguire +la \textit{pathname resolution}, ciascuna di esse corrisponde ad un +\textit{pathname} e contiene il riferimento ad un \textit{inode}, che come +vedremo a breve è l'oggetto usato dal kernel per identificare un un +file.\footnote{in questo caso si parla di file come di un qualunque oggetto + generico che sta sul filesystem e non dell'oggetto file del VFS cui + accennavamo prima.} La \textit{dentry} ottenuta dalla chiamata alla funzione +\code{mount} sarà inserita in corrispondenza al \textit{pathname} della +directory in cui il filesystem è stato montato. + +% NOTA: struct dentry è dichiarata in include/linux/dcache.h + +Le \textit{dentry} sono oggetti del VFS che vivono esclusivamente in memoria, +nella cosiddetta \textit{directory entry cache} (spesso chiamata in breve +\textit{dcache}). Ogni volta che una \textit{system call} specifica un +\textit{pathname} viene effettuata una ricerca nella \textit{dcache} per +ottenere immediatamente la \textit{dentry} corrispondente,\footnote{il buon + funzionamento della \textit{dcache} è in effetti di una delle parti più + critiche per le prestazioni del sistema.} che a sua volta ci darà, tramite +l'\textit{inode}, il riferimento al file. + +Dato che normalmente non è possibile mantenere nella \textit{dcache} le +informazioni relative a tutto l'albero dei file la procedura della +\textit{pathname resolution} richiede un meccanismo con cui riempire gli +eventuali vuoti. Il meccanismo prevede che tutte le volte che si arriva ad una +\textit{dentry} mancante venga invocata la funzione \texttt{lookup} +dell'\textit{inode} associato alla \textit{dentry} precedente nella +risoluzione del \textit{pathname},\footnote{che a questo punto è una + directory, per cui si può cercare al suo interno il nome di un file.} il cui +scopo è risolvere il nome mancante e fornire la sua \textit{dentry} che a +questo punto verrà inserita nella cache. + +Dato che tutte le volte che si monta un filesystem la funzione \texttt{mount} +della corrispondente \kstruct{file\_system\_type} inserisce la \textit{dentry} +iniziale nel \itindex{mount~point} \textit{mount point} dello stesso si avrà +comunque un punto di partenza. Inoltre essendo questa \textit{dentry} relativa +a quel tipo di filesystem essa farà riferimento ad un \textit{inode} di quel +filesystem, e come vedremo questo farà sì che venga eseguita una +\texttt{lookup} adatta per effettuare la risoluzione dei nomi per quel filesystem. -Gli altri due descrittori usati dal VFS sono relativi agli altri due oggetti -su cui è strutturata l'interfaccia. Ciascuno di essi contiene le informazioni -relative al file in uso, insieme ai puntatori alle funzioni dello specifico -filesystem usate per l'accesso dal VFS. In particolare il descrittore -\itindex{inode} dell'\textit{inode} contiene i puntatori alle funzioni che -possono essere usate su qualunque file (come \func{link}, \func{stat} e -\func{open}), mentre il descrittore di file contiene i puntatori alle funzioni -che vengono usate sui file già aperti. - -La funzione più importante implementata dal VFS è la \textit{system call} -\func{open} che permette di aprire un file. Dato un \itindex{pathname} -\textit{pathname} viene eseguita una ricerca dentro la \textit{directory entry - cache} (in breve \textit{dcache}), una tabella che contiene tutte le -\textit{directory entry} (in breve \textit{dentry}) che permette di associare -in maniera rapida ed efficiente il \textit{pathname} a una specifica -\textit{dentry}. - -Una singola \textit{dentry} contiene in genere il puntatore ad un -\itindex{inode} \textit{inode}; quest'ultimo è la struttura base che sta sul -disco e che identifica un singolo oggetto del VFS sia esso un file ordinario, -una directory, un link simbolico, una FIFO, un file di -\index{file!di~dispositivo} dispositivo, o una qualsiasi altra cosa che possa -essere rappresentata dal VFS (i tipi di file riportati in -tab.~\ref{tab:file_file_types}). A ciascuno di essi è associata pure una -struttura che sta in memoria, e che, oltre alle informazioni sullo specifico -file, contiene anche il riferimento alle funzioni (i \textsl{metodi} del VFS) -da usare per poterlo manipolare. - -Le \textit{dentry} ``vivono'' in memoria e non vengono mai salvate su disco, -vengono usate per motivi di velocità, gli \itindex{inode} \textit{inode} invece -stanno su disco e vengono copiati in memoria quando serve, ed ogni cambiamento -viene copiato all'indietro sul disco (aggiornando i cosiddetti -\textsl{metadati} del file), gli \itindex{inode} inode che stanno in memoria -sono \itindex{inode} inode del VFS ed è ad essi che puntano le singole -\textit{dentry}. - -La \textit{dcache} costituisce perciò una sorta di vista completa di tutto -l'albero dei file, ovviamente per non riempire tutta la memoria questa vista è -parziale (la \textit{dcache} cioè contiene solo le \textit{dentry} per i file -per i quali è stato richiesto l'accesso), quando si vuole risolvere un nuovo -\itindex{pathname} \textit{pathname} il VFS deve creare una nuova -\textit{dentry} e caricare \itindex{inode} l'inode corrispondente in memoria. - -Questo procedimento viene eseguito dal metodo \code{lookup()} \itindex{inode} -dell'inode della directory che contiene il file; questo viene installato nelle -relative strutture in memoria quando si effettua il montaggio lo specifico -filesystem su cui l'inode va a vivere. - -Una volta che il VFS ha a disposizione la \textit{dentry} (ed il relativo -\textit{inode}) diventa possibile accedere alle varie operazioni sul file come -la \func{open} per aprire il file o la \func{stat} per leggere i dati -\itindex{inode} dell'inode e passarli in user space. - -L'apertura di un file richiede comunque un'altra operazione, l'allocazione di -una struttura di tipo \struct{file} in cui viene inserito un puntatore alla -\textit{dentry} e una struttura \struct{f\_ops} che contiene i puntatori ai -metodi che implementano le operazioni disponibili sul file. In questo modo i -processi in \textit{user space} possono accedere alle operazioni attraverso -detti metodi, che saranno diversi a seconda del tipo di file (o dispositivo) -aperto (su questo torneremo in dettaglio in sez.~\ref{sec:file_fd}). Un elenco -delle operazioni previste dal kernel è riportato in -tab.~\ref{tab:file_file_operations}. +\itindend{pathname} + +% Un secondo effetto della chiamata funzione \texttt{mount} di +% \kstruct{file\_system\_type} è quello di allocare una struttura +% \kstruct{super\_block} per ciascuna istanza montata, che contiene le +% informazioni generali di un qualunque filesystem montato, come le opzioni di +% montaggio, le dimensioni dei blocchi, quando il filesystem è stato montato +% ecc. Fra queste però viene pure inserta, nel campo \var{s\_op}, una ulteriore +% struttura \kstruct{super\_operations}, il cui contenuto sono i puntatori +% alle funzioni di gestione di un filesystem, anche inizializzata in modo da +% utilizzare le versioni specifiche di quel filesystem. + +L'oggetto più importante per il funzionamento del VFS è probabilmente +l'\textit{inode}, ma con questo nome si può fare riferimento a due cose +diverse. La prima è la struttura su disco (su cui torneremo anche in +sez.~\ref{sec:file_filesystem}) che fa parte della organizzazione dei dati +realizzata dal filesystem e che contiene le informazioni relative alle +proprietà (i cosiddetti \textsl{metadati}) di ogni oggetto presente su di esso +(si intende al solito uno qualunque dei tipi di file di +tab.~\ref{tab:file_file_types}). + +La seconda è la corrispondente struttura \kstruct{inode}, della cui +definizione si è riportato un estratto in +fig.~\ref{fig:kstruct_inode}.\footnote{l'estratto fa riferimento alla versione + del kernel 2.6.37.} Questa struttura viene mantenuta in memoria ed è a +questa che facevamo riferimento quando parlavamo dell'\textit{inode} associato +a ciascuna \textit{dentry}. Nella struttura in memoria sono presenti gli +stessi \textsl{metadati} memorizzati su disco, che vengono letti quando questa +struttura viene allocata e trascritti all'indietro se modificati. + +\begin{figure}[!htb] + \footnotesize \centering + \begin{minipage}[c]{\textwidth} + \includestruct{listati/inode.h} + \end{minipage} + \normalsize + \caption{Estratto della struttura \kstructd{inode} del kernel (da + \texttt{include/linux/fs.h}).} + \label{fig:kstruct_inode} +\end{figure} + +Il fatto che la struttura \kstruct{inode} sia mantenuta in memoria, +direttamente associata ad una \textit{dentry}, rende sostanzialmente immediate +le operazioni che devono semplicemente effettuare un accesso ai dati in essa +contenuti: è così ad esempio che viene realizzata la \textit{system call} +\func{stat} che vedremo in sez.~\ref{sec:file_stat}. Rispetto ai dati salvati +sul disco questa struttura contiene però anche quanto necessario alla +implementazione del VFS, ed in particolare è importante il campo \var{i\_op} +che, come illustrato in fig.~\ref{fig:kstruct_inode}, contiene il puntatore ad +una struttura di tipo \kstruct{inode\_operation}, la cui definizione si può +trovare nel file \texttt{include/kernel/fs.h} dei sorgenti del kernel. + +Questa struttura non è altro che una tabella di funzioni, ogni suo membro cioè +è un puntatore ad una funzione e, come suggerisce il nome della struttura +stessa, queste funzioni sono quelle che definiscono le operazioni che il VFS +può compiere su un \textit{inode}. Si sono riportate in +tab.~\ref{tab:file_inode_operations} le più rilevanti. + +\begin{table}[htb] + \centering + \footnotesize + \begin{tabular}[c]{|l|l|} + \hline + \textbf{Funzione} & \textbf{Operazione} \\ + \hline + \hline + \textsl{\code{create}} & Chiamata per creare un nuovo file (vedi + sez.~\ref{sec:file_open}).\\ + \textsl{\code{link}} & Crea un \textit{hard link} (vedi + sez.~\ref{sec:file_link}).\\ + \textsl{\code{unlink}} & Cancella un \textit{hard link} (vedi + sez.~\ref{sec:file_link}).\\ + \textsl{\code{symlink}}& Crea un link simbolico (vedi + sez.~\ref{sec:file_symlink}).\\ + \textsl{\code{mkdir}} & Crea una directory (vedi + sez.~\ref{sec:file_dir_creat_rem}).\\ + \textsl{\code{rmdir}} & Rimuove una directory (vedi + sez.~\ref{sec:file_dir_creat_rem}).\\ + \textsl{\code{mknod}} & Crea un file speciale (vedi + sez.~\ref{sec:file_mknod}).\\ + \textsl{\code{rename}} & Cambia il nome di un file (vedi + sez.~\ref{sec:file_remove}).\\ + \textsl{\code{lookup}}& Risolve il nome di un file.\\ + \hline + \end{tabular} + \caption{Le principali operazioni sugli \textit{inode} definite tramite + \kstruct{inode\_operation}.} + \label{tab:file_inode_operations} +\end{table} + +Possiamo notare come molte di queste funzioni abbiano nomi sostanzialmente +identici alle varie \textit{system call} con le quali si gestiscono file e +directory, che tratteremo nel resto del capitolo. Quello che succede è che +tutte le volte che deve essere eseguita una \textit{system call}, o una +qualunque altra operazione su un \textit{inode} (come \texttt{lookup}) il VFS +andrà ad utilizzare la funzione corrispondente attraverso il puntatore +\var{i\_op}. + +Sarà allora sufficiente che nella realizzazione di un filesystem si crei una +implementazione di queste funzioni per quel filesystem e si allochi una +opportuna istanza di \kstruct{inode\_operation} contenente i puntatori a dette +funzioni. A quel punto le strutture \kstruct{inode} usate per gli oggetti di +quel filesystem otterranno il puntatore alla relativa istanza di +\kstruct{inode\_operation} e verranno automaticamente usate le funzioni +corrette. + +Si noti però come in tab.~\ref{tab:file_inode_operations} non sia presente la +funzione \texttt{open} che invece è citata in +tab.~\ref{tab:file_file_operations}.\footnote{essa può essere comunque + invocata dato che nella struttura \kstruct{inode} è presente anche il + puntatore \func{i\_fop} alla struttura \kstruct{file\_operation} che + fornisce detta funzione.} Questo avviene perché su Linux l'apertura di un +file richiede comunque un'altra operazione che mette in gioco l'omonimo +oggetto del VFS: l'allocazione di una struttura di tipo \kstruct{file} che +viene associata ad ogni file aperto nel sistema. + +I motivi per cui viene usata una struttura a parte sono diversi, anzitutto, +come illustrato in sez.~\ref{sec:file_fd}, questa è necessaria per le +operazioni eseguite dai processi con l'interfaccia dei file descriptor; ogni +processo infatti mantiene il riferimento ad una struttura \kstruct{file} per +ogni file che ha aperto, ed è tramite essa che esegue le operazioni di I/O. + +Inoltre se le operazioni relative agli \textit{inode} fanno riferimento ad +oggetti posti all'interno di un filesystem e vi si applicano quindi le +funzioni fornite nell'implementazione di quest'ultimo, quando si apre un file +questo può essere anche un file di dispositivo, ed in questo caso il VFS +invece di usare le operazioni fornite dal filesystem (come farebbe per un file +di dati) dovrà invece ricorrere a quelle fornite dal driver del dispositivo. + +\itindend{inode} + +\begin{figure}[!htb] + \footnotesize \centering + \begin{minipage}[c]{\textwidth} + \includestruct{listati/file.h} + \end{minipage} + \normalsize + \caption{Estratto della struttura \kstructd{file} del kernel (da + \texttt{include/linux/fs.h}).} + \label{fig:kstruct_file} +\end{figure} + +Come si può notare dall'estratto di fig.~\ref{fig:kstruct_file}, la struttura +\kstruct{file} contiene, oltre ad alcune informazioni usate dall'interfaccia +dei file descriptor il cui significato emergerà più avanti, il puntatore +\struct{f\_op} ad una struttura \kstruct{file\_operation}. Questa è l'analoga +per i file di \kstruct{inode\_operation}, e definisce le operazioni generiche +fornite dal VFS per i file. Si sono riportate in +tab.~\ref{tab:file_file_operations} le più significative. \begin{table}[htb] \centering @@ -172,23 +324,38 @@ tab.~\ref{tab:file_file_operations}. sez.~\ref{sec:file_asyncronous_io}) sul file.\\ \hline \end{tabular} - \caption{Operazioni sui file definite nel VFS.} + \caption{Operazioni sui file definite tramite \kstruct{file\_operation}.} \label{tab:file_file_operations} \end{table} -In questo modo per ciascun file diventano possibili una serie di operazioni -(non è detto che tutte siano disponibili), che costituiscono l'interfaccia -astratta del VFS. Qualora se ne voglia eseguire una, il kernel andrà ad -utilizzare l'opportuna funzione dichiarata in \struct{f\_ops} appropriata al -tipo di file in questione. - -Pertanto è possibile scrivere allo stesso modo sulla porta seriale come su un -normale file di dati; ovviamente certe operazioni (nel caso della seriale ad -esempio la \code{seek}) non saranno disponibili, però con questo sistema -l'utilizzo di diversi filesystem (come quelli usati da Windows o MacOS) è -immediato e relativamente trasparente per l'utente ed il programmatore. +Anche in questo caso tutte le volte che deve essere eseguita una +\textit{system call} o una qualunque altra operazione sul file il VFS andrà ad +utilizzare la funzione corrispondente attraverso il puntatore +\var{f\_op}. Dato che è cura del VFS quando crea la struttura all'apertura del +file assegnare a \var{f\_op} il puntatore alla versione di +\kstruct{file\_operation} corretta per quel file, sarà possibile scrivere allo +stesso modo sulla porta seriale come su un normale file di dati, e lavorare +sui file allo stesso modo indipendentemente dal filesystem. + +Il VFS realizza la quasi totalità delle operazioni relative ai file grazie +alle funzioni presenti nelle due strutture \kstruct{inode\_operation} e +\kstruct{file\_operation}. Ovviamente non è detto che tutte le operazioni +possibili siano poi disponibili in tutti i casi, ad esempio \code{llseek} non +sarà presente per un dispositivo come la porta seriale o per una fifo, mentre +sui file del filesystem \texttt{vfat} non saranno disponibili i permessi, ma +resta il fatto che grazie al VFS le \textit{system call} per le operazioni sui +file possono restare sempre le stesse nonostante le enormi differenze che +possono esserci negli oggetti a cui si applicano. + + \itindend{Virtual~File~System} +% NOTE: documentazione interessante: +% * sorgenti del kernel: Documentation/filesystems/vfs.txt +% * http://thecoffeedesk.com/geocities/rkfs.html +% * http://www.linux.it/~rubini/docs/vfs/vfs.html + + \subsection{Il funzionamento di un filesystem Unix} \label{sec:file_filesystem} @@ -197,142 +364,170 @@ Come già accennato in sez.~\ref{sec:file_arch_overview} Linux (ed ogni sistema unix-like) organizza i dati che tiene su disco attraverso l'uso di un filesystem. Una delle caratteristiche di Linux rispetto agli altri Unix è quella di poter supportare, grazie al VFS, una enorme quantità di filesystem -diversi, ognuno dei quali ha una sua particolare struttura e funzionalità -proprie. Per questo per il momento non entreremo nei dettagli di un -filesystem specifico, ma daremo una descrizione a grandi linee che si adatta -alle caratteristiche comuni di qualunque filesystem di un sistema unix-like. - -Lo spazio fisico di un disco viene usualmente diviso in partizioni; ogni -partizione può contenere un filesystem. La strutturazione tipica -dell'informazione su un disco è riportata in fig.~\ref{fig:file_disk_filesys}, -in essa si fa riferimento alla struttura del filesystem \acr{ext2}, che -prevede una separazione dei dati in \textit{block group} che replicano il -cosiddetto \textit{superblock} (ma sulle caratteristiche di \acr{ext2} e -derivati torneremo in sez.~\ref{sec:file_ext2}). È comunque caratteristica -comune di tutti i filesystem per Unix, indipendentemente da come poi viene -strutturata nei dettagli questa informazione, prevedere una divisione fra la -lista degli \itindex{inode} inode e lo spazio a disposizione per i dati e le -directory. +diversi, ognuno dei quali avrà una sua particolare struttura e funzionalità +proprie. Per questo non entreremo nei dettagli di un filesystem specifico, ma +daremo una descrizione a grandi linee che si adatta alle caratteristiche +comuni di qualunque filesystem di un sistema unix-like. + +Una possibile strutturazione dell'informazione su un disco è riportata in +fig.~\ref{fig:file_disk_filesys}, dove si hanno tre filesystem su tre +partizioni. In essa per semplicità si è fatto riferimento alla struttura del +filesystem \acr{ext2}, che prevede una suddivisione dei dati in \textit{block + group}. All'interno di ciascun \textit{block group} viene anzitutto +replicato il cosiddetto \textit{superblock}, (la struttura che contiene +l'indice iniziale del filesystem e che consente di accedere a tutti i dati +sottostanti) e creata una opportuna suddivisione dei dati e delle informazioni +per accedere agli stessi. Sulle caratteristiche di \acr{ext2} e derivati +torneremo in sez.~\ref{sec:file_ext2}. + +\itindbeg{inode} + +È comunque caratteristica comune di tutti i filesystem per Unix, +indipendentemente da come poi viene strutturata nei dettagli questa +informazione, prevedere la presenza di due tipi di risorse: gli +\textit{inode}, cui abbiamo già accennato in sez.~\ref{sec:file_vfs_work}, che +sono le strutture che identificano i singoli oggetti sul filesystem, e i +blocchi, che invece attengono allo spazio disco che viene messo a disposizione +per i dati in essi contenuti. \begin{figure}[!htb] \centering - \includegraphics[width=14cm]{img/disk_struct} + \includegraphics[width=12cm]{img/disk_struct} \caption{Organizzazione dello spazio su un disco in partizioni e filesystem.} \label{fig:file_disk_filesys} \end{figure} Se si va ad esaminare con maggiore dettaglio la strutturazione -dell'informazione all'interno del singolo filesystem (tralasciando i dettagli -relativi al funzionamento del filesystem stesso come la strutturazione in -gruppi dei blocchi, il superblock e tutti i dati di gestione) possiamo -esemplificare la situazione con uno schema come quello esposto in -fig.~\ref{fig:file_filesys_detail}. +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}. \begin{figure}[!htb] \centering - \includegraphics[width=14cm]{img/filesys_struct} + \includegraphics[width=12cm]{img/filesys_struct} \caption{Strutturazione dei dati all'interno di un filesystem.} \label{fig:file_filesys_detail} \end{figure} Da fig.~\ref{fig:file_filesys_detail} si evidenziano alcune delle -caratteristiche di base di un filesystem, sulle quali è bene porre attenzione -visto che sono fondamentali per capire il funzionamento delle funzioni che -manipolano i file e le directory che tratteremo nel prossimo capitolo; in -particolare è opportuno ricordare sempre che: +caratteristiche di base di un filesystem, che restano le stesse anche su +filesystem la cui organizzazione dei dati è totalmente diversa da quella +illustrata, e sulle quali è bene porre attenzione visto che sono fondamentali +per capire il funzionamento delle funzioni che manipolano i file e le +directory che tratteremo nel prosieguo del capitolo. In particolare è +opportuno tenere sempre presente che: + \begin{enumerate} -\item L'\textit{inode} \itindex{inode} contiene tutte le informazioni (i - cosiddetti \textsl{metadati}) riguardanti il file: il tipo di file, i - permessi di accesso, le dimensioni, i puntatori ai blocchi fisici che - contengono i dati e così via. Le informazioni che la funzione \func{stat} - fornisce provengono dall'\textit{inode}; dentro una directory si troverà - solo il nome del file e il numero \itindex{inode} dell'\textit{inode} ad esso - associato, cioè quella che da qui in poi chiameremo una \textsl{voce} (come - traduzione dell'inglese \textit{directory entry}, che non useremo anche per - evitare confusione con le \textit{dentry} del kernel di cui si parlava in - sez.~\ref{sec:file_vfs_work}). +\item L'\textit{inode} contiene i cosiddetti \textsl{metadati}, vale dire le + informazioni riguardanti le proprietà del file come oggetto del filesystem: + il tipo di file, i permessi di accesso, le dimensioni, i puntatori ai + blocchi fisici che contengono i dati e così via. Le informazioni che la + funzione \func{stat} (vedi sez.~\ref{sec:file_stat}) fornisce provengono + dall'\textit{inode}. Dentro una directory si troverà solo il nome del file + e il numero dell'\textit{inode} ad esso associato; il nome non è una + proprietà del file e non viene mantenuto nell'\textit{inode}. Da da qui in + poi chiameremo il nome del file contenuto in una directory + ``\textsl{voce}'', come traduzione della nomenclatura inglese + \textit{directory entry} che non useremo per evitare confusione con le + \textit{dentry} del kernel viste in sez.~\ref{sec:file_vfs_work}. -\item Come mostrato in fig.~\ref{fig:file_filesys_detail} si possono avere più - voci che puntano allo stesso \textit{inode}. Ogni \textit{inode} ha un - contatore che contiene il numero di riferimenti che sono stati fatti ad esso - (il cosiddetto \textit{link count}); solo quando questo contatore si annulla - i dati del file vengono effettivamente rimossi dal disco. Per questo la - funzione per cancellare un file si chiama \func{unlink}, ed in realtà non - cancella affatto i dati del file, ma si limita ad eliminare la relativa voce - da una directory e decrementare il numero di riferimenti \itindex{inode} - nell'\textit{inode}. +\item Come mostrato in fig.~\ref{fig:file_filesys_detail} per i file + \texttt{macro.tex} e \texttt{gapil\_macro.tex}, ci possono avere più voci + che fanno riferimento allo stesso \textit{inode}. Fra le proprietà di un + file mantenute nell'\textit{inode} c'è anche il contatore con il numero di + riferimenti che sono stati fatti ad esso, il cosiddetto \textit{link + count}.\footnote{mantenuto anche nel campo \var{i\_nlink} della struttura + \kstruct{inode} di fig.~\ref{fig:kstruct_inode}.} Solo quando questo + contatore si annulla i dati del file possono essere effettivamente rimossi + dal disco. Per questo la funzione per cancellare un file si chiama + \func{unlink} (vedi sez.~\ref{sec:file_link}), ed in realtà non cancella + affatto i dati del file, ma si limita ad eliminare la relativa voce da una + directory e decrementare il numero di riferimenti nell'\textit{inode}. -\item Il numero di \textit{inode} nella voce si riferisce ad un \textit{inode} - nello stesso filesystem e non ci può essere una directory che contiene - riferimenti ad \itindex{inode} \textit{inode} relativi ad altri filesystem. - Questo limita l'uso del comando \cmd{ln} (che crea una nuova voce per un - file esistente con la funzione \func{link}) al filesystem corrente. +\item All'interno di ogni filesystem ogni \textit{inode} è identificato da un + numero univoco. Il numero di \textit{inode} associato ad una voce in una + directory si riferisce ad questo numero e non ci può essere una directory + che contiene riferimenti ad \textit{inode} relativi ad altri filesystem. + Questa è la ragione che limita l'uso del comando \cmd{ln}, che crea una + nuova voce per un file esistente con la funzione \func{link} (vedi + sez.~\ref{sec:file_link}) a file nel filesystem corrente. -\item Quando si cambia nome ad un file senza cambiare filesystem, il contenuto +\item Quando si cambia nome ad un file senza cambiare filesystem il contenuto del file non viene spostato fisicamente, viene semplicemente creata una - nuova voce per \itindex{inode} l'\textit{inode} in questione e rimossa la - vecchia (questa è la modalità in cui opera normalmente il comando \cmd{mv} - attraverso la funzione \func{rename}). Questa operazione non modifica - minimamente neanche l'\textit{inode} del file dato che non si opera su - questo ma sulla directory che lo contiene. + nuova voce per l'\textit{inode} in questione e rimossa la precedente, questa + è la modalità in cui opera normalmente il comando \cmd{mv} attraverso la + funzione \func{rename} (vedi sez.~\ref{sec:file_remove}). Questa operazione + non modifica minimamente neanche l'\textit{inode} del file, dato che non si + opera sul file ma sulla directory che lo contiene. -\item Gli \textit{inode} dei file, che contengono i \textsl{metadati} ed i +\item Gli \textit{inode} dei file, che contengono i \textsl{metadati}, ed i blocchi di spazio disco, che contengono i dati, sono risorse indipendenti ed in genere vengono gestite come tali anche dai diversi filesystem; è pertanto - possibile sia esaurire lo spazio disco (caso più comune) che lo spazio per - gli \textit{inode}, nel primo caso non sarà possibile allocare ulteriore + possibile esaurire sia lo spazio disco (il caso più comune) che lo spazio + per gli \textit{inode}. Nel primo caso non sarà possibile allocare ulteriore spazio, ma si potranno creare file (vuoti), nel secondo non si potranno - creare nuovi file, ma si potranno estendere quelli che ci sono. + creare nuovi file, ma si potranno estendere quelli che ci + sono.\footnote{questo comportamento non è generale, alcuni filesystem + evoluti possono evitare il problema dell'esaurimento degli \textit{inode} + riallocando lo spazio disco libero per i blocchi.} \end{enumerate} -Infine si noti che, essendo file pure loro, il numero di riferimenti esiste -anche per le directory; per cui, se a partire dalla situazione mostrata in -fig.~\ref{fig:file_filesys_detail} creiamo una nuova directory \file{img} -nella directory \file{gapil}, avremo una situazione come quella in -fig.~\ref{fig:file_dirs_link}, dove per chiarezza abbiamo aggiunto dei numeri -di \itindex{inode} inode. - \begin{figure}[!htb] \centering - \includegraphics[width=14cm]{img/dir_links} + \includegraphics[width=12cm]{img/dir_links} \caption{Organizzazione dei \textit{link} per le directory.} \label{fig:file_dirs_link} \end{figure} -La nuova directory avrà allora un numero di riferimenti pari a due, in quanto -è referenziata dalla directory da cui si era partiti (in cui è inserita la -nuova voce che fa riferimento a \texttt{img}) e dalla voce ``\texttt{.}'' che -è sempre inserita in ogni directory; questo vale sempre per ogni directory che -non contenga a sua volta altre directory. Al contempo, la directory da cui si -era partiti avrà un numero di riferimenti di almeno tre, in quanto adesso sarà -referenziata anche dalla voce ``\texttt{..}'' di \texttt{img}. +Infine tenga presente che, essendo file pure loro, il numero di riferimenti +esiste anche per le directory. Per questo se a partire dalla situazione +mostrata in fig.~\ref{fig:file_filesys_detail} creiamo una nuova directory +\file{img} nella directory \file{gapil}, avremo una situazione come quella +illustrata in fig.~\ref{fig:file_dirs_link}. + +La nuova directory avrà un numero di riferimenti pari a due, in quanto è +referenziata dalla directory da cui si era partiti (in cui è inserita la nuova +voce che fa riferimento a \texttt{img}) e dalla voce interna ``\texttt{.}'' +che è presente in ogni directory. Questo è il valore che si troverà sempre +per ogni directory che non contenga a sua volta altre directory. Al contempo, +la directory da cui si era partiti avrà un numero di riferimenti di almeno +tre, in quanto adesso sarà referenziata anche dalla voce ``\texttt{..}'' di +\texttt{img}. L'aggiunta di una sottodirectory fa cioè crescere di uno il +\textit{link count} della directory genitrice. +\itindend{inode} -\subsection{I filesystem di uso comune} + +\subsection{Alcuni dettagli sul filesystem \textsl{ext2} e successori} \label{sec:file_ext2} -Il filesystem standard più usato con Linux è il cosiddetto \textit{third - extended filesystem}, identificato dalla sigla \acr{ext3}.\footnote{si fa - riferimento al momento della stesura di questo paragrafo, l'inizio del - 2010.} Esso nasce come evoluzione del precedente \textit{second extended - filesystem}, o \acr{ext2}, di cui eredita gran parte delle caratteristiche -di base, per questo motivo parleremo anzitutto di questo, dato che molto di -quanto diremo si applica anche ad \acr{ext3}. A partire dal kernel 2.6.XX è -stato dichiarato stabile il nuovo filsesystem \textit{ext4}, ulteriore -evoluzione di \textit{ext3} dotato di molte caratteristiche avanzate, che sta -iniziando a sostituirlo gradualmente. - -Il filesystem \acr{ext2} nasce come filesystem nativo di Linux a partire dalle -prime versioni del kernel e supporta tutte le caratteristiche di un filesystem -standard Unix: è in grado di gestire nomi di file lunghi (256 caratteri, -estensibili a 1012) e supporta una dimensione massima dei file fino a 4~Tb. I -successivi filesystem \acr{ext3} ed \acr{ext4} sono evoluzioni di questo -filesystem, e sia pure con molti miglioramenti ed estensioni significative ne -mantengono in sostanza le caratteristiche fondamentali. + +Benché non esista ``il'' filesystem di Linux, dato che esiste un supporto +nativo di diversi filesystem che sono in uso da anni, quello che gli avvicina +di più è la famiglia di filesystem evolutasi a partire dal \textit{second + extended filesystem}, o \acr{ext2}. Il filesystem \acr{ext2} ha subito un +grande sviluppo e diverse evoluzioni, fra cui l'aggiunta del +\textit{journaling} con \acr{ext3}, probabilmente ancora il filesystem più +diffuso, ed una serie di ulteriori miglioramento con il successivo \acr{ext4}, +che sta iniziando a sostituirlo gradualmente. In futuro è previsto che questo +debba essere sostituito da un filesystem completamente diverso, \acr{btrfs}, +che dovrebbe diventare il filesystem standard di Linux, ma questo al momento è +ancora in fase di sviluppo.\footnote{si fa riferimento al momento dell'ultima + revisione di di questo paragrafo, l'inizio del 2012.} + +Il filesystem \acr{ext2} nasce come filesystem nativo per Linux a partire +dalle prime versioni del kernel e supporta tutte le caratteristiche di un +filesystem standard Unix: è in grado di gestire nomi di file lunghi (256 +caratteri, estensibili a 1012) e supporta una dimensione massima dei file fino +a 4~Tb. I successivi filesystem \acr{ext3} ed \acr{ext4} sono evoluzioni di +questo filesystem, e sia pure con molti miglioramenti ed estensioni +significative ne mantengono le caratteristiche fondamentali. Oltre alle caratteristiche standard, \acr{ext2} fornisce alcune estensioni che non sono presenti su un classico filesystem di tipo Unix; le principali sono @@ -349,14 +544,15 @@ le seguenti: gruppo primario del processo, eccetto il caso in cui la directory ha il bit di \acr{sgid} impostato (per una descrizione dettagliata del significato di questi termini si veda sez.~\ref{sec:file_access_control}), nel qual caso - file e subdirectory ereditano sia il \acr{gid} che lo \acr{sgid}. + file e subdirectory ereditano sia il \ids{GID} che lo \acr{sgid}. \item l'amministratore può scegliere la dimensione dei blocchi del filesystem - in fase di creazione, a seconda delle sue esigenze (blocchi più grandi - permettono un accesso più veloce, ma sprecano più spazio disco). + in fase di creazione, a seconda delle sue esigenze: blocchi più grandi + permettono un accesso più veloce, ma sprecano più spazio disco. \item il filesystem implementa link simbolici veloci, in cui il nome del file - non è salvato su un blocco, ma tenuto all'interno \itindex{inode} dell'inode - (evitando letture multiple e spreco di spazio), non tutti i nomi però - possono essere gestiti così per limiti di spazio (il limite è 60 caratteri). + non è salvato su un blocco, ma tenuto all'interno \itindex{inode} + dell'\textit{inode} (evitando letture multiple e spreco di spazio), non + tutti i nomi però possono essere gestiti così per limiti di spazio (il + limite è 60 caratteri). \item vengono supportati i file immutabili (che possono solo essere letti) per la protezione di file di configurazione sensibili, o file \textit{append-only} che possono essere aperti in scrittura solo per @@ -367,25 +563,19 @@ le seguenti: La struttura di \acr{ext2} è stata ispirata a quella del filesystem di BSD: un filesystem è composto da un insieme di blocchi, la struttura generale è quella riportata in fig.~\ref{fig:file_filesys_detail}, in cui la partizione è divisa -in gruppi di blocchi.\footnote{non si confonda questa definizione con - quella riportata in fig.~\ref{fig:file_dirent_struct}; in quel caso si fa - riferimento alla struttura usata in user space per riportare i dati - contenuti in una directory generica, questa fa riferimento alla struttura - usata dal kernel per un filesystem \acr{ext2}, definita nel file - \texttt{ext2\_fs.h} nella directory \texttt{include/linux} dei sorgenti del - kernel.} +in gruppi di blocchi. Ciascun gruppo di blocchi contiene una copia delle informazioni essenziali del -filesystem (superblock e descrittore del filesystem sono quindi ridondati) per -una maggiore affidabilità e possibilità di recupero in caso di corruzione del -superblock principale. L'utilizzo di raggruppamenti di blocchi ha inoltre -degli effetti positivi nelle prestazioni dato che viene ridotta la distanza -fra i dati e la tabella degli \itindex{inode} inode. +filesystem (i \textit{superblock} sono quindi ridondati) per una maggiore +affidabilità e possibilità di recupero in caso di corruzione del +\textit{superblock} principale. L'utilizzo di raggruppamenti di blocchi ha +inoltre degli effetti positivi nelle prestazioni dato che viene ridotta la +distanza fra i dati e la tabella degli \itindex{inode} inode. \begin{figure}[!htb] \centering \includegraphics[width=9cm]{img/dir_struct} - \caption{Struttura delle directory nel \textit{second extented filesystem}.} + \caption{Struttura delle directory nel \textit{second extended filesystem}.} \label{fig:file_ext2_dirs} \end{figure} @@ -396,12 +586,12 @@ lunghezza, secondo lo schema in fig.~\ref{fig:file_ext2_dirs}; in questo modo è possibile implementare nomi per i file anche molto lunghi (fino a 1024 caratteri) senza sprecare spazio disco. -Con l'introduzione del filesystem \textit{ext3} sono state introdotte anche -alcune modifiche strutturali, la principale di queste è quella che -\textit{ext3} è un filesystem \textit{jounrnaled}, è cioè in grado di eseguire -una registrazione delle operazioni di scrittura su un giornale (uno speciale -file interno) in modo da poter garantire il ripristino della coerenza dei dati -del filesystem\footnote{si noti bene che si è parlato di dati \textsl{del} +Con l'introduzione del filesystem \textit{ext3} sono state introdotte diverse +modifiche strutturali, la principale di queste è quella che \textit{ext3} è un +filesystem \textit{journaled}, è cioè in grado di eseguire una registrazione +delle operazioni di scrittura su un giornale (uno speciale file interno) in +modo da poter garantire il ripristino della coerenza dei dati del +filesystem\footnote{si noti bene che si è parlato di dati \textsl{del} filesystem, non di dati \textsl{nel} filesystem, quello di cui viene garantito un veloce ripristino è relativo ai dati della struttura interna del filesystem, non di eventuali dati contenuti nei file che potrebbero @@ -412,148 +602,229 @@ della scrittura dei dati sul disco. Oltre a questo \textit{ext3} introduce ulteriori modifiche volte a migliorare sia le prestazioni che la semplicità di gestione del filesystem, in particolare per le directory si è passato all'uso di alberi binari con -indicizzazione tramite hash al posto delle \textit{linked list}, ottenendo un -forte guadagno di prestazioni in caso di directory contenenti un gran numero -di file. +indicizzazione tramite hash al posto delle \textit{linked list} che abbiamo +illustrato, ottenendo un forte guadagno di prestazioni in caso di directory +contenenti un gran numero di file. % TODO portare a ext3, ext4 e btrfs ed illustrare le problematiche che si % possono incontrare (in particolare quelle relative alla perdita di contenuti % in caso di crash del sistema) -\subsection{La gestione dei filesystem} +\subsection{La gestione dell'uso dei filesystem} \label{sec:sys_file_config} Come accennato in sez.~\ref{sec:file_arch_overview} per poter accedere ai file occorre prima rendere disponibile al sistema il filesystem su cui essi sono memorizzati; l'operazione di attivazione del filesystem è chiamata -\textsl{montaggio}, per far questo in Linux\footnote{la funzione è specifica - di Linux e non è portabile.} si usa la funzione \funcd{mount} il cui -prototipo è: -\begin{prototype}{sys/mount.h} -{mount(const char *source, const char *target, const char *filesystemtype, - unsigned long mountflags, const void *data)} +\textsl{montaggio}, per far questo in Linux si usa la funzione \funcd{mount}, +il cui prototipo è:\footnote{la funzione è una versione specifica di Linux che + usa la omonima \textit{system call} e non è portabile.} + +\begin{funcproto}{ +\fhead{sys/mount.h} +\fdecl{mount(const char *source, const char *target, const char + *filesystemtype, \\ +\phantom{mount(}unsigned long mountflags, const void *data)} +\fdesc{Monta un filesystem.} +} -Monta il filesystem di tipo \param{filesystemtype} contenuto in \param{source} -sulla directory \param{target}. - - \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di - fallimento, nel qual caso gli errori comuni a tutti i filesystem che possono - essere restituiti in \var{errno} sono: +{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual + caso \var{errno} assumerà uno dei valori: \begin{errlist} - \item[\errcode{EPERM}] il processo non ha i privilegi di amministratore. - \item[\errcode{ENODEV}] \param{filesystemtype} non esiste o non è configurato - nel kernel. - \item[\errcode{ENOTBLK}] non si è usato un \textit{block device} per - \param{source} quando era richiesto. + \item[\errcode{EACCES}] non si ha il permesso di accesso su uno dei + componenti del \itindex{pathname} \textit{pathname}, o si è cercato di + montare un filesystem disponibile in sola lettura senza aver specificato + \const{MS\_RDONLY} o il device \param{source} è su un filesystem montato + con l'opzione \const{MS\_NODEV}. \item[\errcode{EBUSY}] \param{source} è già montato, o non può essere - rimontato in read-only perché ci sono ancora file aperti in scrittura, o - \param{target} è ancora in uso. - \item[\errcode{EINVAL}] il device \param{source} presenta un + rimontato in sola lettura perché ci sono ancora file aperti in scrittura, + o non può essere montato su \param{target} perché la directory è ancora in + uso. + \item[\errcode{EINVAL}] il dispositivo \param{source} presenta un \textit{superblock} non valido, o si è cercato di rimontare un filesystem non ancora montato, o di montarlo senza che \param{target} sia un - \textit{mount point} o di spostarlo quando \param{target} non è un - \textit{mount point} o è \file{/}. - \item[\errcode{EACCES}] non si ha il permesso di accesso su uno dei - componenti del \itindex{pathname} \textit{pathname}, o si è cercato - di montare un filesystem disponibile in sola lettura senza averlo - specificato o il device \param{source} è su un filesystem montato con - l'opzione \const{MS\_NODEV}. - \item[\errcode{ENXIO}] il \itindex{major~number} \textit{major number} del - device \param{source} è sbagliato. + \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. - \end{errlist} - ed inoltre \errval{ENOTDIR}, \errval{EFAULT}, \errval{ENOMEM}, - \errval{ENAMETOOLONG}, \errval{ENOENT} o \errval{ELOOP}.} -\end{prototype} - -La funzione monta sulla directory \param{target}, detta \textit{mount point}, -il filesystem contenuto in \param{source}. In generale un filesystem è -contenuto su un disco, e l'operazione di montaggio corrisponde a rendere -visibile al sistema il contenuto del suddetto disco, identificato attraverso -il file di dispositivo ad esso associato. - -Ma la struttura del \textit{Virtual File System} vista in -sez.~\ref{sec:file_vfs_work} è molto più flessibile e può essere usata anche -per oggetti diversi da un disco. Ad esempio usando il \textit{loop device} si -può montare un file qualunque (come l'immagine di un CD-ROM o di un floppy) -che contiene un filesystem, inoltre alcuni filesystem, come \file{proc} o -\file{devfs} sono del tutto virtuali, i loro dati sono generati al volo ad -ogni lettura, e passati al kernel ad ogni scrittura. - -Il tipo di filesystem è specificato da \param{filesystemtype}, che deve essere -una delle stringhe riportate nel file \procfile{/proc/filesystems}, che -contiene l'elenco dei filesystem supportati dal kernel; nel caso si sia -indicato uno dei filesystem virtuali, il contenuto di \param{source} viene -ignorato. + \item[\errcode{ENODEV}] il tipo \param{filesystemtype} non esiste o non è + configurato nel kernel. + \item[\errcode{ENOTBLK}] non si è usato un \textit{block device} per + \param{source} quando era richiesto. + \item[\errcode{ENXIO}] il \itindex{major~number} \textit{major number} del + dispositivo \param{source} è sbagliato. + \item[\errcode{EPERM}] il processo non ha i privilegi di amministratore. + \end{errlist} + ed inoltre \errval{EFAULT}, \errval{ELOOP}, \errval{ENOMEM}, + \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOTDIR} nel loro + significato generico.} +\end{funcproto} + +La funzione monta sulla directory indicata \param{target}, detta +\itindex{mount~point} \textit{mount point}, il filesystem contenuto nel file +di dispositivo indicato \param{source}. In entrambi i casi, come daremo per +assunto da qui in avanti tutte le volte che si parla di directory o file nel +passaggio di un argomento di una funzione, si intende che questi devono essere +indicati con la stringa contenente il loro \itindex{pathname} +\textit{pathname}. + +Normalmente un filesystem è contenuto su un disco o una partizione, ma come +illustrato in sez.~\ref{sec:file_vfs_work} la struttura del +\itindex{Virtual~File~System} \textit{Virtual File System} è estremamente +flessibile e può essere usata anche per oggetti diversi da un disco. Ad +esempio usando il \textit{loop device} si può montare un file qualunque (come +l'immagine di un CD-ROM o di un floppy) che contiene l'immagine di un +filesystem, inoltre alcuni tipi di filesystem, come \texttt{proc} o +\texttt{sysfs} sono virtuali e non hanno un supporto che ne contenga i dati, +che invece sono generati al volo ad ogni lettura, e passati indietro al kernel +ad ogni scrittura.\footnote{costituiscono quindi un meccanismo di + comunicazione, attraverso l'ordinaria interfaccia dei file, con il kernel.} + +Il tipo di filesystem che si vuole montare è specificato +dall'argomento \param{filesystemtype}, che deve essere una delle stringhe +riportate nel file \procfile{/proc/filesystems} che, come accennato in +sez.~\ref{sec:file_vfs_work}, contiene l'elenco dei filesystem supportati dal +kernel. Nel caso si sia indicato un filesystem virtuale, che non è associato a +nessun file di dispositivo, il contenuto di \param{source} viene ignorato. + +L'argomento \param{data} viene usato per passare le impostazioni relative alle +caratteristiche specifiche di ciascun filesystem. Si tratta di una stringa di +parole chiave (separate da virgole e senza spazi) che indicano le cosiddette +``\textsl{opzioni}'' del filesystem che devono essere impostate; in genere +viene usato direttamente il contenuto del parametro dell'opzione \texttt{-o} +del comando \texttt{mount}. I valori utilizzabili dipendono dal tipo di +filesystem e ciascuno ha i suoi, pertanto si rimanda alla documentazione della +pagina di manuale di questo comando e dei singoli filesystem. Dopo l'esecuzione della funzione il contenuto del filesystem viene resto -disponibile nella directory specificata come \textit{mount point}, il -precedente contenuto di detta directory viene mascherato dal contenuto della -directory radice del filesystem montato. - -Dal kernel 2.4.x inoltre è divenuto possibile sia spostare atomicamente un -\textit{mount point} da una directory ad un'altra, sia montare in diversi -\textit{mount point} lo stesso filesystem, sia montare più filesystem sullo -stesso \textit{mount point} (nel qual caso vale quanto appena detto, e solo il -contenuto dell'ultimo filesystem montato sarà visibile). - -Ciascun filesystem è dotato di caratteristiche specifiche che possono essere -attivate o meno, alcune di queste sono generali (anche se non è detto siano -disponibili in ogni filesystem), e vengono specificate come opzioni di -montaggio con l'argomento \param{mountflags}. - -In Linux \param{mountflags} deve essere un intero a 32 bit i cui 16 più -significativi sono un \textit{magic number}\footnote{cioè un numero speciale - usato come identificativo, che nel caso è \code{0xC0ED}; si può usare la +disponibile nella directory specificata come \itindex{mount~point} +\textit{mount point}, il precedente contenuto di detta directory viene +mascherato dal contenuto della directory radice del filesystem montato. Fino +ai kernel della serie 2.2.x non era possibile montare un filesytem se un +\textit{mount point} era già in uso. + +A partire dal kernel 2.4.x inoltre è divenuto possibile sia spostare +atomicamente un \itindex{mount~point} \textit{mount point} da una directory ad +un'altra, sia montare lo stesso filesystem in diversi \itindex{mount~point} +\textit{mount point}, sia montare più filesystem sullo stesso +\itindex{mount~point} \textit{mount point} impilandoli l'uno sull'altro, nel +qual caso vale comunque quanto detto in precedenza, e cioè che solo il +contenuto dell'ultimo filesystem montato sarà visibile. + +Oltre alle opzioni specifiche di ciascun filesystem, che si passano nella +forma delle opzioni indicata con l'argomento \param{data}, esistono pure +alcune opzioni che si possono applicare in generale, anche se non è detto che +tutti i filesystem le supportino, che si specificano tramite +l'argomento \param{mountflags}. L'argomento inoltre può essere utilizzato per +modificare il comportamento della funzione, facendole compiere una operazione +diversa (ad esempio un rimontaggio, invece che un montaggio). + +In Linux \param{mountflags} deve essere un intero a 32 bit, fino ai kernel +della serie 2.2.x i 16 più significativi avevano un valore riservato che +doveva essere specificato obbligatoriamente,\footnote{il valore era il + \itindex{magic~number} \textit{magic number} \code{0xC0ED}, si può usare la costante \const{MS\_MGC\_MSK} per ottenere la parte di \param{mountflags} - riservata al \textit{magic number}.} mentre i 16 meno significativi sono -usati per specificare le opzioni; essi sono usati come maschera binaria e -vanno impostati con un OR aritmetico della costante \const{MS\_MGC\_VAL} con i -valori riportati in tab.~\ref{tab:sys_mount_flags}. - -\begin{table}[htb] - \footnotesize - \centering - \begin{tabular}[c]{|l|r|l|} - \hline - \textbf{Parametro} & \textbf{Valore}&\textbf{Significato}\\ - \hline - \hline - \const{MS\_RDONLY} & 1 & Monta in sola lettura.\\ - \const{MS\_NOSUID} & 2 & Ignora i bit \itindex{suid~bit} \acr{suid} e - \itindex{sgid~bit} \acr{sgid}.\\ - \const{MS\_NODEV} & 4 & Impedisce l'accesso ai file di dispositivo.\\ - \const{MS\_NOEXEC} & 8 & Impedisce di eseguire programmi.\\ - \const{MS\_SYNCHRONOUS}& 16 & Abilita la scrittura sincrona.\\ - \const{MS\_REMOUNT} & 32 & Rimonta il filesystem cambiando le opzioni.\\ - \const{MS\_MANDLOCK} & 64 & Consente il \textit{mandatory locking} - \itindex{mandatory~locking} (vedi - sez.~\ref{sec:file_mand_locking}).\\ - \const{S\_WRITE} & 128 & Scrive normalmente.\\ - \const{S\_APPEND} & 256 & Consente la scrittura solo in - \itindex{append~mode} \textit{append mode} - (vedi sez.~\ref{sec:file_sharing}).\\ - \const{S\_IMMUTABLE} & 512 & Impedisce che si possano modificare i file.\\ - \const{MS\_NOATIME} &1024 & Non aggiorna gli \textit{access time} (vedi - sez.~\ref{sec:file_file_times}).\\ - \const{MS\_NODIRATIME}&2048 & Non aggiorna gli \textit{access time} delle - directory.\\ - \const{MS\_BIND} &4096 & Monta il filesystem altrove.\\ - \const{MS\_MOVE} &8192 & Sposta atomicamente il punto di montaggio.\\ - \hline - \end{tabular} - \caption{Tabella dei codici dei flag di montaggio di un filesystem.} - \label{tab:sys_mount_flags} -\end{table} + 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: + +\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. In + questo caso verranno presi in considerazione solo gli argomenti + \texttt{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à 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, + ogni modifica fatta in uno qualunque dei due rami di albero sarà visibile + nell'altro, visto che entrambi faranno riferimento agli stessi + \textit{inode}. + + Dal punto di vista del \itindex{Virtual~File~System} VFS l'operazione è + analoga al montaggio di un filesystem proprio nel fatto che anche in questo + caso si inserisce in corripondenza della \textit{dentry} di \texttt{target} + un diverso \textit{inode}, che stavolta invece di essere quello della radice + del filesystem indicato da un file di dispositivo è quello di una directory + già montata. + + Si tenga presente che proprio per questo sotto \texttt{target} comparirà il + contenuto che è presente sotto \texttt{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 + 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.} + + 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 può far sì che l'accesso ai file sotto + \texttt{target} possa avvenire soltanto in sola lettura. + + Il supporto per il \textit{bind mount} consente di superare i limiti + presenti per gli \textit{hard link} (di cui parleremo in + sez.~\ref{sec:file_link}) e di poter far comparire una qualunque porzione + dell'albero dei file all'interno di una qualunque directory, anche se questa + sta su un filesystem diverso, fornendo una alternativa all'uso dei link + simbolici (di cui parleremo in sez.~\ref{sec:file_symlink}) che funziona + correttamente anche all'intero di un \textit{chroot} (argomento su cui + torneremo in sez.~\ref{sec:file_chroot}. + + +\itindend{bind~mount} + +\item[\const{MS\_DIRSYNC}] . + +\item[\const{MS\_MANDLOCK}] Consente il \textit{mandatory locking} + \itindex{mandatory~locking} (vedi sez.~\ref{sec:file_mand_locking}). + +\item[\const{MS\_MOVE}] Sposta atomicamente il punto di montaggio. + +\item[\const{MS\_NOATIME}] Non aggiorna gli \textit{access time} (vedi + sez.~\ref{sec:file_file_times}). + +\item[\const{MS\_NODEV}] Impedisce l'accesso ai file di dispositivo. + +\item[\const{MS\_NODIRATIME}] Non aggiorna gli \textit{access time} delle + directory. +\item[\const{MS\_NOEXEC}] Impedisce di eseguire programmi. + +\item[\const{MS\_NOSUID}] Ignora i bit \itindex{suid~bit} \acr{suid} e + \itindex{sgid~bit} \acr{sgid}. + +\item[\const{MS\_RDONLY}] Monta in sola lettura. + +\item[\const{MS\_RELATIME}] . + +\item[\const{MS\_REMOUNT}] Rimonta il filesystem cambiando le opzioni. + +\item[\const{MS\_SILENT}] . + +\item[\const{MS\_STRICTATIME}] . + +\item[\const{MS\_SYNCHRONOUS}] Abilita la scrittura sincrona. % TODO aggiornare con i nuovi flag di man mount -% gli S_* non esistono più come segnalato da Alessio... % verificare i readonly mount bind del 2.6.26 - -Per l'impostazione delle caratteristiche particolari di ciascun filesystem si -usa invece l'argomento \param{data} che serve per passare le ulteriori -informazioni necessarie, che ovviamente variano da filesystem a filesystem. +\end{basedescript} La funzione \func{mount} può essere utilizzata anche per effettuare il \textsl{rimontaggio} di un filesystem, cosa che permette di cambiarne al volo @@ -566,43 +837,50 @@ viene ignorato. Una volta che non si voglia più utilizzare un certo filesystem è possibile \textsl{smontarlo} usando la funzione \funcd{umount}, il cui prototipo è: -\begin{prototype}{sys/mount.h}{umount(const char *target)} - - Smonta il filesystem montato sulla directory \param{target}. - - \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di - fallimento, nel qual caso \var{errno} assumerà uno dei valori: + +\begin{funcproto}{ +\fhead{sys/mount.h} +\fdecl{umount(const char *target)} +\fdesc{Smonta un filesystem.} +} +{La funzione ritorna $0$ in caso + di successo e $-1$ per un errore, + nel qual caso \var{errno} assumerà uno dei valori: \begin{errlist} \item[\errcode{EPERM}] il processo non ha i privilegi di amministratore. \item[\errcode{EBUSY}] \param{target} è la directory di lavoro di qualche processo, o contiene dei file aperti, o un altro mount point. - \end{errlist} - ed inoltre \errval{ENOTDIR}, \errval{EFAULT}, \errval{ENOMEM}, - \errval{ENAMETOOLONG}, \errval{ENOENT} o \errval{ELOOP}.} -\end{prototype} -\noindent la funzione prende il nome della directory su cui il filesystem è -montato e non il file o il dispositivo che è stato montato,\footnote{questo è - vero a partire dal kernel 2.3.99-pre7, prima esistevano due chiamate - separate e la funzione poteva essere usata anche specificando il file di - dispositivo.} in quanto con il kernel 2.4.x è possibile montare lo stesso -dispositivo in più punti. Nel caso più di un filesystem sia stato montato -sullo stesso \textit{mount point} viene smontato quello che è stato montato -per ultimo. +\end{errlist}ed inoltre \errval{ENOTDIR}, \errval{EFAULT}, \errval{ENOMEM}, +\errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ELOOP} nel loro + significato generico.} +\end{funcproto} + +La funzione prende il nome della directory su cui il filesystem è montato e +non il file o il dispositivo che è stato montato,\footnote{questo è vero a + partire dal kernel 2.3.99-pre7, prima esistevano due chiamate separate e la + funzione poteva essere usata anche specificando il file di dispositivo.} in +quanto con il kernel 2.4.x è possibile montare lo stesso dispositivo in più +punti. Nel caso più di un filesystem sia stato montato sullo stesso +\itindex{mount~point} \textit{mount point} viene smontato quello che è stato +montato per ultimo. Si tenga presente che la funzione fallisce quando il filesystem è \textsl{occupato}, questo avviene quando ci sono ancora file aperti sul filesystem, se questo contiene la directory di lavoro corrente di un qualunque -processo o il mount point di un altro filesystem; in questo caso l'errore -restituito è \errcode{EBUSY}. +processo o il \itindex{mount~point} \textit{mount point} di un altro +filesystem; in questo caso l'errore restituito è \errcode{EBUSY}. Linux provvede inoltre una seconda funzione, \funcd{umount2}, che in alcuni casi permette di forzare lo smontaggio di un filesystem, anche quando questo risulti occupato; il suo prototipo è: -\begin{prototype}{sys/mount.h}{umount2(const char *target, int flags)} - - La funzione è identica a \func{umount} per comportamento e codici di errore, - ma con \param{flags} si può specificare se forzare lo smontaggio. -\end{prototype} +\begin{funcproto}{ +\fhead{sys/mount.h} +\fdecl{umount2(const char *target, int flags)} +\fdesc{Smonta un filesystem.} +} +{La funzione è identica a \func{umount} per valori di ritorno e codici di + errore. } +\end{funcproto} Il valore di \param{flags} è una maschera binaria, e al momento l'unico valore definito è il bit \const{MNT\_FORCE}; gli altri bit devono essere nulli. @@ -618,25 +896,23 @@ Altre due funzioni specifiche di Linux,\footnote{esse si trovano anche su BSD, ma con una struttura diversa.} utili per ottenere in maniera diretta informazioni riguardo al filesystem su cui si trova un certo file, sono \funcd{statfs} e \funcd{fstatfs}, i cui prototipi sono: -\begin{functions} - \headdecl{sys/vfs.h} - \funcdecl{int statfs(const char *path, struct statfs *buf)} - \funcdecl{int fstatfs(int fd, struct statfs *buf)} - - Restituisce in \param{buf} le informazioni relative al filesystem su cui è - posto il file specificato. - - \bodydesc{Le funzioni ritornano 0 in caso di successo e -1 in caso di - errore, nel qual caso \var{errno} assumerà uno dei valori: +\begin{funcproto}{ +\fhead{sys/vfs.h} +\fdecl{int statfs(const char *path, struct statfs *buf)} +\fdecl{int fstatfs(int fd, struct statfs *buf)} +\fdesc{Restituiscono informazioni relative ad un filesystem.} +} +{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, + nel qual caso \var{errno} assumerà uno dei valori: \begin{errlist} \item[\errcode{ENOSYS}] il filesystem su cui si trova il file specificato non - supporta la funzione. - \end{errlist} - e \errval{EFAULT} ed \errval{EIO} per entrambe, \errval{EBADF} per - \func{fstatfs}, \errval{ENOTDIR}, \errval{ENAMETOOLONG}, \errval{ENOENT}, - \errval{EACCES}, \errval{ELOOP} per \func{statfs}.} -\end{functions} + \end{errlist} ed inoltre \errval{EFAULT} ed \errval{EIO} per entrambe, + \errval{EBADF} per \func{fstatfs}, \errval{ENOTDIR}, \errval{ENAMETOOLONG}, + \errval{ENOENT}, \errval{EACCES}, \errval{ELOOP} per \func{statfs} nel loro + significato generico.} +\end{funcproto} + Queste funzioni permettono di ottenere una serie di informazioni generali riguardo al filesystem su cui si trova il file specificato; queste vengono @@ -735,7 +1011,8 @@ diretto, o \textit{hard link}. Il prototipo della funzione è il seguente: errore nel qual caso \var{errno} viene impostata ai valori: \begin{errlist} \item[\errcode{EXDEV}] i file \param{oldpath} e \param{newpath} non fanno - riferimento ad un filesystem montato sullo stesso \textit{mount point}. + riferimento ad un filesystem montato sullo stesso \itindex{mount~point} + \textit{mount point}. \item[\errcode{EPERM}] il filesystem che contiene \param{oldpath} e \param{newpath} non supporta i link diretti o è una directory. \item[\errcode{EEXIST}] un file (o una directory) di nome \param{newpath} @@ -765,9 +1042,9 @@ 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 -\textit{mount point}.\footnote{si tenga presente infatti (vedi - sez.~\ref{sec:sys_file_config}) che a partire dal kernel 2.4 uno stesso - filesystem può essere montato più volte su directory diverse.} +\itindex{mount~point} \textit{mount point}.\footnote{si tenga presente infatti + (vedi sez.~\ref{sec:sys_file_config}) che a partire dal kernel 2.4 uno + stesso filesystem può essere montato più volte su directory diverse.} La funzione inoltre opera sia sui file ordinari che sugli altri oggetti del filesystem, con l'eccezione delle directory. In alcune versioni di Unix solo @@ -780,10 +1057,12 @@ complicata (in genere per questo tipo di errori occorre far girare il programma \cmd{fsck} per riparare il filesystem). Data la pericolosità di questa operazione e la disponibilità dei link -simbolici che possono fornire la stessa funzionalità senza questi problemi, -nel caso di Linux questa capacità è stata completamente disabilitata, e al -tentativo di creare un link diretto ad una directory la funzione \func{link} -restituisce l'errore \errcode{EPERM}. +simbolici (che vedremo in sez.~\ref{sec:file_symlink}) e dei +\itindex{bind~mount} \textit{bind mount} (già visti in +sez.~\ref{sec:sys_file_config}) che possono fornire la stessa funzionalità +senza questi problemi, nel caso di Linux questa capacità è stata completamente +disabilitata, e al tentativo di creare un link diretto ad una directory la +funzione \func{link} restituisce l'errore \errcode{EPERM}. Un ulteriore comportamento peculiare di Linux è quello in cui si crea un \textit{hard link} ad un link simbolico. In questo caso lo standard POSIX @@ -795,10 +1074,9 @@ iniziale di Linux ma a partire dai kernel della serie 2.0.x\footnote{per la kernel di sviluppo 1.3.56, ed è stato temporaneamente ripristinato anche durante lo sviluppo della serie 2.1.x, per poi tornare al comportamento attuale fino ad oggi (per riferimento si veda - \href{http://lwn.net/Articles/293902} - {\texttt{http://lwn.net/Articles/293902}}).} è stato adottato un -comportamento che non segue più lo standard per cui l'\textit{hard link} viene -creato rispetto al link simbolico, e non al file cui questo punta. + \url{http://lwn.net/Articles/293902}).} è stato adottato un comportamento +che non segue più lo standard per cui l'\textit{hard link} viene creato +rispetto al link simbolico, e non al file cui questo punta. La ragione di questa differenza rispetto allo standard, presente anche in altri sistemi unix-like, sono dovute al fatto che un link simbolico può fare @@ -944,7 +1222,7 @@ nello stesso filesystem) si usa invece la funzione \funcd{rename},\footnote{la non vuota. \item[\errcode{EBUSY}] o \param{oldpath} o \param{newpath} sono in uso da parte di qualche processo (come directory di lavoro o come radice) o del - sistema (come mount point). + 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. @@ -1239,7 +1517,7 @@ La funzione che permette la cancellazione di una directory è invece \begin{errlist} \item[\errcode{EPERM}] il filesystem non supporta la cancellazione di directory, oppure la directory che contiene \param{dirname} ha lo - \itindex{sticky~bit} \textit{sticky bit} impostato e l'\acr{uid} effettivo + \itindex{sticky~bit} \textit{sticky bit} impostato e l'\ids{UID} effettivo del processo non corrisponde al proprietario della directory. \item[\errcode{EACCES}] non c'è il permesso di scrittura per la directory che contiene la directory che si vuole cancellare, o non c'è il permesso @@ -2144,7 +2422,7 @@ La funzionane genera un nome univoco sostituendo le \code{XXXXXX} finali di funzione non si può usare una stringa costante. Tutte le avvertenze riguardo alle possibili \itindex{race~condition} \textit{race condition} date per \func{tmpnam} continuano a valere; inoltre in alcune vecchie implementazioni -il valore usato per sostituire le \code{XXXXXX} viene formato con il \acr{pid} +il valore usato per sostituire le \code{XXXXXX} viene formato con il \ids{PID} del processo più una lettera, il che mette a disposizione solo 26 possibilità diverse per il nome del file, e rende il nome temporaneo facile da indovinare. Per tutti questi motivi la funzione è deprecata e non dovrebbe mai essere @@ -2307,13 +2585,13 @@ riportato in tab.~\ref{tab:file_type_macro}. \textbf{Macro} & \textbf{Tipo del file} \\ \hline \hline - \macro{S\_ISREG(m)} & file normale.\\ - \macro{S\_ISDIR(m)} & directory.\\ - \macro{S\_ISCHR(m)} & dispositivo a caratteri.\\ - \macro{S\_ISBLK(m)} & dispositivo a blocchi.\\ - \macro{S\_ISFIFO(m)} & fifo.\\ - \macro{S\_ISLNK(m)} & link simbolico.\\ - \macro{S\_ISSOCK(m)} & socket.\\ + \macro{S\_ISREG}\texttt{(m)} & file normale.\\ + \macro{S\_ISDIR}\texttt{(m)} & directory.\\ + \macro{S\_ISCHR}\texttt{(m)} & dispositivo a caratteri.\\ + \macro{S\_ISBLK}\texttt{(m)} & dispositivo a blocchi.\\ + \macro{S\_ISFIFO}\texttt{(m)} & fifo.\\ + \macro{S\_ISLNK}\texttt{(m)} & link simbolico.\\ + \macro{S\_ISSOCK}\texttt{(m)} & socket.\\ \hline \end{tabular} \caption{Macro per i tipi di file (definite in \texttt{sys/stat.h}).} @@ -2863,7 +3141,7 @@ concetti essenziali e le funzioni usate per gestirne i vari aspetti. Ad ogni file Linux associa sempre l'utente che ne è proprietario (il cosiddetto \textit{owner}) ed un gruppo di appartenenza, secondo il meccanismo -degli identificatori di utente e gruppo (\acr{uid} e \acr{gid}). Questi valori +degli identificatori di utente e gruppo (\ids{UID} e \ids{GID}). Questi valori sono accessibili da programma tramite la funzione \func{stat}, e sono mantenuti nei campi \var{st\_uid} e \var{st\_gid} della struttura \struct{stat} (si veda sez.~\ref{sec:file_stat}).\footnote{questo è vero solo @@ -3010,8 +3288,8 @@ veda sez.~\ref{sec:file_special_perm}). La procedura con cui il kernel stabilisce se un processo possiede un certo permesso (di lettura, scrittura o esecuzione) si basa sul confronto fra l'utente e il gruppo a cui il file appartiene (i valori di \var{st\_uid} e -\var{st\_gid} accennati in precedenza) e l'\acr{uid} effettivo, il \acr{gid} -effettivo e gli eventuali \acr{gid} supplementari del processo.\footnote{in +\var{st\_gid} accennati in precedenza) e l'\ids{UID} effettivo, il \ids{GID} +effettivo e gli eventuali \ids{GID} supplementari del processo.\footnote{in realtà Linux, per quanto riguarda l'accesso ai file, utilizza gli identificatori del gruppo \textit{filesystem} (si ricordi quanto esposto in sez.~\ref{sec:proc_perms}), ma essendo questi del tutto equivalenti ai primi, @@ -3020,19 +3298,19 @@ effettivo e gli eventuali \acr{gid} supplementari del processo.\footnote{in Per una spiegazione dettagliata degli identificatori associati ai processi si veda sez.~\ref{sec:proc_perms}; normalmente, a parte quanto vedremo in -sez.~\ref{sec:file_special_perm}, l'\acr{uid} effettivo e il \acr{gid} effettivo -corrispondono ai valori dell'\acr{uid} e del \acr{gid} dell'utente che ha -lanciato il processo, mentre i \acr{gid} supplementari sono quelli dei gruppi +sez.~\ref{sec:file_special_perm}, l'\ids{UID} effettivo e il \ids{GID} effettivo +corrispondono ai valori dell'\ids{UID} e del \ids{GID} dell'utente che ha +lanciato il processo, mentre i \ids{GID} supplementari sono quelli dei gruppi cui l'utente appartiene. I passi attraverso i quali viene stabilito se il processo possiede il diritto di accesso sono i seguenti: \begin{enumerate} -\item Se l'\acr{uid} effettivo del processo è zero (corrispondente +\item Se l'\ids{UID} effettivo del processo è zero (corrispondente all'amministratore) l'accesso è sempre garantito senza nessun ulteriore controllo. Per questo motivo \textsl{root} ha piena libertà di accesso a tutti i file. -\item Se l'\acr{uid} effettivo del processo è uguale all'\acr{uid} del +\item Se l'\ids{UID} effettivo del processo è uguale all'\ids{UID} del proprietario del file (nel qual caso si dice che il processo è proprietario del file) allora: \begin{itemize*} @@ -3042,8 +3320,8 @@ di accesso sono i seguenti: impostato, l'accesso è consentito \item altrimenti l'accesso è negato \end{itemize*} -\item Se il \acr{gid} effettivo del processo o uno dei \acr{gid} supplementari - dei processi corrispondono al \acr{gid} del file allora: +\item Se il \ids{GID} effettivo del processo o uno dei \ids{GID} supplementari + dei processi corrispondono al \ids{GID} del file allora: \begin{itemize*} \item se il bit dei permessi d'accesso del gruppo è impostato, l'accesso è consentito, @@ -3084,9 +3362,9 @@ corrispondono a quelli dell'utente con cui si è entrati nel sistema. Se però il file del programma (che ovviamente deve essere eseguibile\footnote{per motivi di sicurezza il kernel ignora i bit \acr{suid} e \acr{sgid} per gli script eseguibili.}) ha il bit \acr{suid} impostato, il -kernel assegnerà come \acr{uid} effettivo al nuovo processo l'\acr{uid} del -proprietario del file al posto dell'\acr{uid} del processo originario. Avere -il bit \acr{sgid} impostato ha lo stesso effetto sul \acr{gid} effettivo del +kernel assegnerà come \ids{UID} effettivo al nuovo processo l'\ids{UID} del +proprietario del file al posto dell'\ids{UID} del processo originario. Avere +il bit \acr{sgid} impostato ha lo stesso effetto sul \ids{GID} effettivo del processo. I bit \acr{suid} e \acr{sgid} vengono usati per permettere agli utenti normali @@ -3183,10 +3461,10 @@ consapevolmente, cancellare i file temporanei creati degli altri utenti. \label{sec:file_perm_management} Come visto in sez.~\ref{sec:file_access_control} il controllo di accesso ad un -file viene fatto utilizzando l'\acr{uid} ed il \acr{gid} effettivo del processo; -ci sono casi però in cui si può voler effettuare il controllo con l'\acr{uid} -reale ed il \acr{gid} reale, vale a dire usando i valori di \acr{uid} e -\acr{gid} relativi all'utente che ha lanciato il programma, e che, come +file viene fatto utilizzando l'\ids{UID} ed il \ids{GID} effettivo del processo; +ci sono casi però in cui si può voler effettuare il controllo con l'\ids{UID} +reale ed il \ids{GID} reale, vale a dire usando i valori di \ids{UID} e +\ids{GID} relativi all'utente che ha lanciato il programma, e che, come accennato in sez.~\ref{sec:file_special_perm} e spiegato in dettaglio in sez.~\ref{sec:proc_perms}, non è detto siano uguali a quelli effettivi. @@ -3276,7 +3554,7 @@ filename e su un file descriptor, i loro prototipi sono: \bodydesc{Le funzioni restituiscono zero in caso di successo e -1 per un errore, in caso di errore \var{errno} può assumere i valori: \begin{errlist} - \item[\errcode{EPERM}] l'\acr{uid} effettivo non corrisponde a quello del + \item[\errcode{EPERM}] l'\ids{UID} effettivo non corrisponde a quello del proprietario del file o non è zero. \item[\errcode{EROFS}] il file è su un filesystem in sola lettura. \end{errlist} @@ -3340,7 +3618,7 @@ bit \itindex{suid~bit} \acr{suid} il valore da fornire sarebbe $4755$. Il cambiamento dei permessi di un file eseguito attraverso queste funzioni ha comunque alcune limitazioni, previste per motivi di sicurezza. L'uso delle -funzioni infatti è possibile solo se l'\acr{uid} effettivo del processo +funzioni infatti è possibile solo se l'\ids{UID} effettivo del processo corrisponde a quello del proprietario del file o dell'amministratore, altrimenti esse falliranno con un errore di \errcode{EPERM}. @@ -3350,7 +3628,7 @@ non tutti i valori possibili di \param{mode} sono permessi o hanno effetto; in particolare accade che: \begin{enumerate} \item siccome solo l'amministratore può impostare lo \itindex{sticky~bit} - \textit{sticky bit}, se l'\acr{uid} effettivo del processo non è zero esso + \textit{sticky bit}, se l'\ids{UID} effettivo del processo non è zero esso viene automaticamente cancellato (senza notifica di errore) qualora sia stato indicato in \param{mode}. \item per quanto detto in sez.~\ref{sec:file_ownership_management} riguardo la @@ -3360,7 +3638,7 @@ in particolare accade che: un file appartenente ad un gruppo per cui non si hanno diritti, questo viene automaticamente cancellato da \param{mode} (senza notifica di errore) qualora il gruppo del file non corrisponda a quelli associati al processo - (la cosa non avviene quando l'\acr{uid} effettivo del processo è zero). + (la cosa non avviene quando l'\ids{UID} effettivo del processo è zero). \end{enumerate} Per alcuni filesystem\footnote{i filesystem più comuni (\textsl{ext2}, @@ -3433,21 +3711,21 @@ quale utente e gruppo esso deve appartenere. Lo stesso problema si presenta per la creazione di nuove directory (procedimento descritto in sez.~\ref{sec:file_dir_creat_rem}). -Lo standard POSIX prescrive che l'\acr{uid} del nuovo file corrisponda -all'\acr{uid} effettivo del processo che lo crea; per il \acr{gid} invece prevede -due diverse possibilità: +Lo standard POSIX prescrive che l'\ids{UID} del nuovo file corrisponda +all'\ids{UID} effettivo del processo che lo crea; per il \ids{GID} invece +prevede due diverse possibilità: \begin{itemize*} -\item il \acr{gid} del file corrisponde al \acr{gid} effettivo del processo. -\item il \acr{gid} del file corrisponde al \acr{gid} della directory in cui +\item il \ids{GID} del file corrisponde al \ids{GID} effettivo del processo. +\item il \ids{GID} del file corrisponde al \ids{GID} della directory in cui esso è creato. \end{itemize*} in genere BSD usa sempre la seconda possibilità, che viene per questo chiamata semantica BSD. Linux invece segue quella che viene chiamata semantica SVr4; di norma cioè il nuovo file viene creato, seguendo la prima opzione, con il -\acr{gid} del processo, se però la directory in cui viene creato il file ha il +\ids{GID} del processo, se però la directory in cui viene creato il file ha il bit \acr{sgid} impostato allora viene usata la seconda opzione. -Usare la semantica BSD ha il vantaggio che il \acr{gid} viene sempre +Usare la semantica BSD ha il vantaggio che il \ids{GID} viene sempre automaticamente propagato, restando coerente a quello della directory di partenza, in tutte le sotto-directory. @@ -3456,7 +3734,7 @@ risultato di coerenza che si ha con BSD necessita che quando si creano nuove directory venga anche propagato anche il bit \acr{sgid}. Questo è il comportamento predefinito del comando \cmd{mkdir}, ed è in questo modo ad esempio che le varie distribuzioni assicurano che le sotto-directory create -nella home di un utente restino sempre con il \acr{gid} del gruppo primario +nella home di un utente restino sempre con il \ids{GID} del gruppo primario dello stesso. La presenza del bit \acr{sgid} è inoltre molto comoda quando si hanno @@ -3488,7 +3766,7 @@ l'utente che il gruppo a cui un file appartiene; i rispettivi prototipi sono: \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 per un errore, nel qual caso caso \var{errno} assumerà i valori: \begin{errlist} - \item[\errcode{EPERM}] l'\acr{uid} effettivo non corrisponde a quello del + \item[\errcode{EPERM}] l'\ids{UID} effettivo non corrisponde a quello del proprietario del file o non è zero, o utente e gruppo non sono validi \end{errlist} Oltre a questi entrambe restituiscono gli errori \errval{EROFS} e @@ -4199,15 +4477,15 @@ identificatori del gruppo \textit{effective} del processo, ma in presenza di ACL i passi attraverso i quali viene stabilito se esso ha diritto di accesso sono i seguenti: \begin{enumerate*} -\item Se l'\acr{uid} del processo è nullo l'accesso è sempre garantito senza +\item Se l'\ids{UID} del processo è nullo l'accesso è sempre garantito senza nessun controllo. -\item Se l'\acr{uid} del processo corrisponde al proprietario del file allora: +\item Se l'\ids{UID} del processo corrisponde al proprietario del file allora: \begin{itemize*} \item se la voce \const{ACL\_USER\_OBJ} contiene il permesso richiesto, l'accesso è consentito; \item altrimenti l'accesso è negato. \end{itemize*} -\item Se l'\acr{uid} del processo corrisponde ad un qualunque qualificatore +\item Se l'\ids{UID} del processo corrisponde ad un qualunque qualificatore presente in una voce \const{ACL\_USER} allora: \begin{itemize*} \item se la voce \const{ACL\_USER} corrispondente e la voce @@ -4215,7 +4493,7 @@ sono i seguenti: consentito; \item altrimenti l'accesso è negato. \end{itemize*} -\item Se è il \acr{gid} del processo o uno dei \acr{gid} supplementari +\item Se è il \ids{GID} del processo o uno dei \ids{GID} supplementari corrisponde al gruppo proprietario del file allora: \begin{itemize*} \item se la voce \const{ACL\_GROUP\_OBJ} e una eventuale voce @@ -4224,7 +4502,7 @@ sono i seguenti: l'accesso è consentito; \item altrimenti l'accesso è negato. \end{itemize*} -\item Se è il \acr{gid} del processo o uno dei \acr{gid} supplementari +\item Se è il \ids{GID} del processo o uno dei \ids{GID} supplementari corrisponde ad un qualunque qualificatore presente in una voce \const{ACL\_GROUP} allora: \begin{itemize*} @@ -4568,7 +4846,7 @@ tab.~\ref{tab:acl_to_text_options}. \hline \const{TEXT\_ABBREVIATE} & stampa le voci in forma abbreviata.\\ \const{TEXT\_NUMERIC\_IDS} & non effettua la risoluzione numerica di - \acr{uid} e \acr{gid}.\\ + \ids{UID} e \ids{GID}.\\ \const{TEXT\_SOME\_EFFECTIVE}& per ciascuna voce che contiene permessi che vengono eliminati dalla \const{ACL\_MASK} viene generato un commento con i permessi @@ -4894,7 +5172,7 @@ La funzione richiede che il filesystem sul quale si vuole operare sia montato con il supporto delle quote abilitato; esso deve essere specificato con il nome del file di dispositivo nell'argomento \param{dev}. Per le operazioni che lo richiedono inoltre si dovrà indicare con l'argomento \param{id} l'utente o -il gruppo (specificati rispettivamente per \acr{uid} e \acr{gid}) su cui si +il gruppo (specificati rispettivamente per \ids{UID} e \ids{GID}) su cui si vuole operare. Alcune operazioni usano l'argomento \param{addr} per indicare un indirizzo ad un area di memoria il cui utilizzo dipende dall'operazione stessa. @@ -5003,10 +5281,10 @@ l'amministratore può ottenere i dati di tutti. \hline \const{QFMT\_VFS\_OLD}& il vecchio (ed obsoleto) formato delle quote.\\ \const{QFMT\_VFS\_V0} & la versione 0 usata dal VFS di Linux (supporta - \acr{uid} e \acr{gid} a 32 bit e limiti fino a + \ids{UID} e \ids{GID} a 32 bit e limiti fino a $2^{42}$ byte e $2^{32}$ file.\\ \const{QFMT\_VFS\_V1} & la versione 1 usata dal VFS di Linux (supporta - \acr{uid} e \acr{GID} a 32 bit e limiti fino a + \ids{UID} e \ids{GID} a 32 bit e limiti fino a $2^{64}$ byte e $2^{64}$ file.\\ \hline \end{tabular} @@ -5366,7 +5644,7 @@ casistica assai complessa. Per i kernel fino al 2.6.25, o se non si attiva il supporto per le \textit{file capabilities}, il \textit{capabilities bounding set} è un parametro generale di sistema, il cui valore viene riportato nel file -\procfile{/proc/sys/kernel/cap-bound}. Il suo valore iniziale è definito in +\sysctlfile{kernel/cap-bound}. Il suo valore iniziale è definito in sede di compilazione del kernel, e da sempre ha previsto come default la presenza di tutte le \textit{capabilities} eccetto \const{CAP\_SETPCAP}. In questa situazione solo il primo processo eseguito nel sistema (quello con @@ -5391,7 +5669,7 @@ tutti, compreso l'amministratore.\footnote{la qual cosa, visto il default Con il kernel 2.6.25 e le \textit{file capabilities} il \textit{bounding set} è diventato una proprietà di ciascun processo, che viene propagata invariata sia attraverso una \func{fork} che una \func{exec}. In questo caso il file -\procfile{/proc/sys/kernel/cap-bound} non esiste e \texttt{init} non ha nessun +\sysctlfile{kernel/cap-bound} non esiste e \texttt{init} non ha nessun ruolo speciale, inoltre in questo caso all'avvio il valore iniziale prevede la presenza di tutte le capacità (compresa \const{CAP\_SETPCAP}). @@ -5474,7 +5752,7 @@ nell'esecuzione di un qualunque programma l'amministratore perderebbe tutti i privilegi originali dal processo. Per questo motivo se un programma senza \textit{capabilities} assegnate viene -eseguito da un processo con \acr{uid} reale 0, esso verrà trattato come +eseguito da un processo con \ids{UID} reale 0, esso verrà trattato come se tanto il \textit{permitted set} che l'\textit{inheritable set} fossero con tutte le \textit{capabilities} abilitate, con l'\textit{effective set} attivo, col risultato di fornire comunque al processo tutte le capacità presenti nel @@ -5483,19 +5761,19 @@ il \acr{suid} bit ed appartiene all'amministratore, in entrambi i casi si riesce così a riottenere il comportamento classico di un sistema unix-like. Una seconda circostanza è quella relativa a cosa succede alle -\textit{capabilities} di un processo nelle possibili transizioni da \acr{uid} -nullo a \acr{uid} non nullo o viceversa (corrispondenti rispettivamente a +\textit{capabilities} di un processo nelle possibili transizioni da \ids{UID} +nullo a \ids{UID} non nullo o viceversa (corrispondenti rispettivamente a cedere o riottenere i i privilegi di amministratore) che si possono effettuare con le varie funzioni viste in sez.~\ref{sec:proc_setuid}. In questo caso la casistica è di nuovo alquanto complessa, considerata anche la presenza dei diversi gruppi di identificatori illustrati in tab.~\ref{tab:proc_uid_gid}, si avrà allora che: \begin{enumerate*} -\item se si passa da \acr{uid} effettivo nullo a non nullo +\item se si passa da \ids{UID} effettivo nullo a non nullo l'\textit{effective set} del processo viene totalmente azzerato, se - viceversa si passa da \acr{uid} effettivo non nullo a nullo il + viceversa si passa da \ids{UID} effettivo non nullo a nullo il \textit{permitted set} viene copiato nell'\textit{effective set}; -\item se si passa da \textit{file system} \acr{uid} nullo a non nullo verranno +\item se si passa da \textit{file system} \ids{UID} nullo a non nullo verranno cancellate dall'\textit{effective set} del processo tutte le capacità attinenti i file, e cioè \const{CAP\_LINUX\_IMMUTABLE}, \const{CAP\_MKNOD}, \const{CAP\_DAC\_OVERRIDE}, \const{CAP\_DAC\_READ\_SEARCH}, @@ -5530,7 +5808,7 @@ Per questo motivo a partire dal kernel 2.6.26, se le \textit{file ulteriore maschera binaria, chiamata \textit{securebits flags}, su cui sono mantenuti una serie di flag (vedi tab.~\ref{tab:securebits_values}) il cui valore consente di modificare queste regole speciali che si applicano ai -processi con \acr{uid} nullo. La maschera viene sempre mantenuta +processi con \ids{UID} nullo. La maschera viene sempre mantenuta attraverso una \func{fork}, mentre attraverso una \func{exec} viene sempre cancellato il flag \const{SECURE\_KEEP\_CAPS}. @@ -5544,22 +5822,22 @@ cancellato il flag \const{SECURE\_KEEP\_CAPS}. \hline \const{SECURE\_KEEP\_CAPS}& Il processo non subisce la cancellazione delle sue \textit{capabilities} quando tutti i suoi - \acr{uid} passano ad un valore non + \ids{UID} passano ad un valore non nullo (regola di compatibilità per il cambio - di \acr{uid} n.~3 del precedente + di \ids{UID} n.~3 del precedente elenco), sostituisce il precedente uso dell'operazione \const{PR\_SET\_KEEPCAPS} di \func{prctl}.\\ \const{SECURE\_NO\_SETUID\_FIXUP}&Il processo non subisce le modifiche delle sue \textit{capabilities} nel passaggio - da nullo a non nullo degli \acr{uid} + da nullo a non nullo degli \ids{UID} dei gruppi \textit{effective} e \textit{file system} (regole di compatibilità - per il cambio di \acr{uid} nn.~1 e 2 del + per il cambio di \ids{UID} nn.~1 e 2 del precedente elenco).\\ \const{SECURE\_NOROOT} & Il processo non assume nessuna capacità aggiuntiva quando esegue un programma, anche - se ha \acr{uid} nullo o il programma ha + se ha \ids{UID} nullo o il programma ha il \acr{suid} bit attivo ed appartiene all'amministratore (regola di compatibilità per l'esecuzione di programmi senza @@ -5627,7 +5905,7 @@ che è opportuno dettagliare maggiormente. \begin{table}[!h!btp] \centering \footnotesize - \begin{tabular}{|l|p{11.9cm}|} + \begin{tabular}{|l|p{10.5cm}|} \hline \textbf{Capacità}&\textbf{Descrizione}\\ \hline @@ -5695,7 +5973,7 @@ che è opportuno dettagliare maggiormente. intercomunicazione fra processi (vedi sez.~\ref{sec:ipc_sysv}).\\ \const{CAP\_LEASE} & La capacità di creare dei \textit{file lease} - \index{file!lease} (vedi + \itindex{file~lease} (vedi sez.~\ref{sec:file_asyncronous_lease}) pur non essendo proprietari del file (dal kernel 2.4).\\ @@ -5795,8 +6073,8 @@ capacità), o di impostare i \textit{securebits} delle \textit{capabilities}. La prima fra le capacità ``\textsl{ampie}'' che occorre dettagliare maggiormente è \const{CAP\_FOWNER}, che rimuove le restrizioni poste ad un processo che non ha la proprietà di un file in un vasto campo di -operazioni;\footnote{vale a dire la richiesta che l'\acr{uid} effettivo del - processo (o meglio l'\acr{uid} di filesystem, vedi +operazioni;\footnote{vale a dire la richiesta che l'\ids{UID} effettivo del + processo (o meglio l'\ids{UID} di filesystem, vedi sez.~\ref{sec:proc_setuid}) coincida con quello del proprietario.} queste comprendono i cambiamenti dei permessi e dei tempi del file (vedi sez.~\ref{sec:file_perm_management} e sez.~\ref{sec:file_file_times}), le @@ -5821,13 +6099,13 @@ disattivare la swap, montare, rimontare e smontare filesystem (vedi sez.~\ref{sec:sys_file_config}), effettuare operazioni di controllo su qualunque oggetto dell'IPC di SysV (vedi sez.~\ref{sec:ipc_sysv}), operare sugli attributi estesi dei file di classe \texttt{security} o \texttt{trusted} -(vedi sez.~\ref{sec:file_xattr}), specificare un \acr{uid} arbitrario +(vedi sez.~\ref{sec:file_xattr}), specificare un \ids{UID} arbitrario nella trasmissione delle credenziali dei socket (vedi sez.~\ref{sec:socket_credential_xxx}), assegnare classi privilegiate (\const{IOPRIO\_CLASS\_RT} e prima del kernel 2.6.25 anche \const{IOPRIO\_CLASS\_IDLE}) per lo scheduling dell'I/O (vedi sez.~\ref{sec:io_priority}), superare il limite di sistema sul numero massimo -di file aperti,\footnote{quello indicato da \procfile{/proc/sys/fs/file-max}.} +di file aperti,\footnote{quello indicato da \sysctlfile{fs/file-max}.} effettuare operazioni privilegiate sulle chiavi mantenute dal kernel (vedi sez.~\ref{sec:keyctl_management}), usare la funzione \func{lookup\_dcookie}, usare \const{CLONE\_NEWNS} con \func{unshare} e \func{clone}, (vedi @@ -6444,7 +6722,7 @@ funzione. -\subsection{La funzione \func{chroot}} +\subsection{La gestione dei {chroot}} \label{sec:file_chroot} % TODO introdurre nuova sezione sulle funzionalità di sicurezza avanzate, con @@ -6458,6 +6736,8 @@ Benché non abbia niente a che fare con permessi, utenti e gruppi, la funzione programma ad una sezione limitata del filesystem, per cui ne parleremo in questa sezione. +% 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 @@ -6490,7 +6770,7 @@ con la funzione \funcd{chroot}, il cui prototipo è: \bodydesc{La funzione restituisce zero in caso di successo e -1 per un errore, in caso di errore \var{errno} può assumere i valori: \begin{errlist} - \item[\errcode{EPERM}] l'\acr{uid} effettivo del processo non è zero. + \item[\errcode{EPERM}] l'\ids{UID} effettivo del processo non è zero. \end{errlist} ed inoltre \errval{EFAULT}, \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM}, \errval{ENOTDIR}, \errval{EACCES}, \errval{ELOOP}; @@ -6600,10 +6880,16 @@ programmi e librerie) di cui il server potrebbe avere bisogno. % LocalWords: forced allowed sendmail SYSLOG WAKE ALARM CLOCK BOOTTIME dqstats % LocalWords: REALTIME securebits GETSTATS QFMT curspace curinodes btime itime % LocalWords: QIF BLIMITS bhardlimit bsoftlimit ILIMITS ihardlimit isoftlimit -% LocalWords: INODES LIMITS USAGE valid dqi IIF BGRACE bgrace IGRACE igrace +% LocalWords: INODES LIMITS USAGE valid dqi IIF BGRACE bgrace IGRACE igrace is % LocalWords: Python Truelite Srl quotamodule Repository who nell' dall' KEEP % LocalWords: SECURE KEEPCAPS prctl FIXUP NOROOT LOCKED dell'IPC dell'I IOPRIO -% LocalWords: CAPBSET CLASS IDLE dcookie overflow DIFFERS +% LocalWords: CAPBSET CLASS IDLE dcookie overflow DIFFERS Virtual everything +% LocalWords: dentry register resolution cache dcache operation llseek poll +% LocalWords: multiplexing fsync fasync seek block superblock gapil tex img +% LocalWords: second linked journaled source filesystemtype unsigned device +% LocalWords: mountflags NODEV ENXIO dummy devfs magic MGC RDONLY NOSUID MOVE +% LocalWords: NOEXEC SYNCHRONOUS REMOUNT MANDLOCK NODIRATIME umount MNT statfs +% LocalWords: fstatfs fstab mntent ino bound orig new setpcap metadati sysfs %%% Local Variables: %%% mode: latex