Merge branch 'master' of ssh://roach.truelite.it/srv/git/gapil
authorSimone Piccardi <piccardi@gnulinux.it>
Sat, 26 Jan 2019 11:24:50 +0000 (12:24 +0100)
committerSimone Piccardi <piccardi@gnulinux.it>
Sat, 26 Jan 2019 11:24:50 +0000 (12:24 +0100)
1  2 
fileio.tex

diff --cc 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
       \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}
@@@ -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