From 4d8005673a429c8d47d1b21b84aa839afdf17dda Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Tue, 4 Dec 2018 15:55:38 +0100 Subject: [PATCH] Appunti dalla conferenza --- domandemanpages.txt | 2 + fileio.tex | 105 +++++++++++++++++++++++--------------------- procadv.tex | 6 +++ 3 files changed, 64 insertions(+), 49 deletions(-) diff --git a/domandemanpages.txt b/domandemanpages.txt index 484bd80..a06a041 100644 --- a/domandemanpages.txt +++ b/domandemanpages.txt @@ -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. diff --git a/fileio.tex b/fileio.tex index baf2f0a..419877a 100644 --- a/fileio.tex +++ b/fileio.tex @@ -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 diff --git a/procadv.tex b/procadv.tex index 79847ea..4989cee 100644 --- a/procadv.tex +++ b/procadv.tex @@ -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} -- 2.30.2