Revisione di buona parte di filedir.tex
authorSimone Piccardi <piccardi@gnulinux.it>
Wed, 24 Oct 2001 22:19:50 +0000 (22:19 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Wed, 24 Oct 2001 22:19:50 +0000 (22:19 +0000)
filedir.tex
fileintro.tex
gapil.tex

index 9f3689d38d705135eca538ede7adb64d14fb24db..ab50dc299d1af9f2af4434e6bf18acf28cde1e67 100644 (file)
 \label{cha:files_and_dirs}
 
 In questo capitolo tratteremo in dettaglio le modalità con cui si gestiscono
-file e directory, ed in particolare esamineremo come è strutturato il sistema
-base di protezioni e controllo di accesso ai file, e tutta l'interfaccia che
-permette la manipolazione dei vari attributi di file e directory. Tutto quello
-che riguarda invece la manipolazione del contenuto dei file è lasciato ai
-capitoli successivi.
+file e directory, iniziando dalle funzioni di libreria che si usano per
+copiarli, spostarli e cambiarne i nomi. Esamineremo poi l'interfaccia che
+permette la manipolazione dei vari attributi di file e directory ed alla
+finefaremo una trattazione dettagliata su come è strutturato il sistema base
+di protezioni e controllo di accesso ai file e sulle funzioni che ne
+permettono la gestione. Tutto quello che riguarda invece la manipolazione del
+contenuto dei file è lasciato ai capitoli successivi.
 
 
 
-\section{Il controllo di accesso ai file}
-\label{sec:file_access_control}
+\section{La manipolazione di file e directory}
 
-Una delle caratteristiche fondamentali di tutti i sistemi unix-like è quella
-del controllo di accesso ai file, che viene implementato per qualunque
-filesystem standard. In questa sezione ne esamineremo i concetti essenziali e
-le funzioni usate per gestirne i vari aspetti.
+Come già accennato in \secref{sec:file_filesystem} in un sistema unix-like la
+gestione dei file ha delle caratteristiche specifiche che derivano
+direttamente dall'architettura del sistema; in questa sezione esamineremo le
+funzioni usate per manipolazione nel filesytem di file e directory, per la
+creazione di link simbolici e diretti, per la gestione e la lettura delle
+directory; mettendo in evidenza le conseguenze della struttura standard della
+gestione dei file in un sistema unix-like, già accennate al capitolo
+precedente.
 
 
-\subsection{I permessi per l'accesso ai file}
-\label{sec:file_perm_overview}
+\subsection{Le funzioni \func{link} e \func{unlink}}
+\label{sec:file_link}
 
-Il controllo di accesso ai file in unix segue un modello abbastanza semplice
-(ma adatto alla gran parte delle esigenze) in cui si dividono i permessi su
-tre livelli. Si tenga conto poi che quanto diremo è vero solo per filesystem
-di tipo unix, e non è detto che sia applicabile a un filesystem
-qualunque\footnote{ed infatti non è vero per il filesystem vfat di Windows,
-  per il quale i permessi vengono assegnati in maniera fissa con un opzione in
-  fase di montaggio}.  Esistono inoltre estensioni che permettono di
-implementare le ACL (\textit{Access Control List}) che sono un meccanismo di
-controllo di accesso molto più sofisticato.
+Una caratteristica comune a diversi sistemi operativi è quella di poter creare
+dei nomi fittizi (come gli alias del MacOS o i collegamenti di Windows) che
+permettono di fare riferiremento allo stesso file, chiamandolo con nomi
+diversi o accedendovi da directory diverse.
 
-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 (\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,
-e cioè attribuiti rispettivamente all'utente proprietario del file, a un
-qualunque utente faccia parte del gruppo cui appartiene il file, e a tutti gli
-altri utenti.
+Questo è possibile anche in ambiente unix, dove tali collegamenti sono
+usualmente chiamati \textit{link}, ma data la struttura del sistema di
+gestione dei file (ed in particolare quanto trattato in
+\secref{sec:file_architecture}) ci sono due metodi sostanzialmente diversi per
+fare questa operazione.
 
-I permessi, così come vengono presi dai comandi e dalle routine di sistema,
-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 (\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}).
+Come spiegato in \secref{sec:file_filesystem} l'accesso al contenuto di
+un file su disco avviene attraverso il suo inode, e il nome che si trova in
+una directory è solo una etichetta associata ad un puntatore a che fa
+riferimento al suddetto inode.
 
-Anche i permessi, come tutte le altre informazioni generali, sono tenuti per
-ciascun file nell'inode; in particolare essi sono contenuti in alcuni bit
-del campo \var{st\_mode} della struttura letta da \func{stat} (di nuovo si veda
-\secref{sec:file_stat} per i dettagli).
 
-In genere ci si riferisce a questo raggruppamento dei permessi usando le
-lettere \cmd{u} (per \textit{user}), \cmd{g} (per \textit{group}) e \cmd{o}
-(per \textit{other}), inoltre se si vuole indicare tutti i raggruppamenti
-insieme si usa la lettera \cmd{a} (per \textit{all}). Si tenga ben presente
-questa distinzione dato che in certi casi, mutuando la terminologia in uso nel
-VMS, si parla dei permessi base come di permessi per \textit{owner},
-\textit{group} ed \textit{all}, le cui iniziali possono dar luogo a confusione.
-Le costanti che permettono di accedere al valore numerico di questi bit nel
-campo \var{st\_mode} sono riportate in \ntab.
+Questo significa che la realizzazione di un link è immediata in quanto uno
+stesso file può avere tanti nomi diversi allo stesso tempo, dati da
+altrettante diverse associazioni allo stesso inode; si noti poi che nessuno di
+questi nomi viene ad assumere una particolare preferenza rispetto agli altri.
 
-\begin{table}[htb]
-  \centering
-    \footnotesize
-  \begin{tabular}[c]{|c|l|}
-    \hline
-    \textbf{\var{st\_mode}} bit & \textbf{Significato} \\
-    \hline 
-    \hline 
-    \macro{S\_IRUSR}  &  \textit{user-read}, l'utente può leggere     \\
-    \macro{S\_IWUSR}  &  \textit{user-write}, l'utente può scrivere   \\
-    \macro{S\_IXUSR}  &  \textit{user-execute}, l'utente può eseguire \\ 
-    \hline              
-    \macro{S\_IRGRP}  &  \textit{group-read}, il gruppo può leggere    \\
-    \macro{S\_IWGRP}  &  \textit{group-write}, il gruppo può scrivere  \\
-    \macro{S\_IXGRP}  &  \textit{group-execute}, il gruppo può eseguire\\
-    \hline              
-    \macro{S\_IROTH}  &  \textit{other-read}, tutti possono leggere    \\
-    \macro{S\_IWOTH}  &  \textit{other-write}, tutti possono scrivere  \\
-    \macro{S\_IXOTH}  &  \textit{other-execute}, tutti possono eseguire\\
-    \hline              
-  \end{tabular}
-  \caption{I bit dei permessi di accesso ai file, come definiti in 
-    \texttt{<sys/stat.h>}}
-  \label{tab:file_bit_perm}
-\end{table}
+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:
+\begin{prototype}{unistd.h}
+{int link(const char * oldpath, const char * newpath)}
+  Crea un nuovo collegamento diretto al file indicato da \var{oldpath}
+  dandogli nome \var{newpath}.
+  
+  La funzione restituisce zero in caso di successo e -1 in caso di errore. La
+  variabile \var{errno} viene settata opportunamente, i principali codici di
+  errore sono:
+  \begin{errlist}
+  \item \macro{EXDEV} \var{oldpath} e \var{newpath} non sono sullo
+    stesso filesystem.
+  \item \macro{EPERM} il filesystem che contiene \var{oldpath} e
+    \macro{newpath} non supporta i link diretti o è una directory.
+  \item \macro{EEXIST} un file (o una directory) con quel nome esiste di
+    già.
+  \item \macro{EMLINK} ci sono troppi link al file \var{oldpath} (il
+    numero massimo è specificato dalla variabile \macro{LINK\_MAX}, vedi
+    \secref{sec:xxx_limits}).
+  \end{errlist}
+  ed inoltre \macro{EACCES}, \macro{ENAMETOOLONG}, \macro{ENOTDIR},
+  \macro{EFAULT}, \macro{ENOMEM}, \macro{EROFS}, \macro{ELOOP},
+  \macro{ENOSPC}, \macro{EIO}.
+\end{prototype}
 
-Questi permessi vengono usati in maniera diversa dalle varie funzioni, e a
-seconda che si riferiscano a file, link simbolici o directory, qui ci
-limiteremo ad un riassunto delle regole generali, entrando nei dettagli più
-avanti.
+La creazione di un nuovo collegamento diretto non copia il contenuto del file,
+ma si limita a creare una voce nella directory specificata con \var{newpath} e
+ad aumentare di uno il numero di referenze al file (riportato nel campo
+\var{st\_nlink} della struttura \var{stat}, vedi \secref{sec:file_stat})
+aggiungendo il nuovo nome ai precedenti. Si noti che uno stesso file può
+essere così chiamato con vari nomi in diverse directory.
+Per quanto dicevamo in \secref{sec:file_filesystem} la creazione di un
+collegamento diretto è possibile solo se entrambi i pathname sono nello stesso
+filesystem; inoltre il filesystem deve supportare i collegamenti diretti (il
+mneccanismo non è disponibile ad esempio con il filesystem \acr{vfat} di
+Windows). 
+
+La funzione inoltre opera sia sui file ordinari che sugli altri oggetti del
+filesystem, con l'eccezione delle directory. In alcuni sistemi solo
+l'amministratore è in grado di creare un collegamento diretto ad un'altra
+directory, questo viene fatto perché con una tale operazione è possibile
+creare dei circoli nel filesystem (vedi l'esempio mostrato in
+\secref{sec:file_symlink}, dove riprenderemo il discorso) che molti programmi
+non sono in grado di gestire e la cui rimozione diventerebbe estremamente
+complicata (in genere occorre far girare il programma \cmd{fsck} per riparare
+il filesystem). 
+
+Data la pericolosità di questa operazione e la disponibilità dei link
+simbolici che possono fornire la stessa funzionalità senza questi problemi,
+nei filesystem usati in Linux questa caratteristica è stata completamente
+disabilitata, e al tentativo di creare un link diretto ad una directory la
+funzione restituisce l'errore \macro{EPERM}.
+
+La rimozione di un file (o più precisamente della voce che lo referenzia
+all'interno di una directory) si effettua con la funzione \func{unlink}; il
+suo prototipo è il seguente:
 
-La prima regola è che per poter accedere ad un file attraverso il suo pathname
-occorre il permesso di esecuzione in ciascuna delle directory che compongono
-il pathname, e lo stesso vale per aprire un file nella directory corrente (per
-la quale appunto serve il diritto di esecuzione).
+\begin{prototype}{unistd.h}{int unlink(const char * pathname)}
+  Cancella il nome specificato dal pathname nella relativa directory e
+  decrementa il numero di riferimenti nel relativo inode. Nel caso di link
+  simbolico cancella il link simbolico; nel caso di socket, fifo o file di
+  dispositivo rimuove il nome, ma come per i file i processi che hanno aperto
+  uno di questi oggetti possono continuare ad utilizzarlo.
+  
+  La funzione restituisce zero in caso di successo e -1 per un errore, nel
+  qual caso il file non viene toccato. La variabile \var{errno} viene
+  settata secondo i seguenti codici di errore:
+  \begin{errlist}
+  \item \macro{EISDIR} \var{pathname} si riferisce ad una directory
+    (valore specifico ritornato da Linux che non consente l'uso di
+    \var{unlink} con le directory, e non conforme allo standard POSIX, che
+    prescrive invece l'uso di \macro{EPERM} in caso l'operazione non sia
+    consentita o il processo non abbia privilegi sufficienti).
+  \item \macro{EROFS} \var{pathname} è su un filesystem montato in sola
+  lettura.
+  \item \macro{EISDIR} \var{pathname} fa riferimento a una directory.
+  \end{errlist}
+  ed inoltre: \macro{EACCES}, \macro{EFAULT}, \macro{ENOENT}, \macro{ENOTDIR},
+  \macro{ENOMEM}, \macro{EROFS}, \macro{ELOOP}, \macro{EIO}.
 
-Per una directory infatti il permesso di esecuzione ha il significato
-specifico che essa può essere attraversata nella risoluzione del pathname, ed
-è distinto dal permesso di lettura che invece implica che si può leggere il
-contenuto della directory. Questo significa che se si ha il permesso di
-esecuzione senza permesso di lettura si potrà lo stesso aprire un file in una
-directory (se si hanno i permessi opportuni per il medesimo) ma non si potrà
-vederlo con \cmd{ls} (per crearlo occorrerà anche il permesso di scrittura per
-la directory).
+\end{prototype}
 
-Avere il permesso di lettura per un file consente di aprirlo con le opzioni di
-sola lettura (\macro{O\_RDONLY}) o di lettura/scrittura (\macro{O\_RDWR}) e
-leggerne il contenuto. Avere il permesso di scrittura consente di aprire un
-file in sola scrittura (\macro{O\_WRONLY}) o lettura/scrittura
-(\macro{O\_RDWR}) e modificarne il contenuto, lo stesso permesso è necessario
-per poter troncare il file con l'opzione \macro{O\_TRUNC}.
+Per cancellare una voce in una directory è necessario avere il permesso di
+scrittura su di essa (dato che si va a rimuovere una voce dal suo contenuto) e
+il diritto di esecuzione sulla directory che la contiene (torneremo in
+dettaglio sui permessi e gli attributi in \secref{sec:file_access_control}),
+se inoltre lo \textit{sticky} bit è settato occorrerà anche essere proprietari
+del file o proprietari della directory (o root, per cui nessuna delle
+restrizioni è applicata).
 
-Non si può creare un file fintanto che non si disponga del permesso di
-esecuzione e di quello di scrittura per la directory di destinazione; gli
-stessi permessi occorrono per cancellare un file da una directory (si ricordi
-che questo non implica necessariamente la rimozione del contenuto del file dal
-disco), non è necessario nessun tipo di permesso per il file stesso (infatti
-esso non viene toccato, viene solo modificato il contenuto della directory,
-rimuovendo la voce che ad esso fa rifermento).
+Una delle caratteristiche di queste funzioni è che la creazione/rimozione
+della nome dalla directory e l'incremento/decremento del numero di riferimenti
+nell'inode deve essere una operazione atomica (cioè non interrompibile da
+altri processi), per questo entrambe queste funzioni sono realizzate tramite
+una singola system call.
 
-Per poter eseguire un file (che sia un programma compilato od uno script di
-shell, od un altro tipo di file eseguibile riconosciuto dal kernel), occorre
-avere il permesso di esecuzione, inoltre solo i file regolari possono essere
-eseguiti.
+Si ricordi infine che il file non viene eliminato dal disco fintanto che tutti
+i riferimenti ad esso sono stati cancellati, solo quando il \textit{link
+  count} mantenuto nell'inode diventa zero lo spazio occupato viene rimosso. A
+questo però si aggiunge una altra condizione, e cioè che non ci siano processi
+che abbiano detto file aperto.  
 
-I permessi per un link simbolico sono ignorati, contano quelli del file a cui
-fa riferimento; per questo in genere \cmd{ls} per un link simbolico riporta
-tutti i permessi come concessi; utente e gruppo a cui esso appartiene vengono
-ignorati quando il link viene risolto, vengono controllati solo quando viene
-richiesta la rimozione del link e quest'ultimo è in una directory con lo
-\textsl{sticky bit} settato (si veda \secref{sec:file_sticky}).
+Questa proprietà viene spesso usata per essere sicuri di non lasciare file
+temporanei su disco in caso di crash dei programmi; la tecnica è quella di
+aprire il file e chiamare \func{unlink} subito dopo, in questo modo il
+contenuto del file è sempre disponibile all'interno del processo attraverso il
+suo file descriptor (vedi \secref{sec:file_fd}) fintanto che il processo non
+chiude il file, ma non ne resta traccia in nessuna directory, e lo spazio
+occupato su disco viene immediatamente rilasciato alla conclusione del
+processo (quando tutti i file vengono chiusi).
 
-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}.
 
-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.
+\subsection{Le funzioni \func{remove} e \func{rename}}
+\label{sec:file_remove}
 
-I passi attraverso i quali viene stabilito se il processo possiede il diritto
-di accesso sono i seguenti:
-\begin{itemize}
-\item Se l'\textit{effective user id} 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'uid del
-  proprietario del file (nel qual caso si dice che il processo è proprietario
-  del file) allora:
-  \begin{itemize}
-  \item se il relativo\footnote{per relativo si intende il bit di user-read se
-      il processo vuole accedere in scrittura, quello di user-write per
-      l'accesso in scrittura, etc.} bit dei permessi d'accesso dell'utente è
-    settato, 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:
-  \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.
-\end{itemize}
+Al contrario di quanto avviene con altri unix in Linux non è possibile usare
+\func{unlink} sulle directory, per cancellare una directory si può usare la
+funzione \func{rmdir} (vedi \secref{sec:file_dir_creat_rem}), oppure la
+funzione \func{remove}. Questa è la funzione prevista dallo standard ANSI C
+per cancellare un file o una directory (e funziona anche per i sistemi che non
+supportano i link diretti), che per i file è identica alla \func{unlink} e per
+le directory è identica alla \func{rmdir}:
 
-Si tenga presente che questi passi vengono eseguiti esattamente in
-quest'ordine. Questo vuol dire che se un processo è il proprietario di un file
-l'accesso è consentito o negato solo sulla base dei permessi per l'utente; i
-permessi per il gruppo non vengono neanche controllati; lo stesso vale se il
-processo appartiene ad un gruppo appropriato, in questo caso i permessi per
-tutti gli altri non vengono controllati.
+\begin{prototype}{stdio.h}{int remove(const char *pathname)}
+  Cancella un nome dal filesystem. Usa \func{unlink} per i file e
+  \func{rmdir} per le directory.
+  
+  La funzione restituisce zero in caso di successo e -1 per un errore, nel
+  qual caso il file non viene toccato. Per i codici di errori vedi quanto
+  riportato nelle descrizioni di \func{unlink} e \func{rmdir}.
+\end{prototype}
 
+Per cambiare nome ad un file (o a una directory) si usa invece la funzione
+\func{rename}\footnote{la funzione è definita dallo standard ANSI C solo per i
+  file, POSIX estende la funzione anche alle directory}, il cui prototipo è:
 
-\subsection{I bit \acr{suid} e \acr{sgid}}
-\label{sec:file_suid_sgid}
+\begin{prototype}{stdio.h}
+{int rename(const char *oldpath, const char *newpath)}
+  Rinomina un file, spostandolo fra directory diverse quando richiesto.
+  
+  La funzione restituisce zero in caso di successo e -1 per un errore, nel
+  qual caso il file non viene toccato. La variabile \var{errno} viene settata
+  secondo i seguenti codici di errore:
+  \begin{errlist} 
+  \item \macro{EISDIR} \var{newpath} è una directory mentre \var{oldpath} non
+    è una directory.
+  \item \macro{EXDEV} \var{oldpath} e \var{newpath} non sono sullo stesso
+    filesystem.
+  \item \macro{ENOTEMPTY} \var{newpath} è una directory già esistente e non
+    vuota.
+  \item \macro{EBUSY} o \var{oldpath} o \var{newpath} sono in uso da parte di
+    qualche processo (come directory di lavoro o come root) o del sistema
+    (come mount point).
+  \item \macro{EINVAL} \var{newpath} contiene un prefisso di \var{oldpath} o
+    più in generale si è cercato di creare una directory come sottodirectory
+    di se stessa.
+  \item \macro{EMLINK} \var{oldpath} ha già il massimo numero di link
+    consentiti o è una directory e la directory che contiene \var{newpath} ha
+    già il massimo numero di link.
+  \item \macro{ENOTDIR} Uno dei componenti dei pathname non è una directory o
+    \var{oldpath} è una directory e \var{newpath} esiste e non è una
+    directory.
+  \item \macro{EPERM} le directory contenenti \var{oldpath} o \var{newpath}
+    hanno lo sticky bit attivo e i permessi del processo non consentono
+    rispettivamente la cancellazione e la creazione del file, o il filesystem
+    non supporta i link.
+  \end{errlist} 
+  ed inoltre \macro{EACCESS}, \macro{ENOENT}, \macro{ENOMEM}, \macro{EROFS},
+  \macro{ELOOP} e \macro{ENOSPC}.
+\end{prototype}
 
-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
-\acr{suid} (o \textit{set-user-ID bit}) e \acr{sgid} (o
-\textit{set-group-ID bit}) che sono identificati dalle costanti
-\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 settare
-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
-corrispondono dell'utente con cui si è entrati nel sistema.
+il vantaggio nell'uso
+di questa funzione al posto della chiamata successiva di \func{link} e
+\func{unlink} è che l'operazione è eseguita atomicamente, e non c'è un momento
+in cui il file su disco presenta ad un altro processo un diverso numero di
+collegamenti diretti. Inoltre in questo modo non c'è modo che il nuovo nome
+esista senza essere connesso all'inode; se si ha un crollo del sistema durante
+l'esecuzione può essere possibile che entrambi i nomi esistano, ma il nuovo
+nome quando esiste, è sempre connesso al file.
 
-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} 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
-\acr{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 è necessario chiamare l'amministratore per
-cambiare la propria password. Infatti il comando \cmd{passwd} appartiene a
-root ma ha il bit suid settato per cui quando viene lanciato da un utente
-normale parte con i privilegi di root.
-
-Chiaramente avere un processo che ha privilegi superiori a quelli che avrebbe
-normalmente l'utente che lo ha lanciato comporta vari rischi, e questo tipo di
-programmi devono essere scritti accuratamente per evitare che possano essere
-usati per guadagnare privilegi non consentiti (torneremo sull'argomento in
-\secref{sec:proc_perms}).
-
-La presenza dei bit \acr{suid} e \acr{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:file_mode_flags}.
-
-Gli stessi bit vengono ad assumere in significato completamente diverso per le
-directory, normalmente infatti Linux usa la convenzione di SVR4 per indicare
-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 \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}).
-
-
-\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.
 
