X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=filedir.tex;h=c1bb182b55d93865bc3f79cbd79ec761be294b10;hp=d1d8606e0b6daa1513fd28cda53ddafa996b6c99;hb=96e11f1878552c4c4f245448e9dc6d66e1658542;hpb=247c7ba624f39b283f9e85816c0616348f39c1b6

diff --git a/filedir.tex b/filedir.tex
index d1d8606..c1bb182 100644
--- a/filedir.tex
+++ b/filedir.tex
@@ -53,7 +53,7 @@ rispetto agli altri.
 Per aggiungere un nome ad un inode si utilizza la funzione \func{link}; si
 suole chiamare questo tipo di associazione un collegamento diretto (o
 \textit{hard link}).  Il prototipo della funzione e le sue caratteristiche
-principali, come risultano dalla man page, sono le seguenti:
+principali, come risultano dalla pagina di manuale, sono le seguenti:
 \begin{prototype}{unistd.h}
 {int link(const char *oldpath, const char *newpath)}
   Crea un nuovo collegamento diretto al file indicato da \var{oldpath}
@@ -480,7 +480,7 @@ suo prototipo 
   \begin{errlist}
   \item[\macro{EPERM}] Il filesystem non supporta la cancellazione di
     directory, oppure la directory che contiene \var{dirname} ha lo sticky bit
-    impostato e l'\textit{effective user id} del processo non corrisponde al
+    impostato e l'userid effettivo del processo non corrisponde al
     proprietario della directory.
   \item[\macro{EACCESS}] Non c'è il permesso di scrittura per la directory che
     contiene la directory che si vuole cancellare, o non c'è il permesso di
@@ -920,10 +920,10 @@ su un file, su un link simbolico e su un file descriptor.
 
 La struttura \var{stat} usata da queste funzioni è definita nell'header
 \file{sys/stat.h} e in generale dipende dall'implementazione, la versione
-usata da Linux è mostrata in \nfig, così come riportata dalla man page di
-\func{stat} (in realtà la definizione effettivamente usata nel kernel dipende
-dall'architettura e ha altri campi riservati per estensioni come tempi più
-precisi, o per il padding dei campi).
+usata da Linux è mostrata in \nfig, così come riportata dalla pagina di
+manuale di \func{stat} (in realtà la definizione effettivamente usata nel
+kernel dipende dall'architettura e ha altri campi riservati per estensioni
+come tempi più precisi, o per il padding dei campi).
 
 \begin{figure}[!htb]
   \footnotesize
@@ -1467,29 +1467,29 @@ in una directory con lo \textsl{sticky bit} impostato (si veda
 La procedura con cui il kernel stabilisce se un processo possiede un certo
 permesso (di lettura, scrittura o esecuzione) si basa sul confronto fra
 l'utente e il gruppo a cui il file appartiene (i valori di \var{st\_uid} e
-\var{st\_gid} accennati in precedenza) e l'\textit{effective user id},
-l'\textit{effective group id} e gli eventuali \textit{supplementary group id}
-del processo.\footnote{in realtà Linux per quanto riguarda l'accesso ai file
-  utilizza al posto degli \textit{effective id} i \textit{filesystem id} (si
-  veda \secref{sec:proc_perms}), ma essendo questi del tutto equivalenti ai
-  primi, eccetto il caso in cui si voglia scrivere un server NFS, ignoreremo
-  questa differenza.}
+\var{st\_gid} accennati in precedenza) e l'userid effettivo, il groupid
+effettivo e gli eventuali groupid supplementari del processo.\footnote{in
+  realtà Linux, per quanto riguarda l'accesso ai file, utilizza gli gli
+  identificatori del gruppo \textit{filesystem} (si ricordi quanto esposto in
+  \secref{sec:proc_perms}), ma essendo questi del tutto equivalenti ai primi,
+  eccetto il caso in cui si voglia scrivere un server NFS, ignoreremo questa
+  differenza.}
 
 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 \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.
+\secref{sec:file_suid_sgid}, l'userid effettivo e il groupid effectivo
+corrispondono ai valori dell'\acr{uid} e del \acr{gid} dell'utente che ha
+lanciato il processo, mentre i groupid supplementari 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:
 \begin{enumerate}
-\item Se l'\textit{effective user id} del processo è zero (corrispondente
+\item Se l'userid effettivo del processo è zero (corrispondente
   all'amministratore) l'accesso è sempre garantito senza nessun ulteriore
   controllo. Per questo motivo \textsl{root} ha piena libertà di accesso a
   tutti i file.
-\item Se l'\textit{effective user id} del processo è uguale all'\acr{uid} del
+\item Se l'userid effettivo del processo è uguale all'\acr{uid} del
   proprietario del file (nel qual caso si dice che il processo è proprietario
   del file) allora:
   \begin{itemize*}
