Appunti dalla conferenza
[gapil.git] / fileio.tex
index baf2f0ae52c2c4da20d4467fe7061b663a84174a..419877a21af55b911f88481c2aba421ec1983360 100644 (file)
@@ -1728,61 +1728,64 @@ filesystem su cui il file ad esso corrispondente si trova.
 
 \itindbeg{at-functions}
 
 
 \itindbeg{at-functions}
 
-Un problema generale che si pone con l'uso della funzione \func{open}, così
-come per le altre funzioni che prendono come argomenti dei \textit{pathname}
-relativi, è la possibilità, quando un \textit{pathname} relativo non fa
-riferimento ad un file posto direttamente nella directory di lavoro corrente,
-che alcuni dei componenti del \textit{pathname} vengano modificati in
-parallelo alla chiamata a \func{open}, cosa che lascia aperta la possibilità
-di una \textit{race condition} in cui c'è spazio per un \textit{symlink
-  attack} (si ricordi quanto visto per \func{access} in
-sez.~\ref{sec:file_perm_management}).
+Un problema generico che si pone con l'uso della funzione \func{open}, così
+come con le altre funzioni che prendono come argomenti dei \textit{pathname},
+è la possibilità, quando si usa un \textit{pathname} che non fa riferimento
+diretto ad un file posto nella directory di lavoro corrente, che alcuni dei
+componenti dello stesso vengano modificati in parallelo alla chiamata a
+\func{open}, cosa che lascia aperta la possibilità di una \textit{race
+  condition} in cui c'è spazio per un \textit{symlink attack} (si ricordi
+quanto visto per \func{access} in sez.~\ref{sec:file_perm_management}). 
 
 Inoltre come già accennato, la directory di lavoro corrente è una proprietà
 
 Inoltre come già accennato, la directory di lavoro corrente è una proprietà
-del singolo processo; questo significa che quando si lavora con i
-\textit{thread} essa sarà la stessa per tutti, ma esistono molti casi in cui
-sarebbe invece utile che ogni singolo \textit{thread} avesse la sua directory
-di lavoro.
+associata al singolo processo; questo significa che quando si lavora con i
+\textit{thread} questa sarà sempre la stessa per tutti \textit{thread}, ed un
+cabiamento di directory di lavoro effettuato all'interno di un \textit{thread}
+verrà applicato a tutti, non esiste quindi con le funzioni classiche un modo
+semplice per far si che i singoli \textit{thread} possano aprire file usando
+una propria directory per risolvere i \textit{pathname} relativi.
 
 Per risolvere questi problemi, riprendendo una interfaccia già presente in
 Solaris, a fianco delle normali funzioni che operano sui file (come
 \func{open}, \func{mkdir}, ecc.) sono state introdotte delle ulteriori
 
 Per risolvere questi problemi, riprendendo una interfaccia già presente in
 Solaris, a fianco delle normali funzioni che operano sui file (come
 \func{open}, \func{mkdir}, ecc.) sono state introdotte delle ulteriori
-funzioni, dette anche ``\textit{at-functions}'' in quanto contraddistinte dal
-suffisso \texttt{at}, che permettono l'apertura di un file (o le rispettive
-altre operazioni) usando un \textit{pathname} relativo ad una directory
-specificata.\footnote{l'introduzione è avvenuta su proposta dello sviluppatore
-  principale della \acr{glibc} Urlich Drepper e le corrispondenti
-  \textit{system call} sono state inserite nel kernel a partire dalla versione
-  2.6.16, in precedenza era disponibile una emulazione che, sia pure con
-  prestazioni inferiori, funzionava facendo ricorso all'uso del filesystem
-  \textit{proc} con l'apertura del file attraverso il riferimento a
+funzioni di sistema, chiamate ``\textit{at-functions}'' in quanto quasi tutte
+sono contraddistinte dal suffisso \texttt{at}, che permettono l'apertura di un
+file (o le rispettive altre operazioni) usando un \textit{pathname} relativo
+ad una directory specificata.\footnote{l'introduzione è avvenuta su proposta
+  dello sviluppatore principale della \acr{glibc} Urlich Drepper e le
+  corrispondenti \textit{system call} sono state inserite nel kernel a partire
+  dalla versione 2.6.16, in precedenza era disponibile una emulazione che, sia
+  pure con prestazioni inferiori, funzionava facendo ricorso all'uso del
+  filesystem \textit{proc} con l'apertura del file attraverso il riferimento a
   \textit{pathname} del tipo di \texttt{/proc/self/fd/dirfd/relative\_path}.}
   \textit{pathname} del tipo di \texttt{/proc/self/fd/dirfd/relative\_path}.}
+
 Benché queste funzioni non siano presenti negli standard tradizionali esse
 sono state adottate da altri sistemi unix-like come Solaris, i vari BSD, fino
 ad essere incluse in una recente revisione (la POSIX.1-2008) dello standard
 POSIX.1. Con la \acr{glibc} per l'accesso a queste funzioni è necessario
 Benché queste funzioni non siano presenti negli standard tradizionali esse
 sono state adottate da altri sistemi unix-like come Solaris, i vari BSD, fino
 ad essere incluse in una recente revisione (la POSIX.1-2008) dello standard
 POSIX.1. Con la \acr{glibc} per l'accesso a queste funzioni è necessario