+L'effetto è diverso a seconda che si voglia spostare un file o una directory;
+se ci riferisce a un file allora \var{newpath} deve essere una di
 
-\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..
+\subsection{I link simbolici}
+\label{sec:file_symlink}
 
-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.
+Siccome la funzione \func{link} crea riferimenti agli inodes, essa può
+funzionare soltanto per file che risiedono sullo stesso filesystem, dato che
+in questo caso è garantita l'unicità dell'inode, e solo per un filesystem di
+tipo unix.  Inoltre in Linux non è consentito eseguire un link diretto ad una
+directory.
 
+Per ovviare a queste limitazioni i sistemi unix supportano un'altra forma di
+link (i cosiddetti \textit{soft link} o \textit{symbolic link}), che sono,
+come avviene in altri sistemi operativi, dei file che contengono il
+semplicemente il riferimento ad un altro file (o directory). In questo modo è
+possibile effettuare link anche attraverso filesystem diversi e a directory, e
+pure a file che non esistono ancora.
 
-\subsection{La funzione \texttt{access}}
-\label{sec:file_access}
+Il sistema funziona in quanto i link simbolici sono contrassegnati come tali
+al kernel (analogamente a quanto avviene per le directory) per cui la chiamata
+ad una \var{open} o una \var{stat} su un link simbolico comporta la lettura
+del contenuto del medesimo e l'applicazione della funzione al file specificato
+da quest'ultimo. Invece altre funzioni come quelle per cancellare o rinominare
+i file operano direttamente sul link simbolico (per l'elenco vedi \ntab).
+Inoltre esistono funzioni apposite, come la \func{readlink} e la \func{lstat}
+per accedere alle informazioni del link invece che a quelle del file a cui
+esso fa riferimento.
 
-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 è:
+Le funzioni per operare sui link simbolici sono le seguenti, esse sono tutte
+dichiarate nell'header file \file{unistd.h}.
 
 \begin{prototype}{unistd.h}
-{int access(const char *pathname, int mode)}
-
-  La funzione verifica i permessi di accesso, indicati da \var{mode}, per il
-  file indicato da \var{pathname}. 
+{int symlink(const char * oldname, const char * newname)}
+  Crea un nuovo link simbolico al file indicato da \var{oldname} dandogli
+  nome \func{newname}.
   
-  La funzione ritorna 0 se l'accesso è consentito, -1 altrimenti; in
-  quest'ultimo caso la variabile \texttt{errno} viene settata secondo i codici
-  di errore: \macro{EACCES}, \macro{EROFS}, \macro{EFAULT}, \macro{EINVAL},
-  \macro{ENAMETOOLONG}, \macro{ENOENT}, \macro{ENOTDIR}, \macro{ELOOP},
-  \macro{EIO}.
+  La funzione restituisce zero in caso di successo e -1 per un errore, in caso
+  di errore. La variabile \var{errno} viene settata secondo i codici di
+  errore standard di accesso ai file (trattati in dettaglio in
+  \secref{sec:file_access_control}) ai quali si aggiungono i seguenti:
+  \begin{errlist}
+  \item \macro{EEXIST} Un file (o una directory) con quel nome esiste di
+    già.
+  \item \macro{EROFS} La directory su cui si vuole inserire il nuovo link è
+    su un filesystem montato in sola lettura.
+  \item \macro{ENOSPC} La directory o il filesystem in cui si vuole creare il
+    link è piena e non c'è ulteriore spazio disponibile.
+  \item \macro{ELOOP} Ci sono troppi link simbolici nella risoluzione di
+    \var{oldname} o di \var{newname}.
+  \end{errlist}
 \end{prototype}
 
+Dato che la funzione \func{open} segue i link simbolici, è necessaria usare
+un'altra funzione quando si vuole leggere il contenuto di un link simbolico,
+questa funzione è la:
 
-I valori possibili per il parametro \var{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.
-
-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
-possa scrivere come in un file, e il fatto che un file abbia permesso di
-esecuzione non comporta che contenga un programma eseguibile. La funzione
-ritorna zero solo se tutte i permessi controllati sono disponibili, in caso
-contrario (o di errore) ritorna -1.
+\begin{prototype}{unistd.h}
+{int readlink(const char * path, char * buff, size\_t size)} 
+  Legge il contenuto del link simbolico indicato da \var{path} nel buffer
+  \var{buff} di dimensione \var{size}. Non chiude la stringa con un
+  carattere nullo e la tronca a \var{size} nel caso il buffer sia troppo
+  piccolo per contenerla.
+  
+  La funzione restituisce il numero di caratteri letti dentro \var{buff} o
+  -1 per un errore, in caso di errore. La variabile \var{errno} viene
+  settata secondo i codici di errore:
+  \begin{errlist}
+  \item \macro{EEXIST} Un file (o una directory) con quel nome esiste di
+    già.
+  \item \macro{EROFS} La directory su cui si vuole inserire il nuovo link è
+    su un filesystem montato in sola lettura.
+  \item \macro{ENOSPC} La directory o il filesystem in cui si vuole creare il
+    link è piena e non c'è ulteriore spazio disponibile.
+  \end{errlist}
+\end{prototype}
 
+In \ntab\ si è riportato un elenco dei comportamenti delle varie funzioni che
+operano sui file rispetto ai link simbolici; specificando quali seguono il
+link simbolico e quali possono operare direttamente sul suo contenuto.
 \begin{table}[htb]
   \centering
   \footnotesize
-  \begin{tabular}{|c|l|}
-    \hline
-    \textbf{\var{mode}} & \textbf{Significato} \\
-    \hline
-    \hline
-    \macro{R\_OK} & verifica il permesso di lettura \\
-    \macro{W\_OK} & verifica il permesso di scritture \\
-    \macro{X\_OK} & verifica il permesso di esecuzione \\
-    \macro{F\_OK} & verifica l'esistenza del file \\
+  \begin{tabular}[c]{|l|c|c|}
     \hline
+    \textbf{Funzione} & \textbf{Segue il link} & \textbf{Non segue il link} \\
+    \hline 
+    \hline 
+    \func{access}   & $\bullet$ &           \\
+    \func{chdir}    & $\bullet$ &           \\
+    \func{chmod}    & $\bullet$ &           \\
+    \func{chown}    &           & $\bullet$ \\
+    \func{creat}    & $\bullet$ &           \\
+    \func{exec}     & $\bullet$ &           \\
+    \func{lchown}   & $\bullet$ & $\bullet$ \\
+    \func{link}     &           &           \\
+    \func{lstat}    &           & $\bullet$ \\
+    \func{mkdir}    & $\bullet$ &           \\
+    \func{mkfifo}   & $\bullet$ &           \\
+    \func{mknod}    & $\bullet$ &           \\
+    \func{open}     & $\bullet$ &           \\
+    \func{opendir}  & $\bullet$ &           \\
+    \func{pathconf} & $\bullet$ &           \\
+    \func{readlink} &           & $\bullet$ \\
+    \func{remove}   &           & $\bullet$ \\
+    \func{rename}   &           & $\bullet$ \\
+    \func{stat}     & $\bullet$ &           \\
+    \func{truncate} & $\bullet$ &           \\
+    \func{unlink}   &           & $\bullet$ \\
+    \hline 
   \end{tabular}
-  \caption{Valori possibile per il parametro \var{mode} della funzione 
-    \func{access}}
-  \label{tab:file_access_mode_val}
+  \caption{Uso dei link simbolici da parte di alcune funzioni.}
+  \label{tab:file_symb_effect}
 \end{table}
+si noti che non si è specificato il comportamento delle funzioni che operano
+con i file descriptor, in quanto la gestione del link simbolico viene in
+genere effettuata dalla funzione che restituisce il file descriptor
+(normalmente la \func{open}).
 
-Un esempio tipico per l'uso di questa funzione è quello di un processo che sta
-eseguendo un programma coi privilegi di un altro utente (attraverso l'uso del
-suid bit) che vuole controllare se l'utente originale ha i permessi per
-accedere ad un certo file.
-
+\begin{figure}[htb]
+  \centering
+  \includegraphics[width=5cm]{img/link_loop.eps}
+  \caption{Esempio di loop nel filesystem creato con un link simbolico.}
+  \label{fig:file_link_loop}
+\end{figure}
 
-\subsection{Le funzioni \texttt{chmod} e \texttt{fchmod}}
-\label{sec:file_chmod}
+Un caso comune che si può avere con i link simbolici è la creazione dei
+cosiddetti \textit{loop}. La situazione è illustrata in \curfig, che riporta
+la struttura della directory \file{/boot}. Come si vede si è creato al suo
+interno un link simbolico che punta di nuovo a \file{/boot}\footnote{Questo
+  tipo di loop è stato effettuato per poter permettere a \cmd{grub} (un
+  bootloader estremamente avanzato in grado di accedere direttamente
+  attraverso vari filesystem al file da lanciare come sistema operativo) di
+  vedere i file in questa directory, che è montata su una partizione separata
+  (e che grub vedrebbe come radice), con lo stesso path con cui verrebbero
+  visti dal sistema operativo.}. 
 
-Per cambiare i permessi di un file il sistema mette ad disposizione due
-funzioni, che operano rispettivamente su un filename e su un file descriptor,
-i cui prototipi sono:
+Questo può causare problemi per tutti quei programmi che effettuano la
+scansione di una directory senza tener conto dei link simbolici, ad esempio se
+lanciassimo un comando del tipo \cmd{grep -r linux *}, il loop nella directory
+porterebbe il comando ad esaminare \file{/boot}, \file/{boot/boot},
+\file/{boot/boot/boot} e così via, fino a generare un errore (che poi è
+\macro{ELOOP}) quando viene superato il numero massimo di link simbolici
+consentiti (uno dei limiti del sistema, posto proprio per poter uscire da
+questo tipo di situazione).
 
-\begin{functions}
-  \headdecl{sys/types.h} 
-  \headdecl{sys/stat.h} 
-  
-  \funcdecl{int chmod(const char *path, mode\_t mode)} Cambia i permessi del
-  file indicato da \var{path} al valore indicato da \var{mode}.
-  
-  \funcdecl{int fchmod(int fd, mode\_t mode)} Analoga alla precedente, ma usa
-  il file descriptor \var{fd} per indicare il file.
+Un secondo punto da tenere presente è che un link simbolico può essere fatto
+anche ad un file che non esiste; ad esempio possiamo creare un file temporaneo
+nella nostra directory con un link del tipo:
+\begin{verbatim}
+$ ln -s /tmp/tmp_file temporaneo
+\end{verbatim}%$
+ma anche se \file{/tmp/tmp\_file} non esiste (quello che viene chiamato un
+\textit{dangling link}, letteralemnte \textsl{link ciondolante}). Aprendo in
+scrittura \file{temporaneo} questo verrà scritto; ma se cercassimo di
+accederlo in sola lettura (ad esempio con \cmd{cat}) otterremmo:
+\begin{verbatim}
+$ cat temporaneo
+cat: temporaneo: No such file or directory
+\end{verbatim}%$
+con un errore che può sembrare sbagliato, dato \cmd{ls} ci mostrerebbe
+l'esistenza di \file{temporaneo}.
+
+
+\subsection{Le funzioni \func{mkdir} e \func{rmdir}} 
+\label{sec:file_dir_creat_rem}
+
+Queste due funzioni servono per creare e cancellare delle directory e sono
+omonime degli analoghi comandi di shell.  Per poter accedere ai tipi usati
+da queste funzioni si deve includere il file \file{sys/types.h}, il
+protoripo della prima è:
+
+\begin{prototype}{sys/stat.h}
+  {int mkdir (const char * dirname, mode\_t mode)} 
+  Crea una nuova directory vuota con il nome indicato da \var{dirname},
+  assegnandole i permessi indicati da \var{mode}. Il nome può essere indicato
+  con il pathname assoluto o relativo.
   
-  Le funzioni restituiscono zero in caso di successo e -1 per un errore, in
-  caso di errore \texttt{errno} può assumere i valori:
+  La funzione restituisce zero in caso di successo e -1 per un errore, nel
+  qual caso \var{errno} assumerà 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{EEXIST} Un file (o una directory) con quel nome esiste di già. 
+  \item \macro{EACCESS} 
+    Non c'è il permesso di scrittura per la directory in cui si vuole inserire
+    la nuova directory.
+  \item \macro{EMLINK} La directory in cui si vuole creare la nuova directory
+    contiene troppi file. Sotto Linux questo normalmente non avviene perché il
+    filesystem standard consente la creazione di un numero di file maggiore di
+    quelli che possono essere contenuti nell'hard-disk, ma potendo avere a che
+    fare anche con filesystem di altri sistemi questo errore può presentarsi.
+  \item \macro{ENOSPC} Non c'è abbastanza spazio sul file system per creare
+    la nuova directory o si è esaurita la quota disco dell'utente.
   \end{errlist}
-  ed inoltre \macro{EROFS} e \macro{EIO}; \func{chmod} restituisce anche
-  \macro{EFAULT}, \macro{ENAMETOOLONG}, \macro{ENOENT}, \macro{ENOMEM},
-  \macro{ENOTDIR}, \macro{EACCES}, \macro{ELOOP}; \func{fchmod} anche
-  \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 macro, o specificati
-direttamente, come per l'analogo comando di shell, con il valore ottale. 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 suid
-il valore da fornire sarebbe $4755$.
+  ed inoltre anche \macro{EPERM}, \macro{EFAULT}, \macro{ENAMETOOLONG},
+  \macro{ENOENT}, \macro{ENOTDIR}, \macro{ENOMEM}, \macro{ELOOP},
+  \macro{EROFS}.
+\end{prototype}
 
-\begin{table}[!htb]
-  \centering
-  \footnotesize
-  \begin{tabular}[c]{|c|c|l|}
-    \hline
-    \textbf{\var{mode}} & \textbf{Valore} & \textbf{Significato} \\
-    \hline
-    \hline
-    \macro{S\_ISUID} & 04000 & set user ID \\
-    \macro{S\_ISGID} & 02000 & set group ID \\
-    \macro{S\_ISVTX} & 01000 & sticky bit \\
-    \hline
-    \macro{S\_IRWXU} & 00700 & l'utente ha tutti i permessi \\
-    \macro{S\_IRUSR} & 00400 & l'utente ha il permesso di lettura  \\
-    \macro{S\_IWUSR} & 00200 & l'utente ha il permesso di scrittura \\
-    \macro{S\_IXUSR} & 00100 & l'utente ha il permesso di esecuzione \\
-    \hline
-    \macro{S\_IRWXG} & 00070 & il gruppo ha tutti i permessi  \\
-    \macro{S\_IRGRP} & 00040 & il gruppo ha il permesso di lettura  \\
-    \macro{S\_IWGRP} & 00020 & il gruppo ha il permesso di scrittura \\
-    \macro{S\_IXGRP} & 00010 & il gruppo ha il permesso di esecuzione \\
-    \hline
-    \macro{S\_IRWXO} & 00007 & gli altri hanno tutti i permessi \\
-    \macro{S\_IROTH} & 00004 & gli altri hanno il permesso di lettura  \\
-    \macro{S\_IWOTH} & 00002 & gli altri hanno il permesso di scrittura \\
-    \macro{S\_IXOTH} & 00001 & gli altri hanno il permesso di esecuzione \\
-    \hline
-  \end{tabular}
-  \caption{I valori delle costanti usate per indicare i permessi dei file.}
-  \label{tab:file_permission_const}
-\end{table}
 
-Il cambiamento dei permessi di un file attraverso queste funzioni ha comunque
-alcune limitazioni, provviste per motivi di sicurezza. Questo significa che
-anche se si è proprietari del file non tutte le operazioni sono permesse, in
-particolare:
-\begin{itemize}
-\item siccome solo l'amministratore può settare lo \textit{sticky bit} se 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}.
-\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).
-\end{itemize}
+\begin{prototype}{sys/stat.h}
+  {int rmdir (const char * dirname)} 
+  Cancella la directory \var{dirname}, che deve essere vuota.  Il nome può
+  essere indicato con il pathname assoluto o relativo.
+  
+  La funzione restituisce zero in caso di successo e -1 per un errore, nel
+  qual caso \var{errno} assumerà i valori:
+  \begin{errlist}
+  \item \macro{EPERM} Il filesystem non supporta la cancellazione di
+    directory, oppure la directory che contiene \var{dirname} ha lo sticky bit
+    settato e l'\textit{effective user id} 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
+    attraversare (esecuzione) una delle directory specificate in
+    \var{dirname}.
+  \item \macro{EBUSY} La directory specificata è la directory di lavoro o la
+    radice di qualche processo.
+  \item \macro{ENOTEMPTY} La directory non è vuota.
+  \end{errlist}
+  ed inoltre anche \macro{EFAULT}, \macro{ENAMETOOLONG}, \macro{ENOENT},
+  \macro{ENOTDIR}, \macro{ENOMEM}, \macro{ELOOP}, \macro{EROFS}.
+\end{prototype}
 
-Per alcuni filesystem\footnote{il filesystem \textsl{ext2} supporta questa
-  caratteristica, che è mutuata da BSD.} è inoltre prevista una ulteriore
-misura di sicurezza, volta ad scongiurare l'abuso dei bit \acr{suid} e
-\acr{sgid}; essa consiste nel cancellare automaticamente questi bit qualora un
-processo che non appartenga all'amministratore scriva su un file. In questo
-modo anche se un utente malizioso scopre un file \acr{suid} su cui può
-scrivere, un eventuale modifica comporterà la perdita di ogni ulteriore
-privilegio.
 
+\subsection{Accesso alle directory}
+\label{sec:file_dir_read}
 
-\subsection{La funzione \texttt{umask}}
-\label{sec:file_umask}
+Benché le directory siano oggetti del filesystem come tutti gli altri non ha
+ovviamente senso aprirle come fossero dei file di dati. Può però essere utile
+poterne leggere il contenuto ad esempio per fare la lista dei file che esse
+contengono o ricerche sui medesimi.
 
-Oltre che dai valori indicati in sede di creazione, i permessi assegnati ai
-nuovi file sono controllati anche da una maschera di bit settata con la
-funzione \func{umask}, il cui prototipo è:
+Per accedere al contenuto delle directory si usano i cosiddetti
+\textit{directory streams} (chiamati così per l'analogia con i file stream);
+la funzione \func{opendir} apre uno di questi stream e la funzione
+\func{readdir} legge il contenuto della directory, i cui elementi sono le
+\textit{directory entry} (da distinguersi da quelle della cache di cui
+parlavamo in \secref{sec:file_vfs}) in una opportuna struttura
+\var{struct dirent}.
 
-\begin{prototype}{stat.h}
-{mode\_t umask(mode\_t mask)}
+(NdA Il resto va scritto!!! É noioso e lo farò più avanti).
 
-  Setta la maschera dei permessi dei bit al valore specificato da \var{mask}
-  (di cui vengono presi solo i 9 bit meno significativi).
-  
-  La funzione ritorna il precedente valore della maschera. È una delle poche
-  funzioni che non restituisce codici di errore.
-\end{prototype}
 
-Questa maschera è una caratteristica di ogni processo e viene utilizzata per
-impedire che alcuni permessi possano essere assegnati ai nuovi file in sede di
-creazione, i bit indicati nella maschera vengono infatti esclusi quando un
-nuovo file viene creato.
 
-In genere questa maschera serve per impostare un default che escluda alcuni
-permessi (usualmente quello di scrittura per il gruppo e gli altri,
-corrispondente ad un valore di $022$). Essa è utile perché le routine
-dell'interfaccia ANSI C degli stream non prevedono l'esistenza dei permessi, e
-pertanto tutti i nuovi file vengono sempre creati con un default di $666$
-(cioè permessi di lettura e scrittura per tutti, si veda
-\tabref{tab:file_permission_const} per un confronto); in questo modo è
-possibile cancellare automaticamente i permessi non voluti, senza doverlo fare
-esplicitamente.
+\subsection{La directory di lavoro}
+\label{sec:file_work_dir}
 
-In genere il valore di \func{umask} viene stabilito una volta per tutte al
-login a $022$, e di norma gli utenti non hanno motivi per modificarlo. Se però
-si vuole che un processo possa creare un file che chiunque possa leggere
-allora occorrerà cambiare il valore di \func{umask}.
+A ciascun processo è associato ad una directory nel filesystem che è chiamata
+directory corrente o directory di lavoro (\textit{current working directory})
+che è quella a cui si fa riferimento quando un filename è espresso in forma
+relativa (relativa appunto a questa directory).
 
-\subsection{Le funzioni \texttt{chown}, \texttt{fchown} e \texttt{lchown}}
-\label{sec:file_chown}
+Quando un utente effettua il login questa directory viene settata alla
+cosiddetta \textit{home directory} del suo account, il comando \cmd{cd}
+della shell consente di cambiarla a piacere, spostandosi da una directory ad
+un'altra.  Siccome la directory corrente resta la stessa quando viene creato
+un processo figlio, la directory corrente della shell diventa anche la
+directory corrente di qualunque comando da essa lanciato.
 
-Come per i permessi, il sistema fornisce anche delle funzioni che permettano
-di cambiare utente e gruppo cui il file appartiene; le funzioni in questione
-sono tre e i loro prototipi sono i seguenti:
+Le funzioni qui descritte servono esaminare e cambiare la directory di lavoro
+corrente. 
 
-\begin{functions}
-  \headdecl{sys/types.h} 
-  \headdecl{sys/stat.h} 
+\begin{prototype}{unistd.h}{char * getcwd (char * buffer, size\_t size)}
+  Restituisce il filename completo della directory di lavoro corrente nella
+  stringa puntata da \var{buffer}, che deve essere precedentemente
+  allocata, per una dimensione massima di \var{size}. Si può anche
+  specificare un puntatore nullo come \var{buffer}, nel qual caso la
+  stringa sarà allocata automaticamente per una dimensione pari a
+  \var{size} qualora questa sia diversa da zero, o della lunghezza esatta
+  del pathname altrimenti. In questo caso si deve ricordare di disallocare la
+  stringa una volta cessato il suo utilizzo.
   
-  \funcdecl{int chown(const char *path, uid\_t owner, gid\_t group)}
-  \funcdecl{int fchown(int fd, uid\_t owner, gid\_t group)}
-  \funcdecl{int lchown(const char *path, uid\_t owner, gid\_t group)}
-
-  Le funzioni cambiano utente e gruppo di appartenenza di un file ai valori
-  specificati dalle variabili \var{owner} e \var{group}. 
-
-  Le funzioni restituiscono zero in caso di successo e -1 per un errore, in
-  caso di errore \texttt{errno} viene settato ai valori:
+  La funzione restituisce il puntatore \var{buffer} se riesce,
+  \macro{NULL} se fallisce, in quest'ultimo caso la variabile
+  \var{errno} è settata con i seguenti codici di errore:
   \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{EINVAL} L'argomento \var{size} è zero e \var{buffer} non
+    è nullo.
+  \item \macro{ERANGE} L'argomento \var{size} è più piccolo della
+    lunghezza del pathname. 
+  \item \macro{EACCESS} Manca il permesso di lettura o di ricerca su uno dei
+    componenti del pathname (cioè su una delle directory superiori alla
+    corrente).
   \end{errlist}
-  Oltre a questi entrambe restituiscono gli errori \macro{EROFS} e
-  \macro{EIO}; \func{chown} restituisce anche \macro{EFAULT},
-  \macro{ENAMETOOLONG}, \macro{ENOENT}, \macro{ENOMEM}, \macro{ENOTDIR},
-  \macro{EACCES}, \macro{ELOOP}; \func{fchown} anche \macro{EBADF}.
-\end{functions}
+\end{prototype}
 
-In Linux soltanto l'amministratore può cambiare il proprietario di un file,
-seguendo la semantica di BSD che non consente agli utenti di assegnare i loro
-file ad altri (per evitare eventuali aggiramenti delle quote).
-L'amministratore può cambiare il gruppo di un file, il proprietario può
-cambiare il gruppo dei file che gli appartengono solo se il nuovo gruppo è il
-suo gruppo primario o uno dei gruppi a cui appartiene.
+Di questa funzione esiste una versione \func{char * getwd(char * buffer)}
+fatta per compatibilità all'indietro con BSD, che non consente di specificare
+la dimensione del buffer; esso deve essere allocato in precedenza ed avere una
+dimensione superiore a \macro{PATH\_MAX} (di solito 256 byte, vedi
+\secref{sec:xxx_limits}); il problema è che in Linux non esiste una dimensione
+superiore per un pathname, per cui non è detto che il buffer sia sufficiente a
+contenere il nome del file, e questa è la ragione principale per cui questa
+funzione è deprecata.
 
-La funzione \func{chown} segue i link simbolici, per operare direttamente su
-in link simbolico si deve usare la funzione \func{lchown}\footnote{fino alla
-  versione 2.1.81 in Linux \func{chown} non seguiva i link simbolici, da
-  allora questo comportamento è stato assegnato alla funzione \func{lchown},
-  introdotta per l'occasione, ed è stata creata una nuova system call per
-  \func{chown} che seguisse i link simbolici}. La funzione \func{fchown} opera
-su un file aperto, essa è mutuata da BSD, ma non è nello standard POSIX.
-Un'altra estensione rispetto allo standard POSIX è che specificando -1 come
-valore per \var{owner} e \var{group} i valori restano immutati. 
+Una seconda funzione simile è \func{char * get\_current\_dir\_name(void)}
+che è sostanzialmente equivalente ad una \func{getcwd(NULL, 0)}, con la sola
+differenza che essa ritorna il valore della variabile di ambiente
+\macro{PWD}, che essendo costruita dalla shell può contenere anche dei
+riferimenti simbolici.
 
-Quando queste funzioni sono chiamate con successo da un processo senza i
-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}.
+Come già detto in unix anche le directory sono file, è possibile pertanto
+riferirsi ad esse tramite il file descriptor dell'interfaccia a basso livello,
+e non solo tramite il filename; per questo motivo ci sono due diverse funzioni
+per cambiare directory di lavoro.
 
-%La struttura fondamentale che contiene i dati essenziali relativi ai file è il
-%cosiddetto \textit{inode}; questo conterrà informazioni come il
-%tipo di file (file di dispositivo, directory, file di dati, per un elenco
-%completo vedi \ntab), i permessi (vedi \secref{sec:file_perms}), le date (vedi
-%\secref{sec:file_times}).
+\begin{prototype}{unistd.h}{int chdir (const char * pathname)}
+  Come dice il nome (che significa \textit{change directory}) questa funzione
+  serve a cambiare la directory di lavoro a quella specificata dal pathname
+  contenuto nella stringa \texttt{pathname}.
+\end{prototype}
+  
+\begin{prototype}{unistd.h}{int fchdir (int filedes)} 
+  Analoga alla precedente, ma usa un file descriptor invece del pathname.
+  
+  Entrambe le funzioni restituiscono zero in caso di successo e -1 per un
+  errore, in caso di errore \var{errno} viene settata secondo i codici di
+  errore standard di accesso ai file (trattati in dettaglio in
+  \secref{sec:file_access_control}) ai quali si aggiunge il codice
+  \macro{ENOTDIR} nel caso il \var{filename} indichi un file che non sia una
+  directory.
+\end{prototype}
 
 
 
@@ -617,9 +581,9 @@ controllo di accesso, trattate in in \secref{sec:file_access_control}).
 \label{sec:file_stat}
 
 La lettura delle informazioni relative ai file è fatta attraverso la famiglia
