+\noindent la directory è creata con permessi \code{0700} (al solito si veda
+cap.~\ref{cha:file_unix_interface} per i dettagli); dato che la creazione
+della directory è sempre esclusiva i precedenti problemi di
+\itindex{race~condition} \textit{race condition} non si pongono.
+
+
+\section{La manipolazione delle caratteristiche dei file}
+\label{sec:file_infos}
+
+Come spiegato in sez.~\ref{sec:file_filesystem} tutte le informazioni generali
+relative alle caratteristiche di ciascun file, a partire dalle informazioni
+relative al controllo di accesso, sono mantenute \index{inode} nell'inode.
+
+Vedremo in questa sezione come sia possibile leggere tutte queste informazioni
+usando la funzione \func{stat}, che permette l'accesso a tutti i dati
+memorizzati \index{inode} nell'inode; esamineremo poi le varie funzioni usate
+per manipolare tutte queste informazioni (eccetto quelle che riguardano la
+gestione del controllo di accesso, trattate in in
+sez.~\ref{sec:file_access_control}).
+
+
+\subsection{La lettura delle caratteristiche dei file}
+\label{sec:file_stat}
+
+La lettura delle informazioni relative ai file è fatta attraverso la famiglia
+delle funzioni \func{stat} (\funcd{stat}, \funcd{fstat} e \funcd{lstat});
+questa è la funzione che ad esempio usa il comando \cmd{ls} per poter ottenere
+e mostrare tutti i dati relativi ad un file. 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 \param{file\_name} e le inserisce in
+ \param{buf}.
+
+ \funcdecl{int lstat(const char *file\_name, struct stat *buf)} Identica a
+ \func{stat} eccetto che se il \param{file\_name} è un link simbolico vengono
+ lette le informazioni relative ad esso e non al file a cui fa riferimento.
+
+ \funcdecl{int fstat(int filedes, struct stat *buf)} Identica a \func{stat}
+ eccetto che si usa con un file aperto, specificato tramite il suo file
+ descriptor \param{filedes}.
+
+ \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 per un
+ errore, nel qual caso \var{errno} assumerà uno dei valori: \errval{EBADF},
+ \errval{ENOENT}, \errval{ENOTDIR}, \errval{ELOOP}, \errval{EFAULT},
+ \errval{EACCES}, \errval{ENOMEM}, \errval{ENAMETOOLONG}.}
+\end{functions}
+\noindent il loro comportamento è identico, solo che operano rispettivamente
+su un file, su un link simbolico e su un file descriptor.
+
+La struttura \struct{stat} usata da queste funzioni è definita nell'header
+\file{sys/stat.h} e in generale dipende dall'implementazione; la versione
+usata da Linux è mostrata in fig.~\ref{fig:file_stat_struct}, così come
+riportata dalla pagina di manuale di \func{stat} (in realtà la definizione
+effettivamente usata nel kernel dipende dall'architettura e ha altri campi
+riservati per estensioni come tempi più precisi, o per il padding dei campi).
+
+\begin{figure}[!htb]
+ \footnotesize
+ \centering
+ \begin{minipage}[c]{15cm}
+ \includestruct{listati/stat.h}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{stat} per la lettura delle informazioni dei
+ file.}
+ \label{fig:file_stat_struct}
+\end{figure}
+
+Si noti come i vari membri della struttura siano specificati come tipi
+primitivi del sistema (di quelli definiti in
+tab.~\ref{tab:intro_primitive_types}, e dichiarati in \file{sys/types.h}).
+
+
+\subsection{I tipi di file}
+\label{sec:file_types}
+
+Come riportato in tab.~\ref{tab:file_file_types} in Linux oltre ai file e alle
+directory esistono altri oggetti che possono stare su un filesystem. Il tipo
+di file è ritornato dalla funzione \func{stat} come maschera binaria nel campo
+\var{st\_mode} (che contiene anche le informazioni relative ai permessi) di
+una struttura \struct{stat}.
+
+Dato che il valore numerico può variare a seconda delle implementazioni, lo
+standard POSIX definisce un insieme di macro per verificare il tipo di file,
+queste vengono usate anche da Linux che supporta pure le estensioni allo
+standard per i link simbolici e i socket definite da BSD; l'elenco completo
+delle macro con cui è possibile estrarre l'informazione da \var{st\_mode} è
+riportato in tab.~\ref{tab:file_type_macro}.
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|l|}
+ \hline
+ \textbf{Macro} & \textbf{Tipo del file} \\
+ \hline
+ \hline
+ \macro{S\_ISREG(m)} & file regolare \\
+ \macro{S\_ISDIR(m)} & directory \\
+ \macro{S\_ISCHR(m)} & dispositivo a caratteri \\
+ \macro{S\_ISBLK(m)} & dispositivo a blocchi\\
+ \macro{S\_ISFIFO(m)} & fifo \\
+ \macro{S\_ISLNK(m)} & link simbolico \\
+ \macro{S\_ISSOCK(m)} & socket \\
+ \hline
+ \end{tabular}
+ \caption{Macro per i tipi di file (definite in \texttt{sys/stat.h}).}
+ \label{tab:file_type_macro}
+\end{table}
+
+Oltre alle macro di tab.~\ref{tab:file_type_macro} è possibile usare
+direttamente il valore di \var{st\_mode} per ricavare il tipo di file
+controllando direttamente i vari bit in esso memorizzati. Per questo sempre in
+\file{sys/stat.h} sono definite le costanti numeriche riportate in
+tab.~\ref{tab:file_mode_flags}.
+
+Il primo valore dell'elenco di tab.~\ref{tab:file_mode_flags} è la maschera
+binaria che permette di estrarre i bit nei quali viene memorizzato il tipo di
+file, i valori successivi sono le costanti corrispondenti ai singoli bit, e
+possono essere usati per effettuare la selezione sul tipo di file voluto, con
+un'opportuna combinazione.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|c|l|}
+ \hline
+ \textbf{Flag} & \textbf{Valore} & \textbf{Significato} \\
+ \hline
+ \hline
+ \const{S\_IFMT} & 0170000 & maschera per i bit del tipo di file \\
+ \const{S\_IFSOCK} & 0140000 & socket \\
+ \const{S\_IFLNK} & 0120000 & link simbolico \\
+ \const{S\_IFREG} & 0100000 & file regolare \\
+ \const{S\_IFBLK} & 0060000 & dispositivo a blocchi \\
+ \const{S\_IFDIR} & 0040000 & directory \\
+ \const{S\_IFCHR} & 0020000 & dispositivo a caratteri \\
+ \const{S\_IFIFO} & 0010000 & fifo \\
+ \hline
+ \const{S\_ISUID} & 0004000 & set UID bit \itindex{suid~bit} \\
+ \const{S\_ISGID} & 0002000 & set GID bit \itindex{sgid~bit} \\
+ \const{S\_ISVTX} & 0001000 & sticky bit \itindex{sticky~bit}\\
+ \hline
+% \const{S\_IRWXU} & 00700 & bitmask per i permessi del proprietario \\
+ \const{S\_IRUSR} & 00400 & il proprietario ha permesso di lettura \\
+ \const{S\_IWUSR} & 00200 & il proprietario ha permesso di scrittura \\
+ \const{S\_IXUSR} & 00100 & il proprietario ha permesso di esecuzione\\
+ \hline
+% \const{S\_IRWXG} & 00070 & bitmask per i permessi del gruppo \\
+ \const{S\_IRGRP} & 00040 & il gruppo ha permesso di lettura \\
+ \const{S\_IWGRP} & 00020 & il gruppo ha permesso di scrittura \\
+ \const{S\_IXGRP} & 00010 & il gruppo ha permesso di esecuzione \\
+ \hline
+% \const{S\_IRWXO} & 00007 & bitmask per i permessi di tutti gli altri\\
+ \const{S\_IROTH} & 00004 & gli altri hanno permesso di lettura \\
+ \const{S\_IWOTH} & 00002 & gli altri hanno permesso di esecuzione \\
+ \const{S\_IXOTH} & 00001 & gli altri hanno permesso di esecuzione \\
+ \hline
+ \end{tabular}
+ \caption{Costanti per l'identificazione dei vari bit che compongono il campo
+ \var{st\_mode} (definite in \file{sys/stat.h}).}
+ \label{tab:file_mode_flags}
+\end{table}
+
+Ad esempio se si volesse impostare una condizione che permetta di controllare
+se un file è una directory o un file ordinario si potrebbe definire la macro
+di preprocessore:
+\includecodesnip{listati/is_file_dir.h}
+in cui prima si estraggono da \var{st\_mode} i bit relativi al tipo di file e
+poi si effettua il confronto con la combinazione di tipi scelta.
+
+
+\subsection{Le dimensioni dei file}
+\label{sec:file_file_size}
+
+Il campo \var{st\_size} di una struttura \struct{stat} contiene la dimensione
+del file in byte, se si tratta di un file regolare. Nel caso di un link
+simbolico la dimensione è quella del \itindex{pathname} \textit{pathname} che
+il link stesso contiene; per le fifo questo campo è sempre nullo.
+
+Il campo \var{st\_blocks} definisce la lunghezza del file in blocchi di 512
+byte. Il campo \var{st\_blksize} infine definisce la dimensione preferita per
+i trasferimenti sui file (che è la dimensione usata anche dalle librerie del C
+per l'interfaccia degli stream); scrivere sul file a blocchi di dati di
+dimensione inferiore sarebbe inefficiente.
+
+Si tenga conto che la lunghezza del file riportata in \var{st\_size} non è
+detto che corrisponda all'occupazione dello spazio su disco per via della
+possibile esistenza dei cosiddetti \textit{holes} (letteralmente
+\textsl{buchi}) che si formano tutte le volte che si va a scrivere su un file
+dopo aver eseguito una \func{lseek} (vedi sez.~\ref{sec:file_lseek}) oltre la
+sua fine.
+
+In questo caso si avranno risultati differenti a seconda del modo in cui si
+calcola la lunghezza del file, ad esempio il comando \cmd{du}, (che riporta il
+numero di blocchi occupati) potrà dare una dimensione inferiore, mentre se si
+legge dal file (ad esempio usando il comando \cmd{wc -c}), dato che in tal
+caso per le parti non scritte vengono restituiti degli zeri, si avrà lo stesso
+risultato di \cmd{ls}.
+
+Se è sempre possibile allargare un file, scrivendoci sopra od usando la
+funzione \func{lseek} per spostarsi oltre la sua fine, esistono anche casi in
+cui si può avere bisogno di effettuare un troncamento, scartando i dati
+presenti al di là della dimensione scelta come nuova fine del file.
+
+Un file può sempre essere troncato a zero aprendolo con il flag
+\const{O\_TRUNC}, ma questo è un caso particolare; per qualunque altra
+dimensione si possono usare le due funzioni \funcd{truncate} e
+\funcd{ftruncate}, i cui prototipi sono:
+\begin{functions}
+ \headdecl{unistd.h} \funcdecl{int truncate(const char *file\_name, off\_t
+ length)} Fa si che la dimensione del file \param{file\_name} sia troncata
+ ad un valore massimo specificato da \param{lenght}.
+
+ \funcdecl{int ftruncate(int fd, off\_t length))} Identica a \func{truncate}
+ eccetto che si usa con un file aperto, specificato tramite il suo file
+ descriptor \param{fd}.
+
+ \bodydesc{Le funzioni restituiscono zero in caso di successo e -1 per un
+ errore, nel qual caso \var{errno} viene impostata opportunamente; per
+ \func{ftruncate} si hanno i valori:
+ \begin{errlist}
+ \item[\errcode{EBADF}] \param{fd} non è un file descriptor.
+ \item[\errcode{EINVAL}] \param{fd} è un riferimento ad un socket, non a un
+ file o non è aperto in scrittura.
+ \end{errlist}
+ per \func{truncate} si hanno:
+ \begin{errlist}
+ \item[\errcode{EACCES}] il file non ha permesso di scrittura o non si ha il
+ permesso di esecuzione una delle directory del \itindex{pathname}
+ \textit{pathname}.
+ \item[\errcode{ETXTBSY}] Il file è un programma in esecuzione.
+ \end{errlist}
+ ed anche \errval{ENOTDIR}, \errval{ENAMETOOLONG}, \errval{ENOENT},
+ \errval{EROFS}, \errval{EIO}, \errval{EFAULT}, \errval{ELOOP}.}
+\end{functions}
+
+Se il file è più lungo della lunghezza specificata i dati in eccesso saranno
+perduti; il comportamento in caso di lunghezza inferiore non è specificato e
+dipende dall'implementazione: il file può essere lasciato invariato o esteso
+fino alla lunghezza scelta; in quest'ultimo caso lo spazio viene riempito con
+zeri (e in genere si ha la creazione di un \textit{hole} nel file).
+
+
+\subsection{I tempi dei file}
+\label{sec:file_file_times}
+
+Il sistema mantiene per ciascun file tre tempi. Questi sono registrati
+\index{inode} nell'inode insieme agli altri attributi del file e possono
+essere letti tramite la funzione \func{stat}, che li restituisce attraverso
+tre campi della struttura \struct{stat} di fig.~\ref{fig:file_stat_struct}. Il
+significato di detti tempi e dei relativi campi è riportato nello schema in
+tab.~\ref{tab:file_file_times}, dove è anche riportato un esempio delle
+funzioni che effettuano cambiamenti su di essi.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|c|l|l|c|}
+ \hline
+ \textbf{Membro} & \textbf{Significato} & \textbf{Funzione}
+ & \textbf{Opzione di \cmd{ls}} \\
+ \hline
+ \hline
+ \var{st\_atime}& ultimo accesso ai dati del file &\func{read},
+ \func{utime} & \cmd{-u}\\
+ \var{st\_mtime}& ultima modifica ai dati del file &\func{write},
+ \func{utime} & default\\
+ \var{st\_ctime}& ultima modifica ai dati dell'inode&\func{chmod},
+ \func{utime} & \cmd{-c} \\
+ \hline
+ \end{tabular}
+ \caption{I tre tempi associati a ciascun file.}
+ \label{tab:file_file_times}
+\end{table}
+
+Il primo punto da tenere presente è la differenza fra il cosiddetto tempo di
+modifica (il \textit{modification time} \var{st\_mtime}) e il tempo di
+cambiamento di stato (il \textit{change time} \var{st\_ctime}). Il primo
+infatti fa riferimento ad una modifica del contenuto di un file, mentre il
+secondo ad una modifica \index{inode} dell'inode; siccome esistono molte
+operazioni (come la funzione \func{link} e molte altre che vedremo in seguito)
+che modificano solo le informazioni contenute \index{inode} nell'inode senza
+toccare il contenuto del file, diventa necessario l'utilizzo di un altro
+tempo.
+
+Il sistema non tiene conto dell'ultimo accesso \index{inode} all'inode,
+pertanto funzioni come \func{access} o \func{stat} non hanno alcuna influenza
+sui tre tempi. Il tempo di ultimo accesso (ai dati) viene di solito usato per
+cancellare i file che non servono più dopo un certo lasso di tempo (ad esempio
+il programma \cmd{leafnode} cancella i vecchi articoli sulla base di questo
+tempo).
+
+Il tempo di ultima modifica invece viene usato da \cmd{make} per decidere
+quali file necessitano di essere ricompilati o (talvolta insieme anche al
+tempo di cambiamento di stato) per decidere quali file devono essere
+archiviati per il backup. Il comando \cmd{ls} (quando usato con le opzioni
+\cmd{-l} o \cmd{-t}) mostra i tempi dei file secondo lo schema riportato
+nell'ultima colonna di tab.~\ref{tab:file_file_times}.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|c|c|c|c|c|c|l|}
+ \hline
+ \multicolumn{1}{|p{3cm}|}{\centering{\vspace{6pt}\textbf{Funzione}}} &
+ \multicolumn{3}{|p{3.6cm}|}{\centering{
+ \textbf{File o directory del riferimento}}}&
+ \multicolumn{3}{|p{3.6cm}|}{\centering{
+ \textbf{Directory contenente il riferimento}}}
+ &\multicolumn{1}{|p{3.6cm}|}{\centering{\vspace{6pt}\textbf{Note}}} \\
+ \cline{2-7}
+ \cline{2-7}
+ \multicolumn{1}{|p{3cm}|}{}
+ &\multicolumn{1}{|p{.9cm}|}{\centering{\textsl{(a)}}}
+ &\multicolumn{1}{|p{.9cm}|}{\centering{\textsl{(m)}}}
+ &\multicolumn{1}{|p{.9cm}|}{\centering{\textsl{(c)}}}
+ &\multicolumn{1}{|p{.9cm}|}{\centering{\textsl{(a)}}}
+ &\multicolumn{1}{|p{.9cm}|}{\centering{\textsl{(m)}}}
+ &\multicolumn{1}{|p{.9cm}|}{\centering{\textsl{(c)}}}
+ &\multicolumn{1}{|p{3cm}|}{} \\
+ \hline
+ \hline
+ \func{chmod}, \func{fchmod}
+ & -- & -- &$\bullet$& -- & -- & -- & \\
+ \func{chown}, \func{fchown}
+ & -- & -- &$\bullet$& -- & -- & -- & \\
+ \func{creat}
+ &$\bullet$&$\bullet$&$\bullet$& -- &$\bullet$&$\bullet$& con
+ \const{O\_CREATE} \\ \func{creat}
+ & -- &$\bullet$&$\bullet$& -- &$\bullet$&$\bullet$&
+ con \const{O\_TRUNC} \\ \func{exec}
+ &$\bullet$& -- & -- & -- & -- & -- & \\
+ \func{lchown}
+ & -- & -- &$\bullet$& -- & -- & -- & \\
+ \func{link}
+ & -- & -- &$\bullet$& -- &$\bullet$&$\bullet$& \\
+ \func{mkdir}
+ &$\bullet$&$\bullet$&$\bullet$& -- &$\bullet$&$\bullet$& \\
+ \func{mkfifo}
+ &$\bullet$&$\bullet$&$\bullet$& -- &$\bullet$&$\bullet$& \\
+ \func{open}
+ &$\bullet$&$\bullet$&$\bullet$& -- &$\bullet$&$\bullet$& con
+ \const{O\_CREATE} \\ \func{open}
+ & -- &$\bullet$&$\bullet$& -- & -- & -- & con
+ \const{O\_TRUNC} \\ \func{pipe}
+ &$\bullet$&$\bullet$&$\bullet$& -- & -- & -- & \\
+ \func{read}
+ &$\bullet$& -- & -- & -- & -- & -- & \\
+ \func{remove}
+ & -- & -- &$\bullet$& -- &$\bullet$&$\bullet$& se esegue
+ \func{unlink}\\ \func{remove}
+ & -- & -- & -- & -- &$\bullet$&$\bullet$& se esegue
+ \func{rmdir}\\ \func{rename}
+ & -- & -- &$\bullet$& -- &$\bullet$&$\bullet$& per entrambi
+ gli argomenti\\ \func{rmdir}
+ & -- & -- & -- & -- &$\bullet$&$\bullet$& \\
+ \func{truncate}, \func{ftruncate}
+ & -- &$\bullet$&$\bullet$& -- & -- & -- & \\
+ \func{unlink}
+ & -- & -- &$\bullet$& -- &$\bullet$&$\bullet$& \\
+ \func{utime}
+ &$\bullet$&$\bullet$&$\bullet$& -- & -- & -- & \\
+ \func{write}
+ & -- &$\bullet$&$\bullet$& -- & -- & -- & \\
+ \hline
+ \end{tabular}
+ \caption{Prospetto dei cambiamenti effettuati sui tempi di ultimo
+ accesso \textsl{(a)}, ultima modifica \textsl{(m)} e ultimo cambiamento
+ \textsl{(c)} dalle varie funzioni operanti su file e directory.}
+ \label{tab:file_times_effects}
+\end{table}
+
+L'effetto delle varie funzioni di manipolazione dei file sui tempi è
+illustrato in tab.~\ref{tab:file_times_effects}. Si sono riportati gli effetti
+sia per il file a cui si fa riferimento, sia per la directory che lo contiene;
+questi ultimi possono essere capiti se si tiene conto di quanto già detto, e
+cioè che anche le directory sono file (che contengono una lista di nomi) che
+il sistema tratta in maniera del tutto analoga a tutti gli altri.
+
+Per questo motivo tutte le volte che compiremo un'operazione su un file che
+comporta una modifica del nome contenuto nella directory, andremo anche a
+scrivere sulla directory che lo contiene cambiandone il tempo di modifica. Un
+esempio di questo può essere la cancellazione di un file, invece leggere o
+scrivere o cambiare i permessi di un file ha effetti solo sui tempi di
+quest'ultimo.
+
+Si noti infine come \var{st\_ctime} non abbia nulla a che fare con il tempo di
+creazione del file, usato in molti altri sistemi operativi, ma che in Unix non
+esiste. Per questo motivo quando si copia un file, a meno di preservare
+esplicitamente i tempi (ad esempio con l'opzione \cmd{-p} di \cmd{cp}) esso
+avrà sempre il tempo corrente come data di ultima modifica.
+
+I tempi di ultimo accesso e modifica possono essere cambiati usando la
+funzione \funcd{utime}, il cui prototipo è:
+\begin{prototype}{utime.h}
+{int utime(const char *filename, struct utimbuf *times)}
+
+Cambia i tempi di ultimo accesso e modifica \index{inode} dell'inode
+specificato da \param{filename} secondo i campi \var{actime} e \var{modtime}
+di \param{times}. Se questa è \val{NULL} allora viene usato il tempo corrente.
+
+\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EACCES}] non si ha il permesso di scrittura sul file.
+ \item[\errcode{ENOENT}] \param{filename} non esiste.
+ \end{errlist}}
+\end{prototype}
+
+La funzione prende come argomento \param{times} una struttura
+\struct{utimbuf}, la cui definizione è riportata in
+fig.~\ref{fig:struct_utimebuf}, con la quale si possono specificare i nuovi
+valori che si vogliono impostare per tempi.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \includestruct{listati/utimbuf.h}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{utimbuf}, usata da \func{utime} per modificare
+ i tempi dei file.}
+ \label{fig:struct_utimebuf}
+\end{figure}
+
+L'effetto della funzione e i privilegi necessari per eseguirla dipendono da
+cosa è l'argomento \param{times}; se è \val{NULL} la funzione imposta il
+tempo corrente ed è sufficiente avere accesso in scrittura al file; se invece
+si è specificato un valore la funzione avrà successo solo se si è proprietari
+del file (o si hanno i privilegi di amministratore).
+
+Si tenga presente che non è comunque possibile specificare il tempo di
+cambiamento di stato del file, che viene comunque cambiato dal kernel tutte le
+volte che si modifica \index{inode} l'inode (quindi anche alla chiamata di
+\func{utime}). Questo serve anche come misura di sicurezza per evitare che si
+possa modificare un file nascondendo completamente le proprie tracce. In
+realtà la cosa resta possibile, se si è in grado di accedere al file di
+dispositivo, scrivendo direttamente sul disco senza passare attraverso il
+filesystem, ma ovviamente in questo modo la cosa è molto più complicata da
+realizzare.
+
+
+
+\section{Il controllo di accesso ai file}
+\label{sec:file_access_control}
+
+Una delle caratteristiche fondamentali di tutti i sistemi unix-like è quella
+del controllo di accesso ai file, che viene implementato per qualunque
+filesystem standard.\footnote{per standard si intende che implementa le
+ caratteristiche previste dallo standard POSIX. In Linux sono disponibili
+ anche una serie di altri filesystem, come quelli di Windows e del Mac, che
+ non supportano queste caratteristiche.} In questa sezione ne esamineremo i
+concetti essenziali e le funzioni usate per gestirne i vari aspetti.
+
+
+\subsection{I permessi per l'accesso ai file}
+\label{sec:file_perm_overview}
+
+Ad ogni file Linux associa sempre l'utente che ne è proprietario (il
+cosiddetto \textit{owner}) ed un gruppo di appartenenza, secondo il meccanismo
+degli identificatori di utente e gruppo (\acr{uid} e \acr{gid}). Questi valori
+sono accessibili da programma tramite la funzione \func{stat}, e sono
+mantenuti nei campi \var{st\_uid} e \var{st\_gid} della struttura
+\struct{stat} (si veda sez.~\ref{sec:file_stat}).\footnote{Questo è vero solo
+ per filesystem di tipo Unix, ad esempio non è vero per il filesystem vfat di
+ Windows, che non fornisce nessun supporto per l'accesso multiutente, e per
+ il quale i permessi vengono assegnati in maniera fissa con un opzione in
+ fase di montaggio.}
+
+Il controllo di accesso ai file segue un modello abbastanza semplice che
+prevede tre permessi fondamentali strutturati su tre livelli di accesso.
+Esistono varie estensioni a questo modello,\footnote{come le \textit{Access
+ Control List} che possono essere aggiunte al filesystem standard con
+ opportune patch, la cui introduzione nei kernel ufficiali è iniziata con la
+ serie 2.5.x. per arrivare a meccanismi di controllo ancora più sofisticati
+ come il \textit{mandatory access control} di SE-Linux.} ma nella maggior
+parte dei casi il meccanismo standard è più che sufficiente a soddisfare tutte
+le necessità più comuni. I tre permessi di base associati ad ogni file sono:
+\begin{itemize*}
+\item il permesso di lettura (indicato con la lettera \texttt{r}, dall'inglese
+ \textit{read}).
+\item il permesso di scrittura (indicato con la lettera \texttt{w},
+ dall'inglese \textit{write}).
+\item il permesso di esecuzione (indicato con la lettera \texttt{x},
+ dall'inglese \textit{execute}).
+\end{itemize*}
+mentre i tre livelli su cui sono divisi i privilegi sono:
+\begin{itemize*}
+\item i privilegi per l'utente proprietario del file.
+\item i privilegi per un qualunque utente faccia parte del gruppo cui
+ appartiene il file.
+\item i privilegi per tutti gli altri utenti.
+\end{itemize*}
+
+L'insieme dei permessi viene espresso con un numero a 12 bit; di questi i nove
+meno significativi sono usati a gruppi di tre per indicare i permessi base di
+lettura, scrittura ed esecuzione e sono applicati rispettivamente
+rispettivamente al proprietario, al gruppo, a tutti gli altri.
+
+\begin{figure}[htb]
+ \centering
+ \includegraphics[width=6cm]{img/fileperm}
+ \caption{Lo schema dei bit utilizzati per specificare i permessi di un file
+ contenuti nel campo \var{st\_mode} di \struct{stat}.}
+ \label{fig:file_perm_bit}
+\end{figure}
+
+I restanti tre bit (noti come \itindex{suid~bit} \textit{suid bit},
+\itindex{sgid~bit} \textit{sgid bit}, e \itindex{sticky~bit} \textit{sticky
+ bit}) sono usati per indicare alcune caratteristiche più complesse del
+meccanismo del controllo di accesso su cui torneremo in seguito (in
+sez.~\ref{sec:file_special_perm}); lo schema di allocazione dei bit è
+riportato in fig.~\ref{fig:file_perm_bit}.
+
+Anche i permessi, come tutte le altre informazioni pertinenti al file, sono
+memorizzati \index{inode} nell'inode; in particolare essi sono contenuti in
+alcuni bit del campo \var{st\_mode} della struttura \struct{stat} (si veda di
+nuovo fig.~\ref{fig:file_stat_struct}).
+
+In genere ci si riferisce ai tre livelli dei privilegi usando le lettere
+\cmd{u} (per \textit{user}), \cmd{g} (per \textit{group}) e \cmd{o} (per
+\textit{other}), inoltre se si vuole indicare tutti i raggruppamenti insieme
+si usa la lettera \cmd{a} (per \textit{all}). Si tenga ben presente questa
+distinzione dato che in certi casi, mutuando la terminologia in uso nel VMS,
+si parla dei permessi base come di permessi per \textit{owner}, \textit{group}
+ed \textit{all}, le cui iniziali possono dar luogo a confusione. Le costanti
+che permettono di accedere al valore numerico di questi bit nel campo
+\var{st\_mode} sono riportate in tab.~\ref{tab:file_bit_perm}.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|c|l|}
+ \hline
+ \textbf{\var{st\_mode}} bit & \textbf{Significato} \\
+ \hline
+ \hline
+ \const{S\_IRUSR} & \textit{user-read}, l'utente può leggere \\
+ \const{S\_IWUSR} & \textit{user-write}, l'utente può scrivere \\
+ \const{S\_IXUSR} & \textit{user-execute}, l'utente può eseguire \\
+ \hline
+ \const{S\_IRGRP} & \textit{group-read}, il gruppo può leggere \\
+ \const{S\_IWGRP} & \textit{group-write}, il gruppo può scrivere \\
+ \const{S\_IXGRP} & \textit{group-execute}, il gruppo può eseguire\\
+ \hline
+ \const{S\_IROTH} & \textit{other-read}, tutti possono leggere \\
+ \const{S\_IWOTH} & \textit{other-write}, tutti possono scrivere \\
+ \const{S\_IXOTH} & \textit{other-execute}, tutti possono eseguire\\
+ \hline
+ \end{tabular}
+ \caption{I bit dei permessi di accesso ai file, come definiti in
+ \texttt{<sys/stat.h>}}
+ \label{tab:file_bit_perm}
+\end{table}
+
+I permessi vengono usati in maniera diversa dalle varie funzioni, e a seconda
+che si riferiscano a dei file, dei link simbolici o delle directory; qui ci
+limiteremo ad un riassunto delle regole generali, entrando nei dettagli più
+avanti.
+
+La prima regola è che per poter accedere ad un file attraverso il suo
+\itindex{pathname} \textit{pathname} occorre il permesso di esecuzione in
+ciascuna delle directory che compongono il \textit{pathname}; lo stesso vale
+per aprire un file nella directory corrente (per la quale appunto serve il
+diritto di esecuzione).
+
+Per una directory infatti il permesso di esecuzione significa che essa può
+essere attraversata nella risoluzione del \itindex{pathname}
+\textit{pathname}, ed è distinto dal permesso di lettura che invece implica
+che si può leggere il contenuto della directory.
+
+Questo significa che se si ha il permesso di esecuzione senza permesso di
+lettura si potrà lo stesso aprire un file in una directory (se si hanno i
+permessi opportuni per il medesimo) ma non si potrà vederlo con \cmd{ls}
+(mentre per crearlo occorrerà anche il permesso di scrittura per la
+directory).
+
+Avere il permesso di lettura per un file consente di aprirlo con le opzioni
+(si veda quanto riportato in tab.~\ref{tab:file_open_flags}) di sola lettura o
+di lettura/scrittura e leggerne il contenuto. Avere il permesso di scrittura
+consente di aprire un file in sola scrittura o lettura/scrittura e modificarne
+il contenuto, lo stesso permesso è necessario per poter troncare il file.
+
+Non si può creare un file fintanto che non si disponga del permesso di
+esecuzione e di quello di scrittura per la directory di destinazione; gli
+stessi permessi occorrono per cancellare un file da una directory (si ricordi
+che questo non implica necessariamente la rimozione del contenuto del file dal
+disco), non è necessario nessun tipo di permesso per il file stesso (infatti
+esso non viene toccato, viene solo modificato il contenuto della directory,
+rimuovendo la voce che ad esso fa riferimento).
+
+Per poter eseguire un file (che sia un programma compilato od uno script di
+shell, od un altro tipo di file eseguibile riconosciuto dal kernel), occorre
+avere il permesso di esecuzione, inoltre solo i file regolari possono essere
+eseguiti.
+
+I permessi per un link simbolico sono ignorati, contano quelli del file a cui
+fa riferimento; per questo in genere il comando \cmd{ls} riporta per un link
+simbolico tutti i permessi come concessi; utente e gruppo a cui esso
+appartiene vengono pure ignorati quando il link viene risolto, vengono
+controllati solo quando viene richiesta la rimozione del link e quest'ultimo è
+in una directory con lo \itindex{sticky~bit} \textit{sticky bit} impostato (si
+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
+ 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,
+ eccetto il caso in cui si voglia scrivere un server NFS, ignoreremo questa
+ differenza.}
+
+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
+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
+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
+ 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
+ proprietario del file (nel qual caso si dice che il processo è proprietario
+ del file) allora:
+ \begin{itemize*}
+ \item se il relativo\footnote{per relativo si intende il bit di user-read se
+ il processo vuole accedere in scrittura, quello di user-write per
+ l'accesso in scrittura, ecc.} bit dei permessi d'accesso dell'utente è
+ 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
+ dei processi corrispondono al \acr{gid} del file allora:
+ \begin{itemize*}
+ \item se il bit dei permessi d'accesso del gruppo è impostato, l'accesso è
+ consentito,
+ \item altrimenti l'accesso è negato
+ \end{itemize*}
+\item se il bit dei permessi d'accesso per tutti gli altri è impostato,
+ l'accesso è consentito, altrimenti l'accesso è negato.
+\end{enumerate}
+
+Si tenga presente che questi passi vengono eseguiti esattamente in
+quest'ordine. Questo vuol dire che se un processo è il proprietario di un file,
+l'accesso è consentito o negato solo sulla base dei permessi per l'utente; i
+permessi per il gruppo non vengono neanche controllati. Lo stesso vale se il
+processo appartiene ad un gruppo appropriato, in questo caso i permessi per
+tutti gli altri non vengono controllati.
+
+
+\subsection{I bit dei permessi speciali}
+\label{sec:file_special_perm}
+
+\itindbeg{suid~bit}
+\itindbeg{sgid~bit}
+
+Come si è accennato (in sez.~\ref{sec:file_perm_overview}) nei dodici bit del
+campo \var{st\_mode} di \struct{stat} che vengono usati per il controllo di
+accesso oltre ai bit dei permessi veri e propri, ci sono altri tre bit che
+vengono usati per indicare alcune proprietà speciali dei file. Due di questi
+sono i bit detti \acr{suid} (da \textit{set-user-ID bit}) e \acr{sgid} (da
+\textit{set-group-ID bit}) che sono identificati dalle costanti
+\const{S\_ISUID} e \const{S\_ISGID}.
+
+Come spiegato in dettaglio in sez.~\ref{sec:proc_exec}, quando si lancia un
+programma il comportamento normale del kernel è quello di impostare gli
+identificatori del gruppo \textit{effective} del nuovo processo al valore dei
+corrispondenti del gruppo \textit{real} del processo corrente, che normalmente
+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
+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
+processo.
+
+I bit \acr{suid} e \acr{sgid} vengono usati per permettere agli utenti normali
+di usare programmi che richiedono privilegi speciali; l'esempio classico è il
+comando \cmd{passwd} che ha la necessità di modificare il file delle password,
+quest'ultimo ovviamente può essere scritto solo dall'amministratore, ma non è
+necessario chiamare l'amministratore per cambiare la propria password. Infatti
+il comando \cmd{passwd} appartiene a root ma ha il bit \acr{suid} impostato
+per cui quando viene lanciato da un utente normale parte con i privilegi di
+root.
+
+Chiaramente avere un processo che ha privilegi superiori a quelli che avrebbe
+normalmente l'utente che lo ha lanciato comporta vari rischi, e questo tipo di
+programmi devono essere scritti accuratamente per evitare che possano essere
+usati per guadagnare privilegi non consentiti (l'argomento è affrontato in
+dettaglio in sez.~\ref{sec:proc_perms}).
+
+La presenza dei bit \acr{suid} e \acr{sgid} su un file può essere rilevata con
+il comando \cmd{ls -l}, che visualizza una lettera \cmd{s} al posto della
+\cmd{x} in corrispondenza dei permessi di utente o gruppo. La stessa lettera
+\cmd{s} può essere usata nel comando \cmd{chmod} per impostare questi bit.
+Infine questi bit possono essere controllati all'interno di \var{st\_mode} con
+l'uso delle due costanti \const{S\_ISUID} e \const{S\_IGID}, i cui valori sono
+riportati in tab.~\ref{tab:file_mode_flags}.
+
+Gli stessi bit vengono ad assumere in significato completamente diverso per le
+directory, normalmente infatti Linux usa la convenzione di SVr4 per indicare
+con questi bit l'uso della semantica BSD nella creazione di nuovi file (si
+veda sez.~\ref{sec:file_ownership_management} per una spiegazione dettagliata
+al proposito).
+
+Infine Linux utilizza il bit \acr{sgid} per un'ulteriore estensione mutuata
+da SVr4. Il caso in cui un file ha il bit \acr{sgid} impostato senza che lo
+sia anche il corrispondente bit di esecuzione viene utilizzato per attivare
+per quel file il \itindex{mandatory~locking} \textit{mandatory locking}
+(affronteremo questo argomento in dettaglio più avanti, in
+sez.~\ref{sec:file_mand_locking}).
+
+\itindend{suid~bit}
+\itindend{sgid~bit}
+
+
+\itindbeg{sticky~bit}
+
+L'ultimo dei bit rimanenti, identificato dalla costante \const{S\_ISVTX}, è in
+parte un rimasuglio delle origini dei sistemi Unix. A quell'epoca infatti la
+memoria virtuale e l'accesso ai file erano molto meno sofisticati e per
+ottenere la massima velocità possibile per i programmi usati più comunemente
+si poteva impostare questo bit.
+
+L'effetto di questo bit era che il \index{segmento!testo} segmento di testo
+del programma (si veda sez.~\ref{sec:proc_mem_layout} per i dettagli) veniva
+scritto nella swap la prima volta che questo veniva lanciato, e vi permaneva
+fino al riavvio della macchina (da questo il nome di \textsl{sticky bit});
+essendo la swap un file continuo o una partizione indicizzata direttamente si
+poteva risparmiare in tempo di caricamento rispetto alla ricerca attraverso la
+struttura del filesystem. Lo \textsl{sticky bit} è indicato usando la lettera
+\texttt{t} al posto della \texttt{x} nei permessi per gli altri.
+
+Ovviamente per evitare che gli utenti potessero intasare la swap solo
+l'amministratore era in grado di impostare questo bit, che venne chiamato
+anche con il nome di \textit{saved text bit}, da cui deriva quello della
+costante. Le attuali implementazioni di memoria virtuale e filesystem rendono
+sostanzialmente inutile questo procedimento.
+
+Benché ormai non venga più utilizzato per i file, lo \textit{sticky bit} ha
+invece assunto un uso importante per le directory;\footnote{lo \textit{sticky
+ bit} per le directory è un'estensione non definita nello standard POSIX,
+ Linux però la supporta, così come BSD e SVr4.} in questo caso se tale bit è
+impostato un file potrà essere rimosso dalla directory soltanto se l'utente ha
+il permesso di scrittura su di essa ed inoltre è vera una delle seguenti
+condizioni:
+\begin{itemize*}
+\item l'utente è proprietario del file
+\item l'utente è proprietario della directory
+\item l'utente è l'amministratore
+\end{itemize*}
+un classico esempio di directory che ha questo bit impostato è \file{/tmp}, i
+permessi infatti di solito sono i seguenti:
+\begin{verbatim}
+$ ls -ld /tmp
+drwxrwxrwt 6 root root 1024 Aug 10 01:03 /tmp
+\end{verbatim}%$
+quindi con lo \textit{sticky bit} bit impostato. In questo modo qualunque
+utente nel sistema può creare dei file in questa directory (che, come
+suggerisce il nome, è normalmente utilizzata per la creazione di file
+temporanei), ma solo l'utente che ha creato un certo file potrà cancellarlo o
+rinominarlo. In questo modo si evita che un utente possa, più o meno
+consapevolmente, cancellare i file temporanei creati degli altri utenti.
+
+\itindend{sticky~bit}
+
+\subsection{Le funzioni per la gestione dei permessi dei file}
+\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
+\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.
+
+Per far questo si può usare la funzione \funcd{access}, il cui prototipo è:
+\begin{prototype}{unistd.h}
+{int access(const char *pathname, int mode)}
+
+Verifica i permessi di accesso.
+
+\bodydesc{La funzione ritorna 0 se l'accesso è consentito, -1 se l'accesso non
+ è consentito ed in caso di errore; nel qual caso la variabile \var{errno}
+ assumerà i valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] il valore di \param{mode} non è valido.
+ \item[\errcode{EACCES}] l'accesso al file non è consentito, o non si ha il
+ permesso di attraversare una delle directory di \param{pathname}.
+ \item[\errcode{EROFS}] si è richiesto l'accesso in scrittura per un file su
+ un filesystem montato in sola lettura.
+ \end{errlist}
+ ed inoltre \errval{EFAULT}, \errval{ENAMETOOLONG}, \errval{ENOENT},
+ \errval{ENOTDIR}, \errval{ELOOP}, \errval{EIO}.}
+\end{prototype}
+
+La funzione verifica i permessi di accesso, indicati da \param{mode}, per il
+file indicato da \param{pathname}. I valori possibili per l'argomento
+\param{mode} sono esprimibili come combinazione delle costanti numeriche
+riportate in tab.~\ref{tab:file_access_mode_val} (attraverso un OR binario
+delle stesse). I primi tre valori implicano anche la verifica dell'esistenza
+del file, se si vuole verificare solo quest'ultima si può usare \const{F\_OK},
+o anche direttamente \func{stat}. Nel caso in cui \param{pathname} si
+riferisca ad un link simbolico, questo viene seguito ed il controllo è fatto
+sul file a cui esso fa riferimento.
+
+La funzione controlla solo i bit dei permessi di accesso, si ricordi che il
+fatto che una directory abbia permesso di scrittura non significa che ci si
+possa scrivere come in un file, e il fatto che un file abbia permesso di
+esecuzione non comporta che contenga un programma eseguibile. La funzione
+ritorna zero solo se tutte i permessi controllati sono disponibili, in caso
+contrario (o di errore) ritorna -1.
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}{|c|l|}
+ \hline
+ \textbf{\param{mode}} & \textbf{Significato} \\
+ \hline
+ \hline
+ \const{R\_OK} & verifica il permesso di lettura \\
+ \const{W\_OK} & verifica il permesso di scritture \\
+ \const{X\_OK} & verifica il permesso di esecuzione \\
+ \const{F\_OK} & verifica l'esistenza del file \\
+ \hline
+ \end{tabular}
+ \caption{Valori possibile per l'argomento \param{mode} della funzione
+ \func{access}.}
+ \label{tab:file_access_mode_val}
+\end{table}
+
+Un esempio tipico per l'uso di questa funzione è quello di un processo che sta
+eseguendo un programma coi privilegi di un altro utente (ad esempio attraverso
+l'uso del \itindex{suid~bit} \textit{suid bit}) che vuole controllare se
+l'utente originale ha i permessi per accedere ad un certo file.
+
+Per cambiare i permessi di un file il sistema mette ad disposizione due
+funzioni \funcd{chmod} e \funcd{fchmod}, che operano rispettivamente su un
+filename e su un file descriptor, i loro prototipi sono:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/stat.h}
+
+ \funcdecl{int chmod(const char *path, mode\_t mode)} Cambia i permessi del
+ file indicato da \param{path} al valore indicato da \param{mode}.
+
+ \funcdecl{int fchmod(int fd, mode\_t mode)} Analoga alla precedente, ma usa
+ il file descriptor \param{fd} per indicare il file.
+
+ \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
+ proprietario del file o non è zero.
+ \item[\errcode{EROFS}] Il file è su un filesystem in sola lettura.
+ \end{errlist}
+ ed inoltre \errval{EIO}; \func{chmod} restituisce anche \errval{EFAULT},
+ \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM}, \errval{ENOTDIR},
+ \errval{EACCES}, \errval{ELOOP}; \func{fchmod} anche \errval{EBADF}.}
+\end{functions}
+
+Entrambe le funzioni utilizzano come secondo argomento \param{mode}, una
+variabile dell'apposito tipo primitivo \type{mode\_t} (vedi
+tab.~\ref{tab:intro_primitive_types}) utilizzato per specificare i permessi sui
+file.
+
+\begin{table}[!htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|c|c|l|}
+ \hline
+ \textbf{\param{mode}} & \textbf{Valore} & \textbf{Significato} \\
+ \hline
+ \hline
+ \const{S\_ISUID} & 04000 & set user ID \itindex{suid~bit} \\
+ \const{S\_ISGID} & 02000 & set group ID \itindex{sgid~bit}\\
+ \const{S\_ISVTX} & 01000 & sticky bit \itindex{sticky~bit}\\
+ \hline
+ \const{S\_IRWXU} & 00700 & l'utente ha tutti i permessi \\
+ \const{S\_IRUSR} & 00400 & l'utente ha il permesso di lettura \\
+ \const{S\_IWUSR} & 00200 & l'utente ha il permesso di scrittura \\
+ \const{S\_IXUSR} & 00100 & l'utente ha il permesso di esecuzione \\
+ \hline
+ \const{S\_IRWXG} & 00070 & il gruppo ha tutti i permessi \\
+ \const{S\_IRGRP} & 00040 & il gruppo ha il permesso di lettura \\
+ \const{S\_IWGRP} & 00020 & il gruppo ha il permesso di scrittura \\
+ \const{S\_IXGRP} & 00010 & il gruppo ha il permesso di esecuzione \\
+ \hline
+ \const{S\_IRWXO} & 00007 & gli altri hanno tutti i permessi \\
+ \const{S\_IROTH} & 00004 & gli altri hanno il permesso di lettura \\
+ \const{S\_IWOTH} & 00002 & gli altri hanno il permesso di scrittura \\
+ \const{S\_IXOTH} & 00001 & gli altri hanno il permesso di esecuzione \\
+ \hline
+ \end{tabular}
+ \caption{Valori delle costanti usate per indicare i vari bit di
+ \param{mode} utilizzato per impostare i permessi dei file.}
+ \label{tab:file_permission_const}
+\end{table}
+
+Le costanti con cui specificare i singoli bit di \param{mode} sono riportate
+in tab.~\ref{tab:file_permission_const}. Il valore di \param{mode} può essere
+ottenuto combinando fra loro con un OR binario le costanti simboliche relative
+ai vari bit, o specificato direttamente, come per l'omonimo comando di shell,
+con un valore numerico (la shell lo vuole in ottale, dato che i bit dei
+permessi sono divisibili in gruppi di tre), che si può calcolare direttamente
+usando lo schema si utilizzo dei bit illustrato in
+fig.~\ref{fig:file_perm_bit}.
+
+Ad esempio i permessi standard assegnati ai nuovi file (lettura e scrittura
+per il proprietario, sola lettura per il gruppo e gli altri) sono
+corrispondenti al valore ottale $0644$, un programma invece avrebbe anche il
+bit di esecuzione attivo, con un valore di $0755$, se si volesse attivare il
+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
+corrisponde a quello del proprietario del file o dell'amministratore,
+altrimenti esse falliranno con un errore di \errcode{EPERM}.
+
+Ma oltre a questa regola generale, di immediata comprensione, esistono delle
+limitazioni ulteriori. Per questo motivo, anche se si è proprietari del file,
+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
+ 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
+ creazione dei nuovi file, si può avere il caso in cui il file creato da un
+ processo è assegnato ad un gruppo per il quale il processo non ha privilegi.
+ Per evitare che si possa assegnare il bit \itindex{sgid~bit} \acr{sgid} ad
+ 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).
+\end{enumerate}
+
+Per alcuni filesystem\footnote{i filesystem più comuni (\textsl{ext2},
+ \textsl{ext3}, \textsl{reiserfs}) supportano questa caratteristica, che è
+ mutuata da BSD.} è inoltre prevista un'ulteriore misura di sicurezza, volta
+a scongiurare l'abuso dei \itindex{suid~bit} bit \acr{suid} e \acr{sgid}; essa
+consiste nel cancellare automaticamente questi bit dai permessi di un file
+qualora un processo che non appartenga all'amministratore\footnote{per la
+ precisione un processo che non dispone della capability
+ \const{CAP\_FSETID}.} effettui una scrittura. In questo modo anche se un
+utente malizioso scopre un file \acr{suid} su cui può scrivere, un'eventuale
+modifica comporterà la perdita di questo privilegio.
+
+Le funzioni \func{chmod} e \func{fchmod} ci permettono di modificare i
+permessi di un file, resta però il problema di quali sono i permessi assegnati
+quando il file viene creato. Le funzioni dell'interfaccia nativa di Unix, come
+vedremo in sez.~\ref{sec:file_open}, permettono di indicare esplicitamente i
+permessi di creazione di un file, ma questo non è possibile per le funzioni
+dell'interfaccia standard ANSI C che non prevede l'esistenza di utenti e
+gruppi, ed inoltre il problema si pone anche per l'interfaccia nativa quando i
+permessi non vengono indicati esplicitamente.
+
+In tutti questi casi l'unico riferimento possibile è quello della modalità di
+apertura del nuovo file (lettura/scrittura o sola lettura), che però può
+fornire un valore che è lo stesso per tutti e tre i permessi di
+sez.~\ref{sec:file_perm_overview} (cioè $666$ nel primo caso e $222$ nel
+secondo). Per questo motivo il sistema associa ad ogni processo\footnote{è
+ infatti contenuta nel campo \var{umask} della struttura \struct{fs\_struct},
+ vedi fig.~\ref{fig:proc_task_struct}.} una maschera di bit, la cosiddetta
+\textit{umask}, che viene utilizzata per impedire che alcuni permessi possano
+essere assegnati ai nuovi file in sede di creazione. I bit indicati nella
+maschera vengono infatti cancellati dai permessi quando un nuovo file viene
+creato.
+
+La funzione che permette di impostare il valore di questa maschera di
+controllo è \funcd{umask}, ed il suo prototipo è:
+\begin{prototype}{stat.h}
+{mode\_t umask(mode\_t mask)}
+
+Imposta la maschera dei permessi dei bit al valore specificato da \param{mask}
+(di cui vengono presi solo i 9 bit meno significativi).
+
+ \bodydesc{La funzione ritorna il precedente valore della maschera. È una
+ delle poche funzioni che non restituisce codici di errore.}
+\end{prototype}
+
+In genere si usa questa maschera per impostare un valore predefinito che
+escluda preventivamente alcuni permessi (usualmente quello di scrittura per il
+gruppo e gli altri, corrispondente ad un valore per \param{mask} pari a
+$022$). In questo modo è possibile cancellare automaticamente i permessi non
+voluti. Di norma questo valore viene impostato una volta per tutte al login a
+$022$, e gli utenti non hanno motivi per modificarlo.
+
+
+
+\subsection{La gestione della titolarità dei file}
+\label{sec:file_ownership_management}
+
+Vedremo in sez.~\ref{sec:file_base_func} con quali funzioni si possono creare
+nuovi file, in tale occasione vedremo che è possibile specificare in sede di
+creazione quali permessi applicare ad un file, però non si può indicare a
+quale utente e gruppo esso deve appartenere. Lo stesso problema si presenta
+per la creazione di nuove directory (procedimento descritto in
+sez.~\ref{sec:file_dir_creat_rem}).
+
+Lo standard POSIX prescrive che l'\acr{uid} del nuovo file corrisponda
+all'user-ID 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} della directory in cui
+ esso è creato.
+\end{itemize*}
+in genere BSD usa sempre la seconda possibilità, che viene per questo chiamata
+semantica BSD. Linux invece segue quella che viene chiamata semantica SVr4; di
+norma cioè il nuovo file viene creato, seguendo la prima opzione, con il
+\acr{gid} del processo, se però la directory in cui viene creato il file ha il
+bit \acr{sgid} impostato allora viene usata la seconda opzione.
+
+Usare la semantica BSD ha il vantaggio che il \acr{gid} viene sempre
+automaticamente propagato, restando coerente a quello della directory di
+partenza, in tutte le sotto-directory.
+
+La semantica SVr4 offre la possibilità di scegliere, ma per ottenere lo stesso
+risultato di coerenza che si ha con BSD necessita che per le nuove directory
+venga anche propagato anche il bit \acr{sgid}. Questo è il comportamento
+predefinito del comando \cmd{mkdir}, ed è in questo modo ad esempio che Debian
+assicura che le sotto-directory create nella home di un utente restino sempre
+con il \acr{gid} del gruppo primario dello stesso.
+
+Come per i permessi, il sistema fornisce anche delle funzioni che permettano
+di cambiare utente e gruppo cui il file appartiene; le funzioni in questione
+sono tre: \funcd{chown}, \funcd{fchown} e \funcd{lchown}, ed i loro prototipi
+sono:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/stat.h}
+
+ \funcdecl{int chown(const char *path, uid\_t owner, gid\_t group)}
+ \funcdecl{int fchown(int fd, uid\_t owner, gid\_t group)}
+ \funcdecl{int lchown(const char *path, uid\_t owner, gid\_t group)}
+
+ Le funzioni cambiano utente e gruppo di appartenenza di un file ai valori
+ specificati dalle variabili \param{owner} e \param{group}.
+
+ \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
+ 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
+ \errval{EIO}; \func{chown} restituisce anche \errval{EFAULT},
+ \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM}, \errval{ENOTDIR},
+ \errval{EACCES}, \errval{ELOOP}; \func{fchown} anche \errval{EBADF}.}
+\end{functions}
+
+In Linux soltanto l'amministratore (in sostanza un processo con la
+\itindex{capabilities} capability \const{CAP\_CHOWN}) può cambiare il
+proprietario di un file, seguendo la semantica di BSD che non consente agli
+utenti di assegnare i loro file ad altri (per evitare eventuali aggiramenti
+delle quote). L'amministratore può cambiare il gruppo di un file, il
+proprietario può cambiare il gruppo dei file che gli appartengono solo se il
+nuovo gruppo è il suo gruppo primario o uno dei gruppi di cui fa parte.
+
+La funzione \func{chown} segue i link simbolici, per operare direttamente su
+un link simbolico si deve usare la funzione \func{lchown}.\footnote{fino alla
+ versione 2.1.81 in Linux \func{chown} non seguiva i link simbolici, da
+ allora questo comportamento è stato assegnato alla funzione \func{lchown},
+ introdotta per l'occasione, ed è stata creata una nuova system call per
+ \func{chown} che seguisse i link simbolici.} La funzione \func{fchown} opera
+su un file aperto, essa è mutuata da BSD, ma non è nello standard POSIX.
+Un'altra estensione rispetto allo standard POSIX è che specificando -1 come
+valore per \param{owner} e \param{group} i valori restano immutati.
+
+Quando queste funzioni sono chiamate con successo da un processo senza i
+privilegi di root entrambi i bit \itindex{suid~bit} \acr{suid} e
+\itindex{sgid~bit} \acr{sgid} vengono cancellati. Questo non avviene per il
+bit \acr{sgid} nel caso in cui esso sia usato (in assenza del corrispondente
+permesso di esecuzione) per indicare che per il file è attivo il
+\itindex{mandatory~locking} \textit{mandatory locking}.
+
+
+\subsection{Un quadro d'insieme sui permessi}
+\label{sec:file_riepilogo}
+
+Avendo affrontato in maniera separata il comportamento delle varie funzioni ed
+il significato dei singoli bit dei permessi sui file, vale la pena fare un
+riepilogo in cui si riassumono le caratteristiche di ciascuno di essi, in modo
+da poter fornire un quadro d'insieme.
+
+In tab.~\ref{tab:file_fileperm_bits} si sono riassunti gli effetti dei vari
+bit per un file; per quanto riguarda l'applicazione dei permessi per
+proprietario, gruppo ed altri si ricordi quanto illustrato in
+sez.~\ref{sec:file_perm_overview}. Si rammenti che il valore dei permessi non
+ha alcun effetto qualora il processo possieda i privilegi di amministratore.
+
+\begin{table}[!htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|c|c|c|c|c|c|c|c|c|c|c|c|l|}
+ \hline
+ \multicolumn{3}{|c|}{}&
+ \multicolumn{3}{|c|}{user}&
+ \multicolumn{3}{|c|}{group}&
+ \multicolumn{3}{|c|}{other}&
+ \multirow{2}{*}{\textbf{Operazioni possibili}} \\
+ \cline{1-12}
+ \acr{s}&\acr{s}&\acr{t}&r&w&x&r&w&x&r&w&x& \\
+ \hline
+ \hline
+ 1&-&-&-&-&-&-&-&-&-&-&-&Se eseguito ha i permessi del proprietario\\
+ -&1&-&-&-&1&-&-&-&-&-&-&Se eseguito ha i permessi del gruppo proprietario\\
+ -&1&-&-&-&0&-&-&-&-&-&-&Il \itindex{mandatory~locking}
+ \textit{mandatory locking} è abilitato\\
+ -&-&1&-&-&-&-&-&-&-&-&-&Non utilizzato\\
+ -&-&-&1&-&-&-&-&-&-&-&-&Permesso di lettura per il proprietario\\
+ -&-&-&-&1&-&-&-&-&-&-&-&Permesso di scrittura per il proprietario\\
+ -&-&-&-&-&1&-&-&-&-&-&-&Permesso di esecuzione per il proprietario\\
+ -&-&-&-&-&-&1&-&-&-&-&-&Permesso di lettura per il gruppo proprietario\\
+ -&-&-&-&-&-&-&1&-&-&-&-&Permesso di scrittura per il gruppo proprietario\\
+ -&-&-&-&-&-&-&-&1&-&-&-&Permesso di esecuzione per il gruppo proprietario\\
+ -&-&-&-&-&-&-&-&-&1&-&-&Permesso di lettura per tutti gli altri\\
+ -&-&-&-&-&-&-&-&-&-&1&-&Permesso di scrittura per tutti gli altri \\
+ -&-&-&-&-&-&-&-&-&-&-&1&Permesso di esecuzione per tutti gli altri\\
+ \hline
+ \end{tabular}
+ \caption{Tabella riassuntiva del significato dei bit dei permessi per un
+ file.}
+ \label{tab:file_fileperm_bits}
+\end{table}
+
+Per compattezza, nella tabella si sono specificati i bit di \itindex{suid~bit}
+\textit{suid}, \itindex{sgid~bit} \textit{sgid} e \textit{sticky}
+\itindex{sticky~bit} con la notazione illustrata anche in
+fig.~\ref{fig:file_perm_bit}.
+
+In tab.~\ref{tab:file_dirperm_bits} si sono invece riassunti gli effetti dei
+vari bit dei permessi per una directory; anche in questo caso si sono
+specificati i bit di \itindex{suid~bit} \textit{suid}, \itindex{sgid~bit}
+\textit{sgid} e \textit{sticky} \itindex{sticky~bit} con la notazione compatta
+illustrata in fig.~\ref{fig:file_perm_bit}.
+
+\begin{table}[!htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|c|c|c|c|c|c|c|c|c|c|c|c|l|}
+ \hline
+ \multicolumn{3}{|c|}{}&
+ \multicolumn{3}{|c|}{user}&
+ \multicolumn{3}{|c|}{group}&
+ \multicolumn{3}{|c|}{other}&
+ \multirow{2}{*}{\textbf{Operazioni possibili}} \\
+ \cline{1-12}
+ \acr{s}&\acr{s}&\acr{t}&r&w&x&r&w&x&r&w&x& \\
+ \hline
+ \hline
+ 1&-&-&-&-&-&-&-&-&-&-&-&Non utilizzato\\
+ -&1&-&-&-&-&-&-&-&-&-&-&Propaga il gruppo proprietario ai nuovi file creati\\
+ -&-&1&-&-&-&-&-&-&-&-&-&Limita l'accesso in scrittura dei file nella directory\\
+ -&-&-&1&-&-&-&-&-&-&-&-&Permesso di visualizzazione per il proprietario\\
+ -&-&-&-&1&-&-&-&-&-&-&-&Permesso di aggiornamento per il proprietario\\
+ -&-&-&-&-&1&-&-&-&-&-&-&Permesso di attraversamento per il proprietario\\
+ -&-&-&-&-&-&1&-&-&-&-&-&Permesso di visualizzazione per il gruppo proprietario\\
+ -&-&-&-&-&-&-&1&-&-&-&-&Permesso di aggiornamento per il gruppo proprietario\\
+ -&-&-&-&-&-&-&-&1&-&-&-&Permesso di attraversamento per il gruppo proprietario\\
+ -&-&-&-&-&-&-&-&-&1&-&-&Permesso di visualizzazione per tutti gli altri\\
+ -&-&-&-&-&-&-&-&-&-&1&-&Permesso di aggiornamento per tutti gli altri \\
+ -&-&-&-&-&-&-&-&-&-&-&1&Permesso di attraversamento per tutti gli altri\\
+ \hline
+ \end{tabular}
+ \caption{Tabella riassuntiva del significato dei bit dei permessi per una
+ directory.}
+ \label{tab:file_dirperm_bits}
+\end{table}
+
+Nelle tabelle si è indicato con ``-'' il fatto che il valore degli altri bit
+non è influente rispetto a quanto indicato in ciascuna riga; l'operazione fa
+riferimento soltanto alla combinazione di bit per i quali il valore è
+riportato esplicitamente.
+
+% TODO intrudurre nuova sezione sulle funzionalità di sicurezza avanzate, con
+% dentro chroot, gli attributi estesi, ecc.
+
+\subsection{La funzione \func{chroot}}
+\label{sec:file_chroot}
+
+Benché non abbia niente a che fare con permessi, utenti e gruppi, la funzione
+\func{chroot} viene usata spesso per restringere le capacità di accesso di un
+programma ad una sezione limitata del filesystem, per cui ne parleremo in
+questa sezione.
+
+Come accennato in sez.~\ref{sec:proc_fork} ogni processo oltre ad una
+directory di lavoro, ha anche una directory \textsl{radice}\footnote{entrambe
+ sono contenute in due campi (rispettivamente \var{pwd} e \var{root}) di
+ \struct{fs\_struct}; vedi fig.~\ref{fig:proc_task_struct}.} che, pur essendo
+di norma corrispondente alla radice dell'albero di file e directory come visto
+dal kernel (ed illustrato in sez.~\ref{sec:file_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.
+
+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
+padre da ogni processo figlio, in generale i processi risolvono i
+\itindsub{pathname}{assoluto}\textit{pathname} assoluti a partire sempre dalla
+stessa directory, che corrisponde alla \file{/} del sistema.
+
+In certe situazioni però, per motivi di sicurezza, è utile poter impedire che
+un processo possa accedere a tutto il filesystem; per far questo si può
+cambiare la sua directory radice con la funzione \funcd{chroot}, il cui
+prototipo è:
+\begin{prototype}{unistd.h}{int chroot(const char *path)}
+ Cambia la directory radice del processo a quella specificata da
+ \param{path}.
+
+\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.
+ \end{errlist}
+ ed inoltre \errval{EFAULT}, \errval{ENAMETOOLONG}, \errval{ENOENT},
+ \errval{ENOMEM}, \errval{ENOTDIR}, \errval{EACCES}, \errval{ELOOP};
+ \errval{EROFS} e \errval{EIO}.}
+\end{prototype}
+\noindent in questo modo la directory radice del processo diventerà
+\param{path} (che ovviamente deve esistere) ed ogni
+\itindsub{pathname}{assoluto}\textit{pathname} assoluto usato dalle funzioni
+chiamate nel processo sarà risolto a partire da essa, rendendo impossibile
+accedere alla parte di albero sovrastante. Si ha così quella che viene
+chiamata una \textit{chroot jail}, in quanto il processo non può più accedere
+a file al di fuori della sezione di albero in cui è stato
+\textsl{imprigionato}.
+
+Solo un processo con i privilegi di amministratore può usare questa funzione,
+e la nuova radice, per quanto detto in sez.~\ref{sec:proc_fork}, sarà ereditata
+da tutti i suoi processi figli. Si tenga presente però che la funzione non
+cambia la directory di lavoro, che potrebbe restare fuori dalla \textit{chroot
+ jail}.