Riorganizzate varie parti, rimetto in linea la nuova versione
[gapil.git] / filedir.tex
index cbd718b..1f0edcd 100644 (file)
@@ -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
-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,
@@ -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
-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}).
@@ -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
-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:
@@ -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
-  \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,
-  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
@@ -203,22 +190,22 @@ processo appartiene ad un gruppo appropriato, in questo caso i permessi per
 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
-\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
-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
@@ -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).
 
-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}).
@@ -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
-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}
-\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
-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}}
@@ -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
-  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
@@ -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
-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}.