-delle funzioni \func{stat}; questa è la funzione che il comando \cmd{ls} usa
-per poter ottenere e mostrare tutti i dati dei files. I prototipi di queste
-funzioni sono i seguenti:
+delle funzioni \func{stat}; questa è la funzione che ad esempio usa il comando
+\cmd{ls} per poter ottenere e mostrare tutti i dati dei files. I prototipi di
+queste funzioni sono i seguenti:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/stat.h} 
@@ -638,7 +602,7 @@ funzioni sono i seguenti:
   descriptor \var{filedes}.
   
   Le funzioni restituiscono zero in caso di successo e -1 per un errore, in
-  caso di errore \texttt{errno} può assumere uno dei valori: \macro{EBADF},
+  caso di errore \var{errno} può assumere uno dei valori: \macro{EBADF},
   \macro{ENOENT}, \macro{ENOTDIR}, \macro{ELOOP}, \macro{EFAULT},
   \macro{EACCESS}, \macro{ENOMEM}, \macro{ENAMETOOLONG}.
 \end{functions}
@@ -718,7 +682,7 @@ riportato in \ntab.
 
 Oltre a queste macro è possibile usare direttamente il valore di
 \var{st\_mode} per ricavare il significato dei vari bit in esso memorizzati,
-per questo sempre in \texttt{sys/stat.h} sono definiti i flag riportati in
+per questo sempre in \file{sys/stat.h} sono definiti i flag riportati in
 \ntab:
 \begin{table}[htb]
   \centering
