come i tempi del file. Se lo scopo dell'operazione, come avviene spesso per i
database, è assicurarsi che i dati raggiungano il disco e siano rileggibili
immediatamente in maniera corretta, è sufficiente l'uso di \func{fdatasync}
-che non comporta anche l'esecuzione di operazioni non necessarie all'integrità
-dei dati, come l'aggiornamento dei tempi di ultima modifica ed ultimo accesso.
+che evita le scritture non necessarie per avere l'integrità dei dati, come
+l'aggiornamento dei tempi di ultima modifica ed ultimo accesso.
Si tenga presente che l'uso di queste funzioni non comporta la
sincronizzazione della directory che contiene il file e la scrittura della
cui l'errore viene rilevato quando la scrittura viene effettivamente
eseguita.
-L'uso di \func{sync} presenta in certi casi, quando ci sono più filesystem
-montati, problemi di prestazioni dovute al fatto che la funzione provoca la
-sincronizzazione dei dati su tutti quanti i filesystem, anche quando
-interesserebbe che questo avvenga soltanto su quello dei file su cui si sta
-lavorando. se i dati in attesa sono molti questo può causare seri problemi di
-prestazioni.
+L'uso di \func{sync} può causare, quando ci sono più filesystem montati,
+problemi di prestazioni dovuti al fatto che effettua la sincronizzazione dei
+dati su tutti i filesystem, anche quando sarebbe sufficiente eseguirla
+soltanto su quello dei file su cui si sta lavorando; quando i dati in attesa
+sono molti questo può causare una alta attività di I/O ed i relativi problemi
+di prestazioni.
Per questo motivo è stata introdotta una nuova funzione di sistema,
\funcd{syncfs},\footnote{la funzione è stata introdotta a partire dal kernel
\end{funcproto}
La funzione richiede che si specifichi nell'argomento \param{fd} un file
-descriptor su cui si sta operando, e lo scarico dei dati sarà limitato al
-filesystem su cui il file ad esso corrispondente si trova.
+descriptor su cui si sta operando, e la registrazione immediata dei dati sarà
+limitata al filesystem su cui il file ad esso corrispondente si trova.
-\subsection{Le \textit{at-functions}: \func{openat} e affini}
+\subsection{Le \textit{at-functions}: \func{openat} e compagnia}
\label{sec:file_openat}
\itindbeg{at-functions}
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 è 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
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} (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
+ad essere incluse in una recente revisione dello standard POSIX.1 (la
+POSIX.1-2008). Con la \acr{glibc} per l'accesso a queste funzioni è necessario
+definire la macro \macro{\_ATFILE\_SOURCE} (comunque attiva di default).
+
+L'uso di queste funzioni richiede una apertura preliminare della directory che
+si intende usare come base per la risoluzione dei \textit{pathname} relativi
+(ad esempio usando \func{open} con il flag \const{O\_PATH} visto in
+sez.~\ref{sec:file_open_close}) per ottenere un file descriptor che dovrà
+essere passato alle stesse. Tutte queste funzioni infatti prevedono la
+presenza un apposito argomento, in genere il primo, che negli esempi seguenti
+chiameremo sempre \param{dirfd}.
+
+In questo modo, una volta aperta la directory di partenza, si potranno
+effettuare controlli ed aperture solo con \textit{pathname} relativi alla
+stessa, e tutte le \textit{race condition} dovute al possibile cambiamento di
+uno dei componenti posti al di sopra della stessa cesseranno di esistere.
+Inoltre, pur restando la directory di lavoro una proprietà comune del
+processo, si potranno usare queste funzioni quando si lavora con i
+\textit{thread} per eseguire la risoluzione dei \textit{pathname} relativi ed
+avere una directory di partenza diversa in ciascuno di essi.
+
+Questo metodo consente inoltre 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. Infine poter identificare una directory di partenza
+tramite il suo file descriptor consente di avere un riferimento stabile alla
+stessa anche qualora venisse rinominata, e tiene occupato il filesystem dove
+si trova, come per la directory di lavoro di un processo.
+
+La sintassi generica di queste nuove funzioni prevede 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. Come esempio prendiamo in
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
+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
\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$&\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}\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.
+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 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
% 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
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
\textbf{Costante} & \textbf{Significato} \\
\hline
\hline
- \constd{AT\_SYMLINK\_NOFOLLOW}& Se impostato la funzione non esegue la
- dereferenziazione dei collegamenti
- simbolici.\\
- \constd{AT\_SYMLINK\_FOLLOW}& Se impostato la funzione esegue la
- dereferenziazione dei collegamenti simbolici
- (usato esplicitamente solo da
- \func{linkat}).\\
\constd{AT\_EACCES} & Usato solo da \func{faccessat}, richiede che
il controllo dei permessi sia fatto usando
l'\ids{UID} effettivo invece di quello
reale.\\
+ \constd{AT\_EMPTY\_PATH} & Usato da varie funzioni per operare
+ direttamente (specificando una stringa vuota
+ per il \texttt{pathname}) sul file descriptor
+ \param{dirfd} che in questo caso deve essere
+ ottenuto aprendo un file, che
+ può non essere una directory, con il flag
+ \param{O\_PATH} (vedi
+ sez.~\ref{sec:file_open_close}).\\
\constd{AT\_REMOVEDIR} & Usato solo da \func{unlinkat}, richiede che
la funzione si comporti come \func{rmdir}
invece che come \func{unlink}.\\
+ \constd{AT\_SYMLINK\_FOLLOW}& Se impostato la funzione esegue la
+ dereferenziazione dei collegamenti simbolici
+ (usato esplicitamente solo da
+ \func{linkat}).\\
+ \constd{AT\_SYMLINK\_NOFOLLOW}& Se impostato la funzione non esegue la
+ dereferenziazione dei collegamenti
+ simbolici.\\
\hline
\end{tabular}
\caption{Le costanti utilizzate per i bit dell'argomento
\end{table}
+
+
+% 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
+
+
+% 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
+
+
\texttt{ATTENZIONE PARTE DA RIVEDERE}
% LocalWords: nell' du vm Documentation Urlich Drepper futimesat times l'I
% LocalWords: futimens fs Tread all'I ll TMPFILE EDQUOT extN Minix UDF XFS
% LocalWords: shmem Btrfs ubifs tmpfile fchmod fchown fsetxattr fchdir PF
-% LocalWords: fstatfs sull' SIGTTIN EDESTADDRREQ datagram connect
+% LocalWords: fstatfs sull' SIGTTIN EDESTADDRREQ datagram connect seal
+% LocalWords: dirty execveat execve scandirat statx
projects / gapil.git / commitdiff