From: Simone Piccardi Date: Sat, 26 Jan 2019 11:24:50 +0000 (+0100) Subject: Merge branch 'master' of ssh://roach.truelite.it/srv/git/gapil X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=commitdiff_plain;h=95289c5b54de712ed5b7119cdd7bb8df93a281ef Merge branch 'master' of ssh://roach.truelite.it/srv/git/gapil --- 95289c5b54de712ed5b7119cdd7bb8df93a281ef diff --cc fileio.tex index 41d3954,e6a904f..bc3edfb --- a/fileio.tex +++ b/fileio.tex @@@ -1734,16 -1734,18 +1734,17 @@@ diretto ad un file posto nella director 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}). + quanto visto per \func{access} in sez.~\ref{sec:file_perm_management}) + cambiando una delle directory sovrastanti il file fra un controllo e la + successiva apertura. - Inoltre come già accennato, la directory di lavoro corrente è una proprietà + Inoltre, come già accennato, la directory di lavoro corrente è una proprietà associata al singolo processo; questo significa che quando si lavora con i - \textit{thread} questa sarà sempre la stessa per tutti \textit{thread}, per - cui un cabiamento di directory di lavoro effettuato all'interno di un - \textit{thread} verrà applicato anche a tutti gli altri; 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. -\textit{thread} questa sarà sempre la stessa per tutti \textit{thread}, ed un -cambiamento di directory di lavoro effettuato all'interno di un \textit{thread} -verrà applicato a tutti gli altri. 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 di lavoro per risolvere i \textit{pathname} -relativi. ++\textit{thread} questa è la stessa per tutti, per cui se la si cambia ++all'interno di un \textit{thread} il cambiamento varrà anche per tutti gli ++altri. Non esiste quindi con le funzioni classiche un modo semplice per far sì ++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 @@@ -1807,29 -1821,24 +1820,23 @@@ esame la nuova funzione di sistema \fun Il comportamento di \func{openat} è del tutto analogo a quello di \func{open}, con la sola eccezione del fatto che se per l'argomento \param{pathname} si --utilizza un \textit{pathname} relativo questo, sarà risolto rispetto alla -directory indicata da \param{dirfd}. Qualora invece si usi un ++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 +se per \param{dirfd} si usa il valore speciale \constd{AT\_FDCWD} la risoluzione sarà effettuata rispetto alla directory di lavoro corrente del -processo. Si tenga presente però che questa costante, come le altre costanti -\texttt{AT\_*}, è definita in \headfile{fcntl.h}, pertanto se la si vuole -usare occorrerà includere comunque questo file, anche per le funzioni che non -sono definite in esso. +processo. Questa, come le altre costanti \texttt{AT\_*}, è definita in +\headfile{fcntl.h}, per cui per usarla occorrerà includere comunque questo +file, anche per le funzioni che non sono definite in esso. - Si tenga presente che l'uso di \func{openat} non risolve in generale tutte le - possibili \textit{race condition} legate 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 particolare si avrà un errore di \errcode{EBADF} se esso non è un file descriptor valido, ed un errore di \errcode{ENOTDIR} se esso non fa riferimento ad una directory, tranne il caso in cui si sia specificato un --\textit{pathname} assoluto, nel qual caso, come detto, il valore --di \param{dirfd} sarà completamente ignorato. ++\textit{pathname} assoluto, nel qual caso, come detto, il valore di ++\param{dirfd} sarà completamente ignorato. \begin{table}[htb] \centering @@@ -1844,13 -1853,16 +1851,16 @@@ \funcm{fchmodat} &$\bullet$&\func{chmod} \\ \func{fchownat} &$\bullet$&\func{chown},\func{lchown}\\ \funcm{fstatat} &$\bullet$&\func{stat},\func{lstat} \\ - \func{linkat} &$\bullet$\footnotemark&\func{link} \\ + \funcm{futimesat}& -- & obsoleta \\ - \func{linkat} &$\bullet$\footnotemark&\func{link} \\ ++ \func{linkat} &$\bullet$&\func{link} \\ \funcm{mkdirat} & -- &\func{mkdir} \\ \funcm{mkfifoat} & -- &\func{mkfifo} \\ \funcm{mknodat} & -- &\func{mknod} \\ \func{openat} & -- &\func{open} \\ \funcm{readlinkat}& -- &\func{readlink}\\ \funcm{renameat} & -- &\func{rename} \\ - \funcm{renameat2}& -- &\func{rename} \\ ++ \funcm{renameat2}\footnotemark& -- &\func{rename} \\ + \funcm{scandirat}& -- &\func{scandir} \\ \funcm{statx} &$\bullet$&\func{stat} \\ \funcm{symlinkat}& -- &\func{symlink} \\ \func{unlinkat} &$\bullet$&\func{unlink},\func{rmdir} \\ @@@ -1862,56 -1874,35 +1872,53 @@@ \label{tab:file_atfunc_corr} \end{table} --\footnotetext{in questo caso l'argomento \param{flags} è disponibile ed -- utilizzabile solo a partire dal kernel 2.6.18.} ++\footnotetext{anche se la funzione ha un argomento \param{flags} questo ++ attiene a funzionalità specifiche della stessa e non all'uso generico fatto ++ nelle altre \textit{at-functions}, pertanto lo si è indicato come assente.} In tab.~\ref{tab:file_atfunc_corr} si sono riportate le funzioni introdotte con questa nuova interfaccia, con a fianco la corrispondente funzione --classica. La gran parte di queste seguono la convenzione appena vista per --\func{openat}, in cui agli argomenti della corrispondente funzione classica --viene anteposto l'argomento \param{dirfd}, ed hanno per il resto un --comportamento identico e non staremo pertanto a trattarle una per una. Per una --parte di queste, indicate dal contenuto della omonima colonna di ++classica. Tutte seguono la convenzione appena vista per \func{openat}, in cui ++agli argomenti della funzione classica viene anteposto l'argomento ++\param{dirfd}. Per alcune, indicate dal contenuto della omonima colonna di 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 argomento finale, \param{flags}, che è stato introdotto ++per fornire un meccanismo con cui modificarne il comportamento. -Per le funzioni che lo prevedono l'ulteriore argomento \param{flag} è stato -introdotto per fornire un meccanismo con cui modificarne il comportamento. Il -solo caso generale, valido per tutte, è quello in cui si sta operando su un ++Buona parte di queste funzioni hanno un comportamento identico alla ++corrispondente funzione ordinaria, pertanto non le tratteremo esplicitamente, ++vale per loro quanto detto con \func{openat} per l'uso del nuovo argomento ++\param{dirfd}. + - % TODO trattare fstatat e con essa - % TODO trattare anche statx, aggiunta con il kernel 4.11 (vedi - % https://lwn.net/Articles/707602/ e - % https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a528d35e8bfcc521d7cb70aaf03e1bd296c8493f) - - % TODO manca prototipo di linkat, verificare se metterlo o metter menzione - % altre modifiche al riguardo nel 3.11 (AT_EMPTY_PATH?) vedi - % http://lwn.net/Articles/562488/ + - % TODO: Trattare esempio di inzializzazione di file e successivo collegamento - % con l'uso di O_TMPFILE e linkat, vedi man open + ++Il solo caso generale, valido per tutte, è quello in cui si sta operando su un + collegamento simbolico, e si vuole poter scegliere se far agire la funzione + direttamente sullo stesso o sul file da esso referenziato. Ma oltre a questo + caso generico, l'argomento viene usato per controllare ulteriori -caratteristiche di funzionamento, dipendenti dalla funzione stessa, per cui -deve essere comunque passato come maschera binaria ed impostato usando i -valori delle appropriate costanti \texttt{AT\_*}, definite in ++caratteristiche di funzionamento, dipendenti dalla funzione stessa; per questo ++motivo deve essere comunque passato come maschera binaria ed impostato usando ++i valori delle appropriate costanti \texttt{AT\_*}, definite in + \headfile{fcntl.h}. - % TODO manca prototipo di utimensat, verificare se metterlo o metter menzione - % TODO manca prototipo di renameat2, introdotta nel 3.15, vedi - % http://lwn.net/Articles/569134/ - % TODO manca prototipo di execveat, introdotta nel 3.19, vedi - % https://lwn.net/Articles/626150/ cerca anche fexecve + %% Verificare uso generico di AT_EMPTY_XX -Come esempio delle funzioni che lo utilizzano solo nel caso generico possiamo -considerare \funcd{fchownat}, che può essere usata per sostituire sia -\func{chown} che \func{lchown}; il suo prototipo è: +% TODO: trattare i nuovi AT_flags quando e se arriveranno, vedi +% https://lwn.net/Articles/767547/ + - +Per tutte le funzioni che lo prevedono, a parte \func{unlinkat} e +\funcd{faccessat}, l'ulteriore argomento è stato introdotto solo per fornire +un meccanismo con cui modificarne il comportamento nel caso si stia operando +su un collegamento simbolico, così da poter scegliere se far agire la funzione +direttamente sullo stesso o sul file da esso referenziato. Dato che in certi +casi esso può fornire ulteriori indicazioni per modificare il comportamento +delle funzioni, \param{flags} deve comunque essere passato come maschera +binaria, ed impostato usando i valori delle appropriate costanti +\texttt{AT\_*}, definite in \headfile{fcntl.h}. + +Come esempio di questo secondo tipo di funzioni possiamo considerare +\funcd{fchownat}, che può essere usata per sostituire sia \func{chown} +che \func{lchown}; il suo prototipo è: \begin{funcproto}{ \fhead{unistd.h} @@@ -2005,15 -1996,15 +2012,21 @@@ se \param{flags} è una maschera binari flag disponibile per questa funzione, lo si può assegnare direttamente. Infine una terza funzione, \funcm{linkat}, utilizza in maniera diversa dalle --altre l'argomento \param{flags}, anche se in questo caso l'utilizzo continua --ad essere attinente al comportamento con i collegamenti simbolici. Si ricordi --che su Linux il comportamento di \func{link} è quello di non seguire mai i ++altre l'argomento \param{flags},\footnote{si tenga presente che per questa ++ funzione l'argomento \param{flags} è disponibile ed utilizzabile solo a ++ partire dal kernel 2.6.18.} anche se in questo caso l'utilizzo continua ad ++essere attinente al comportamento con i collegamenti simbolici. Si ricordi che ++su Linux il comportamento di \func{link} è quello di non seguire mai i collegamenti simbolici, pertanto l'uso ordinario dell'argomento parrebbe in questo caso essere inutile. A partire dal kernel 2.6.18 invece però è stato aggiunta per questa funzione la possibilità di usare il valore \const{AT\_SYMLINK\_FOLLOW}, che richiede di dereferenziare i collegamenti simbolici. ++ ++ ++ ++ Dato che questo è il comportamento adottato per un valore nullo di \param{flags} da tutte le altre funzioni, \func{linkat} è l'unica per cui può essere usato esplicitamente questo valore e per la quale non ha senso