+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.
+
+
+
+\section{Il controllo di accesso ai file}
+\label{sec:filedir_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{I permessi per l'accesso ai file}
+\label{sec:filedir_perm_overview}
+
+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 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.
+
+Ad ogni file unix associa sempre l'utente che ne è proprietario (il cosiddetto
+\textit{owner}) e il gruppo di appartenenza, secondo il meccanismo degli
+identificatori di utenti e gruppi (\textsl{uid} e \textsl{gid}), e accessibili
+da programm tramite i campi \var{st\_uid} e \var{st\_gid} della struttura
+\var{stat} (si veda \secref{sec:filedir_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.
+
+I permessi sono espressi da un insieme 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 rispettivamente con le lettere
+\textsl{w}, \textit{r} \textsl{x} nei comandi di sistema) applicabili
+rispettivamente al proprietario, al gruppo, a tutti. I restanti tre bit
+(\textsl{suid}, \textsl{sgid}, e \textsl{sticky}) sono usati per indicare
+alcune caratteristiche più complesse su cui torneremo in seguito (vedi
+\secref{sec:filedir_suid_sgid} e \secref{sec:filedir_sticky}).
+
+Anche i permessi sono tenuti per ciascun file (di qualunque tipo, quindi anche
+per le fifo, i socket e i file di dispositivo) nell'inode, in opportuni bit
+del campo \var{st\_mode} della struttura letta da \func{stat} (vedi
+\figref{fig:filedir_stat_struct}).
+
+
+In genere ci si riferisce a questi permessi usando le lettere \textsl{u} (per
+\textit{user}), \textsl{g} (per \textit{group}) e \textsl{o} (per
+\textit{other}), inoltre se si vuole indicare tutti questi gruppi insieme si
+usa la lettera \textsl{a} (per \textit{all}). Si tenga ben presente questa
+distinzione, dato che in certi casi, mutuando la termimologia in uso nel VMS,
+si parla dei permessi base come di permessi di owner, group ed all, le cui
+iniziali possono da luogo a confuzione. Le costanti che permettono di accedere
+al valore numerico di questi bit sono riportate in \ntab.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|c|l|}
+ \hline
+ \var{st\_mode} bit & 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}
+
+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 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).
+
+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).
+
+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. 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}.
+
+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 fisica del file), non è
+necessario nessun tipo di permesso per il file stesso (infatti esso non viene
+toccato, viene solo modificato il contenute della directory).
+
+Per poter eseguire un file (che sia un programma compilato od uno script di
+shell), occorre il permesso di esecuzione per il medesimo, inoltre solo i file
+regolari possono essere eseguiti.
+
+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.
+
+Per una spiegazione dettagliata degli identificatori associati ai processi si
+veda \secref{sec:prochand_perms}; normalmente, a parte quanto vedremo in
+\secref{sec:filedir_suid_sgid}, l'\textit{effective user id} e
+l'\textit{effective group id} corrispondono a uid e gid dell'utente che ha
+lanciato il processo, mentre i \textit{supplementary group id} sono quelli dei
+gruppi cui l'utente appartiene.
+
+% Quando un processo cerca l'accesso al file esso controlla i propri uid e gid
+% confrontandoli con quelli del file e se l'operazione richiesta è compatibile
+% con i permessi associati al file essa viene eseguita, altrimenti viene
+% bloccata ed è restituito un errore di \texttt{EPERM}. Questo procedimento non
+% viene eseguito per l'amministratore di sistema (il cui uid è zero) il quale
+% a
+% pertanto accesso senza restrizione a qualunque file del sistema.
+
+% In realtà il procedimento è più complesso di quanto descritto in maniera
+% elementare qui; inoltre ad un processo sono associati diversi identificatori,
+% torneremo su questo in maggiori dettagli in seguito in
+% \secref{sec:proc_perms}.
+
+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 gid del file
+ allora:
+ \begin{itemize}
+ \item se il bit dei permessi d'accesso del gruppo è settato, l'accesso è
+ consentito, 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}
+
+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.
+
+\subsection{I flag \texttt{suid} e \texttt{sgid}}
+\label{sec:filedir_suid_sgid}
+
+Quandi si lancia un programma in genere l'\textit{effective user id} e
+l'\textit{effective group id} sono settati rispettivamente all'uid e al gid
+dell'utente che ha lanciato il programma.
+
+
+Ma nei dodici bit del campo \var{st\_mode} relativi ai permessi esiste un bit
+speciale, il \textit{set-user-ID bit} o suid, che se settato fa si che quando
+un programma viene lanciato invece di avere assegnato come \textit{effective
+ user id} l'uid di chi lo lancia, assume quello del proprietario del file.
+Analogamente il \textit{set-group-ID bit} o sgid settato per un file ha lo
+stesso effetto sull'\textit{effective group id}.
+
+Questa caratteristica viene usata 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,
+che può essere scritto solo dall'amministratore. Per questo il comando
+\cmd{passwd} appartiene a root e ha il suid bit settato per cui quando viene
+lanciato da un utente normale ha comunque i privilegi di root.
+
+Chiaramente avere un processo che ha privilegi superiori a quelli che avrebbe
+normalmente un utente comporta vari rischi, e questo tipo di programmi devono
+essere scritti accuratamente (torneremo sull'argomento in
+\secref{sec:prochand_perms}).
+
+I due bit suid e sgid possono essere controllati all'interno di \var{st\_mode}
+con l'uso delle due costanti \macro{S\_ISUID} e \macro{S\_ISGID}, definite in
+\tabref{tab:filedir_file_mode_flags}.
+
+
+\subsection{Il flag \texttt{sticky}}
+\label{sec:filedir_sticky}
+
+L'ultimo
+
+\subsection{La titolarità di nuovi files e directory}
+\label{sec:filedir_ownership}
+
+
+\subsection{La funzione \texttt{access}}
+\label{sec:filedir_access}
+
+
+\subsection{La funzione \texttt{umask}}
+\label{sec:filedir_umask}
+
+
+\subsection{Le funzioni \texttt{chmod} e \texttt{fchmod}}
+\label{sec:filedir_chmod}
+
+\subsection{Le funzioni \texttt{chown}, \texttt{fchown} e \texttt{lchown}}
+\label{sec:filedir_chown}
+
+
+
+
+%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}).
+