+
+\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
+assunto un uso corrente per le directory\footnote{lo \textsl{sticky bit} per
+ le directory è 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}
+$ ls -ld /tmp
+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, così si può evitare 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} come creare nuovi file, ma se è
+possibile specificare in sede di creazione quali permessi applicare ad un
+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:file_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 \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 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 una maggiore
+possibilità di scelta, ma per ottenere lo stesso risultato necessita che per
+le nuove directory venga anche propagato anche il bit \acr{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 \acr{gid} del gruppo primario dello stesso.
+
+
+\subsection{La funzione \func{access}}
+\label{sec:file_access}
+
+Come detto 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 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:file_suid_sgid} e spiegato in \secref{sec:proc_perms} non è
+detto sia uguale all'\textit{effective user id}). Per far questo si può usare
+la funzione \func{access}, il cui prototipo è: