\func{fchown}, \func{fchmod}, \func{ioctl}, ecc.) fallirà con un errore di
\errval{EBADF}, come se questo non fosse un file descriptor valido. Per questo
motivo usando questo flag non è necessario avere nessun permesso per aprire un
-file, neanche quello di lettura (occorre ovviamente avere il permesso di
+file, neanche quello di lettura (ma occorre ovviamente avere il permesso di
esecuzione per le directory sovrastanti).
Questo consente di usare il file descriptor con funzioni che non richiedono
supportano l'uso come come primo argomento (torneremo su questo in
sez.~\ref{sec:file_openat}).
-
Nelle prime versioni di Unix i valori di \param{flag} specificabili per
\func{open} erano solo quelli relativi alle modalità di accesso del file. Per
questo motivo per creare un nuovo file c'era una \textit{system call}
Infine si tenga presente che, come accennato in sez.~\ref{sec:file_file_size},
con \func{lseek} è possibile impostare una posizione anche oltre la corrente
fine del file. In tal caso alla successiva scrittura il file sarà esteso a
-partire da detta posizione, con la creazione di quello che viene chiamato
+partire da detta posizione, con la creazione di quello che viene chiamato un
``\textsl{buco}'' (in gergo \textit{hole}) nel file. Il nome deriva dal fatto
che nonostante la dimensione del file sia cresciuta in seguito alla scrittura
-effettuata, lo spazio vuoto fra la precedente fine del file ed la nuova parte
-scritta dopo lo spostamento non corrisponde ad una allocazione effettiva di
+effettuata, lo spazio vuoto fra la precedente fine del file e la nuova parte,
+scritta dopo lo spostamento, non corrisponde ad una allocazione effettiva di
spazio su disco, che sarebbe inutile dato che quella zona è effettivamente
vuota.
Questa è una delle caratteristiche specifiche della gestione dei file di un
-sistema unix-like e si dice che il file in questione è uno \textit{sparse
- file}. In sostanza, se si ricorda la struttura di un filesystem illustrata
-in fig.~\ref{fig:file_filesys_detail}, quello che accade è che
-nell'\textit{inode} del file viene segnata l'allocazione di un blocco di dati
-a partire dalla nuova posizione, ma non viene allocato nulla per le posizioni
-intermedie; in caso di lettura sequenziale del contenuto del file il kernel si
-accorgerà della presenza del buco, e restituirà degli zeri come contenuto di
-quella parte del file.
+sistema unix-like e quando si ha questa situazione si dice che il file in
+questione è uno \textit{sparse file}. In sostanza, se si ricorda la struttura
+di un filesystem illustrata in fig.~\ref{fig:file_filesys_detail}, quello che
+accade è che nell'\textit{inode} del file viene segnata l'allocazione di un
+blocco di dati a partire dalla nuova posizione, ma non viene allocato nulla
+per le posizioni intermedie. In caso di lettura sequenziale del contenuto del
+file il kernel si accorgerà della presenza del buco, e restituirà degli zeri
+come contenuto di quella parte del file.
Questa funzionalità comporta una delle caratteristiche della gestione dei file
su Unix che spesso genera più confusione in chi non la conosce, per cui
\cmd{du}, che calcola lo spazio disco occupato in base al numero dei blocchi
effettivamente allocati per il file.
-Questo avviene proprio perché in un sistema unix-like la dimensione di un file
-è una caratteristica del tutto indipendente dalla quantità di spazio disco
-effettivamente allocato, e viene registrata sull'\textit{inode} come le altre
-proprietà del file. La dimensione viene aggiornata automaticamente quando si
-estende un file scrivendoci, e viene riportata dal campo \var{st\_size} di una
-struttura \struct{stat} quando si effettua la chiamata ad una delle funzioni
-\texttt{*stat} viste in sez.~\ref{sec:file_stat}.
-
-Questo comporta che in generale, fintanto che lo si è scritto sequenzialmente,
-la dimensione di un file sarà più o meno corrispondente alla quantità di
-spazio disco da esso occupato, ma esistono dei casi, come questo in cui ci si
-sposta in una posizione oltre la fine corrente del file, o come quello
-accennato in sez.~\ref{sec:file_file_size} in cui si estende la dimensione di
-un file con una \func{truncate}, in cui in sostanza si modifica il valore
-della dimensione di \var{st\_size} senza allocare spazio su disco. Questo
-consente di creare inizialmente file di dimensioni anche molto grandi, senza
-dover occupare da subito dello spazio disco che in realtà sarebbe
-inutilizzato.
+Tutto ciò avviene proprio perché in un sistema unix-like la dimensione di un
+file è una caratteristica del tutto indipendente dalla quantità di spazio
+disco effettivamente allocato, e viene registrata sull'\textit{inode} come le
+altre proprietà del file. La dimensione viene aggiornata automaticamente
+quando si estende un file scrivendoci, e viene riportata dal campo
+\var{st\_size} di una struttura \struct{stat} quando si effettua la chiamata
+ad una delle funzioni \texttt{*stat} viste in sez.~\ref{sec:file_stat}.
+
+Questo comporta che la dimensione di un file, fintanto che lo si è scritto
+sequenzialmente, sarà corrispondente alla quantità di spazio disco da esso
+occupato, ma possono esistere dei casi, come questo in cui ci si sposta in una
+posizione oltre la fine corrente del file, o come quello accennato in
+sez.~\ref{sec:file_file_size} in cui si estende la dimensione di un file con
+una \func{truncate}, in cui si modifica soltanto il valore della dimensione di
+\var{st\_size} senza allocare spazio su disco. Così è possibile creare
+inizialmente file di dimensioni anche molto grandi, senza dover occupare da
+subito dello spazio disco che in realtà sarebbe inutilizzato.
\itindend{sparse~file}
La funzione prende esattamente gli stessi argomenti di \func{read} con lo
stesso significato, a cui si aggiunge l'argomento \param{offset} che indica
-una posizione sul file a partire dalla quale verranno i \param{count}
+una posizione sul file a partire dalla quale verranno letti i \param{count}
byte. Identico è il comportamento ed il valore di ritorno, ma la posizione
corrente sul file resterà invariata. Il valore di \param{offset} fa sempre
riferimento all'inizio del file.
potuto scrivere qualsiasi dato.
\item[\errcode{EINVAL}] \param{fd} è connesso ad un oggetto che non consente
la scrittura o si è usato \const{O\_DIRECT} ed il buffer non è allineato.
-% \item[\errcode{EPERM}] la scrittura è proibita da un \textit{file seal}.
+ \item[\errcode{EPERM}] la scrittura è proibita da un \textit{file seal}
+ (vedi sez.~\ref{sec:file_fcntl_ioctl}).
\item[\errcode{EPIPE}] \param{fd} è connesso ad una \textit{pipe} il cui
altro capo è chiuso in lettura; in questo caso viene anche generato il
segnale \signal{SIGPIPE}, se questo viene gestito (o bloccato o ignorato)
della gestione file in un sistema unix-like, esaminando in dettaglio il
comportamento delle funzioni base, inoltre tratteremo le funzioni che
permettono di eseguire alcune operazioni avanzate con i file (il grosso
-dell'argomento sarà comunque affrontato in cap.~\ref{cha:file_advanced}).
+dell'argomento sarà comunque affrontato nel cap.~\ref{cha:file_advanced}).
\subsection{La gestione dell'accesso concorrente ai files}
Come accennato in sez.~\ref{sec:file_open_close} tutte le operazioni di
scrittura sono in genere bufferizzate dal kernel, che provvede ad effettuarle
-in maniera asincrona, ad esempio accorpando gli accessi alla stessa zona del
-disco in un secondo tempo rispetto al momento della esecuzione della
-\func{write}.
+in maniera asincrona per ottimizzarle, ad esempio accorpando gli accessi alla
+stessa zona del disco in un secondo tempo rispetto al momento della esecuzione
+della \func{write}.
-Per questo motivo quando è necessaria una sincronizzazione dei dati il sistema
-mette a disposizione delle funzioni che provvedono a forzare lo scarico dei
-dati dai buffer del kernel. La prima di queste funzioni di sistema è
-\funcd{sync}, il cui prototipo è:\footnote{questo è il prototipo usato a
- partire dalla \acr{glibc} 2.2.2 seguendo gli standard, in precedenza la
- funzione era definita come \code{int sync(void)} e ritornava sempre $0$.}
+Per questo motivo quando è necessaria una sincronizzazione immediata dei dati
+il sistema mette a disposizione delle funzioni che provvedono a forzare lo
+scarico dei dati dai buffer del kernel. La prima di queste funzioni di
+sistema è \funcd{sync}, il cui prototipo è:\footnote{questo è il prototipo
+ usato a partire dalla \acr{glibc} 2.2.2 seguendo gli standard, in precedenza
+ la funzione era definita come \code{int sync(void)} e ritornava sempre $0$.}
\begin{funcproto}{
\fhead{unistd.h}
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
+lavorando. se i dati in attesa sono molti questo può causare seri problemi di
prestazioni.
Per questo motivo è stata introdotta una nuova funzione di sistema,
\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}
}
\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 \param{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
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
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
ma la gestione sia delle loro proprietà, che di tutta una serie di ulteriori
funzionalità che il kernel può mettere a disposizione.
+% TODO: trattare qui i file seal
+
Per le operazioni di manipolazione e di controllo delle varie proprietà e
caratteristiche di un file descriptor, viene usata la funzione di sistema
\funcd{fcntl},\footnote{ad esempio si gestiscono con questa funzione varie
projects / gapil.git / blobdiff