-\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{I permessi per l'accesso ai file}
-\label{sec:file_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 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.
-
-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.
-
-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}).
-
-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.
-
-\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}
-
-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).
-
-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}.
-
-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).
-
-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.
-
-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}).
-
-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.
-
-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}
-
-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.