@@ -758,7 +722,7 @@ per questo sempre in \texttt{sys/stat.h} sono definiti i flag riportati in
     \hline    
   \end{tabular}
   \caption{Costanti per l'identificazione dei vari bit che compongono il campo
-    \var{st\_mode} (definite in \texttt{sys/stat.h})}
+    \var{st\_mode} (definite in \file{sys/stat.h})}
   \label{tab:file_mode_flags}
 \end{table}
 
@@ -819,7 +783,7 @@ le due funzioni:
   descriptor \var{fd}.
   
   Le funzioni restituiscono zero in caso di successo e -1 per un errore, in
-  caso di errore \texttt{errno} viene settato opportunamente; per
+  caso di errore \var{errno} viene settato opportunamente; per
   \func{ftruncate} si hanno i valori:
   \begin{errlist}
   \item \macro{EBADF} \var{fd}  non è un file descriptor.
@@ -1028,514 +992,592 @@ molto pi
 
 
 
-\section{La manipolazione di file e directory}
 
-Come già accennato in \secref{sec:file_filesystem} in un sistema unix-like i
-file hanno delle caratteristiche specifiche dipendenti dall'architettura del
-sistema, esamineremo qui allora le funzioni usate per la creazione di link
-simbolici e diretti e per la gestione delle directory, approfondendo quanto
-già accennato in precedenza.
+\section{Il controllo di accesso ai file}
+\label{sec:file_access_control}
 
