X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=filedir.tex;h=361e05a5afbcf9fffca3288cefe625b79ed41e48;hp=b16e2dc7b549f2f01a4d1276785025da5ed6fb07;hb=a88d4dd8fdd85cdfe8fd04684d4afb4c24174995;hpb=0e9402ecfdb1d1c387b7d53ab8dfb153a735c453 diff --git a/filedir.tex b/filedir.tex index b16e2dc..361e05a 100644 --- a/filedir.tex +++ b/filedir.tex @@ -1,171 +1,23 @@ \chapter{Files e directories} \label{cha:files_and_dirs} -In questo capitolo tratteremo in dettaglio le varie caratteristiche di files e -directories, ed in particolare approfondiremo i dettagli su come è organizzata -la struttura dei files in un sistema unix, esamineremo come è strutturato il +In questo capitolo tratteremo in dettaglio le modalità con cui si gestiscono +files e directories, ed in particolare esamineremo come è strutturato il sistema base di protezioni e controllo di accesso ai files, e tutta l'interfaccia che permette la manipolazione dei vari attributi di files e -directories. Tutto quello che riguarda invece la manipolazione dei contenuti è -lasciato ai capitoli successivi. - - -\section{L'organizzazione di files e directories} -\label{sec:filedir_org} - -L'organizzazione dei nomi dei file deriva direttamente dall'organizzazione dei -medesimi nell'albero descritto brevemente in \secref{sec:fileintr_overview}; -una directory comunque, come già specificato in \secref{sec:fileintr_vfs}, è -solo un particolare tipo di file che contiene le informazioni che associano un -nome al contenuto. Per questo, anche se è usuale parlare di ``file in una -directory'' in realtà una directory contiene solo delle etichette per fare -riferimento ai file stessi. - -I manuale delle librerie del C chiama i nomi contenuti nelle directory -\textsl{componenti} (in inglese \textit{file name components}), noi li -chiameremo più semplicemente nomi. Un file può essere indicato rispetto alla -directory corrente semplicemente specificando il nome da essa contenuto. Una -directory contiene semplicemente un elenco di questi nomi, che possono -corrispondere a un qualunque oggetto del filesystem, compresa un'altra -directory; l'albero viene appunto creato inserendo directory in altre -directory. - -Il nome completo di file generico è composto da una serie di questi -\textsl{componenti} separati da una \texttt{/} (in Linux più \texttt{/} -consecutive sono considerate equivalenti ad una sola). Il nome completo di un -file viene usualmente chiamato \textit{pathname}, e anche se il manuale della -glibc depreca questo nome (poiché genererebbe confusione, dato che con -\textit{path} si indica anche un insieme di directory su cui effettuare una -ricerca, come quello in cui si cercano i comandi) l'uso è ormai così comune -che è senz'altro più chiaro dell'alternativa proposta. - -Il processo con cui si associa ad un pathname uno specifico file è chiamato -risoluzione del nome (\textit{file name resolution} o \textit{pathname - resolution}). La risoluzione viene fatta esaminando il pathname da destra a -sinistra e localizzando ogni nome nella directory indicata dal nome -precedente: ovviamente perché il procedimento funzioni occorre che i nomi -indicati come directory esistano e siano effettivamente directory, inoltre i -permessi devono consentire l'accesso. - -Se il pathname comincia per \texttt{/} la ricerca parte dalla directory radice -del processo; questa, a meno di un \textit{chroot} (su cui torneremo in -seguito, vedi \secref{sec:xxx_chroot}) è la stessa per tutti i processi ed -equivale alla directory radice dell'albero (come descritto in -\secref{sec:fileintr_overview}): in questo caso si parla di un pathname -\textsl{assoluto}. Altrimenti la ricerca parte dalla directory corrente (su -cui torneremo più avanti in \secref{sec:filedir_work_dir}) ed il pathname è -detto \textsl{relativo}. - -I nomi \texttt{.} e \texttt{..} hanno un significato speciale e vengono -inseriti in ogni directory, il primo fa riferimento alla directory corrente e -il secondo alla directory \textsl{genitore} (\textit{parent directory}) cioè -la directory che contiene il riferimento alla directory corrente; nel caso -questa sia la directory radice allora il riferimento è a se stessa. - - -\section{L'architettura di gestione dei file} -\label{sec:filedir_file_handling} - -Per capire fino in fondo le proprietà di files e directories in un sistema -unix ed il funzionamento delle relative funzioni di manipolazione occorre una -breve introduzione sulla gestione dei medesimo e sugli oggetti su cui è basato -un filesystem unix; in particolare si riprenderà, approfondendolo sul piano -dell'uso nelle funzioni di libreria, il concetto di \textit{inode} di cui -abbiamo brevemente accennato le caratteristiche (dal lato dell'implementazione -nel kernel) in \secref{sec:fileintr_vfs}. - - -\subsection{Il funzionamento di un filesystem unix} -\label{sec:filedir_filesystem} - -Come già accennato in \secref{sec:fileintr_overview} Linux (ed ogni unix in -generale) 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 non entreremo nei dettagli di un filesystem specifico, ma -daremo una descrizione a grandi linee che si adatta alle caratteristiche -comuni di un qualunque filesystem standard unix. - -Dato un disco lo spazio fisico viene usualmente diviso in partizioni; ogni -partizione può contenere un filesystem; quest'ultimo è in genere strutturato -secondo \nfig, con una lista di inodes all'inizio e il resto dello spazio a -disposizione per i dati e le directory. - -\begin{figure}[htb] - \centering - - \caption{Organizzazione dello spazio su un disco in partizioni e filesystem} - \label{fig:filedir_disk_filesys} -\end{figure} - -Se si va ad esaminare come è strutturata l'informazione all'interno di un -singolo filesystem (tralasciando le parti connesse alla strutturazione e al -funzionamento del filesystem stesso come il super-block) avremo una situazione -del tipo di quella esposta in \nfig. -\begin{figure}[htb] - \centering - - \caption{Organizzazione di un filesystem} - \label{fig:filedir_filesys_detail} -\end{figure} -da questa figura si evidenziano alcune caratteristiche su cui è bene porre -attenzione in quanto sono fondamentali per capire il funzionamento delle -funzioni che manipolano i file e le directory su cui torneremo fra poco; in -particolare è opportuno ricordare sempre che: - -\begin{enumerate} - -\item L'\textit{inode} contiene tutte le informazioni 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 - \texttt{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, cioè quella che da qui in poi chiameremo una \textsl{voce} - (traduzione approssimata dell'inglese \textit{directory entry}, che non - useremo anche per evitare confusione con le \textit{dentries} del kernel di - cui si parlava in \secref{sec:fileintr_vfs}). - -\item Come mostrato in \curfig si possono avere più voci che puntano allo - stesso \textit{inode}. Ogni \textit{inode} ha un contatore che contiene il - numero di riferimenti (\textit{link count}) che sono stati fatti ad esso; - 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 \texttt{unlink}, ed in realtà non cancella affatto i dati del - file, ma si limita a 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 \textit{inodes} relativi ad altri filesystem. Questo limita - l'uso del comando \texttt{ln} (che crea una nuova voce per un file - esistente, con la funzione \texttt{link}) al filesystem corrente. - -\item Quando si cambia nome ad un file senza cambiare filesystem il contenuto - del file non deve essere spostato, viene semplicemente creata una nuova voce - per l'\textit{inode} in questione e rimossa la vecchia (questa è la modalità - in cui opera normalmente il comando \texttt{mv} attraverso la funzione - \texttt{rename}). +directories. Tutto quello che riguarda invece la manipolazione del contenuto +dei file è lasciato ai capitoli successivi. -\end{enumerate} -Infine è bene avere presente che essendo file pure loro, esiste un numero di -riferimenti anche per le directories; per cui se ad esempio a partire dalla -situazione mostrata in \curfig\ creiamo una nuova directory \texttt{textdir} -nella directory corrente avremo una situazione come quella in \nfig, dove per -chiarezza abbiamo aggiunto dei numeri di inode. - -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{textdir}) e dalla voce \texttt{.} -che è sempre inserita in ogni directory; questo vale sempre per ogni directory -che non contenga a sua volta altre directories. Al contempo la directory da -cui si era partiti avrà un numero di riferiementi di almeno tre, in quanto -adesso sarà referenziata anche dalla voce \texttt{..} di \texttt{textdir}. +\section{La gestione di file e directory} +Le prime funzioni che considereremo sono quelle relative alla gestione di file +e directory, secondo le caratteristiche standard che essi presentano in un +filesystem unix, già esaminate in precedenza (vedi +\secref{sec:fileintr_filesystem}). \subsection{Le funzioni \texttt{link} e \texttt{unlink}} -\label{sec:filedir_link} +\label{sec:fileintr_link} Una delle caratteristiche usate quando si opera con i file è quella di poter creare dei nomi fittizi (alias o collegamenti) per potersi riferire allo @@ -198,8 +50,7 @@ principali, come risultano dalla man page, sono le seguenti: \item \texttt{EXDEV} \texttt{oldpath} e \texttt{newpath} non sono sullo stesso filesystem. \item \texttt{EPERM} il filesystem che contiene \texttt{oldpath} e - \texttt{newpath} non supporta i link diretti, oppure \texttt{oldpath} è - una directory. + \texttt{newpath} non supporta i link diretti o è una directory. \item \texttt{EFAULT} una delle stringhe passate come parametri è fuori dello spazio di indirizzi del processo. \item \texttt{EACCESS} errore di accesso (mancano i permessi per scrivere o @@ -232,7 +83,7 @@ ma si limita ad aumentare di uno il numero di referenze al file aggiungendo il nuovo nome ai precedenti. Si noti che uno stesso file può essere così richiamato in diverse directory. -Per quanto dicevamo in \secref{sec:filedir_filesystem} la creazione del +Per quanto dicevamo in \secref{sec:fileintr_filesystem} la creazione del collegamento diretto è possibile solo se entrambi i pathname sono nello stesso filesystem; inoltre il filesystem deve supportare i collegamenti diretti (non è il caso ad esempio del filesystem \texttt{vfat} di windows). @@ -240,7 +91,7 @@ il caso ad esempio del filesystem \texttt{vfat} di windows). La funzione opera sui file ordinari, come sugli altri oggetti del filesystem, ma solo l'amministratore è in grado di creare un collegamento diretto ad un'altra directory, questo lo si fa perché in questo caso è possibile creare -dei circoli nel filesystem (vedi \secref{sec:filedir_symlink}) che molti +dei circoli nel filesystem (vedi \secref{sec:fileintr_symlink}) che molti programmi non sono in grado di gestire e la cui rimozione diventa estremamente complicata (in genere occorre far girare il programma \texttt{fsck} per riparare il filesystem); data la sua pericolosità in Linux questa @@ -264,10 +115,13 @@ effettua con la funzione \texttt{unlink}; il suo prototipo \item \texttt{EACCESS} errore di accesso (mancano i permessi per scrivere o per attraversare le directories), vedi \secref{sec:filedir_access_control} per i dettagli. - \item \texttt{EPERM} il filesystem che contiene \texttt{pathname} non - consente l'operazione. - \item \texttt{EFAULT} la stringa passata come parametro è fuori dello spazio - di indirizzi del processo. + \item \texttt{EISDIR} \texttt{pathname} si riferisce ad una directory + (valore specifico ritornato da linux che non consente l'uso di + \texttt{unlink} con le directory, e non conforme allo standard POSIX, che + prescrive invece l'uso di \texttt{EPERM} in caso l'operazione non sia + consnetita o il processo non abbia privilegi sufficienti). + \item \texttt{EFAULT} la stringa + passata come parametro è fuori dello spazio di indirizzi del processo. \item \texttt{ENAMETOOLONG} il pathname troppo lungo. \item \texttt{ENOENT} uno dei componenti del pathname non esiste o è un link simbolico spezzato. @@ -307,7 +161,7 @@ crash dei programmi; la tecnica \texttt{unlink} subito dopo. \subsection{Le funzioni \texttt{remove} e \texttt{rename}} -\label{sec:filedir_cre_canc} +\label{sec:fileintr_remove} Al contrario di quanto avviene con altri unix in Linux non è possibile usare \texttt{unlink} sulle directory, per cancellare una directory si può usare la @@ -340,35 +194,48 @@ nuovo nome dopo che il vecchio qual caso il file non viene toccato. La variabile \texttt{errno} viene settata secondo i seguenti codici di errore: \begin{errlist} - \item \texttt{EFAULT} la stringa \texttt{filename} è fuori dello spazio di - indirizzi del processo. + \item \texttt{EISDIR} \texttt{newpath} è una directory già esistente mentre + \texttt{oldpath} non è una directory. + \item \texttt{EXDEV} \texttt{oldpath} e \texttt{newpath} non sono sullo + stesso filesystem. + \item \texttt{ENOTEMPTY} \texttt{newpath} è una directory già esistente e + non vuota. + \item \texttt{EBUSY} o \texttt{oldpath} o \texttt{newpath} sono in uso da + parte di qualche processo (come directory di lavoro o come root) o del + sistema (come mount point). + \item \texttt{EINVAL} \texttt{newpath} contiene un prefisso di + \texttt{oldpath} o più in generale si è cercato di creare una directory + come sottodirectory di se stessa. + \item \texttt{EMLINK} \texttt{oldpath} ha già il massimo numero di link + consentiti o è una directory e la directory che contiene \texttt{newpath} + ha già il massimo numero di link. + \item \texttt{ENOTDIR} Uno dei componenti dei pathname non è una directory + o\texttt{oldpath} è una directory e \texttt{newpath} esiste e non è una + directory. + \item \texttt{EFAULT} o \texttt{oldpath} o \texttt{newpath} è fuori dello + spazio di indirizzi del processo. \item \texttt{EACCESS} Non c'è il permesso di scrittura per la directory in cui si vuole creare il nuovo link o una delle directory del pathname non consente la ricerca (permesso di esecuzione). - \item \texttt{EPERM} il pathname indica una directory o il filesystem che - contiene \texttt{filename} non consente l'operazione. - \item \texttt{EROFS} I file sono su un filesystem montato in sola lettura. - \item \texttt{ENAMETOOLONG} il pathname è troppo lungo. + \item \texttt{EPERM} le directory contenenti \texttt{oldpath} o + \texttt{newpath} hanno lo sticky bit attivo e i permessi del processo non + consentono rispettivamente la cancellazione e la creazione del file, o il + filesystem non supporta i link. + \item \texttt{ENAMETOOLONG} uno dei pathname è troppo lungo. \item \texttt{ENOENT} Uno dei componenti del pathname non esiste o è un link simbolico spezzato. - \item \texttt{ENOTDIR} Uno dei componenti del pathname non è una directory. \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a completare l'operazione. + \item \texttt{EROFS} I file sono su un filesystem montato in sola lettura. \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione del pathname. - \item \texttt{EISDIR} - \item \texttt{EXDEV} - \item \texttt{ENOTEMPTY} - \item \texttt{EBUSY} - \item \texttt{EINVAL} - \item \texttt{EMLINK} - \item \texttt{ENOSPC} - + \item \texttt{ENOSPC} Il device di destinazione non ha più spazio per la + nuova voce. \end{errlist} \end{prototype} \subsection{I link simbolici} -\label{sec:filedir_sym_link} +\label{sec:fileintr_symlink} Siccome la funzione \texttt{link} crea riferimenti agli inodes, essa può funzionare soltanto per file che risiedono sullo stesso filesystem, dato che @@ -443,84 +310,6 @@ questa funzione \end{errlist} \end{prototype} - -\section{La manipolazione delle caratteristiche dei files} -\label{sec:filedir_infos} - -Come spiegato in \secref{sec:filedir_file_handling} tutte le informazioni -generali relative alle caratteristiche di ciascun file sono mantenute -nell'inode. Vedremo in questa sezione come sia possibile accedervi usando la -funzione \texttt{stat} ed esamineremo alcune funzioni utilizzabili per -manipolare una parte di questa informazione. Tutto quello che invece riguarda -il meccanismo di controllo di accesso ad i file e le relative funzioni di -manipolazione sarà invece esaminanto in \secref{sec:filedir_access_control}. - - -\subsection{Le funzioni \texttt{stat}, \texttt{fstat} e \texttt{lstat}} -\label{sec:filedir_stat} - -La lettura delle informazioni relative ai file è fatta attraverso la famiglia -delle funzioni \texttt{stat}, questa è la funzione che il comando \texttt{ls} -usa per poter stampare tutti i dati dei files; il prototipo della funzione è -il seguente; -\begin{prototype}{sys/stat.h} -{int stat(const char *file_name, struct stat *buf)} - - La funzione restituisce zero in caso di successo e -1 per un errore, in caso - di errore \texttt{errno} viene settato ai valori: - \begin{errlist} - \item \texttt{EACCESS} Non c'è il permesso di accedere al file. - \item \texttt{ENOTDIR} Una componente del pathname non è una directory. - \item \texttt{EMLOOP} Ci sono troppi link simbolici nel pathname. - \item \texttt{EFAULT} I puntatori usati sono fuori dallo spazio di indirizzi - del processo. - \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a - completare l'operazione. - \item \texttt{ENAMETOOLONG} Il filename è troppo lungo. - \end{errlist} -\end{prototype} - -\subsection{I tipi di file} -\label{sec:filedir_file_types} - -\subsection{La dimensione dei file} -\label{sec:filedir_file_size} - -\subsection{I tempi dei file} -\label{sec:filedir_file_times} - -\subsection{La funzione \texttt{utime}} -\label{sec:filedir_utime} - - - - -\section{Il controllo di accesso ai file} -\label{sec:filedir_access_control} - - -\subsection{I flag \texttt{suid} e \texttt{sgid}} -\label{sec:filedir_suid_sgid} - -\subsection{La titolarità di nuovi files e directory} -\label{sec:filedir_ownership} - -\subsection{La funzione \texttt{access}} -\label{sec:filedir_access} - -\subsection{La funzione \texttt{umask}} -\label{sec:filedir_umask} - -\subsection{Le funzioni \texttt{chmod} e \texttt{fchmod}} -\label{sec:filedir_chmod} - -\subsection{Il flag \texttt{sticky}} -\label{sec:filedir_sticky} - -\subsection{Le funzioni \texttt{chown}, \texttt{fchown} e \texttt{lchown}} -\label{sec:filedir_chown} - - \section{La manipolazione delle directories} \label{sec:filedir_dir_handling} @@ -656,6 +445,252 @@ per cambiare directory di lavoro. \end{prototype} +\section{La manipolazione delle caratteristiche dei files} +\label{sec:filedir_infos} + +Come spiegato in \secref{sec:fileintr_filesystem} tutte le informazioni +generali relative alle caratteristiche di ciascun file sono mantenute +nell'inode. Vedremo in questa sezione come sia possibile accedervi usando la +funzione \texttt{stat} ed esamineremo alcune funzioni utilizzabili per +manipolare una parte di questa informazione. Tutto quello che invece riguarda +il meccanismo di controllo di accesso ad i file e le relative funzioni di +manipolazione sarà invece esaminanto in \secref{sec:filedir_access_control}. + + +\subsection{Le funzioni \texttt{stat}, \texttt{fstat} e \texttt{lstat}} +\label{sec:filedir_stat} + +La lettura delle informazioni relative ai file è fatta attraverso la famiglia +delle funzioni \texttt{stat}, che è la funzione che il comando \texttt{ls} usa +per poter stampare tutti i dati dei files. I prototipi di queste funzioni sono +i seguenti: +\begin{functions} + \headdecl{sys/types.h} + \headdecl{sys/stat.h} + \headdecl{unistd.h} + + \funcdecl{int stat(const char *file\_name, struct stat *buf)} Legge le + informazione del file specificato da \var{file\_name} e le inserisce in + \var{buf}. + + \funcdecl{int lstat(const char *file\_name, struct stat *buf)} Identica a + \func{stat} eccetto che se il \var{file\_name} è un link simbolico vengono + lette le informazioni relativa ad esso e non al file a cui punta. + + \funcdecl{int fstat(int filedes, struct stat *buf)} Identica a \func{stat} + eccetto che funziona con un file aperto, specificato tramite il suo file + descriptor \var{filedes}. + + Le funzioni restituiscono zero in caso di successo e -1 per un errore, in + caso di errore \texttt{errno} viene settato ai valori: + \begin{errlist} + \item \texttt{EACCESS} Non c'è il permesso di accedere al file. + \item \texttt{ENOTDIR} Una componente del pathname non è una directory. + \item \texttt{EMLOOP} Ci sono troppi link simbolici nel pathname. + \item \texttt{EFAULT} I puntatori usati sono fuori dallo spazio di indirizzi + del processo. + \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a + completare l'operazione. + \item \texttt{ENAMETOOLONG} Il filename è troppo lungo. + \end{errlist} +\end{functions} + +La struttura \texttt{stat} è definita nell'header \texttt{sys/stat.h} e in +generale dipende dall'implementazione, la versione usata da Linux è mostrata +in \nfig, così come riportata dalla man page (in realtà la definizione +effettivamente usata nel kernel dipende dall'archietettura e ha altri campi +riservati per estensioni come tempo più precisi, o per il padding dei campi). + +\begin{figure}[!htb] + \footnotesize + \centering + \begin{minipage}[c]{15cm} + \begin{lstlisting}[]{} +struct stat { + dev_t st_dev; /* device */ + ino_t st_ino; /* inode */ + mode_t st_mode; /* protection */ + nlink_t st_nlink; /* number of hard links */ + uid_t st_uid; /* user ID of owner */ + gid_t st_gid; /* group ID of owner */ + dev_t st_rdev; /* device type (if inode device) */ + off_t st_size; /* total size, in bytes */ + unsigned long st_blksize; /* blocksize for filesystem I/O */ + unsigned long st_blocks; /* number of blocks allocated */ + time_t st_atime; /* time of last access */ + time_t st_mtime; /* time of last modification */ + time_t st_ctime; /* time of last change */ +}; + \end{lstlisting} + \end{minipage} + \normalsize + \caption{La struttura \texttt{stat} per la lettura delle informazioni dei + file} + \label{fig:filedir_stat_struct} +\end{figure} + +Si noti come i vari membri della struttura siano specificati come tipi nativi +del sistema (di quelli definiti in \tabref{tab:xxx_sys_types}, e dichiarati in +\texttt{sys/types.h}). + + +\subsection{I tipi di file} +\label{sec:filedir_file_types} + +Come riportato in \tabref{tab:fileintr_file_types} in Linux oltre ai file e +alle directory esistono vari altri oggetti che possono stare su un filesystem; +il tipo di file è ritornato dalla \texttt{stat} nel campo \texttt{st\_mode}. + +Dato che il valore numerico può variare a seconda delle implementazioni lo +standard POSIX definisce un insieme di macro per verificare il tipo di files, +queste venfono usate anche da Linux che supporta pure le estensioni per link +simbolici e socket definite da BDS, l'elenco è riportato in \ntab: +\begin{table}[htb] + \centering + \footnotesize + \begin{tabular}[c]{|l|l|} + \hline + Macro & Tipo del file \\ + \hline + \hline + \macro{S\_ISREG(m)} & file normale \\ + \macro{S\_ISDIR(m)} & directory \\ + \macro{S\_ISCHR(m)} & device a caraetteri \\ + \macro{S\_ISBLK(m)} & device a blocchi\\ + \macro{S\_ISFIFO(m)} & fifo \\ + \macro{S\_ISLNK(m)} & link simbolico \\ + \macro{S\_ISSOCK(m)} & socket \\ + \hline + \end{tabular} + \caption{Macro per i tipi di file (definite in \texttt{sys/stat.h})} + \label{tab:filedir_file_type_macro} +\end{table} + +Oltre a queste macro è possibile usare direttamente il valore di +\var{st\_mode} per ricavare il significato dei vari bit del campo attraverso +l'uso dei flag riportati in \ntab: +\begin{table}[htb] + \centering + \footnotesize + \begin{tabular}[c]{|l|c|l|} + \hline + Flag & Valore & Significato \\ + \hline + \hline + \macro{S\_IFMT} & 0170000 & bitmask for the file type bitfields \\ + \macro{S\_IFSOCK} & 0140000 & socket \\ + \macro{S\_IFLNK} & 0120000 & symbolic link \\ + \macro{S\_IFREG} & 0100000 & regular file \\ + \macro{S\_IFBLK} & 0060000 & block device \\ + \macro{S\_IFDIR} & 0040000 & directory \\ + \macro{S\_IFCHR} & 0020000 & character device \\ + \macro{S\_IFIFO} & 0010000 & fifo \\ + \macro{S\_ISUID} & 0004000 & set UID bit \\ + \macro{S\_ISGID} & 0002000 & set GID bit (see below) \\ + \macro{S\_ISVTX} & 0001000 & sticky bit (see below) \\ + \macro{S\_IRWXU} & 00700 & mask for file owner permissions \\ + \macro{S\_IRUSR} & 00400 & owner has read permission \\ + \macro{S\_IWUSR} & 00200 & owner has write permission \\ + \macro{S\_IXUSR} & 00100 & owner has execute permission \\ + \macro{S\_IRWXG} & 00070 & mask for group permissions \\ + \macro{S\_IRGRP} & 00040 & group has read permission \\ + \macro{S\_IWGRP} & 00020 & group has write permission \\ + \macro{S\_IXGRP} & 00010 & group has execute permission \\ + \macro{S\_IRWXO} & 00007 & mask for permissions for others (not in + group) \\ + \macro{S\_IROTH} & 00004 & others have read permission \\ + \macro{S\_IWOTH} & 00002 & others have write permisson \\ + \macro{S\_IXOTH} & 00001 & others have execute permission \\ + \hline + \end{tabular} + \caption{Flag per il campo \var{st\_mode} (definite in + \texttt{sys/stat.h})} + \label{tab:filedir_file_mode_flags} +\end{table} + +\subsection{La dimensione dei file} +\label{sec:filedir_file_size} + +Il membro \var{st\_size} contiene la dimensione del + +\subsection{I tempi dei file} +\label{sec:filedir_file_times} + +\subsection{La funzione \texttt{utime}} +\label{sec:filedir_utime} + + + + +\section{Il controllo di accesso ai file} +\label{sec:filedir_access_control} + + +In unix è implementata da qualunque filesystem standard una forma elementare +(ma adatta alla maggior parte delle esigenze) di controllo di accesso ai +files. Torneremo sull'argomento in dettaglio più avanti (vedi +\secref{sec:filedir_access_control}), qui ci limitiamo ad una introduzione dei +concetti essenziali. + +Si tenga conto poi che quanto diremo è vero solo per filesystem di tipo Unix, +e non è detto che sia applicabile (ed infatti non è vero per il filesystem di +Windows) a un filesystem qualunque. Esistono inoltre estensioni che permettono +di implementare le ACL (\textit{Access Control List}) che sono un meccanismo +di controllo di accesso molto più sofisticato. + +Ad ogni file Unix associa sempre l'utente che ne è proprietario (il cosiddetto +\textit{owner}) e il gruppo di appartenenza, secondo il meccanismo degli uid e +gid accennato in \secref{sec:intro_multiuser}, e un insieme di permessi che +sono divisi in tre classi, e cioè attribuiti rispettivamente al proprietario, +a qualunque utente faccia parte del gruppo cui appartiene il file, e a tutti +gli altri utenti. + +I permessi sono espressi da un insieme di 12 bit: di questi i nove meno +significativi sono usati a gruppi di tre per indicare i permessi base di +lettura, scrittura ed esecuzione (indicati rispettivamente con le lettere +\textit{w}, \textit{r} \textit{x}) applicabili rispettivamente al +proprietario, al gruppo, a tutti (una descrizione più dettagliata dei vari +permessi associati ai file è riportata in \secref{sec:filedir_suid_sgid}). I +restanti tre bit sono usati per indicare alcune caratteristiche più complesse +(\textit{suid}, \textit{sgid}, e \textit{sticky}) su cui pure torneremo in +seguito (vedi \secref{sec:filedir_suid_sgid} e \secref{sec:filedir_sticky}). + +Tutte queste informazioni sono tenute per ciascun file nell'inode. Quando un +processo cerca l'accesso al file esso controlla i propri uid e gid +confrontandoli con quelli del file e se l'operazione richiesta è compatibile +con i permessi associati al file essa viene eseguita, altrimenti viene +bloccata ed è restituito un errore di \texttt{EPERM}. Questo procedimento non +viene eseguito per l'amministratore di sistema (il cui uid è zero) il quale ha +pertanto accesso senza restrizione a qualunque file del sistema. + +% In realtà il procedimento è più complesso di quanto descritto in maniera +% elementare qui; inoltre ad un processo sono associati diversi identificatori, +% torneremo su questo in maggiori dettagli in seguito in \secref{sec:proc_perms}. + + + +\subsection{I flag \texttt{suid} e \texttt{sgid}} +\label{sec:filedir_suid_sgid} + +\subsection{La titolarità di nuovi files e directory} +\label{sec:filedir_ownership} + +\subsection{La funzione \texttt{access}} +\label{sec:filedir_access} + +\subsection{La funzione \texttt{umask}} +\label{sec:filedir_umask} + +\subsection{Le funzioni \texttt{chmod} e \texttt{fchmod}} +\label{sec:filedir_chmod} + +\subsection{Il flag \texttt{sticky}} +\label{sec:filedir_sticky} + +\subsection{Le funzioni \texttt{chown}, \texttt{fchown} e \texttt{lchown}} +\label{sec:filedir_chown} + + %La struttura fondamentale che contiene i dati essenziali relativi ai file è il