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
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
\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} \\
\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}
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
projects / gapil.git / commitdiff