+Una delle caratteristiche fondamentali di tutti i sistemi unix-like è quella
+del controllo di accesso ai file, che viene implementato per qualunque
+filesystem standard. In questa sezione ne esamineremo i concetti essenziali e
+le funzioni usate per gestirne i vari aspetti.
 
-\subsection{Le funzioni \func{link} e \func{unlink}}
-\label{sec:file_link}
 
-Una delle caratteristiche comuni a vari sistemi operativi è quella di poter
-creare dei nomi fittizi (alias o collegamenti) per potersi riferire allo
-stesso file accedendovi da directory diverse. Questo è possibile anche in
-ambiente unix, dove tali collegamenti sono usualmente chiamati \textit{link},
-ma data la struttura del sistema ci sono due metodi sostanzialmente diversi
-per fare questa operazione.
+\subsection{I permessi per l'accesso ai file}
+\label{sec:file_perm_overview}
 
-Come spiegato in \secref{sec:file_architecture} l'accesso al contenuto di
-un file su disco avviene attraverso il suo inode, e il nome che si trova in
-una directory è solo una etichetta associata ad un puntatore a detto inode.
-Questo significa che la realizzazione di un link è immediata in quanto uno
-stesso file può avere tanti nomi diversi allo stesso tempo, dati da
-altrettante diverse associazioni allo stesso inode; si noti poi che nessuno di
-questi nomi viene ad assumere una particolare preferenza rispetto agli altri.
+Il controllo di accesso ai file in unix segue un modello abbastanza semplice
+(ma adatto alla gran parte delle esigenze) in cui si dividono i permessi su
+tre livelli. Si tenga conto poi che quanto diremo è vero solo per filesystem
+di tipo unix, e non è detto che sia applicabile a un filesystem
+qualunque\footnote{ed infatti non è vero per il filesystem vfat di Windows,
+  per il quale i permessi vengono assegnati in maniera fissa con un opzione in
+  fase di montaggio}.  Esistono inoltre estensioni che permettono di
+implementare le ACL (\textit{Access Control List}) che sono un meccanismo di
+controllo di accesso molto più sofisticato.
 
-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:
-\begin{prototype}{unistd.h}
-{int link(const char * oldpath, const char * newpath)}
-  Crea un nuovo collegamento diretto al file indicato da \var{oldpath}
-  dandogli nome \var{newpath}.
-  
-  La funzione restituisce zero in caso di successo e -1 in caso di errore. La
-  variabile \var{errno} viene settata opportunamente, i principali codici
-  di errore sono:
-  \begin{errlist}
-  \item \macro{EXDEV} \var{oldpath} e \var{newpath} non sono sullo
-    stesso filesystem.
-  \item \macro{EPERM} il filesystem che contiene \var{oldpath} e
-    \macro{newpath} non supporta i link diretti o è una directory.
-  \item \macro{EEXIST} un file (o una directory) con quel nome esiste di
-    già.
-  \item \macro{EMLINK} ci sono troppi link al file \vat{oldpath} (il
-    numero massimo è specificato dalla variabile \macro{LINK\_MAX}, vedi
-    \secref{sec:xxx_limits}).
-  \end{errlist}
-  
-\end{prototype}
+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 (\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,
+e cioè attribuiti rispettivamente all'utente proprietario del file, a un
+qualunque utente faccia parte del gruppo cui appartiene il file, e a tutti gli
+altri utenti.
 
-La creazione di un nuovo collegamento diretto non copia il contenuto del file,
-ma si limita ad aumentare di uno il numero di referenze al file (come si può
-controllare con il campo \var{st\_nlink} di \var{stat}) aggiungendo il nuovo
-nome ai precedenti. Si noti che uno stesso file può essere così richiamato in
-diverse directory.
-Per quanto dicevamo in \secref{sec:file_filesystem} la creazione del
-collegamento diretto è possibile solo se entrambi i pathname sono nello stesso
-filesystem; inoltre il filesystem deve supportare i collegamenti diretti (non è
-il caso ad esempio del filesystem \acr{vfat} di Windows).
-
-La funzione opera sui file ordinari, come sugli altri oggetti del filesystem,
-in alcuni filesystem solo l'amministratore è in grado di creare un
-collegamento diretto ad un'altra directory, questo lo si fa perché in questo
-caso è possibile creare dei circoli nel filesystem (vedi
-\secref{sec:file_symlink}) che molti programmi non sono in grado di gestire e
-la cui rimozione diventerebbe estremamente complicata (in genere occorre far
-girare il programma \cmd{fsck} per riparare il filesystem); data la sua
-pericolosità in generale nei filesystem usati in Linux questa caratteristica è
-stata disabilitata, e la funzione restituisce l'errore \macro{EPERM}.
-
-La rimozione di un file (o più precisamente della voce che lo referenzia) si
-effettua con la funzione \func{unlink}; il suo prototipo è il seguente:
+I permessi, così come vengono presi dai comandi e dalle routine di sistema,
+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 (\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}).
 
-\begin{prototype}{unistd.h}{int unlink(const char * pathname)}
-  Cancella il nome specificato dal pathname nella relativa directory e
-  decrementa il numero di riferimenti nel relativo inode. Nel caso di link
-  simbolico cancella il link simbolico; nel caso di socket, fifo o file di
-  dispositivo rimuove il nome, ma come per i file i processi che hanno aperto
-  uno di questi oggetti possono continuare ad utilizzarlo.
-  
-  La funzione restituisce zero in caso di successo e -1 per un errore, nel
-  qual caso il file non viene toccato. La variabile \texttt{errno} viene
-  settata secondo i seguenti codici di errore:
-  \begin{errlist}
-  \item \macro{EISDIR} \var{pathname} si riferisce ad una directory
-    (valore specifico ritornato da Linux che non consente l'uso di
-    \var{unlink} con le directory, e non conforme allo standard POSIX, che
-    prescrive invece l'uso di \macro{EPERM} in caso l'operazione non sia
-    consentita o il processo non abbia privilegi sufficienti).
-  \item \texttt{EROFS} \var{pathname} è su un filesystem montato in sola
-  lettura.
-  \item \texttt{EISDIR} \var{pathname} fa riferimento a una directory.
-  \end{errlist}
-\end{prototype}
+Anche i permessi, come tutte le altre informazioni generali, sono tenuti per
+ciascun file nell'inode; in particolare essi sono contenuti in alcuni bit
+del campo \var{st\_mode} della struttura letta da \func{stat} (di nuovo si veda
+\secref{sec:file_stat} per i dettagli).
 
-Per cancellare una voce in una directory è necessario avere il permesso di
-scrittura su di essa (dato che si va a rimuovere una voce dal suo contenuto) e
-il diritto di esecuzione sulla directory che la contiene (torneremo in
-dettaglio sui permessi e gli attributi fra poco), se inoltre lo
-\textit{sticky} bit è settato occorrerà anche essere proprietari del file o
-proprietari della directory (o root, per cui nessuna delle restrizioni è
-applicata).
+In genere ci si riferisce a questo raggruppamento dei permessi usando le
+lettere \cmd{u} (per \textit{user}), \cmd{g} (per \textit{group}) e \cmd{o}
+(per \textit{other}), inoltre se si vuole indicare tutti i raggruppamenti
+insieme si usa la lettera \cmd{a} (per \textit{all}). Si tenga ben presente
+questa distinzione dato che in certi casi, mutuando la terminologia in uso nel
+VMS, si parla dei permessi base come di permessi per \textit{owner},
+\textit{group} ed \textit{all}, le cui iniziali possono dar luogo a confusione.
+Le costanti che permettono di accedere al valore numerico di questi bit nel
+campo \var{st\_mode} sono riportate in \ntab.
 
-Una delle caratteristiche di queste funzioni è che la creazione/rimozione
-della nome dalla directory e l'incremento/decremento del numero di riferimenti
-nell'inode deve essere una operazione atomica (cioè non interrompibile da
-altri) processi, per questo entrambe queste funzioni sono realizzate tramite
-una singola system call.
+\begin{table}[htb]
+  \centering
+    \footnotesize
+  \begin{tabular}[c]{|c|l|}
+    \hline
+    \textbf{\var{st\_mode}} bit & \textbf{Significato} \\
+    \hline 
+    \hline 
+    \macro{S\_IRUSR}  &  \textit{user-read}, l'utente può leggere     \\
+    \macro{S\_IWUSR}  &  \textit{user-write}, l'utente può scrivere   \\
+    \macro{S\_IXUSR}  &  \textit{user-execute}, l'utente può eseguire \\ 
+    \hline              
+    \macro{S\_IRGRP}  &  \textit{group-read}, il gruppo può leggere    \\
+    \macro{S\_IWGRP}  &  \textit{group-write}, il gruppo può scrivere  \\
+    \macro{S\_IXGRP}  &  \textit{group-execute}, il gruppo può eseguire\\
+    \hline              
+    \macro{S\_IROTH}  &  \textit{other-read}, tutti possono leggere    \\
+    \macro{S\_IWOTH}  &  \textit{other-write}, tutti possono scrivere  \\
+    \macro{S\_IXOTH}  &  \textit{other-execute}, tutti possono eseguire\\
+    \hline              
+  \end{tabular}
+  \caption{I bit dei permessi di accesso ai file, come definiti in 
+    \texttt{<sys/stat.h>}}
+  \label{tab:file_bit_perm}
+\end{table}
 
-Si ricordi infine che il file non viene eliminato dal disco fintanto che tutti
-i riferimenti ad esso sono stati cancellati, solo quando il \textit{link
-  count} mantenuto nell'inode diventa zero lo spazio occupato viene rimosso. A
-questo però si aggiunge una altra condizione, e cioè che non ci siano processi
-che abbiano detto file aperto. Come accennato questa proprietà viene spesso
-usata per essere sicuri di non lasciare file temporanei su disco in caso di
-crash dei programmi; la tecnica è quella di aprire il file e chiamare
-\texttt{unlink} subito dopo.
+Questi permessi vengono usati in maniera diversa dalle varie funzioni, e a
+seconda che si riferiscano a file, link simbolici o directory, qui ci
+limiteremo ad un riassunto delle regole generali, entrando nei dettagli più
+avanti.
 
