+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 (che ovviamente deve essere
+eseguibile\footnote{per motivi di sicurezza il kernel ignora i bit \acr{suid}
+ e \acr{sgid} per gli script eseguibili.}) ha il bit \acr{suid} impostato, il
+kernel assegnerà come 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} impostato senza che lo
+sia anche il corrispondente bit di esecuzione viene utilizzato per attivare
+per quel file il \textit{mandatory locking} (affronteremo questo argomento in
+dettaglio più 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 tale bit è
+impostato un file potrà essere rimosso dalla directory soltanto se l'utente ha
+il permesso di scrittura su di essa ed inoltre è vera una delle seguenti
+condizioni:
+\begin{itemize*}
+\item l'utente è proprietario del file
+\item l'utente è proprietario della directory
+\item l'utente è l'amministratore
+\end{itemize*}
+un classico esempio di directory che ha questo bit impostato è \file{/tmp}, i
+permessi infatti di solito sono 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 groupid 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 \cmd{mkdir}, ed è in
+questo modo ad esempio che Debian assicura che le sottodirectory create nella
+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)}