X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=blobdiff_plain;f=filedir.tex;h=281f8180be103417987806f1fac5a754aed3aeae;hb=2414addb7861eb72315a3de58b6f2cb5c83ab6ed;hp=956d32c7b4c238849f9020a028612bdc18e9cbac;hpb=4e1da5b259a86278710be32441de7b88b9287ec1;p=gapil.git diff --git a/filedir.tex b/filedir.tex index 956d32c..281f818 100644 --- a/filedir.tex +++ b/filedir.tex @@ -9,18 +9,674 @@ %% License". %% -\chapter{File e directory} +\chapter{La gestione di file e directory} \label{cha:files_and_dirs} In questo capitolo tratteremo in dettaglio le modalità con cui si gestiscono -file e directory, iniziando dalle funzioni di libreria che si usano per -copiarli, spostarli e cambiarne i nomi. Esamineremo poi l'interfaccia che -permette la manipolazione dei vari attributi di file e directory ed alla fine -prenderemo in esame 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. +file e directory, iniziando da un approfondimento dell'architettura del +sistema illustrata a grandi linee in sez.~\ref{sec:file_arch_overview} ed +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. + + + +\section{L'architettura della gestione dei file} +\label{sec:file_arch_func} + +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). + + +\subsection{Il funzionamento del \textit{Virtual File System} di Linux} +\label{sec:file_vfs_work} + +% 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} + +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. + +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 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 +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}. + +\begin{table}[htb] + \centering + \footnotesize + \begin{tabular}[c]{|l|p{8cm}|} + \hline + \textbf{Funzione} & \textbf{Operazione} \\ + \hline + \hline + \textsl{\code{open}} & Apre il file (vedi sez.~\ref{sec:file_open}).\\ + \textsl{\code{read}} & Legge dal file (vedi sez.~\ref{sec:file_read}).\\ + \textsl{\code{write}} & Scrive sul file (vedi + sez.~\ref{sec:file_write}).\\ + \textsl{\code{llseek}} & Sposta la posizione corrente sul file (vedi + sez.~\ref{sec:file_lseek}).\\ + \textsl{\code{ioctl}} & Accede alle operazioni di controllo + (vedi sez.~\ref{sec:file_ioctl}).\\ + \textsl{\code{readdir}}& Legge il contenuto di una directory (vedi + sez.~\ref{sec:file_dir_read}).\\ + \textsl{\code{poll}} & Usata nell'I/O multiplexing (vedi + sez.~\ref{sec:file_multiplexing}).\\ + \textsl{\code{mmap}} & Mappa il file in memoria (vedi + sez.~\ref{sec:file_memory_map}).\\ + \textsl{\code{release}}& Chiamata quando l'ultimo riferimento a un file + aperto è chiuso.\\ + \textsl{\code{fsync}} & Sincronizza il contenuto del file (vedi + sez.~\ref{sec:file_sync}).\\ + \textsl{\code{fasync}} & Abilita l'I/O asincrono (vedi + sez.~\ref{sec:file_asyncronous_io}) sul file.\\ + \hline + \end{tabular} + \caption{Operazioni sui file definite nel VFS.} + \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. +\itindend{Virtual~File~System} + + +\subsection{Il funzionamento di un filesystem Unix} +\label{sec:file_filesystem} + +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. + +\begin{figure}[!htb] + \centering + \includegraphics[width=14cm]{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}. + +\begin{figure}[!htb] + \centering + \includegraphics[width=14cm]{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: + +\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 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 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 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. + +\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 + spazio, ma si potranno creare file (vuoti), nel secondo non si potranno + creare nuovi file, ma si potranno estendere quelli che ci sono. + +\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} + \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}. + + +\subsection{I filesystem di uso comune} +\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. + +Oltre alle caratteristiche standard, \acr{ext2} fornisce alcune estensioni che +non sono presenti su un classico filesystem di tipo Unix; le principali sono +le seguenti: +\begin{itemize} +\item i \textit{file attributes} consentono di modificare il comportamento del + kernel quando agisce su gruppi di file. Possono essere impostati su file e + directory e in quest'ultimo caso i nuovi file creati nella directory + ereditano i suoi attributi. +\item sono supportate entrambe le semantiche di BSD e SVr4 come opzioni di + montaggio. La semantica BSD comporta che i file in una directory sono creati + con lo stesso identificatore di gruppo della directory che li contiene. La + semantica SVr4 comporta che i file vengono creati con l'identificatore del + 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}. +\item l'amministratore può scegliere la dimensione dei blocchi del filesystem + in fase di creazione, a seconda delle sue esigenze (blocchi più grandi + permettono un accesso più veloce, ma sprecano più spazio disco). +\item 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). +\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 + aggiungere dati (caratteristica utilizzabile per la protezione dei file di + log). +\end{itemize} + +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.} + +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. + +\begin{figure}[!htb] + \centering + \includegraphics[width=9cm]{img/dir_struct} + \caption{Struttura delle directory nel \textit{second extented filesystem}.} + \label{fig:file_ext2_dirs} +\end{figure} + +Le directory sono implementate come una \itindex{linked~list} \textit{linked + list} con voci di dimensione variabile. Ciascuna voce della lista contiene +il numero di inode \itindex{inode}, la sua lunghezza, il nome del file e la sua +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} + 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 + essere stati persi.} in brevissimo tempo in caso di interruzione improvvisa +della corrente o di crollo del sistema che abbia causato una interruzione +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. + +% 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} +\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)} + +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: + \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{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 + \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. + \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. + +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 + 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} + +% 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. + +La funzione \func{mount} può essere utilizzata anche per effettuare il +\textsl{rimontaggio} di un filesystem, cosa che permette di cambiarne al volo +alcune delle caratteristiche di funzionamento (ad esempio passare da sola +lettura a lettura/scrittura). Questa operazione è attivata attraverso uno dei +bit di \param{mountflags}, \const{MS\_REMOUNT}, che se impostato specifica che +deve essere effettuato il rimontaggio del filesystem (con le opzioni +specificate dagli altri bit), anche in questo caso il valore di \param{source} +viene ignorato. + +Una volta che non si voglia più utilizzare un certo filesystem è possibile +\textsl{smontarlo} usando la funzione \funcd{umount}, il cui prototipo è: +\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{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. + +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}. + +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} + +Il valore di \param{flags} è una maschera binaria, e al momento l'unico valore +definito è il bit \const{MNT\_FORCE}; gli altri bit devono essere nulli. +Specificando \const{MNT\_FORCE} la funzione cercherà di liberare il filesystem +anche se è occupato per via di una delle condizioni descritte in precedenza. A +seconda del tipo di filesystem alcune (o tutte) possono essere superate, +evitando l'errore di \errcode{EBUSY}. In tutti i casi prima dello smontaggio +viene eseguita una sincronizzazione dei dati. + +% TODO documentare MNT_DETACH e MNT_EXPIRE ... + +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{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} + +Queste funzioni permettono di ottenere una serie di informazioni generali +riguardo al filesystem su cui si trova il file specificato; queste vengono +restituite all'indirizzo \param{buf} di una struttura \struct{statfs} definita +come in fig.~\ref{fig:sys_statfs}, ed i campi che sono indefiniti per il +filesystem in esame sono impostati a zero. I valori del campo \var{f\_type} +sono definiti per i vari filesystem nei relativi file di header dei sorgenti +del kernel da costanti del tipo \var{XXX\_SUPER\_MAGIC}, dove \var{XXX} in +genere è il nome del filesystem stesso. + +\begin{figure}[!htb] + \footnotesize \centering + \begin{minipage}[c]{\textwidth} + \includestruct{listati/statfs.h} + \end{minipage} + \normalsize + \caption{La struttura \structd{statfs}.} + \label{fig:sys_statfs} +\end{figure} + + +Le \acr{glibc} provvedono infine una serie di funzioni per la gestione dei due +file \conffile{/etc/fstab} ed \conffile{/etc/mtab}, che convenzionalmente sono +usati in quasi tutti i sistemi unix-like per mantenere rispettivamente le +informazioni riguardo ai filesystem da montare e a quelli correntemente +montati. Le funzioni servono a leggere il contenuto di questi file in +opportune strutture \struct{fstab} e \struct{mntent}, e, per +\conffile{/etc/mtab} per inserire e rimuovere le voci presenti nel file. + +In generale si dovrebbero usare queste funzioni (in particolare quelle +relative a \conffile{/etc/mtab}), quando si debba scrivere un programma che +effettua il montaggio di un filesystem; in realtà in questi casi è molto più +semplice invocare direttamente il programma \cmd{mount}, per cui ne +tralasceremo la trattazione, rimandando al manuale delle \acr{glibc} +\cite{glibc} per la documentazione completa. + +% TODO scrivere relativamente alle varie funzioni (getfsent e getmntent &C) +% TODO documentare swapon e swapoff (man 2 ...) + + @@ -48,9 +704,8 @@ chiamandolo con nomi diversi o accedendovi da directory diverse. Questo è possibile anche in ambiente Unix, dove tali collegamenti sono usualmente chiamati \textit{link}; ma data l'architettura del sistema riguardo -la gestione dei file (ed in particolare quanto trattato in -sez.~\ref{sec:file_arch_func}) ci sono due metodi sostanzialmente diversi per -fare questa operazione. +la gestione dei file ci sono due metodi sostanzialmente diversi per fare +questa operazione. Come spiegato in sez.~\ref{sec:file_filesystem} l'accesso al contenuto di un file su disco avviene passando attraverso il suo \itindex{inode} @@ -584,7 +1239,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'user-ID effettivo + \itindex{sticky~bit} \textit{sticky bit} impostato e l'\acr{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 @@ -722,9 +1377,9 @@ serie 2.4 alla serie 2.6 è stata aumentata a 32 bit la dimensione del tipo \type{dev\_t}, con delle dimensioni passate a 12 bit per il \itindex{major~number} \textit{major number} e 20 bit per il \itindex{minor~number} \textit{minor number}. La transizione però ha anche -comportato il passaggio di \type{dev\_t} a tipo opaco, e la necessità di -specificare il numero tramite delle opportune macro, così da non avere -problemi di compatibilità con eventuali ulteriori estensioni. +comportato il passaggio di \type{dev\_t} a \index{tipo!opaco} tipo opaco, e la +necessità di specificare il numero tramite delle opportune macro, così da non +avere problemi di compatibilità con eventuali ulteriori estensioni. Le macro sono definite nel file \file{sys/sysmacros.h}, che viene automaticamente incluso quando si include \file{sys/types.h}; si possono @@ -2355,8 +3010,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'user-ID effettivo, il group-ID -effettivo e gli eventuali group-ID supplementari del processo.\footnote{in +\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 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, @@ -2365,19 +3020,19 @@ effettivo e gli eventuali group-ID 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'user-ID effettivo e il group-ID effettivo +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 group-ID supplementari sono quelli dei gruppi +lanciato il processo, mentre i \acr{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'user-ID effettivo del processo è zero (corrispondente +\item Se l'\acr{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'user-ID effettivo del processo è uguale all'\acr{uid} del +\item Se l'\acr{uid} effettivo del processo è uguale all'\acr{uid} del proprietario del file (nel qual caso si dice che il processo è proprietario del file) allora: \begin{itemize*} @@ -2387,7 +3042,7 @@ di accesso sono i seguenti: impostato, l'accesso è consentito \item altrimenti l'accesso è negato \end{itemize*} -\item Se il group-ID effettivo del processo o uno dei group-ID supplementari +\item Se il \acr{gid} effettivo del processo o uno dei \acr{gid} supplementari dei processi corrispondono al \acr{gid} del file allora: \begin{itemize*} \item se il bit dei permessi d'accesso del gruppo è impostato, l'accesso è @@ -2429,9 +3084,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 user-ID effettivo al nuovo processo l'\acr{uid} del +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 group-ID effettivo del +il bit \acr{sgid} impostato ha lo stesso effetto sul \acr{gid} effettivo del processo. I bit \acr{suid} e \acr{sgid} vengono usati per permettere agli utenti normali @@ -2528,9 +3183,9 @@ 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'user-ID ed il group-ID effettivo del processo; -ci sono casi però in cui si può voler effettuare il controllo con l'user-ID -reale ed il group-ID reale, vale a dire usando i valori di \acr{uid} e +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 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. @@ -2621,7 +3276,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'user-ID effettivo non corrisponde a quello del + \item[\errcode{EPERM}] l'\acr{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} @@ -2685,7 +3340,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'user-ID effettivo del processo +funzioni infatti è possibile solo se l'\acr{uid} effettivo del processo corrisponde a quello del proprietario del file o dell'amministratore, altrimenti esse falliranno con un errore di \errcode{EPERM}. @@ -2695,7 +3350,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'user-ID effettivo del processo non è zero esso + \textit{sticky bit}, se l'\acr{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 @@ -2705,7 +3360,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'user-ID effettivo del processo è zero). + (la cosa non avviene quando l'\acr{uid} effettivo del processo è zero). \end{enumerate} Per alcuni filesystem\footnote{i filesystem più comuni (\textsl{ext2}, @@ -2779,10 +3434,10 @@ 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'user-ID effettivo del processo che lo crea; per il \acr{gid} invece prevede +all'\acr{uid} effettivo del processo che lo crea; per il \acr{gid} invece prevede due diverse possibilità: \begin{itemize*} -\item il \acr{gid} del file corrisponde al group-ID effettivo del processo. +\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 esso è creato. \end{itemize*} @@ -2833,7 +3488,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'user-ID effettivo non corrisponde a quello del + \item[\errcode{EPERM}] l'\acr{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 @@ -3064,7 +3719,7 @@ classi di attributi riportate in tab.~\ref{tab:extended_attribute_class}. sez.~\ref{sec:proc_capabilities}.\\ \texttt{system} & Gli \textit{extended security attributes}: sono usati dal kernel per memorizzare dati di sistema associati ai - file come le \itindex{Access~Control~List} ACL (vedi + file come le \itindex{Access~Control~List~(ACL)} ACL (vedi sez.~\ref{sec:file_ACL}) o le \itindex{capabilities} \textit{capabilities} (vedi sez.~\ref{sec:proc_capabilities}).\\ @@ -3086,13 +3741,13 @@ classi di attributi riportate in tab.~\ref{tab:extended_attribute_class}. Dato che uno degli usi degli \textit{Extended Attributes} è quello che li -impiega per realizzare delle estensioni (come le \itindex{Access~Control~List} -ACL, \index{SELinux} SELinux, ecc.) al tradizionale meccanismo dei controlli -di accesso di Unix, l'accesso ai loro valori viene regolato in maniera diversa -a seconda sia della loro classe sia di quali, fra le estensioni che li -utilizzano, sono poste in uso. In particolare, per ciascuna delle classi -riportate in tab.~\ref{tab:extended_attribute_class}, si hanno i seguenti -casi: +impiega per realizzare delle estensioni (come le +\itindex{Access~Control~List~(ACL)} ACL, \index{SELinux} SELinux, ecc.) al +tradizionale meccanismo dei controlli di accesso di Unix, l'accesso ai loro +valori viene regolato in maniera diversa a seconda sia della loro classe sia +di quali, fra le estensioni che li utilizzano, sono poste in uso. In +particolare, per ciascuna delle classi riportate in +tab.~\ref{tab:extended_attribute_class}, si hanno i seguenti casi: \begin{basedescript}{\desclabelwidth{1.7cm}\desclabelstyle{\nextlinelabel}} \item[\texttt{security}] L'accesso agli \textit{extended security attributes} dipende dalle politiche di sicurezza stabilite da loro stessi tramite @@ -3109,12 +3764,13 @@ casi: \item[\texttt{system}] Anche l'accesso agli \textit{extended system attributes} dipende dalle politiche di accesso che il kernel realizza anche utilizzando gli stessi valori in essi contenuti. Ad esempio nel caso - delle \itindex{Access~Control~List} ACL l'accesso è consentito in lettura ai - processi che hanno la capacità di eseguire una ricerca sul file (cioè hanno - il permesso di lettura sulla directory che contiene il file) ed in scrittura - al proprietario del file o ai processi dotati della \textit{capability} - \index{capabilities} \const{CAP\_FOWNER}.\footnote{vale a dire una politica - di accesso analoga a quella impiegata per gli ordinari permessi dei file.} + delle \itindex{Access~Control~List~(ACL)} ACL l'accesso è consentito in + lettura ai processi che hanno la capacità di eseguire una ricerca sul file + (cioè hanno il permesso di lettura sulla directory che contiene il file) ed + in scrittura al proprietario del file o ai processi dotati della + \textit{capability} \index{capabilities} \const{CAP\_FOWNER}.\footnote{vale + a dire una politica di accesso analoga a quella impiegata per gli ordinari + permessi dei file.} \item[\texttt{trusted}] L'accesso ai \textit{trusted extended attributes}, sia per la lettura che per la scrittura, è consentito soltanto ai processi con @@ -3376,7 +4032,7 @@ illustrate in precedenza per le altre funzioni relative agli attributi estesi. % la documentazione di sistema è nei pacchetti libacl1-dev e acl % vedi anche http://www.suse.de/~agruen/acl/linux-acls/online/ -\itindbeg{Access~Control~List} +\itindbeg{Access~Control~List~(ACL)} Il modello classico dei permessi di Unix, per quanto funzionale ed efficiente, è comunque piuttosto limitato e per quanto possa aver coperto per lunghi anni @@ -3543,15 +4199,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'user-ID del processo è nullo l'accesso è sempre garantito senza +\item Se l'\acr{uid} del processo è nullo l'accesso è sempre garantito senza nessun controllo. -\item Se l'user-ID del processo corrisponde al proprietario del file allora: +\item Se l'\acr{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'user-ID del processo corrisponde ad un qualunque qualificatore +\item Se l'\acr{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 @@ -3559,7 +4215,7 @@ sono i seguenti: consentito; \item altrimenti l'accesso è negato. \end{itemize*} -\item Se è il group-ID del processo o uno dei group-ID supplementari +\item Se è il \acr{gid} del processo o uno dei \acr{gid} supplementari corrisponde al gruppo proprietario del file allora: \begin{itemize*} \item se la voce \const{ACL\_GROUP\_OBJ} e una eventuale voce @@ -3568,7 +4224,7 @@ sono i seguenti: l'accesso è consentito; \item altrimenti l'accesso è negato. \end{itemize*} -\item Se è il group-ID del processo o uno dei group-ID supplementari +\item Se è il \acr{gid} del processo o uno dei \acr{gid} supplementari corrisponde ad un qualunque qualificatore presente in una voce \const{ACL\_GROUP} allora: \begin{itemize*} @@ -3619,11 +4275,12 @@ mantenere i dati di una ACL contenente fino ad un massimo di \param{count} voci. La funzione ritorna un valore di tipo \type{acl\_t}, da usare in tutte le altre funzioni che operano sulla ACL. La funzione si limita alla allocazione iniziale e non inserisce nessun valore nella ACL che resta vuota. -Si tenga presente che pur essendo \type{acl\_t} un tipo opaco che identifica -``\textsl{l'oggetto}'' ACL, il valore restituito dalla funzione non è altro -che un puntatore all'area di memoria allocata per i dati richiesti; pertanto -in caso di fallimento verrà restituito un puntatore nullo e si dovrà -confrontare il valore di ritorno della funzione con ``\code{(acl\_t) NULL}''. +Si tenga presente che pur essendo \type{acl\_t} un \index{tipo!opaco} tipo +opaco che identifica ``\textsl{l'oggetto}'' ACL, il valore restituito dalla +funzione non è altro che un puntatore all'area di memoria allocata per i dati +richiesti; pertanto in caso di fallimento verrà restituito un puntatore nullo +e si dovrà confrontare il valore di ritorno della funzione con +``\code{(acl\_t) NULL}''. Una volta che si siano completate le operazioni sui dati di una ACL la memoria allocata dovrà essere liberata esplicitamente attraverso una chiamata alla @@ -3911,7 +4568,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 - user-ID e group-ID.\\ + \acr{uid} e \acr{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 @@ -4144,7 +4801,7 @@ vengono utilizzati tipi di dato ad hoc.\footnote{descritti nelle singole ad un altra con \funcd{acl\_copy\_entry} o eliminare una voce da una ACL con \funcd{acl\_delete\_entry}. -\itindend{Access~Control~List} +\itindend{Access~Control~List~(ACL)} \subsection{La gestione delle quote disco} @@ -4817,7 +5474,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 \textit{real user-ID} 0, esso verrà trattato come +eseguito da un processo con \acr{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 @@ -4826,19 +5483,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 -\textit{user-ID} nullo a \textit{user-ID} 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: +\textit{capabilities} di un processo nelle possibili transizioni da \acr{uid} +nullo a \acr{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 \textit{effective user-ID} nullo a non nullo +\item se si passa da \acr{uid} effettivo nullo a non nullo l'\textit{effective set} del processo viene totalmente azzerato, se - viceversa si passa da \textit{effective user-ID} non nullo a nullo il + viceversa si passa da \acr{uid} effettivo non nullo a nullo il \textit{permitted set} viene copiato nell'\textit{effective set}; -\item se si passa da \textit{file system user-ID} nullo a non nullo verranno +\item se si passa da \textit{file system} \acr{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}, @@ -4873,7 +5530,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 \textit{user-ID} nullo. La maschera viene sempre mantenuta +processi con \acr{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}. @@ -4887,22 +5544,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 - \textit{user-ID} passano ad un valore non + \acr{uid} passano ad un valore non nullo (regola di compatibilità per il cambio - di \textit{user-ID} n. 3 del precedente + di \acr{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 \textit{user-ID} + da nullo a non nullo degli \acr{uid} dei gruppi \textit{effective} e \textit{file system} (regole di compatibilità - per il cambio di \textit{user-ID} nn. 1 e 2 del + per il cambio di \acr{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 \textit{user-ID} nullo o il programma ha + se ha \acr{uid} nullo o il programma ha il \acr{suid} bit attivo ed appartiene all'amministratore (regola di compatibilità per l'esecuzione di programmi senza @@ -5138,8 +5795,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'user-ID effettivo del - processo (o meglio il \textit{filesystem user-ID}, vedi +operazioni;\footnote{vale a dire la richiesta che l'\acr{uid} effettivo del + processo (o meglio l'\acr{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 @@ -5164,7 +5821,7 @@ disattivare la swap, montare, rimontare e smontare filesystem (vedi sez.~\ref{sec:sys_file_config}), effettuare operazioni di controllo su qualunque oggetto dell'IPC di SysV (vedi sez.~\ref{sec:ipc_sysv}), operare sugli attributi estesi dei file di classe \texttt{security} o \texttt{trusted} -(vedi sez.~\ref{sec:file_xattr}), specificare un \textit{user-ID} arbitrario +(vedi sez.~\ref{sec:file_xattr}), specificare un \acr{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 @@ -5291,17 +5948,18 @@ una libreria a parte,\footnote{la libreria è \texttt{libcap2}, nel caso di programma le utilizza si dovrà indicare esplicitamente l'uso della suddetta libreria attraverso l'opzione \texttt{-lcap} del compilatore. -Le funzioni dell'interfaccia delle bozze di POSIX.1e prevedono l'uso di uno -tipo di dato opaco, \type{cap\_t}, come puntatore ai dati mantenuti nel -cosiddetto \textit{capability state},\footnote{si tratta in sostanza di un - puntatore ad una struttura interna utilizzata dalle librerie, i cui campi - non devono mai essere acceduti direttamente.} in sono memorizzati tutti i -dati delle \textit{capabilities}. In questo modo è possibile mascherare i -dettagli della gestione di basso livello, che potranno essere modificati senza -dover cambiare le funzioni dell'interfaccia, che faranno riferimento soltanto -ad oggetti di questo tipo. L'interfaccia pertanto non soltanto fornisce le -funzioni per modificare e leggere le \textit{capabilities}, ma anche quelle -per gestire i dati attraverso \type{cap\_t}. +Le funzioni dell'interfaccia delle bozze di POSIX.1e prevedono l'uso di un +\index{tipo!opaco} tipo di dato opaco, \type{cap\_t}, come puntatore ai dati +mantenuti nel cosiddetto \textit{capability state},\footnote{si tratta in + sostanza di un puntatore ad una struttura interna utilizzata dalle librerie, + i cui campi non devono mai essere acceduti direttamente.} in sono +memorizzati tutti i dati delle \textit{capabilities}. In questo modo è +possibile mascherare i dettagli della gestione di basso livello, che potranno +essere modificati senza dover cambiare le funzioni dell'interfaccia, che +faranno riferimento soltanto ad oggetti di questo tipo. L'interfaccia +pertanto non soltanto fornisce le funzioni per modificare e leggere le +\textit{capabilities}, ma anche quelle per gestire i dati attraverso +\type{cap\_t}. La prima funzione dell'interfaccia è quella che permette di inizializzare un \textit{capability state}, allocando al contempo la memoria necessaria per i @@ -5805,16 +6463,16 @@ directory di lavoro, ha anche una directory \textsl{radice}\footnote{entrambe sono contenute in due campi (rispettivamente \var{pwd} e \var{root}) di \struct{fs\_struct}; vedi fig.~\ref{fig:proc_task_struct}.} che, pur essendo di norma corrispondente alla radice dell'albero di file e directory come visto -dal kernel (ed illustrato in sez.~\ref{sec:file_organization}), ha per il -processo il significato specifico di directory rispetto alla quale vengono -risolti i \itindsub{pathname}{assoluto}\textit{pathname} -assoluti.\footnote{cioè quando un processo chiede la risoluzione di un - \textit{pathname}, il kernel usa sempre questa directory come punto di - partenza.} Il fatto che questo valore sia specificato per ogni processo apre -allora la possibilità di modificare le modalità di risoluzione dei -\textit{pathname} assoluti da parte di un processo cambiando questa directory, -così come si fa coi \itindsub{pathname}{relativo}\textit{pathname} relativi -cambiando la directory di lavoro. +dal kernel (ed illustrato in sez.~\ref{sec:file_pathname}), ha per il processo +il significato specifico di directory rispetto alla quale vengono risolti i +\itindsub{pathname}{assoluto}\textit{pathname} assoluti.\footnote{cioè quando + un processo chiede la risoluzione di un \textit{pathname}, il kernel usa + sempre questa directory come punto di partenza.} Il fatto che questo valore +sia specificato per ogni processo apre allora la possibilità di modificare le +modalità di risoluzione dei \textit{pathname} assoluti da parte di un processo +cambiando questa directory, così come si fa coi +\itindsub{pathname}{relativo}\textit{pathname} relativi cambiando la directory +di lavoro. Normalmente la directory radice di un processo coincide anche con la radice del filesystem usata dal kernel, e dato che il suo valore viene ereditato dal @@ -5832,7 +6490,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'user-ID effettivo del processo non è zero. + \item[\errcode{EPERM}] l'\acr{uid} effettivo del processo non è zero. \end{errlist} ed inoltre \errval{EFAULT}, \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM}, \errval{ENOTDIR}, \errval{EACCES}, \errval{ELOOP};