-\subsection{Le funzioni \func{remove} e \func{rename}}
-\label{sec:file_remove}
+La prima regola è che per poter accedere ad un file attraverso il suo pathname
+occorre il permesso di esecuzione in ciascuna delle directory che compongono
+il pathname, e lo stesso vale per aprire un file nella directory corrente (per
+la quale appunto serve il diritto di esecuzione).
 
-Al contrario di quanto avviene con altri unix in Linux non è possibile usare
-\texttt{unlink} sulle directory, per cancellare una directory si può usare la
-funzione \texttt{rmdir} (vedi \secref{sec:file_dir_creat_rem}), oppure la
-funzione \texttt{remove}. Questa è la funzione prevista dallo standard ANSI C
-per cancellare un file o una directory (e funziona anche per i sistemi che non
-supportano i link diretti), che per i file è identica alla \texttt{unlink} e
-per le directory è identica alla \texttt{rmdir}:
+Per una directory infatti il permesso di esecuzione ha il significato
+specifico che essa può essere attraversata nella risoluzione del pathname, ed
+è distinto dal permesso di lettura che invece implica che si può leggere il
+contenuto della directory. Questo significa che se si ha il permesso di
+esecuzione senza permesso di lettura si potrà lo stesso aprire un file in una
+directory (se si hanno i permessi opportuni per il medesimo) ma non si potrà
+vederlo con \cmd{ls} (per crearlo occorrerà anche il permesso di scrittura per
+la directory).
 
-\begin{prototype}{stdio.h}{int remove(const char *pathname)}
-  Cancella un nome dal filesystem. Usa \texttt{unlink} per i file e
-  \texttt{rmdir} per le directory.
-  
-  La funzione restituisce zero in caso di successo e -1 per un errore, nel
-  qual caso il file non viene toccato. Per i codici di errori vedi quanto
-  riportato nella descrizione di \texttt{unlink} e \texttt{rmdir}.
-\end{prototype}
+Avere il permesso di lettura per un file consente di aprirlo con le opzioni di
+sola lettura (\macro{O\_RDONLY}) o di lettura/scrittura (\macro{O\_RDWR}) e
+leggerne il contenuto. Avere il permesso di scrittura consente di aprire un
+file in sola scrittura (\macro{O\_WRONLY}) o lettura/scrittura
+(\macro{O\_RDWR}) e modificarne il contenuto, lo stesso permesso è necessario
+per poter troncare il file con l'opzione \macro{O\_TRUNC}.
 
-Per cambiare nome ad un file si usa invece la funzione \texttt{rename}, il
-vantaggio nell'uso di questa funzione al posto della chiamata successiva di
-\texttt{unlink} e \texttt{link} è che l'operazione è eseguita atomicamente, in
-questo modo non c'è la possibilità che un processo che cerchi di accedere al
-nuovo nome dopo che il vecchio è stato cambiato lo trovi mancante.
+Non si può creare un file fintanto che non si disponga del permesso di
+esecuzione e di quello di scrittura per la directory di destinazione; gli
+stessi permessi occorrono per cancellare un file da una directory (si ricordi
+che questo non implica necessariamente la rimozione del contenuto del file dal
+disco), non è necessario nessun tipo di permesso per il file stesso (infatti
+esso non viene toccato, viene solo modificato il contenuto della directory,
+rimuovendo la voce che ad esso fa rifermento).
 
-\begin{prototype}{stdio.h}
-{int rename(const char *oldpath, const char *newpath)}
-  Rinomina un file, spostandolo fra directory diverse quando richiesto.
+Per poter eseguire un file (che sia un programma compilato od uno script di
+shell, od un altro tipo di file eseguibile riconosciuto dal kernel), occorre
+avere il permesso di esecuzione, inoltre solo i file regolari possono essere
+eseguiti.
 
-  La funzione restituisce zero in caso di successo e -1 per un errore, nel
-  qual caso il file non viene toccato. La variabile \texttt{errno} viene
-  settata secondo i seguenti codici di errore:
-  \begin{errlist} 
-  \item \texttt{EISDIR} \texttt{newpath} è una directory già esistente mentre
-    \texttt{oldpath} non è una directory. 
-  \item \texttt{EXDEV} \texttt{oldpath} e \texttt{newpath} non sono sullo
-    stesso filesystem. 
-  \item \texttt{ENOTEMPTY} \texttt{newpath} è una directory già esistente e
-    non vuota.
-  \item \texttt{EBUSY} o \texttt{oldpath} o \texttt{newpath} sono in uso da
-    parte di qualche processo (come directory di lavoro o come root) o del
-    sistema (come mount point).
-  \item \texttt{EINVAL} \texttt{newpath} contiene un prefisso di
-    \texttt{oldpath} o più in generale si è cercato di creare una directory
-    come sottodirectory di se stessa.
-  \item \texttt{EMLINK} \texttt{oldpath} ha già il massimo numero di link
-    consentiti o è una directory e la directory che contiene \texttt{newpath}
-    ha già il massimo numero di link. 
-  \item \texttt{ENOTDIR} Uno dei componenti dei pathname non è una directory
-    o\texttt{oldpath} è una directory e \texttt{newpath} esiste e non è una
-    directory.
-  \item \texttt{EACCESS} Non c'è il permesso di scrittura per la directory in
-    cui si vuole creare il nuovo link o una delle directory del pathname non
-    consente la ricerca (permesso di esecuzione).
-  \item \texttt{EPERM} le directory contenenti \texttt{oldpath} o
-    \texttt{newpath} hanno lo sticky bit attivo e i permessi del processo non
-    consentono rispettivamente la cancellazione e la creazione del file, o il
-    filesystem non supporta i link.
-  \item \texttt{ENOSPC} Il device di destinazione non ha più spazio per la
-    nuova voce. 
-  \end{errlist}    
-\end{prototype}
+I permessi per un link simbolico sono ignorati, contano quelli del file a cui
+fa riferimento; per questo in genere \cmd{ls} per un link simbolico riporta
+tutti i permessi come concessi; utente e gruppo a cui esso appartiene vengono
+ignorati quando il link viene risolto, vengono controllati solo quando viene
+richiesta la rimozione del link e quest'ultimo è in una directory con lo
+\textsl{sticky bit} settato (si veda \secref{sec:file_sticky}).
 
-\subsection{I link simbolici}
-\label{sec:file_symlink}
+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}.
 
-Siccome la funzione \texttt{link} crea riferimenti agli inodes, essa può
-funzionare soltanto per file che risiedono sullo stesso filesystem, dato che
-in questo caso è garantita l'unicità dell'inode, e solo per un filesystem di
-tipo unix.  Inoltre in Linux non è consentito eseguire un link diretto ad una
-directory.
+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.
 
-Per ovviare a queste limitazioni i sistemi unix supportano un'altra forma di
-link (i cosiddetti \textit{soft link} o \textit{symbolic link}), che sono,
-come avviene in altri sistemi operativi, dei file che contengono il
-semplicemente il riferimento ad un altro file (o directory). In questo modo è
-possibile effettuare link anche attraverso filesystem diversi e a directory, e
-pure a file che non esistono ancora.
+I passi attraverso i quali viene stabilito se il processo possiede il diritto
+di accesso sono i seguenti:
+\begin{itemize}
+\item Se l'\textit{effective user id} 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'uid del
+  proprietario del file (nel qual caso si dice che il processo è proprietario
+  del file) allora:
+  \begin{itemize}
+  \item se il relativo\footnote{per relativo si intende il bit di user-read se
+      il processo vuole accedere in scrittura, quello di user-write per
+      l'accesso in scrittura, etc.} bit dei permessi d'accesso dell'utente è
+    settato, 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:
+  \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.
+\end{itemize}
 
-Il sistema funziona in quanto i link simbolici sono contrassegnati come tali
-al kernel (analogamente a quanto avviene per le directory) per cui la chiamata
-ad una \texttt{open} o una \texttt{stat} su un link simbolico comporta la
-lettura del contenuto del medesimo e l'applicazione della funzione al file
-specificato da quest'ultimo. Invece altre funzioni come quelle per cancellare
-o rinominare i file operano direttamente sul link simbolico (per l'elenco vedi
-\ntab). Inoltre esistono funzioni apposite, come la \texttt{readlink} e la
-\texttt{lstat} per accedere alle informazioni del link invece che a quelle del
-file a cui esso fa riferimento.
+Si tenga presente che questi passi vengono eseguiti esattamente in
+quest'ordine. Questo vuol dire che se un processo è il proprietario di un file
+l'accesso è consentito o negato solo sulla base dei permessi per l'utente; i
+permessi per il gruppo non vengono neanche controllati; lo stesso vale se il
+processo appartiene ad un gruppo appropriato, in questo caso i permessi per
+tutti gli altri non vengono controllati.
 
-Le funzioni per operare sui link simbolici sono le seguenti, esse sono tutte
-dichiarate nell'header file \texttt{unistd.h}.
 
-\begin{prototype}{unistd.h}
-{int symlink(const char * oldname, const char * newname)}
-  Crea un nuovo link simbolico al file indicato da \texttt{oldname} dandogli
-  nome \texttt{newname}.
-  
-  La funzione restituisce zero in caso di successo e -1 per un errore, in caso
-  di errore. La variabile \texttt{errno} viene settata secondo i codici di
-  errore standard di accesso ai file (trattati in dettaglio in
-  \secref{sec:file_access_control}) ai quali si aggiungono i seguenti:
-  \begin{errlist}
-  \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
-    già.
-  \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
-    su un filesystem montato in sola lettura.
-  \item \texttt{ENOSPC} La directory o il filesystem in cui si vuole creare il
-    link è piena e non c'è ulteriore spazio disponibile.
-  \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione di
-    \texttt{oldname} o di \texttt{newname}.
-  \end{errlist}
-\end{prototype}
+\subsection{I bit \acr{suid} e \acr{sgid}}
+\label{sec:file_suid_sgid}
 
-Dato che la funzione \texttt{open} segue i link simbolici, è necessaria usare
-un'altra funzione quando si vuole leggere il contenuto di un link simbolico,
-questa funzione è la:
+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
+\acr{suid} (o \textit{set-user-ID bit}) e \acr{sgid} (o
+\textit{set-group-ID bit}) che sono identificati dalle costanti
+\macro{S\_ISUID} e \macro{S\_ISGID}.
 
-\begin{prototype}{unistd.h}
-{int readlink(const char * path, char * buff, size\_t size)} 
-  Legge il contenuto del link simbolico indicato da \texttt{path} nel buffer
-  \texttt{buff} di dimensione \texttt{size}. Non chiude la stringa con un
-  carattere nullo e la tronca a \texttt{size} nel caso il buffer sia troppo
-  piccolo per contenerla.
-  
-  La funzione restituisce il numero di caratteri letti dentro \texttt{buff} o
-  -1 per un errore, in caso di errore. La variabile \texttt{errno} viene
-  settata secondo i codici di errore:
-  \begin{errlist}
-  \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
-    già.
-  \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
-    su un filesystem montato in sola lettura.
-  \item \texttt{ENOSPC} La directory o il filesystem in cui si vuole creare il
-    link è piena e non c'è ulteriore spazio disponibile.
-  \end{errlist}
-\end{prototype}
+Come spiegato in dettaglio in \secref{sec:proc_exec}, quando si lancia un
+programma il comportamento normale del kernel è quello di settare
+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
+corrispondono dell'utente con cui si è entrati nel sistema.
 
-In \ntab\ si è riportato un elenco dei comportamenti delle varie funzioni che
-operano sui file rispetto ai link simbolici; specificando quali seguono il
-link simbolico e quali possono operare direttamente sul suo contenuto.
-\begin{table}[htb]
-  \centering
-  \footnotesize
-  \begin{tabular}[c]{|l|c|c|}
-    \hline
-    \textbf{Funzione} & \textbf{Segue il link} & \textbf{Non segue il link} \\
-    \hline 
-    \hline 
-    \func{access}   & $\bullet$ &           \\
-    \func{chdir}    & $\bullet$ &           \\
-    \func{chmod}    & $\bullet$ &           \\
-    \func{chown}    &           & $\bullet$ \\
-    \func{creat}    & $\bullet$ &           \\
-    \func{exec}     & $\bullet$ &           \\
-    \func{lchown}   & $\bullet$ & $\bullet$ \\
-    \func{link}     &           &           \\
-    \func{lstat}    &           & $\bullet$ \\
-    \func{mkdir}    & $\bullet$ &           \\
-    \func{mkfifo}   & $\bullet$ &           \\
-    \func{mknod}    & $\bullet$ &           \\
-    \func{open}     & $\bullet$ &           \\
-    \func{opendir}  & $\bullet$ &           \\
-    \func{pathconf} & $\bullet$ &           \\
-    \func{readlink} &           & $\bullet$ \\
-    \func{remove}   &           & $\bullet$ \\
-    \func{rename}   &           & $\bullet$ \\
-    \func{stat}     & $\bullet$ &           \\
-    \func{truncate} & $\bullet$ &           \\
-    \func{unlink}   &           & $\bullet$ \\
-    \hline 
-  \end{tabular}
-  \caption{Uso dei link simbolici da parte di alcune funzioni.}
-  \label{tab:file_symb_effect}
-\end{table}
-si noti che non si è specificato il comportamento delle funzioni che operano
-con i file descriptor, in quanto la gestione del link simbolico viene in
-genere effettuata dalla funzione che restituisce il file descriptor
-(normalmente la \func{open}).
+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} 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
+\acr{sgid} settato ha lo stesso effetto sull'\textit{effective group id} del
+processo.
 
