Sticky bit!

diff --git a/filedir.tex b/filedir.tex
index 4a18d3ebb9b2701f32d7260eea1dd21428c0bcaf..3b13ce8cbf633e3191f5cfcf25e7ee2e72c68f6a 100644 (file)
--- a/filedir.tex
+++ b/filedir.tex
@@ -198,28 +198,29 @@ tutti gli altri non vengono controllati.
 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} e \textsl{sgid}.
+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 corrispondono dell'utente
-con cui si è entrati nel sistema.
+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} (o \textit{set-user-ID bit}) settato al posto dell'uid del
-processo originario il kernel assegnerà come \textit{effective user id} al
-nuovo processo l'uid del proprietario del file.  Analogamente avere il bit
-\textsl{sgid} (o \textit{set-group-ID bit}) settato ha lo stesso effetto
-sull'\textit{effective group id}. 
+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 è necessairo chiamare l'amministratore per
-cambiare la propria pasword. Infatti il comando \cmd{passwd} appartiene a root
+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.
 
@@ -228,17 +229,19 @@ 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}).
 
-I due bit suid e sgid possono essere controllati all'interno di \var{st\_mode}
-con l'uso delle due costanti \macro{S\_ISUID} e \macro{S\_ISGID}, definite in
-\tabref{tab:filedir_file_mode_flags}. I file possono essere identificati con
-il comando \cmd{ls -l} in quanto presentano 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.
+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, in questo caso infatti linux usa la convezione di SVR4 per indicare
-con questi bit l'uso della semantica BSD nella creazione di nuovi file
-(si veda \secref{sec:filedir_ownership}). 
+directory, normalmente infatti linux usa la convezione di SVR4 per indicare
+con questi bit l'uso della semantica BSD nella creazione di nuovi file (si
+veda \secref{sec:filedir_ownership}).
 
 Infine il caso in cui il file abbia il bit \textsl{sgid} settato ma non il
 corrispondente bit per l'esecuzione viene utilizzato per attivare per quel
@@ -249,11 +252,51 @@ file il \textit{mandatory locking} (argomento affrontato nei dettagli in
 \subsection{Il bit \textsl{sticky}}
 \label{sec:filedir_sticky}
 
-L'ultimo 
+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 è 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 possano intasare la swap solo
+l'amministratore è in grado di settare questo bit, che venne poi 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.
+
+Benché ormai non venga più utilizzato per i file, lo \textsl{sticky bit} ha
+invece assunto un uso corrente per le directory\footnote{lo \textsl{sticky
+    bit} è una estensione non definita nello standard POSIX, linux la
+  supporta, così come BSD e SRV4}, se il bit è settato infatti un file può
+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}
+il 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, o crearne di
+nuovi, ma solo l'utente che ha creato un file nella directory potrà
+cancellarlo o rinominarlo.
 
 \subsection{La titolarità di nuovi file e directory}
 \label{sec:filedir_ownership}
 
+Come spiegato in \secref{} per creare un nuovo file in una directory occorre
+avere il permesso di scrittura, ma 
+
 
 \subsection{La funzione \texttt{access}}
 \label{sec:filedir_access}