+\begin{figure}[!htb]
+ \footnotesize
+ \centering
+ \begin{minipage}[c]{15cm}
+ \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
+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 \var{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 nativi
+del sistema (di quelli definiti in \tabref{tab:xxx_sys_types}, e dichiarati in
+\file{sys/types.h}).
+
+
+\subsection{I tipi di file}
+\label{sec:file_types}
+
+Come riportato in \tabref{tab:file_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 \func{stat} come maschera binaria nel campo
+\var{st\_mode} (che che contiene anche le informazioni relative ai permessi).
+
+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 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 \ntab.
+\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)} & device a caratteri \\
+ \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:file_type_macro}
+\end{table}
+
+Oltre alle macro di \tabref{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 \ntab.
+
+Il primo valore dell'elenco di \secref{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
+ \macro{S\_IFMT} & 0170000 & bitmask per i bit del tipo di file \\
+ \macro{S\_IFSOCK} & 0140000 & socket \\
+ \macro{S\_IFLNK} & 0120000 & link simbolico \\
+ \macro{S\_IFREG} & 0100000 & file regolare \\
+ \macro{S\_IFBLK} & 0060000 & device a blocchi \\
+ \macro{S\_IFDIR} & 0040000 & directory \\
+ \macro{S\_IFCHR} & 0020000 & device a caratteri \\
+ \macro{S\_IFIFO} & 0010000 & fifo \\
+ \hline
+ \macro{S\_ISUID} & 0004000 & set UID bit \\
+ \macro{S\_ISGID} & 0002000 & set GID bit \\
+ \macro{S\_ISVTX} & 0001000 & sticky bit \\
+ \hline
+% \macro{S\_IRWXU} & 00700 & bitmask per i permessi del proprietario \\
+ \macro{S\_IRUSR} & 00400 & il proprietario ha permesso di lettura \\
+ \macro{S\_IWUSR} & 00200 & il proprietario ha permesso di scrittura \\
+ \macro{S\_IXUSR} & 00100 & il proprietario ha permesso di esecuzione\\
+ \hline
+% \macro{S\_IRWXG} & 00070 & bitmask per i permessi del gruppo \\
+ \macro{S\_IRGRP} & 00040 & il gruppo ha permesso di lettura \\
+ \macro{S\_IWGRP} & 00020 & il gruppo ha permesso di scrittura \\
+ \macro{S\_IXGRP} & 00010 & il gruppo ha permesso di esecuzione \\
+ \hline
+% \macro{S\_IRWXO} & 00007 & bitmask per i permessi di tutti gli altri\\
+ \macro{S\_IROTH} & 00004 & gli altri hanno permesso di lettura \\
+ \macro{S\_IWOTH} & 00002 & gli altri hanno permesso di esecuzione \\
+ \macro{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:
+\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
+#define IS_FILE_DIR(x) (((x) & S_IFMT) & (S_IFDIR | S_IFREG))
+\end{lstlisting}
+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 membro \var{st\_size} contiene la dimensione del file in byte (se il file è
+un file normale, nel caso di un link simbolico la dimensione è quella del
+pathname che contiene).
+
+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 \secref{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
+\macro{O\_TRUNC}, ma questo è un caso particolare; per qualunque altra
+dimensione si possono usare le due funzioni \func{truncate} e
+\func{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 \var{file\_name} sia troncata ad
+ un valore massimo specificato da \var{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 \var{fd}.
+
+ \bodydesc{Le funzioni restituiscono zero in caso di successo e -1 per
+ un errore, nel qual caso \var{errno} viene settato opportunamente;
+ per \func{ftruncate} si hanno i valori:
+ \begin{errlist}
+ \item[\macro{EBADF}] \var{fd} non è un file descriptor.
+ \item[\macro{EINVAL}] \var{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[\macro{EACCES}] il file non ha permesso di scrittura o non si ha il
+ permesso di esecuzione una delle directory del pathname.
+ \item[\macro{ETXTBSY}] Il file è un programma in esecuzione.
+ \end{errlist}
+ ed anche \macro{ENOTDIR}, \macro{ENAMETOOLONG}, \macro{ENOENT},
+ \macro{EROFS}, \macro{EIO}, \macro{EFAULT}, \macro{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
+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 \var{stat} di \figref{fig:file_stat_struct}. Il significato di detti
+tempi e dei relativi campi è riportato nello schema in \ntab, dove si è 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 dell'inode; siccome esistono molte operazioni (come la
+funzione \func{link} e molte altre che vedremo in seguito) che modificano solo
+le informazioni contenute nell'inode senza toccare il file, diventa necessario
+l'utilizzo di un altro tempo.
+
+Il sistema non tiene conto dell'ultimo accesso 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 \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 \curtab.
+
+L'effetto delle varie funzioni di manipolazione dei file sui tempi è
+illustrato in \ntab. 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.
+
+\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
+ \macro{O\_CREATE} \\ \func{creat}
+ & &$\bullet$&$\bullet$& &$\bullet$&$\bullet$&
+ con \macro{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
+ \macro{O\_CREATE} \\ \func{open}
+ & &$\bullet$&$\bullet$& & & & con
+ \macro{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}
+
+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.
+
+
+\subsection{La funzione \func{utime}}
+\label{sec:file_utime}
+
+I tempi di ultimo accesso e modifica possono essere cambiati usando la
+funzione \func{utime}, il cui prototipo è:
+\begin{prototype}{utime.h}
+{int utime(const char *filename, struct utimbuf *times)}
+
+Cambia i tempi di ultimo accesso e modifica dell'inode specificato da
+\param{filename} secondo i campi \var{actime} e \var{modtime} di
+\param{times}. Se questa è \macro{NULL} allora viene usato il tempo corrente.
+
+\bodydesc{La funzione restituisce zero in caso di successo e -1 in caso
+ di errore, nel qual caso \var{errno} è settata opportunamente.
+\begin{errlist}
+\item[\macro{EACCESS}] non si ha il permesso di scrittura sul file.
+\item[\macro{ENOENT}] \param{filename} non esiste.
+\end{errlist}}
+\end{prototype}
+
+La struttura \var{utimebuf} usata da \func{utime} è definita come:
+\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
+struct utimbuf {
+ time_t actime; /* access time */
+ time_t modtime; /* modification time */
+};
+\end{lstlisting}
+
+L'effetto della funzione e i privilegi necessari per eseguirla dipendono da
+cosa è l'argomento \param{times}; se è \macro{NULL} la funzione setta 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 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 device, 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. 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 utenti e gruppi (\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 \var{stat}
+(si veda \secref{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, e sono presenti in filesystem non ancora inclusi nel kernel
+ ufficiale come \textsl{xfs}, o 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
+soffisfare 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.
+
+I restanti tre bit (noti come \acr{suid}, \acr{sgid}, e \textsl{sticky}) sono
+usati per indicare alcune caratteristiche più complesse del meccanismo del
+controllo di accesso su cui torneremo in seguito (in
+\secref{sec:file_suid_sgid} e \secref{sec:file_sticky}).
+
+Anche i permessi, come tutte le altre informazioni pertinenti al file, sono
+memorizzati nell'inode; in particolare essi sono contenuti in alcuni bit del
+campo \var{st\_mode} della struttura \func{stat} (si veda di nuovo
+\figref{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 \ntab.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|c|l|}
+ \hline
+ \textbf{\var{st\_mode}} bit & \textbf{Significato} \\
+ \hline
+ \hline
+ \macro{S\_IRUSR} & \textit{user-read}, l'utente può leggere \\
+ \macro{S\_IWUSR} & \textit{user-write}, l'utente può scrivere \\
+ \macro{S\_IXUSR} & \textit{user-execute}, l'utente può eseguire \\
+ \hline
+ \macro{S\_IRGRP} & \textit{group-read}, il gruppo può leggere \\
+ \macro{S\_IWGRP} & \textit{group-write}, il gruppo può scrivere \\
+ \macro{S\_IXGRP} & \textit{group-execute}, il gruppo può eseguire\\
+ \hline
+ \macro{S\_IROTH} & \textit{other-read}, tutti possono leggere \\
+ \macro{S\_IWOTH} & \textit{other-write}, tutti possono scrivere \\
+ \macro{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 pathname
+occorre il permesso di esecuzione in ciascuna delle directory che compongono
+il 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 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 \tabref{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 \textsl{sticky bit} settato (si veda
+\secref{sec:file_sticky}).
+
+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'\textit{effective user id},
+l'\textit{effective group id} e gli eventuali \textit{supplementary group id}
+del processo.\footnote{in realtà Linux per quanto riguarda l'accesso ai file
+ utilizza al posto degli \textit{effective id} i \textit{filesystem id} (si
+ veda \secref{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 \secref{sec:proc_perms}; normalmente, a parte quanto vedremo in
+\secref{sec:file_suid_sgid}, l'\textit{effective user id} e
+l'\textit{effective group id} corrispondono a \acr{uid} e \acr{gid}
+dell'utente che ha lanciato il processo, mentre i \textit{supplementary group
+ id} 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'\textit{effective user id} 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'\textit{effective user id} 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, etc.} bit dei permessi d'accesso dell'utente è
+ settato, l'accesso è consentito
+ \item altrimenti l'accesso è negato
+ \end{itemize*}
+\item Se l'\textit{effective group id} del processo o uno dei
+ \textit{supplementary group id} dei processi corrispondono al \acr{gid} del
+ file allora:
+ \begin{itemize*}
+ \item se il bit dei permessi d'accesso del gruppo è settato, l'accesso è
+ consentito,
+ \item altrimenti l'accesso è negato
+ \end{itemize*}
+\item se il bit dei permessi d'accesso per tutti gli altri è settato,
+ 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 \acr{suid} e \acr{sgid}}
+\label{sec:file_suid_sgid}
+
+Come si è accennato (in \secref{sec:file_perm_overview}) nei dodici bit del
+campo \var{st\_mode} di \var{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
+\macro{S\_ISUID} e \macro{S\_ISGID}.
+
+Come spiegato in dettaglio in \secref{sec:proc_exec}, quando si lancia un
+programma il comportamento normale del kernel è quello di settare
+l'\textit{effective user id} e l'\textit{effective group id} del nuovo
+processo all'\acr{uid} e al \acr{gid} del processo corrente, che normalmente
+corrispondono dell'utente con cui si è entrati nel sistema.
+
+Se però il file del programma\footnote{per motivi di sicurezza il kernel
+ ignora i bit \acr{suid} e \acr{sgid} per gli script eseguibili.} (che
+ovviamente deve essere eseguibile) ha il bit \acr{suid} settato, il kernel
+assegnerà come \textit{effective user id} al nuovo processo l'\acr{uid} del
+proprietario del file al posto dell'\acr{uid} del processo originario. Avere
+il bit \acr{sgid} settato ha lo stesso effetto sull'\textit{effective group
+ id} del processo.
+
+I bit \acr{suid} e \acr{sgid} vengono usati per permettere agli utenti normali
+di usare programmi che abbisognano di 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} settato 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 \secref{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 settare questi bit.
+Infine questi bit possono essere controllati all'interno di \var{st\_mode} con
+l'uso delle due costanti \macro{S\_ISUID} e \macro{S\_IGID}, i cui valori sono
+riportati in \tabref{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 \secref{sec:file_ownership} per una spiegazione dettagliata al
+proposito).
+
+Infine Linux utilizza il bit \acr{sgid} per una ulteriore estensione mutuata
+da SVr4. Il caso in cui un file ha il bit \acr{sgid} settato senza che lo sia
+anche il corrispondente bit di esecuzione viene utilizzato per attivare per
+quel file il \textit{mandatory locking} (argomento che affronteremo in
+dettagliopiù avanti in \secref{sec:file_mand_locking}).
+
+
+\subsection{Il bit \textsl{sticky}}
+\label{sec:file_sticky}
+
+L'ultimo dei bit rimanenti, identificato dalla costante \macro{S\_ISVTX}, è in
+parte un rimasuglio delle origini dei sistemi Unix. A quell'epoca infatti la
+memoria virtuale e l'accesso ai files erano molto meno sofisticati e per
+ottenere la massima velocità possibile per i programmi usati più comunemente
+si poteva settare questo bit.
+
+L'effetto di questo bit era che il segmento di testo del programma (si veda
+\secref{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 indicizzato direttamente in questo modo si poteva risparmiare in
+tempo di caricamento rispetto alla ricerca del file su disco. Lo
+\textsl{sticky bit} è indicato usando la lettera \cmd{t} al posto della
+\cmd{x} nei permessi per gli altri.
+
+Ovviamente per evitare che gli utenti potessero intasare la swap solo
+l'amministratore era in grado di settare 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 \textsl{sticky bit} ha
+invece assunto un uso importante per le directory;\footnote{lo \textsl{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 il bit è
+settato 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 settato è \file{/tmp}, i
+permessi infatti di solito sono settati come:
+\begin{verbatim}
+$ ls -ld /tmp
+drwxrwxrwt 6 root root 1024 Aug 10 01:03 /tmp
+\end{verbatim}%$
+in questo modo chiunque può creare file in questa directory (che infatti è
+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 degli
+altri.
+
+
+\subsection{La titolarità di nuovi file e directory}
+\label{sec:file_ownership}
+
+Vedremo in \secref{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 di presenta
+per la creazione di nuove directory (procedimento descritto in
+\secref{sec:file_dir_creat_rem}).
+
+Lo standard POSIX prescrive che l'\acr{uid} del nuovo file corrisponda
+all'\textit{effective user id} del processo che lo crea; per il \acr{gid}
+invece prevede due diverse possibilità:
+\begin{itemize*}
+\item il \acr{gid} del file corrisponde all'\textit{effective group id} 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} settato 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 sottodirectory. 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 di default di \func{mkdir}, ed è in
+questo modo ad esempio che Debian assicura che le sottodirectory create nelle
+home di un utente restino sempre con il \acr{gid} del gruppo primario dello
+stesso.
+
+
+\subsection{La funzione \func{access}}
+\label{sec:file_access}
+
+Come visto in \secref{sec:file_access_control} il controllo di accesso ad un
+file viene fatto usando \textit{effective user id} e \textit{effective group
+ id} del processo; ma ci sono casi in cui è necessario effettuare il
+controllo usando il \textit{real user id} ed il \textit{real group id} (cioè
+\acr{uid} e \acr{gid} dell'utente che ha lanciato il programma, e che, come
+accennato in \secref{sec:file_suid_sgid} e spiegato in
+\secref{sec:proc_perms}, non è detto siano uguali agli \textit{effective id}).
+Per far questo si può usare la funzione \func{access}, il cui prototipo è:
+\begin{prototype}{unistd.h}
+{int access(const char *pathname, int mode)}
+
+Verifica i permessi di accesso, indicati da \var{mode}, per il file indicato
+da \var{pathname}.
+
+\bodydesc{La funzione ritorna 0 se l'accesso è consentito, -1 altrimenti; in
+ quest'ultimo caso la variabile \var{errno} viene settata secondo i codici di
+ errore: \macro{EACCES}, \macro{EROFS}, \macro{EFAULT}, \macro{EINVAL},
+ \macro{ENAMETOOLONG}, \macro{ENOENT}, \macro{ENOTDIR}, \macro{ELOOP},
+ \macro{EIO}.}
+\end{prototype}
+
+I valori possibili per l'argomento \param{mode} sono esprimibili come
+combinazione delle costanti numeriche riportate in \ntab\ (attraverso un OR
+binario). I primi tre valori implicano anche la verifica dell'esistenza del
+file, se si vuole verificare solo quest'ultima si può usare \macro{F\_OK}, o
+anche direttamente \func{stat}. In caso \var{pathname} si riferisca ad un link
+simbolico 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{\var{mode}} & \textbf{Significato} \\
+ \hline
+ \hline
+ \macro{R\_OK} & verifica il permesso di lettura \\
+ \macro{W\_OK} & verifica il permesso di scritture \\
+ \macro{X\_OK} & verifica il permesso di esecuzione \\
+ \macro{F\_OK} & verifica l'esistenza del file \\
+ \hline
+ \end{tabular}
+ \caption{Valori possibile per il parametro \var{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 esmepio attraverso
+l'uso del \acr{suid} bit) che vuole controllare se l'utente originale ha i
+permessi per accedere ad un certo file.
+
+
+\subsection{Le funzioni \func{chmod} e \func{fchmod}}
+\label{sec:file_chmod}
+
+Per cambiare i permessi di un file il sistema mette ad disposizione due
+funzioni \func{chmod} e \func{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 \var{path} al valore indicato da \var{mode}.
+
+ \funcdecl{int fchmod(int fd, mode\_t mode)} Analoga alla precedente, ma usa
+ il file descriptor \var{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[\macro{EPERM}] L'\textit{effective user id} non corrisponde a quello
+ del proprietario del file o non è zero.
+ \end{errlist}
+ ed inoltre \macro{EROFS} e \macro{EIO}; \func{chmod} restituisce anche
+ \macro{EFAULT}, \macro{ENAMETOOLONG}, \macro{ENOENT}, \macro{ENOMEM},
+ \macro{ENOTDIR}, \macro{EACCES}, \macro{ELOOP}; \func{fchmod} anche
+ \macro{EBADF}.}
+\end{functions}
+
+I valori possibili per \var{mode} sono indicati in \ntab. I valori possono
+esser combinati con l'OR binario delle relative costanti simboliche, o
+specificati direttamente, come per l'analogo comando di shell, con il valore
+numerico (la shell lo vuole in ottale, dato che i bit dei permessi sono
+divisibili in gruppi di tre). 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 \acr{suid} il valore da fornire sarebbe $4755$.
+
+\begin{table}[!htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|c|c|l|}
+ \hline
+ \textbf{\var{mode}} & \textbf{Valore} & \textbf{Significato} \\
+ \hline
+ \hline
+ \macro{S\_ISUID} & 04000 & set user ID \\
+ \macro{S\_ISGID} & 02000 & set group ID \\
+ \macro{S\_ISVTX} & 01000 & sticky bit \\
+ \hline
+ \macro{S\_IRWXU} & 00700 & l'utente ha tutti i permessi \\
+ \macro{S\_IRUSR} & 00400 & l'utente ha il permesso di lettura \\
+ \macro{S\_IWUSR} & 00200 & l'utente ha il permesso di scrittura \\
+ \macro{S\_IXUSR} & 00100 & l'utente ha il permesso di esecuzione \\
+ \hline
+ \macro{S\_IRWXG} & 00070 & il gruppo ha tutti i permessi \\
+ \macro{S\_IRGRP} & 00040 & il gruppo ha il permesso di lettura \\
+ \macro{S\_IWGRP} & 00020 & il gruppo ha il permesso di scrittura \\
+ \macro{S\_IXGRP} & 00010 & il gruppo ha il permesso di esecuzione \\
+ \hline
+ \macro{S\_IRWXO} & 00007 & gli altri hanno tutti i permessi \\
+ \macro{S\_IROTH} & 00004 & gli altri hanno il permesso di lettura \\
+ \macro{S\_IWOTH} & 00002 & gli altri hanno il permesso di scrittura \\
+ \macro{S\_IXOTH} & 00001 & gli altri hanno il permesso di esecuzione \\
+ \hline
+ \end{tabular}
+ \caption{I valori delle costanti usate per indicare i permessi dei file.}
+ \label{tab:file_permission_const}
+\end{table}
+
+Il cambiamento dei permessi di un file attraverso queste funzioni ha comunque
+alcune limitazioni, provviste per motivi di sicurezza. Questo significa che
+anche se si è proprietari del file non tutte le operazioni sono permesse, in
+particolare:
+\begin{enumerate}
+\item siccome solo l'amministratore può settare lo \textit{sticky bit}, se
+ l'\textit{effective user id} del processo non è zero esso viene
+ automaticamente cancellato (senza notifica di errore) qualora sia stato
+ indicato in \var{mode}.
+\item per via della semantica SVr4 nella creazione dei nuovi file, si può
+ avere il caso in cui il file creato da un processo è assegnato a un gruppo
+ per il quale il processo non ha privilegi. Per evitare che si possa
+ assegnare il bit \acr{sgid} ad un file appartenente a un gruppo per cui
+ non si hanno diritti, questo viene automaticamente cancellato (senza
+ notifica di errore) da \var{mode} qualora il gruppo del file non corrisponda
+ a quelli associati al processo (la cosa non avviene quando
+ l'\textit{effective user id} del processo è zero).
+\end{enumerate}
+
+Per alcuni filesystem\footnote{il filesystem \acr{ext2} supporta questa
+ caratteristica, che è mutuata da BSD.} è inoltre prevista una ulteriore
+misura di sicurezza, volta a scongiurare l'abuso dei bit \acr{suid} e
+\acr{sgid}; essa consiste nel cancellare automaticamente questi bit qualora un
+processo che non appartenga all'amministratore scriva su un file. In questo
+modo anche se un utente malizioso scopre un file \acr{suid} su cui può
+scrivere, un'eventuale modifica comporterà la perdita di ogni ulteriore
+privilegio.
+
+\subsection{La funzione \func{umask}}
+\label{sec:file_umask}
+
+Oltre che dai valori indicati in sede di creazione, i permessi assegnati ai
+nuovi file sono controllati anche da una maschera di bit settata con la
+funzione \func{umask}, il cui prototipo è:
+\begin{prototype}{stat.h}
+{mode\_t umask(mode\_t mask)}
+
+ Setta la maschera dei permessi dei bit al valore specificato da \var{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}
+
+Questa maschera è una caratteristica di ogni processo\footnote{è infatti
+ contenuta nel campo \var{umask} di \var{fs\_struct}, vedi
+ \figref{fig:proc_task_struct}.} e viene utilizzata per impedire che alcuni
+permessi possano essere assegnati ai nuovi file in sede di creazione. I bit
+indicati nella maschera vengono infatti esclusi quando un nuovo file viene
+creato.
+
+In genere questa maschera serve per impostare un default che escluda alcuni
+permessi (usualmente quello di scrittura per il gruppo e gli altri,
+corrispondente ad un valore di $022$). Essa è utile perché le routine
+dell'interfaccia ANSI C degli stream non prevedono l'esistenza dei permessi, e
+pertanto tutti i nuovi file vengono sempre creati con un default di $666$
+(cioè permessi di lettura e scrittura per tutti, si veda
+\tabref{tab:file_permission_const} per un confronto); in questo modo è
+possibile cancellare automaticamente i permessi non voluti, senza doverlo fare
+esplicitamente.
+
+In genere il valore di \func{umask} viene stabilito una volta per tutte al
+login a $022$, e di norma gli utenti non hanno motivi per modificarlo. Se però
+si vuole che un processo possa creare un file che chiunque possa leggere
+allora occorrerà cambiare il valore di \func{umask}.
+
+
+\subsection{Le funzioni \func{chown}, \func{fchown} e \func{lchown}}
+\label{sec:file_chown}
+
+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 e i loro prototipi sono i seguenti:
+\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 \var{owner} e \var{group}.
+
+ \bodydesc{Le funzioni restituiscono zero in caso di successo e -1 per
+ un errore, in caso di errore \var{errno} viene settato ai valori:
+ \begin{errlist}
+ \item[\macro{EPERM}] L'\textit{effective user id} 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 \macro{EROFS} e
+ \macro{EIO}; \func{chown} restituisce anche \macro{EFAULT},
+ \macro{ENAMETOOLONG}, \macro{ENOENT}, \macro{ENOMEM}, \macro{ENOTDIR},
+ \macro{EACCES}, \macro{ELOOP}; \func{fchown} anche \macro{EBADF}.}
+\end{functions}
+
+In Linux soltanto l'amministratore 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 a cui appartiene.
+
+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 \var{owner} e \var{group} i valori restano immutati.
+
+Quando queste funzioni sono chiamate con successo da un processo senza i
+privilegi di root entrambi i bit \acr{suid} e \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 \textit{mandatory locking}.