-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:fileintr_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 \texttt{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:fileintr_symlink}) che molti programmi non sono in grado di
-gestire e la cui rimozione diventa estremamente complicata (in genere occorre
-far girare il programma \texttt{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 \texttt{EPERM}.
-
-La rimozione di un file (o più precisamente della voce che lo referenzia) si
-effettua con la funzione \texttt{unlink}; il suo prototipo è il seguente:
-
-\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 \texttt{EISDIR} \var{pathname} si riferisce ad una directory
- (valore specifico ritornato da linux che non consente l'uso di
- \texttt{unlink} con le directory, e non conforme allo standard POSIX, che
- prescrive invece l'uso di \texttt{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}
+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{enumerate}
+\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'\acr{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{enumerate}
+
+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 bit \acr{suid} e \acr{sgid}}
+\label{sec:file_suid_sgid}
+
+Come si è accennato (in \secref{sec:file_perm_overview}) nei dodici bit del
+campo \var{st\_mode} usati per il controllo di accesso oltre ai bit dei
+permessi veri e propri, ci sono altri tre bit che vengono usati per indicare
+alcune proprietà speciali dei file. Due di questi sono i bit detti
+\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}.