Riorganizzate varie parti, rimetto in linea la nuova versione

[gapil.git] / filedir.tex

diff --git a/filedir.tex b/filedir.tex
index cbd718bdc7582cb4c0d1f567a5405e8aba1ac1bc..1f0edcd66b40e82a0c62684b45025bd8aeb4170a 100644 (file)
--- a/filedir.tex
+++ b/filedir.tex
@@ -34,7 +34,7 @@ controllo di accesso molto pi
 
 Ad ogni file unix associa sempre l'utente che ne è proprietario (il cosiddetto
 \textit{owner}) e il gruppo di appartenenza, secondo il meccanismo degli
 
 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
+identificatori di utenti e gruppi (\acr{uid} e \acr{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:file_stat}). Ad ogni file
 viene inoltre associato un insieme di permessi che sono divisi in tre classi,
 sono accessibili da programma tramite i campi \var{st\_uid} e \var{st\_gid}
 della struttura \var{stat} (si veda \secref{sec:file_stat}). Ad ogni file
 viene inoltre associato un insieme di permessi che sono divisi in tre classi,


@@ -47,7 +47,7 @@ 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
 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
+gli altri.  I restanti tre bit (\acr{suid}, \acr{sgid}, e

 \textsl{sticky}) sono usati per indicare alcune caratteristiche più complesse
 su cui torneremo in seguito (vedi \secref{sec:file_suid_sgid} e
 \secref{sec:file_sticky}).
 \textsl{sticky}) sono usati per indicare alcune caratteristiche più complesse
 su cui torneremo in seguito (vedi \secref{sec:file_suid_sgid} e
 \secref{sec:file_sticky}).


@@ -149,22 +149,9 @@ del processo.
 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'\textit{effective user id} e
 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'\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}.
+l'\textit{effective group id} corrispondono a \acr{uid} e \acr{gid}
+dell'utente che ha lanciato il processo, mentre i \textit{supplementary group
+  id} 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:
 
 I passi attraverso i quali viene stabilito se il processo possiede il diritto
 di accesso sono i seguenti:


@@ -184,15 +171,15 @@ di accesso sono i seguenti:
   \item altrimenti l'accesso è negato
   \end{itemize}
 \item Se l'\textit{effective group id} del processo o uno dei
   \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:
+  \textit{supplementary group id} dei processi corrispondono al \acr{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,
   \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.
+  l'accesso è consentito, altrimenti l'accesso è negato.

 \end{itemize}
 
 Si tenga presente che questi passi vengono eseguiti esattamente in
 \end{itemize}
 
 Si tenga presente che questi passi vengono eseguiti esattamente in


@@ -203,22 +190,22 @@ processo appartiene ad un gruppo appropriato, in questo caso i permessi per
 tutti gli altri non vengono controllati.
 
 
 tutti gli altri non vengono controllati.
 
 

-\subsection{I bit \textsl{suid} e \textsl{sgid}}
+\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} 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
 \label{sec:file_suid_sgid}
 
 Come si è accennato (in \secref{sec:file_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
+\acr{suid} (o \textit{set-user-ID bit}) e \acr{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:proc_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
 \textit{set-group-ID bit}) che sono identificati dalle constanti
 \macro{S\_ISUID} e \macro{S\_ISGID}.
 
 Come spiegato in dettaglio in \secref{sec:proc_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.
+processo all'\acr{uid} e al \acr{gid} 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
 
 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


@@ -258,8 +245,8 @@ 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).
 
 veda \secref{sec:file_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
+Infine Linux utilizza il bit \acr{sgid} per una ulteriore estensione
+mutuata da SVR4. Il caso in cui il file abbia il bit \acr{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}).
 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}).


@@ -322,26 +309,28 @@ 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
 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 gid invece
-prevede due diverse possibilità:
+all'\textit{effective user id} del processo che lo crea; per il \acr{gid}
+invece prevede due diverse possibilità:

 \begin{itemize}
 \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.
+\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
 \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
-\textsl{sgid} settato allora viene usata la seconda opzione..
+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 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.
+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 \texttt{access}}
 
 
 \subsection{La funzione \texttt{access}}


@@ -489,7 +478,7 @@ particolare:
 \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
 \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
+  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
   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


@@ -591,8 +580,8 @@ Un'altra estensione rispetto allo standard POSIX 
 valore per \var{owner} e \var{group} i valori restano immutati. 
 
 Quando queste funzioni sono chiamate con successo da un processo senza i
 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 \textsl{suid} e \textsl{sgid} vengono
-cancellati. Questo non avviene per il bit \textsl{sgid} nel caso in cui esso
+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}.
 
 sia usato (in assenza del corrispondente permesso di esecuzione) per indicare
 che per il file è attivo il \textit{mandatory locking}.