@@ -1499,9 +1499,8 @@ di accesso sono i seguenti:
     impostato, l'accesso è consentito
   \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 \acr{gid} del
-  file allora:
+\item Se il groupid effettivo del processo o uno dei groupid supplementari dei
+  processi corrispondono al \acr{gid} del file allora:
   \begin{itemize*}
   \item se il bit dei permessi d'accesso del gruppo è impostato, l'accesso è
     consentito, 
@@ -1531,18 +1530,17 @@ sono i bit detti \acr{suid} (da \textit{set-user-ID bit}) e \acr{sgid} (da
 \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
-l'\textit{effective user id} e l'\textit{effective group id} del nuovo
-processo all'\acr{uid} e al \acr{gid} del processo corrente, che normalmente
+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\footnote{per motivi di sicurezza il kernel
   ignora i bit \acr{suid} e \acr{sgid} per gli script eseguibili.} (che
 ovviamente deve essere eseguibile) ha il bit \acr{suid} impostato, il kernel
-assegnerà come \textit{effective user id} 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 sull'\textit{effective group
-  id} del processo.
+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 è
@@ -1640,11 +1638,10 @@ 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'\textit{effective user id} del processo che lo crea; per il \acr{gid}
-invece prevede due diverse possibilità:
+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 all'\textit{effective group id} del
-  processo.
+\item il \acr{gid} del file corrisponde al group id effettivo del processo.
 \item il \acr{gid} del file corrisponde al \acr{gid} della directory in cui
   esso è creato.
 \end{itemize*}
@@ -1669,13 +1666,13 @@ stesso.
 \label{sec:file_access}
 
 Come visto 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 è necessario effettuare il
-controllo usando il \textit{real user id} ed il \textit{real group id} (cioè
-\acr{uid} e \acr{gid} dell'utente che ha lanciato il programma, e che, come
-accennato in \secref{sec:file_suid_sgid} e spiegato in
-\secref{sec:proc_perms}, non è detto siano uguali agli \textit{effective id}).
-Per far questo si può usare la funzione \func{access}, il cui prototipo è:
+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)}
 
@@ -1683,18 +1680,20 @@ Verifica i permessi di accesso, indicati da \var{mode}, per il file indicato
 da \var{pathname}.
   
 \bodydesc{La funzione ritorna 0 se l'accesso è consentito, -1 altrimenti; in
-  quest'ultimo caso la variabile \var{errno} viene impostata secondo i codici di
-  errore: \macro{EACCES}, \macro{EROFS}, \macro{EFAULT}, \macro{EINVAL},
+  quest'ultimo caso la variabile \var{errno} viene impostata secondo i codici
+  di errore: \macro{EACCES}, \macro{EROFS}, \macro{EFAULT}, \macro{EINVAL},
   \macro{ENAMETOOLONG}, \macro{ENOENT}, \macro{ENOTDIR}, \macro{ELOOP},
   \macro{EIO}.}
 \end{prototype}
 
 I valori possibili per l'argomento \param{mode} sono esprimibili come
-combinazione delle costanti numeriche riportate in \ntab\ (attraverso un OR
-binario). I primi tre valori implicano anche la verifica dell'esistenza del
-file, se si vuole verificare solo quest'ultima si può usare \macro{F\_OK}, o
-anche direttamente \func{stat}. In caso \var{pathname} si riferisca ad un link
-simbolico il controllo è fatto sul file a cui esso fa riferimento.
+combinazione delle costanti numeriche riportate in
+\tabref{tab:file_access_mode_val} (attraverso un OR binario delle stesse). I
+primi tre valori implicano anche la verifica dell'esistenza del file, se si
+vuole verificare solo quest'ultima si può usare \macro{F\_OK}, o anche
+direttamente \func{stat}. Nel caso in cui \var{pathname} si riferisca ad un
+link simbolico, questo viene seguito ed il controllo è fatto sul file a cui
+esso fa riferimento.
 
 La funzione controlla solo i bit dei permessi di accesso, si ricordi che il
 fatto che una directory abbia permesso di scrittura non significa che ci si
@@ -1722,7 +1721,7 @@ contrario (o di errore) ritorna -1.
 \end{table}
 
 Un esempio tipico per l'uso di questa funzione è quello di un processo che sta
