Appunti dalla conferenza
authorSimone Piccardi <piccardi@truelite.it>
Tue, 4 Dec 2018 14:55:38 +0000 (15:55 +0100)
committerSimone Piccardi <piccardi@truelite.it>
Tue, 4 Dec 2018 14:55:38 +0000 (15:55 +0100)
domandemanpages.txt
fileio.tex
procadv.tex

index 484bd80..a06a041 100644 (file)
@@ -4,3 +4,5 @@ sottinsieme di quelle effettive)
 Con readv/writev che fine ha fatto EOPNOTSUPP?
 
 tee ed il supporto per i socket ?
+
+openat e il supposto problema della race condition.
index baf2f0a..419877a 100644 (file)
@@ -1728,61 +1728,64 @@ filesystem su cui il file ad esso corrispondente si trova.
 
 \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à
-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
-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}.}
+
 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
-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}
@@ -1801,10 +1804,10 @@ esame la nuova funzione di sistema \funcd{openat}, avremo il prototipo:
 }  
 \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
@@ -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.
 
+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
@@ -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}.
 
 
-
-
 % TODO trattare fstatat e con essa
 % TODO trattare anche statx, aggiunta con il kernel 4.11 (vedi
 % https://lwn.net/Articles/707602/ e
index 79847ea..4989cee 100644 (file)
@@ -407,6 +407,12 @@ Introdotta a partire dal kernel 2.4.21, solo su PowerPC.
 % TODO: trattare PTRACE_O_SUSPEND_SECCOMP, aggiunta con il kernel 4.3, vedi
 % http://lwn.net/Articles/656675/ 
 
+\subsection{La funzione \func{kcmp}}
+\label{sec:process_kcmp}
+
+%Da fare
+% vedi man kcmp e man 2 open
+
 
 \section{La gestione avanzata della creazione dei processi}
 \label{sec:process_adv_creation}