+\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 \tabref{tab:file_bit_perm}.
+
+\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} impostato (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'userid effettivo, il groupid
+effettivo e gli eventuali groupid supplementari del processo.\footnote{in
+ realtà Linux, per quanto riguarda l'accesso ai file, utilizza gli gli
+ identificatori del gruppo \textit{filesystem} (si ricordi quanto esposto in
+ \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'userid effettivo e il groupid effectivo
+corrispondono ai valori dell'\acr{uid} e del \acr{gid} dell'utente che ha
+lanciato il processo, mentre i groupid 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'userid 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'userid 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, etc.} bit dei permessi d'accesso dell'utente è
+ impostato, l'accesso è consentito
+ \item altrimenti l'accesso è negato
+ \end{itemize*}
+\item Se il groupid effettivo del processo o uno dei groupid 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 \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 impostare gli
+identificatori del gruppo \textit{effective} del nuovo processo al valore dei
+corrispondenti del gruppo \textit{real} 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} impostato, il kernel
+assegnerà come userid 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 groupid effettivo 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} 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 \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 impostare 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} impostare 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 impostare 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 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 \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 è
+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 impostati 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'userid 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 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 predefinito 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 utilizzando l'userid ed il groupid effettivo del processo; ci
+sono casi però in cui si può voler effettuare il controllo con l'userid reale
+ed il groupid 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
+\secref{sec:file_suid_sgid} e spiegato in dettaglio in
+\secref{sec:proc_perms}, non è detto siano uguali a quelli effettivi. 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 \param{mode}, per il file indicato
+da \param{pathname}.
+
+\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[\macro{EINVAL}] il valore di \param{mode} non è valido.
+ \item[\macro{EACCES}] l'accesso al file non è consentito, o non si ha il
+ permesso di attraversare una delle directory di \param{pathname}.
+ \item[\macro{EROFS}] si è richiesto l'accesso in scrittura per un file su un
+ filesystem montato in sola lettura.
+ \end{errlist}
+ ed inoltre \macro{EFAULT}, \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
+\tabref{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 \macro{F\_OK}, o anche
+direttamente \func{stat}. Nel caso in cui \var{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{\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 esempio 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'userid effettivo 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
+\tabref{tab:file_permission_const}. 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ò impostare lo \textit{sticky bit}, se
+ l'userid effettivo 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'userid effettivo 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 impostata con la
+funzione \func{umask}, il cui prototipo è:
+\begin{prototype}{stat.h}
+{mode\_t umask(mode\_t mask)}
+
+ Imposta 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 valore predefinito dei
+permessi che ne escluda alcuni (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 valore 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} può assumere i valori:
+ \begin{errlist}
+ \item[\macro{EPERM}] L'userid 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 \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}.