-eseguendo un programma coi privilegi di un altro utente (ad esmepio attraverso
+eseguendo un programma coi privilegi di un altro utente (ad esempio attraverso
 l'uso del \acr{suid} bit) che vuole controllare se l'utente originale ha i
 permessi per accedere ad un certo file.
 
@@ -1746,8 +1745,8 @@ filename e su un file descriptor, i loro prototipi sono:
   \bodydesc{Le funzioni restituiscono zero in caso di successo e -1 per
     un errore, in caso di errore \var{errno} può assumere i valori:
   \begin{errlist}
-  \item[\macro{EPERM}] L'\textit{effective user id} non corrisponde a quello
-    del proprietario del file o non è zero.
+  \item[\macro{EPERM}] L'userid effettivo non corrisponde a quello del
+    proprietario del file o non è zero.
   \end{errlist}
   ed inoltre \macro{EROFS} e \macro{EIO}; \func{chmod} restituisce anche
   \macro{EFAULT}, \macro{ENAMETOOLONG}, \macro{ENOENT}, \macro{ENOMEM},
@@ -1755,15 +1754,16 @@ filename e su un file descriptor, i loro prototipi sono:
   \macro{EBADF}.}
 \end{functions}
 
-I valori possibili per \var{mode} sono indicati in \ntab. I valori possono
-esser combinati con l'OR binario delle relative costanti simboliche, o
-specificati direttamente, come per l'analogo comando di shell, con il valore
-numerico (la shell lo vuole in ottale, dato che i bit dei permessi sono
-divisibili in gruppi di tre). Ad esempio i permessi standard assegnati ai
-nuovi file (lettura e scrittura per il proprietario, sola lettura per il
-gruppo e gli altri) sono corrispondenti al valore ottale $0644$, un programma
-invece avrebbe anche il bit di esecuzione attivo, con un valore di $0755$, se
-si volesse attivare il bit \acr{suid} il valore da fornire sarebbe $4755$.
+I valori possibili per \var{mode} sono indicati in
+\tabref{tab:file_permission_const}. I valori possono esser combinati con l'OR
+binario delle relative costanti simboliche, o specificati direttamente, come
+per l'analogo comando di shell, con il valore numerico (la shell lo vuole in
+ottale, dato che i bit dei permessi sono divisibili in gruppi di tre). Ad
+esempio i permessi standard assegnati ai nuovi file (lettura e scrittura per
+il proprietario, sola lettura per il gruppo e gli altri) sono corrispondenti
+al valore ottale $0644$, un programma invece avrebbe anche il bit di
+esecuzione attivo, con un valore di $0755$, se si volesse attivare il bit
+\acr{suid} il valore da fornire sarebbe $4755$.
 
 \begin{table}[!htb]
   \centering
@@ -1803,17 +1803,17 @@ anche se si 
 particolare:
 \begin{enumerate}
 \item siccome solo l'amministratore può impostare lo \textit{sticky bit}, se
-  l'\textit{effective user id} del processo non è zero esso viene
-  automaticamente cancellato (senza notifica di errore) qualora sia stato
-  indicato in \var{mode}.
+  l'userid effettivo del processo non è zero esso viene automaticamente
+  cancellato (senza notifica di errore) qualora sia stato indicato in
+  \var{mode}.
 \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 \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
-  l'\textit{effective user id} del processo è zero).
+  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 l'userid effettivo del
+  processo è zero).
 \end{enumerate}
 
 Per alcuni filesystem\footnote{il filesystem \acr{ext2} supporta questa
@@ -1884,8 +1884,8 @@ sono tre e i loro prototipi sono i seguenti:
   \bodydesc{Le funzioni restituiscono zero in caso di successo e -1 per
     un errore, in caso di errore \var{errno} viene impostata ai valori:
   \begin{errlist}
-  \item[\macro{EPERM}] L'\textit{effective user id} non corrisponde a quello
-    del proprietario del file o non è zero, o utente e gruppo non sono validi
+  \item[\macro{EPERM}] L'userid effettivo non corrisponde a quello del
+    proprietario del file o non è zero, o utente e gruppo non sono validi
   \end{errlist}
   Oltre a questi entrambe restituiscono gli errori \macro{EROFS} e
   \macro{EIO}; \func{chown} restituisce anche \macro{EFAULT},
@@ -1949,7 +1949,7 @@ radice con la funzione \func{chroot}, il cui prototipo 
 \bodydesc{La funzione restituisce zero in caso di successo e -1 per
     un errore, in caso di errore \var{errno} viene impostata ai valori:
   \begin{errlist}
-  \item[\macro{EPERM}] L'\textit{effective user id} non è zero.
+  \item[\macro{EPERM}] L'userid effettivo del processo non è zero.
   \end{errlist}
   ed inoltre \macro{EFAULT}, \macro{ENAMETOOLONG}, \macro{ENOENT},
   \macro{ENOMEM}, \macro{ENOTDIR}, \macro{EACCES}, \macro{ELOOP};