-definire la macro \macro{\_ATFILE\_SOURCE}.
-
-L'uso di queste funzioni prevede una apertura iniziale della directory che
-sarà la base della risoluzione dei \textit{pathname} relativi che verranno
-usati in seguito, dopo di che si dovrà passare il relativo file descriptor
-alle varie funzioni che useranno quella directory come punto di partenza per
-la risoluzione. In questo modo, anche quando si lavora con i \textit{thread},
-si può mantenere una directory di lavoro diversa per ciascuno di essi.
-
-Questo metodo, oltre a risolvere i problemi di \textit{race condition},
-consente anche di ottenere aumenti di prestazioni significativi quando si
-devono eseguire molte operazioni su sezioni dell'albero dei file che prevedono
-delle gerarchie di sottodirectory molto profonde. Infatti in questo caso basta
-eseguire la risoluzione del \textit{pathname} della directory di partenza una
-sola volta (nell'apertura iniziale) e non tutte le volte che si deve accedere
-a ciascun file che essa contiene.
-
-La sintassi generale di queste nuove funzioni è che esse prevedono come primo
-argomento il file descriptor della directory da usare come base per la
+definire la macro \macro{\_ATFILE\_SOURCE} (attiva di default).
+
+L'uso di queste funzioni prevede una apertura iniziale della directory che si
+intende usare come base per la risoluzione dei \textit{pathname} relativi,
+dopo di che si dovrà passare il suddetto file descriptor alle stesse, che
+useranno quella directory come punto di partenza per la risoluzione. In questo
+modo, anche quando si lavora con i \textit{thread}, si può mantenere una
+directory di lavoro diversa per ciascuno di essi.
+
+Questo metodo, oltre a risolvere i problemi di \textit{race condition} dovuti
+al possibile cambiamento di uno dei componenti del \textit{pathname}, consente
+anche di ottenere aumenti di prestazioni significativi quando si devono
+eseguire molte operazioni su sezioni dell'albero dei file che prevedono delle
+gerarchie di sottodirectory molto profonde. Infatti in questo caso basta
+eseguire la risoluzione del \textit{pathname} di una qualunque directory di
+partenza una sola volta (nell'apertura iniziale) e non tutte le volte che si
+deve accedere a ciascun file che essa contiene. 
+
+La sintassi generale di queste nuove funzioni è l'utilizzo come primo
+argomento del file descriptor della directory da usare come base per la
 risoluzione dei nomi, mentre gli argomenti successivi restano identici a
 risoluzione dei nomi, mentre gli argomenti successivi restano identici a
-quelli della corrispondente funzione ordinaria. Se ad esempio prendiamo in
-esame la nuova funzione di sistema \funcd{openat}, avremo il prototipo:
+quelli della corrispondente funzione ordinaria. Come esempio prendiamo in
+esame la nuova funzione di sistema \funcd{openat}, il cui prototipo è:
 
 \begin{funcproto}{
 \fhead{fcntl.h}
 
 \begin{funcproto}{
 \fhead{fcntl.h}
@@ -1801,10 +1804,10 @@ esame la nuova funzione di sistema \funcd{openat}, avremo il prototipo:
 }  
 \end{funcproto}
 
 }  
 \end{funcproto}
 
-Il comportamento delle nuove funzioni è del tutto analogo a quello delle
-corrispettive classiche, con la sola eccezione del fatto che se fra i loro
-argomenti si utilizza un \textit{pathname} relativo questo sarà risolto
-rispetto alla directory indicata da \param{dirfd}. Qualora invece si usi un
+Il comportamento di \func{openat} è del tutto analogo a quello di \func{open},
+con la sola eccezione del fatto che se per l'argomento \pathname{pathname} si
+utilizza un \textit{pathname} relativo questo, sarà risolto rispetto alla
+directory indicata da \param{dirfd}. Qualora invece si usi un
 \textit{pathname} assoluto \param{dirfd} verrà semplicemente ignorato. Infine
 se per \param{dirfd} si usa il valore speciale \constd{AT\_FDCWD}, la
 risoluzione sarà effettuata rispetto alla directory di lavoro corrente del
 \textit{pathname} assoluto \param{dirfd} verrà semplicemente ignorato. Infine
 se per \param{dirfd} si usa il valore speciale \constd{AT\_FDCWD}, la
 risoluzione sarà effettuata rispetto alla directory di lavoro corrente del
@@ -1813,6 +1816,12 @@ processo. Si tenga presente però che questa, come le altre costanti
 usare occorrerà includere comunque questo file, anche per le funzioni che non
 sono definite in esso.
 
 usare occorrerà includere comunque questo file, anche per le funzioni che non
 sono definite in esso.
 
+Si tenga comunque presente che l'uso di \func{openat} non risolve in generale
+tutte le possibili \textit{race condition} legati all'apertura di un file,
+dopo un eventuale controllo di accesso o esistenza, ma consente comunque di
+difendersi da tutti gli attacchi eseguiti modificando le componenti superiori
+del suo \textit{pathname}. Inoltre una ...
+
 Così come il comportamento, anche i valori di ritorno e le condizioni di
 errore delle nuove funzioni sono gli stessi delle funzioni classiche, agli
 errori si aggiungono però quelli dovuti a valori errati per \param{dirfd}; in
 Così come il comportamento, anche i valori di ritorno e le condizioni di
 errore delle nuove funzioni sono gli stessi delle funzioni classiche, agli
 errori si aggiungono però quelli dovuti a valori errati per \param{dirfd}; in
@@ -1867,8 +1876,6 @@ tab.~\ref{tab:file_atfunc_corr}, oltre al nuovo argomento iniziale, è prevista
 anche l'aggiunta di un ulteriore argomento finale, \param{flags}.
 
 
 anche l'aggiunta di un ulteriore argomento finale, \param{flags}.
 
 
-
-
 % TODO trattare fstatat e con essa
 % TODO trattare anche statx, aggiunta con il kernel 4.11 (vedi
 % https://lwn.net/Articles/707602/ e
 % TODO trattare fstatat e con essa
 % TODO trattare anche statx, aggiunta con il kernel 4.11 (vedi
 % https://lwn.net/Articles/707602/ e