-\begin{figure}[htb]
-  \centering
-  \includegraphics[width=5cm]{img/link_loop.eps}
-  \caption{Esempio di loop nel filesystem creato con un link simbolico.}
-  \label{fig:file_link_loop}
-\end{figure}
+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 è necessario chiamare l'amministratore per
+cambiare la propria password. Infatti il comando \cmd{passwd} appartiene a
+root ma ha il bit suid settato per cui quando viene lanciato da un utente
+normale parte con i privilegi di root.
 
-Un caso comune che si può avere con i link simbolici è la creazione dei
-cosiddetti \textit{loop}. La situazione è illustrata in \curfig, che riporta
-la struttura della directory \file{/boot}. Come si vede si è creato al suo
-interno un link simbolico che punta di nuovo a \file{/boot}\footnote{Questo
-  tipo di loop è stato effettuato per poter permettere a \cmd{grub} (un
-  bootloader estremamente avanzato in grado di accedere direttamente
-  attraverso vari filesystem al file da lanciare come sistema operativo) di
-  vedere i file in questa directory, che è montata su una partizione separata
-  (e che grub vedrebbe come radice), con lo stesso path con cui verrebbero
-  visti dal sistema operativo.}. 
+Chiaramente avere un processo che ha privilegi superiori a quelli che avrebbe
+normalmente l'utente che lo ha lanciato comporta vari rischi, e questo tipo di
+programmi devono essere scritti accuratamente per evitare che possano essere
+usati per guadagnare privilegi non consentiti (torneremo sull'argomento in
+\secref{sec:proc_perms}).
 
-Questo può causare problemi per tutti quei programmi che effettuano la
-scansione di una directory senza tener conto dei link simbolici, ad esempio se
-lanciassimo un comando del tipo \cmd{grep -r linux *}, il loop nella directory
-porterebbe il comando ad esaminare \file{/boot}, \file/{boot/boot},
-\file/{boot/boot/boot} e così via, fino a generare un errore (che poi è
-\macro{ELOOP}) quando viene superato il numero massimo di link simbolici
-consentiti (uno dei limiti del sistema, posto proprio per poter uscire da
-questo tipo di situazione).
+La presenza dei bit \acr{suid} e \acr{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:file_mode_flags}.
 
-Un secondo punto da tenere presente è che un link simbolico può essere fatto
-anche ad un file che non esiste; ad esempio possiamo creare un file temporaneo
-nella nostra directory con un link del tipo:
-\begin{verbatim}
-$ ln -s /tmp/tmp_file temporaneo
-\end{verbatim}%$
-ma anche se \file{/tmp/tmp\_file} non esiste (quello che viene chiamato un
-\textit{dangling link}, letteralemnte \textsl{link ciondolante}). Aprendo in
-scrittura \file{temporaneo} questo verrà scritto; ma se cercassimo di
-accederlo in sola lettura (ad esempio con \cmd{cat}) otterremmo:
+Gli stessi bit vengono ad assumere in significato completamente diverso per le
+directory, normalmente infatti Linux usa la convenzione di SVR4 per indicare
+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 \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}).
+
+
+\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}
-$ cat temporaneo
-cat: temporaneo: No such file or directory
+$ ls -ld /tmp
+drwxrwxrwt    6 root     root         1024 Aug 10 01:03 /tmp
 \end{verbatim}%$
-con un errore che può sembrare sbagliato, dato \cmd{ls} ci mostrerebbe
-l'esistenza di \file{temporaneo}.
+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{Le funzioni \texttt{mkdir} e \texttt{rmdir}} 
-\label{sec:file_dir_creat_rem}
+\subsection{La titolarità di nuovi file e directory}
+\label{sec:file_ownership}
 
-Queste due funzioni servono per creare e cancellare delle directory e sono
-omonime degli analoghi comandi di shell.  Per poter accedere ai tipi usati
-da queste funzioni si deve includere il file \texttt{sys/types.h}, il
-protoripo della prima è:
+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}).
 
-\begin{prototype}{sys/stat.h}
-  {int mkdir (const char * dirname, mode\_t mode)} 
-  Crea una nuova directory vuota con il nome indicato da \var{dirname},
-  assegnandole i permessi indicati da \var{mode}. Il nome può essere indicato
-  con il pathname assoluto o relativo.
+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 è:
+
+\begin{prototype}{unistd.h}
+{int access(const char *pathname, int mode)}
+
+  La funzione verifica i permessi di accesso, indicati da \var{mode}, per il
+  file indicato da \var{pathname}. 
   
-  La funzione restituisce zero in caso di successo e -1 per un errore, nel
-  qual caso \var{errno} assumerà i valori:
-  \begin{errlist}
-  \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di già. 
-  \item \texttt{EACCESS} 
-    Non c'è il permesso di scrittura per la directory in cui si vuole inserire
-    la nuova directory.
-  \item \texttt{EMLINK} La directory in cui si vuole creare la nuova directory
-    contiene troppi file. Sotto Linux questo normalmente non avviene perché il
-    filesystem standard consente la creazione di un numero di file maggiore di
-    quelli che possono essere contenuti nell'hard-disk, ma potendo avere a che
-    fare anche con filesystem di altri sistemi questo errore può presentarsi.
-  \item \texttt{ENOSPC} Non c'è abbastanza spazio sul file system per creare
-    la nuova directory o si è esaurita la quota disco dell'utente.
-  \end{errlist}
-  ed inoltre anche \macro{EPERM}, \macro{EFAULT}, \macro{ENAMETOOLONG},
-  \macro{ENOENT}, \macro{ENOTDIR}, \macro{ENOMEM}, \macro{ELOOP},
-  \macro{EROFS}.
+  La funzione ritorna 0 se l'accesso è consentito, -1 altrimenti; in
+  quest'ultimo caso la variabile \texttt{errno} viene settata 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}
 
 
-\begin{prototype}{sys/stat.h}
-  {int rmdir (const char * dirname)} 
-  Cancella la directory \var{dirname}, che deve essere vuota.  Il nome può
-  essere indicato con il pathname assoluto o relativo.
+I valori possibili per il parametro \var{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.
+
+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
+possa scrivere come in un file, e il fatto che un file abbia permesso di
+esecuzione non comporta che contenga un programma eseguibile. La funzione
+ritorna zero solo se tutte i permessi controllati sono disponibili, in caso
+contrario (o di errore) ritorna -1.
+
+\begin{table}[htb]
+  \centering
+  \footnotesize
+  \begin{tabular}{|c|l|}
+    \hline
+    \textbf{\var{mode}} & \textbf{Significato} \\
+    \hline
+    \hline
+    \macro{R\_OK} & verifica il permesso di lettura \\
+    \macro{W\_OK} & verifica il permesso di scritture \\
+    \macro{X\_OK} & verifica il permesso di esecuzione \\
+    \macro{F\_OK} & verifica l'esistenza del file \\
+    \hline
+  \end{tabular}
+  \caption{Valori possibile per il parametro \var{mode} della funzione 
+    \func{access}}
+  \label{tab:file_access_mode_val}
+\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 (attraverso l'uso del
+suid bit) che vuole controllare se l'utente originale ha i permessi per
+accedere ad un certo file.
+
+
+\subsection{Le funzioni \texttt{chmod} e \texttt{fchmod}}
+\label{sec:file_chmod}
+
+Per cambiare i permessi di un file il sistema mette ad disposizione due
+funzioni, che operano rispettivamente su un filename e su un file descriptor,
+i cui prototipi sono:
+
+\begin{functions}
+  \headdecl{sys/types.h} 
+  \headdecl{sys/stat.h} 
   
-  La funzione restituisce zero in caso di successo e -1 per un errore, nel
-  qual caso \var{errno} assumerà i valori:
+  \funcdecl{int chmod(const char *path, mode\_t mode)} Cambia i permessi del
+  file indicato da \var{path} al valore indicato da \var{mode}.
+  
+  \funcdecl{int fchmod(int fd, mode\_t mode)} Analoga alla precedente, ma usa
+  il file descriptor \var{fd} per indicare il file.
+  
+  Le funzioni restituiscono zero in caso di successo e -1 per un errore, in
+  caso di errore \texttt{errno} può assumere i valori:
   \begin{errlist}
-  \item \texttt{EPERM} Il filesystem non supporta la cancellazione di
-    directory, oppure la directory che contiene \var{dirname} ha lo sticky bit
-    settato e l'\textit{effective user id} del processo non corrisponde al
-    proprietario della directory. 
-  \item \texttt{EACCESS} Non c'è il permesso di scrittura per la directory che
-    contiene la directory che si vuole cancellare, o non c'è il permesso di
-    attraversare (esecuzione) una delle directory specificate in
-    \var{dirname}.
-  \item \texttt{EBUSY} La directory specificata è la directory di lavoro o la
-    radice di qualche processo.
-  \item \texttt{ENOTEMPTY} La directory non è vuota.
+  \item \macro{EPERM} L'\textit{effective user id} non corrisponde a quello
+    del proprietario del file o non è zero.
   \end{errlist}
-  ed inoltre anche \macro{EFAULT}, \macro{ENAMETOOLONG}, \macro{ENOENT},
-  \macro{ENOTDIR}, \macro{ENOMEM}, \macro{ELOOP}, \macro{EROFS}.
-\end{prototype}
+  ed inoltre \macro{EROFS} e \macro{EIO}; \func{chmod} restituisce anche
+  \macro{EFAULT}, \macro{ENAMETOOLONG}, \macro{ENOENT}, \macro{ENOMEM},
+  \macro{ENOTDIR}, \macro{EACCES}, \macro{ELOOP}; \func{fchmod} anche
+  \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 macro, o specificati
+direttamente, come per l'analogo comando di shell, con il valore ottale. 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 suid
+il valore da fornire sarebbe $4755$.
 
+\begin{table}[!htb]
+  \centering
+  \footnotesize
+  \begin{tabular}[c]{|c|c|l|}
+    \hline
+    \textbf{\var{mode}} & \textbf{Valore} & \textbf{Significato} \\
+    \hline
+    \hline
+    \macro{S\_ISUID} & 04000 & set user ID \\
+    \macro{S\_ISGID} & 02000 & set group ID \\
+    \macro{S\_ISVTX} & 01000 & sticky bit \\
+    \hline
+    \macro{S\_IRWXU} & 00700 & l'utente ha tutti i permessi \\
+    \macro{S\_IRUSR} & 00400 & l'utente ha il permesso di lettura  \\
+    \macro{S\_IWUSR} & 00200 & l'utente ha il permesso di scrittura \\
+    \macro{S\_IXUSR} & 00100 & l'utente ha il permesso di esecuzione \\
+    \hline
+    \macro{S\_IRWXG} & 00070 & il gruppo ha tutti i permessi  \\
+    \macro{S\_IRGRP} & 00040 & il gruppo ha il permesso di lettura  \\
+    \macro{S\_IWGRP} & 00020 & il gruppo ha il permesso di scrittura \\
+    \macro{S\_IXGRP} & 00010 & il gruppo ha il permesso di esecuzione \\
+    \hline
+    \macro{S\_IRWXO} & 00007 & gli altri hanno tutti i permessi \\
+    \macro{S\_IROTH} & 00004 & gli altri hanno il permesso di lettura  \\
+    \macro{S\_IWOTH} & 00002 & gli altri hanno il permesso di scrittura \\
+    \macro{S\_IXOTH} & 00001 & gli altri hanno il permesso di esecuzione \\
+    \hline
+  \end{tabular}
+  \caption{I valori delle costanti usate per indicare i permessi dei file.}
+  \label{tab:file_permission_const}
+\end{table}
 
+Il cambiamento dei permessi di un file attraverso queste funzioni ha comunque
+alcune limitazioni, provviste per motivi di sicurezza. Questo significa che
+anche se si è proprietari del file non tutte le operazioni sono permesse, in
+particolare:
+\begin{itemize}
+\item siccome solo l'amministratore può settare lo \textit{sticky bit} se 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}.
+\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).
+\end{itemize}
 
