+file e directory, ed in particolare esamineremo come è strutturato il sistema
+base di protezioni e controllo di accesso ai file, e tutta l'interfaccia che
+permette la manipolazione dei vari attributi di file e directory. Tutto quello
+che riguarda invece la manipolazione del contenuto dei file è lasciato ai
+capitoli successivi.
+
+
+
+\section{Il controllo di accesso ai file}
+\label{sec:filedir_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:filedir_perm_overview}
+
+Il controllo di accesso ai file in unix segue un modello abbastanza semplice,
+ma adatto alla gran parte delle esigenze, in cui si dividono i permessi su tre
+livelli. Si tenga conto poi che quanto diremo è vero solo per filesystem di
+tipo unix, e non è detto che sia applicabile a un filesystem
+qualunque\footnote{ed infatti non è vero per il filesystem vfat di Windows,
+ per il quale i permessi vengono assegnati in maniera fissa con un opzione in
+ fase di montaggio}. Esistono inoltre estensioni che permettono di
+implementare le ACL (\textit{Access Control List}) che sono un meccanismo di
+controllo di accesso molto più sofisticato.
+
+Ad ogni file unix associa sempre l'utente che ne è proprietario (il cosiddetto
+\textit{owner}) e il gruppo di appartenenza, secondo il meccanismo degli
+identificatori di utenti e gruppi (\textsl{uid} e \textsl{gid}). Questi valori
+sono accessibili da programma tramite i campi \var{st\_uid} e \var{st\_gid}
+della struttura \var{stat} (si veda \secref{sec:filedir_stat}). Ad ogni file
+viene inoltre associato un insieme di permessi che sono divisi in tre classi,
+e cioè attribuiti rispettivamente all'utente proprietario del file, a un
+qualunque utente faccia parte del gruppo cui appartiene il file, e a tutti gli
+altri utenti.
+
+I permessi, così come vengono presi dai comandi e dalle routine di sistema,
+sono espressi da un numero di 12 bit; di questi i nove meno significativi sono
+usati a gruppi di tre per indicare i permessi base di lettura, scrittura ed
+esecuzione (indicati nei comandi di sistema con le lettere \cmd{w}, \cmd{r} e
+\cmd{x}) ed applicabili rispettivamente al proprietario, al gruppo, a tutti
+gli altri. I restanti tre bit (\textsl{suid}, \textsl{sgid}, e
+\textsl{sticky}) sono usati per indicare alcune caratteristiche più complesse
+su cui torneremo in seguito (vedi \secref{sec:filedir_suid_sgid} e
+\secref{sec:filedir_sticky}).
+
+Anche i permessi, come tutte le altre informazioni generali, sono tenuti per
+ciascun file nell'inode; in particolare essi sono contenuti in alcuni bit
+del campo \var{st\_mode} della struttura letta da \func{stat} (di nuovo si veda
+\secref{sec:filedir_stat} per i dettagli).
+
+In genere ci si riferisce a questo raggruppamento dei permessi 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
+ \var{st\_mode} bit & 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}
+
+Questi permessi vengono usati in maniera diversa dalle varie funzioni, e a
+seconda che si riferiscano a file, link simbolici o 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, e 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 ha il significato
+specifico 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} (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 di
+sola lettura (\macro{O\_RDONLY}) o di lettura-scrittura (\macro{O\_RDWR}) e
+leggerne il contenuto. Avere il permesso di scrittura consente di aprire un
+file in sola scrittura (\macro{O\_WRONLY}) o lettura-scrittura
+(\macro{O\_RDWR}) e modificarne il contenuto, lo stesso permesso è necessario
+per poter troncare il file con l'opzione \macro{O\_TRUNC}.
+
+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 fisica del file), 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 rifermento).
+
+Per poter eseguire un file (che sia un programma compilato od uno script di
+shell), occorre il permesso di esecuzione per il medesimo, 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 \cmd{ls} per un link simbolico riporta
+tutti i permessi come concessi; utente e gruppo a cui esso appartiene vengono
+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:filedir_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.
+
+Per una spiegazione dettagliata degli identificatori associati ai processi si
+veda \secref{sec:prochand_perms}; normalmente, a parte quanto vedremo in
+\secref{sec:filedir_suid_sgid}, l'\textit{effective user id} e
+l'\textit{effective group id} corrispondono a uid e gid dell'utente che ha
+lanciato il processo, mentre i \textit{supplementary group id} sono quelli dei
+gruppi cui l'utente appartiene.
+
+% Quando un processo cerca l'accesso al file esso controlla i propri uid e gid
+% confrontandoli con quelli del file e se l'operazione richiesta è compatibile
+% con i permessi associati al file essa viene eseguita, altrimenti viene
+% bloccata ed è restituito un errore di \texttt{EPERM}. Questo procedimento non
+% viene eseguito per l'amministratore di sistema (il cui uid è zero) il quale
+% a
+% pertanto accesso senza restrizione a qualunque file del sistema.
+
+% In realtà il procedimento è più complesso di quanto descritto in maniera
+% elementare qui; inoltre ad un processo sono associati diversi identificatori,
+% torneremo su questo in maggiori dettagli in seguito in
+% \secref{sec:proc_perms}.
+
+I passi attraverso i quali viene stabilito se il processo possiede il diritto
+di accesso sono i seguenti:
+\begin{itemize}
+\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'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 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{itemize}
+
+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 \textsl{suid} e \textsl{sgid}}
+\label{sec:filedir_suid_sgid}
+
+Come si è accennato (in \secref{sec:filedir_perm_overview}) nei dodici bit del
+campo \var{st\_mode} 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
+\textsl{suid} (o \textit{set-user-ID bit}) e \textsl{sgid} (o
+\textit{set-group-ID bit}) che sono identificati dalle constanti
+\macro{S\_ISUID} e \macro{S\_ISGID}.
+
+Come spiegato in dettaglio in \secref{sec:prochand_exec}, quando si lancia un
+programma il comportamendo normale del kernel è quello di settare
+l'\textit{effective user id} e l'\textit{effective group id} del nuovo
+processo all'uid e al gid del processo corrente, che normalmente corrispondono
+dell'utente con cui si è entrati nel sistema.
+
+Se però il file del programma (che ovviamente deve essere eseguibile) ha il
+bit \textsl{suid} settato, il kernel assegnerà come \textit{effective user id}
+al nuovo processo l'uid del proprietario del file al posto dell'uid del
+processo originario. Avere il bit \textsl{sgid} settato ha lo stesso effetto
+sull'\textit{effective group id} del processo.
+
+I bit \textsl{suid} e \textsl{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 suid bit 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 (torneremo sull'argomento in
+\secref{sec:prochand_perms}) per evitare che possano essere usati per
+guadagnare privilegi non consentiti.
+
+La presenza dei bit \textsl{suid} e \textsl{sgid} su un file può essere
+rilevata con il comando \cmd{ls -l}, in tal caso comparirà la 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:filedir_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:filedir_ownership} per una spiegazione dettagliata al
+proposito).
+
+Infine Linux utilizza il bit \textsl{sgid} per una ulteriore estensione
+mutuata da SVR4. Il caso in cui il file abbia il bit \textsl{sgid} settato ma
+non il corrispondente bit di esecuzione viene utilizzato per attivare per
+quel file il \textit{mandatory locking} (argomento che affronteremo nei
+dettagli in \secref{sec:xxx_mandatory_lock}).
+
+
+\subsection{Il bit \textsl{sticky}}
+\label{sec:filedir_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
+mecchina (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.
+
+Ovviamente per evitare che gli utenti potessero intasare la swap solo
+l'amministratore era in grado di settare questo bit, che venne chiamato anche
+\textit{saved text bit}, da cui deriva il nome della costante. Le attuali
+implementazioni di memoria virtuale e filesystem rendono sostanzialmente
+inutile questo procedimento. Lo \textsl{sticky bit} è indicato attraverso la
+lettera \cmd{t} al posto della \cmd{x} nei permessi per gli altri.
+
+Benché ormai non venga più utilizzato per i file, lo \textsl{sticky bit} ha
+assunto un uso corrente per le directory\footnote{lo \textsl{sticky bit} è una
+ 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 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}
+drwxrwxrwt 6 root root 1024 Aug 10 01:03 /tmp
+\end{verbatim}
+in questo modo chiunque può leggere, scrivere ed eseguire i file temporanei
+ivi memorizzati, sia crearne di nuovi, ma solo l'utente che ha creato un file
+nella directory potrà cancellarlo o rinominarlo, evitando così che utente
+possa, più o meno consapevolemnte, cancellare i file degli altri.
+
+
+\subsection{La titolarità di nuovi file e directory}
+\label{sec:filedir_ownership}
+
+Vedremo in \secref{sec:fileunix_base_func} quali sono le funzioni per creare
+nuovi file, ma se è possibile specificare in sede di creazione quali permessi
+applicare ad un nuovo file, 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:filedir_dir_creat_rem}).
+
+Lo standard POSIX prescrive che l'uid del nuovo file corrisponda
+all'\textit{effective user id} del processo che lo crea; per il gid invece
+prevede due diverse possibilità:
+\begin{itemize}
+\item il gid del file corrisponde all'\textit{effective group id} del processo
+\item il gid del file corrisponde al 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 gid
+del processo, se però la directory in cui viene creato il file ha il bit sgid
+settato allora viene usata la seconda opzione..
+
+Usare la semantica BSD ha il vantaggio che il gid viene sempre automaticamente
+propagato, restando coerente a quello della directory di partenza, in tutte le
+sottodirectory. La semantica SVR4 offre una maggiore possibilità di scelta, ma
+per ottenere lo stesso risultato necessita che per le nuove directory venga
+anche propagato anche il bit sgid. Questo è comunque 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 gid
+del gruppo primario dello stesso.
+
+
+\subsection{La funzione \texttt{access}}
+\label{sec:filedir_access}
+
+Come detto in \secref{sec:filedir_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 si può voler effettuare il
+controllo usando il \textit{real user id} e il \textit{real group id} (cioè
+l'uid dell'utente che ha lanciato il programma, che, come accennato in
+\secref{sec:filedir_suid_sgid} e spiegato in \secref{sec:prochand_perms} non è
+detto sia uguale all'\textit{effective user 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)}
+
+ La funzione verifica i permessi di accesso, indicati da \var{mode}, per il
+ file indicato da \var{pathname}.
+
+ La funzione ritorna 0 se l'accesso è consentito, -1 altrimenti; in
+ quest'utlimo caso la variabile \texttt{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 il parametro \var{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'ultimaa 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
+ \begin{tabular}{|c|l|}
+ \hline
+ \var{mode} & 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:filedir_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 (attraverso l'uso del
+suid bit) che vuole controllare se l'utente originale ha i permessi per
+accedere ad un certo file.
+
+
+\subsection{Le funzioni \texttt{chmod} e \texttt{fchmod}}
+\label{sec:filedir_chmod}
+
+Per cambiare i permessi di un file il sistema mette ad disposizione due
+funzioni, che operano rispettivamente su un filename e su un file descriptor,
+i cui 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.
+
+ Le funzioni restituiscono zero in caso di successo e -1 per un errore, in
+ caso di errore \texttt{errno} viene settato ai valori:
+ \begin{errlist}
+ \item \macro{EPERM} L'\textit{effective user id} non corrisponde a quello
+ del proprietario del file o non è zero.
+ \end{errlist}
+ Oltre a questi entrambe restituiscono gli errori \macro{EROFS} e
+ \macro{EIO}; \func{chmod} restituisce anche \macro{EFAULT},
+ \macro{ENAMETOOLONG}, \macro{ENOENT}, \macro{ENOMEM}, \macro{ENOTDIR},
+ \macro{EACCES}, \macro{ELOOP}; \func{chmod} 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 macro, o specificati
+direttamente, come per l'analogo comando di shell, con il valore ottale. 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 suid
+il valore da fornire sarebbe $4755$.
+
+\begin{table}[!htb]
+ \centering
+ \begin{tabular}[c]{|c|c|l|}
+ \hline
+ \var{mode} & Valore & 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:filedir_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{itemize}
+\item siccome solo l'amministratore può settare lo \textit{sticky bit} se 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 \textsl{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{itemize}
+
+Per alcuni filesystem\footnote{il filesystem \textsl{ext2} supporta questa
+ caratteristica, che è mutuata da BSD.} è inoltre prevista una ulteriore
+misura di sicurezza, volta ad scongiurare l'abuso dei bit \textsl{suid} e
+\textsl{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 \textsl{suid} su cui può
+scrivere, un eventuale modifica comporterà la perdita di ogni ulteriore
+privilegio.
+
+
+\subsection{La funzione \texttt{umask}}
+\label{sec:filedir_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).
+
+ 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 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:filedir_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, 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 \texttt{chown}, \texttt{fchown} e \texttt{lchown}}
+\label{sec:filedir_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 questioni
+sono tre e i loro prototipi sono i seguenti:
+
+\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.
+
+ Le funzioni restituiscono zero in caso di successo e -1 per un errore, in
+ caso di errore \texttt{errno} viene settato ai valori:
+ \begin{errlist}
+ \item \macro{EPERM} L'\textit{effective user id} non corrisponde a quello
+ del proprietario del file o non è zero.
+ \end{errlist}
+ Oltre a questi entrambe restituiscono gli errori \macro{EROFS} e
+ \macro{EIO}; \func{chmod} restituisce anche \macro{EFAULT},
+ \macro{ENAMETOOLONG}, \macro{ENOENT}, \macro{ENOMEM}, \macro{ENOTDIR},
+ \macro{EACCES}, \macro{ELOOP}; \func{chmod} anche \macro{EBADF}.
+\end{functions}
+
+
+
+
+
+
+
+
+
+
+
+
+%La struttura fondamentale che contiene i dati essenziali relativi ai file è il
+%cosiddetto \textit{inode}; questo conterrà informazioni come il
+%tipo di file (file di dispositivo, directory, file di dati, per un elenco
+%completo vedi \ntab), i permessi (vedi \secref{sec:file_perms}), le date (vedi
+%\secref{sec:file_times}).
+