-\subsection{Accesso alle directory}
-\label{sec:file_dir_read}
+Per alcuni filesystem\footnote{il filesystem \textsl{ext2} supporta questa
+  caratteristica, che è mutuata da BSD.} è inoltre prevista una ulteriore
+misura di sicurezza, volta ad scongiurare l'abuso dei bit \acr{suid} e
+\acr{sgid}; essa consiste nel cancellare automaticamente questi bit qualora un
+processo che non appartenga all'amministratore scriva su un file. In questo
+modo anche se un utente malizioso scopre un file \acr{suid} su cui può
+scrivere, un eventuale modifica comporterà la perdita di ogni ulteriore
+privilegio.
 
-Benché le directory siano oggetti del filesystem come tutti gli altri non ha
-ovviamente senso aprirle come fossero dei file di dati. Può però essere utile
-poterne leggere il contenuto ad esempio per fare la lista dei file che esse
-contengono o ricerche sui medesimi.
 
-Per accedere al contenuto delle directory si usano i cosiddetti
-\textit{directory streams} (chiamati così per l'analogia con i file stream);
-la funzione \texttt{opendir} apre uno di questi stream e la funzione
-\texttt{readdir} legge il contenuto della directory, i cui elementi sono le
-\textit{directory entry} (da distinguersi da quelle della cache di cui
-parlavamo in \secref{sec:file_vfs}) in una opportuna struttura
-\texttt{struct dirent}.
+\subsection{La funzione \func{umask}}
+\label{sec:file_umask}
 
-(NdA Il resto va scritto!!! É noioso e lo farò più avanti).
+Oltre che dai valori indicati in sede di creazione, i permessi assegnati ai
+nuovi file sono controllati anche da una maschera di bit settata con la
+funzione \func{umask}, il cui prototipo è:
 
+\begin{prototype}{stat.h}
+{mode\_t umask(mode\_t mask)}
 
+  Setta la maschera dei permessi dei bit al valore specificato da \var{mask}
+  (di cui vengono presi solo i 9 bit meno significativi).
+  
+  La funzione ritorna il precedente valore della maschera. È una delle poche
+  funzioni che non restituisce codici di errore.
+\end{prototype}
 
-\subsection{La directory di lavoro}
-\label{sec:file_work_dir}
+Questa maschera è una caratteristica di ogni processo e viene utilizzata per
+impedire che alcuni permessi possano essere assegnati ai nuovi file in sede di
+creazione, i bit indicati nella maschera vengono infatti esclusi quando un
+nuovo file viene creato.
 
-A ciascun processo è associato ad una directory nel filesystem che è chiamata
-directory corrente o directory di lavoro (\textit{current working directory})
-che è quella a cui si fa riferimento quando un filename è espresso in forma
-relativa (relativa appunto a questa directory).
+In genere questa maschera serve per impostare un default che escluda alcuni
+permessi (usualmente quello di scrittura per il gruppo e gli altri,
+corrispondente ad un valore di $022$). Essa è utile perché le routine
+dell'interfaccia ANSI C degli stream non prevedono l'esistenza dei permessi, e
+pertanto tutti i nuovi file vengono sempre creati con un default di $666$
+(cioè permessi di lettura e scrittura per tutti, si veda
+\tabref{tab:file_permission_const} per un confronto); in questo modo è
+possibile cancellare automaticamente i permessi non voluti, senza doverlo fare
+esplicitamente.
 
-Quando un utente effettua il login questa directory viene settata alla
-cosiddetta \textit{home directory} del suo account, il comando \texttt{cd}
-della shell consente di cambiarla a piacere, spostandosi da una directory ad
-un'altra.  Siccome la directory corrente resta la stessa quando viene creato
-un processo figlio, la directory corrente della shell diventa anche la
-directory corrente di qualunque comando da essa lanciato.
+In genere il valore di \func{umask} viene stabilito una volta per tutte al
+login a $022$, e di norma gli utenti non hanno motivi per modificarlo. Se però
+si vuole che un processo possa creare un file che chiunque possa leggere
+allora occorrerà cambiare il valore di \func{umask}.
 
-Le funzioni qui descritte servono esaminare e cambiare la directory di lavoro
-corrente. 
+\subsection{Le funzioni \func{chown}, \func{fchown} e \func{lchown}}
+\label{sec:file_chown}
 
-\begin{prototype}{unistd.h}{char * getcwd (char * buffer, size\_t size)}
-  Restituisce il filename completo della directory di lavoro corrente nella
-  stringa puntata da \texttt{buffer}, che deve essere precedentemente
-  allocata, per una dimensione massima di \texttt{size}. Si può anche
-  specificare un puntatore nullo come \textit{buffer}, nel qual caso la
-  stringa sarà allocata automaticamente per una dimensione pari a
-  \texttt{size} qualora questa sia diversa da zero, o della lunghezza esatta
-  del pathname altrimenti. In questo caso si deve ricordare di disallocare la
-  stringa una volta cessato il suo utilizzo.
+Come per i permessi, il sistema fornisce anche delle funzioni che permettano
+di cambiare utente e gruppo cui il file appartiene; le funzioni in questione
+sono tre e i loro prototipi sono i seguenti:
+
+\begin{functions}
+  \headdecl{sys/types.h} 
+  \headdecl{sys/stat.h} 
   
-  La funzione restituisce il puntatore \texttt{buffer} se riesce,
-  \texttt{NULL} se fallisce, in quest'ultimo caso la variabile
-  \texttt{errno} è settata con i seguenti codici di errore:
+  \funcdecl{int chown(const char *path, uid\_t owner, gid\_t group)}
+  \funcdecl{int fchown(int fd, uid\_t owner, gid\_t group)}
+  \funcdecl{int lchown(const char *path, uid\_t owner, gid\_t group)}
+
+  Le funzioni cambiano utente e gruppo di appartenenza di un file ai valori
+  specificati dalle variabili \var{owner} e \var{group}. 
+
+  Le funzioni restituiscono zero in caso di successo e -1 per un errore, in
+  caso di errore \texttt{errno} viene settato ai valori:
   \begin{errlist}
-  \item \texttt{EINVAL} L'argomento \texttt{size} è zero e \texttt{buffer} non
-    è nullo.
-  \item \texttt{ERANGE} L'argomento \texttt{size} è più piccolo della
-    lunghezza del pathname. 
-  \item \texttt{EACCESS} Manca il permesso di lettura o di ricerca su uno dei
-    componenti del pathname (cioè su una delle directory superiori alla
-    corrente).
+  \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
   \end{errlist}
-\end{prototype}
-
-Di questa funzione esiste una versione \texttt{char * getwd(char * buffer)}
-fatta per compatibilità all'indietro con BSD, che non consente di specificare
-la dimensione del buffer; esso deve essere allocato in precedenza ed avere una
-dimensione superiore a \texttt{PATH\_MAX} (di solito 256 byte, vedi
-\secref{sec:xxx_limits}); il problema è che in Linux non esiste una dimensione
-superiore per un pathname, per cui non è detto che il buffer sia sufficiente a
-contenere il nome del file, e questa è la ragione principale per cui questa
-funzione è deprecata.
+  Oltre a questi entrambe restituiscono gli errori \macro{EROFS} e
+  \macro{EIO}; \func{chown} restituisce anche \macro{EFAULT},
+  \macro{ENAMETOOLONG}, \macro{ENOENT}, \macro{ENOMEM}, \macro{ENOTDIR},
+  \macro{EACCES}, \macro{ELOOP}; \func{fchown} anche \macro{EBADF}.
+\end{functions}
 
-Una seconda funzione simile è \texttt{char * get\_current\_dir\_name(void)}
-che è sostanzialmente equivalente ad una \texttt{getcwd(NULL, 0)}, con la sola
-differenza che essa ritorna il valore della variabile di ambiente
-\texttt{PWD}, che essendo costruita dalla shell può contenere anche dei
-riferimenti simbolici.
+In Linux soltanto l'amministratore può cambiare il proprietario di un file,
+seguendo la semantica di BSD che non consente agli utenti di assegnare i loro
+file ad altri (per evitare eventuali aggiramenti delle quote).
+L'amministratore può cambiare il gruppo di un file, il proprietario può
+cambiare il gruppo dei file che gli appartengono solo se il nuovo gruppo è il
+suo gruppo primario o uno dei gruppi a cui appartiene.
 
-Come già detto in unix anche le directory sono file, è possibile pertanto
-riferirsi ad esse tramite il file descriptor dell'interfaccia a basso livello,
-e non solo tramite il filename; per questo motivo ci sono due diverse funzioni
-per cambiare directory di lavoro.
+La funzione \func{chown} segue i link simbolici, per operare direttamente su
+in link simbolico si deve usare la funzione \func{lchown}\footnote{fino alla
+  versione 2.1.81 in Linux \func{chown} non seguiva i link simbolici, da
+  allora questo comportamento è stato assegnato alla funzione \func{lchown},
+  introdotta per l'occasione, ed è stata creata una nuova system call per
+  \func{chown} che seguisse i link simbolici}. La funzione \func{fchown} opera
+su un file aperto, essa è mutuata da BSD, ma non è nello standard POSIX.
+Un'altra estensione rispetto allo standard POSIX è che specificando -1 come
+valore per \var{owner} e \var{group} i valori restano immutati. 
 
-\begin{prototype}{unistd.h}{int chdir (const char * pathname)}
-  Come dice il nome (che significa \textit{change directory}) questa funzione
-  serve a cambiare la directory di lavoro a quella specificata dal pathname
-  contenuto nella stringa \texttt{pathname}.
-\end{prototype}
-  
-\begin{prototype}{unistd.h}{int fchdir (int filedes)} 
-  Analoga alla precedente, ma usa un file descriptor invece del pathname.
+Quando queste funzioni sono chiamate con successo da un processo senza i
+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}.
 
-  Entrambe le funzioni restituiscono zero in caso di successo e -1 per un
-  errore, in caso di errore \texttt{errno} viene settata secondo i codici di
-  errore standard di accesso ai file (trattati in dettaglio in
-  \secref{sec:file_access_control}) ai quali si aggiunge il codice
-  \texttt{ENOTDIR} nel caso il \texttt{filename} indichi un file che non sia
-  una directory.
-\end{prototype}
+%La struttura fondamentale che contiene i dati essenziali relativi ai file è il
+%cosiddetto \textit{inode}; questo conterrà informazioni come il
+%tipo di file (file di dispositivo, directory, file di dati, per un elenco
+%completo vedi \ntab), i permessi (vedi \secref{sec:file_perms}), le date (vedi
+%\secref{sec:file_times}).
 
 
index 330f812b8a2a02dab3ebcc9bd94cbf10e93b93f9..7ed71e42b654c555d63ac01d0eab07c2ce84116b 100644 (file)
@@ -642,7 +642,7 @@ superblock principale.
 
 L'utilizzo di raggrupamenti di blocchi ha inoltre degli effetti positivi nelle
 prestazioni dato che viene ridotta la distanza fra i dati e la tabella degli
-inodes
+inode. 
 
 Le directory sono implementate come una linked list con voci di dimensione
 variabile. Ciascuna voce della lista contiene il numero di inode, la sua
@@ -652,5 +652,3 @@ in questo modo 
 
 
 
-
-
index 6e7bfe37299e3a7465f2d07beb0e2529b804b821..2e3e44c4aea6dbb953f0cc66820424810cc2570e 100644 (file)
--- a/gapil.tex
+++ b/gapil.tex
@@ -1,7 +1,7 @@
-%% 
+%%  
 %% GaPiL : Guida alla Programmazione in Linux
 %%
-%% S. Piccardi Oct. 2000
+%% S. Piccardi Oct. 2000 
 %%
 %% main.tex: file principale, gli altri vanno inclusi da questo.
 %%