Come si può notare dall'estratto di fig.~\ref{fig:kstruct_file}, la struttura
\kstruct{file} contiene, oltre ad alcune informazioni usate dall'interfaccia
-dei file descriptor il cui significato emergerà più avanti, il puntatore
-\var{f\_op} ad una struttura \kstruct{file\_operation}. Questa è l'analoga per
-i file di \kstruct{inode\_operation}, e definisce le operazioni generiche
-fornite dal VFS per i file. Si sono riportate in
-tab.~\ref{tab:file_file_operations} le più significative.
+dei file descriptor il cui significato emergerà più avanti (vedi
+sez.~\ref{sec:file_unix_interface}), il puntatore \var{f\_op} ad una struttura
+\kstruct{file\_operation}. Questa è l'analoga per i file di
+\kstruct{inode\_operation}, e definisce le operazioni generiche fornite dal
+VFS per i file. Si sono riportate in tab.~\ref{tab:file_file_operations} le
+più significative.
\begin{table}[htb]
\centering
mount}. Lo scopo dell'opzione è ottenere che tutti i successivi
\textit{bind mount} ottenuti da un \textit{mount point} così marcato siano
di tipo \textit{shared} e vengano inseriti nello stesso \textit{mount peer
- group} in modo da ``\textsl{condivere}'' ogni ulteriore operazione di
+ group} in modo da ``\textsl{condividere}'' ogni ulteriore operazione di
montaggio o smontaggio. Con questa opzione le operazioni di montaggio e
smontaggio effettuate al di sotto di uno \textit{shared mount} vengono
automaticamente ``\textsl{propagate}'' a tutti gli altri membri del
simbolico. Pertanto un collegamento simbolico può anche riferirsi ad un file
che non esiste ed in questo caso si ha quello che viene chiamato un
\itindex{dangling~link} \textit{dangling link}, letteralmente un
-\index{collegamento!ciondolante} ``\textsl{collegamento ciondolante}''.
+\index{collegamento!ciondolante} ``\textsl{collegamento ciondolante}''. Ad
+esempio possiamo usare il comando \cmd{ln} per creare un collegamento
+simbolico nella nostra directory con:
+\begin{Console}
+piccardi@hain:~/gapil$ \textbf{ln -s /tmp/tmp_file symlink}
+\end{Console}
+%$
+e questo avrà successo anche se \file{/tmp/tmp\_file} non esiste:
+\begin{Console}
+piccardi@hain:~/gapil$ \textbf{ls symlink}
+symlink
+\end{Console}
+%$
+ma questo può generare confusione, perché accedendo in lettura a
+\file{symlink}, ad esempio con \cmd{cat}, otterremmo:
+\begin{Console}
+piccardi@hain:~/gapil$ \textbf{cat symlink}
+cat: symlink: No such file or directory
+\end{Console}
+%$
+con un errore che può sembrare sbagliato, dato che \cmd{ls} ci ha mostrato in
+precedenza l'esistenza di \file{symlink}. Se invece andassimo a scrivere su
+\file{symlink}, l'effetto sarebbe quello di ottenere la creazione di
+\file{/tmp/tmp\_file} (che a quel punto verrebbe creato) senza errori.
Come accennato i collegamenti simbolici sono risolti automaticamente dal
kernel all'invocazione delle varie \textit{system call}. In
sez.~\ref{sec:file_open_close}) e tutte le operazioni seguenti fanno
riferimento solo a quest'ultimo.
+Si tenga anche presente che a partire dal kernel 3.16, se si abilita la
+funzionalità dei \textit{protected symlinks} (attiva di default in tutte le
+distribuzioni più recenti) la risoluzione dei nomi attraverso un collegamento
+simbolico può fallire per una serie di restrizione di sicurezza aggiuntive
+imposte dal meccanismo (si consulti sez.~\ref{sec:procadv_security_misc} per i
+dettagli).
+
Dato che, come indicato in tab.~\ref{tab:file_symb_effect}, funzioni come la
\func{open} seguono i collegamenti simbolici, occorrono funzioni apposite per
accedere alle informazioni del collegamento invece che a quelle del file a cui
\begin{funcproto}{
\fhead{unistd.h}
-\fdecl{int readlink(const char *path, char *buff, size\_t size)}
+\fdecl{int readlink(const char *pathname, char *buff, size\_t size)}
\fdesc{Legge il contenuto di un collegamento simbolico.}
}
{La funzione ritorna il numero di caratteri letti dentro \param{buff} in caso
di successo e $-1$ per un errore, nel qual caso \var{errno} assumerà uno
dei valori:
\begin{errlist}
- \item[\errcode{EINVAL}] \param{path} non è un collegamento simbolico
+ \item[\errcode{EACCES}] non si hanno i permessi di attraversamento di una
+ delle directory del pathname
+ \item[\errcode{EINVAL}] \param{pathname} non è un collegamento simbolico
o \param{size} non è positiva.
- \end{errlist} ed inoltre \errval{EACCES}, \errval{EFAULT}, \errval{EIO},
- \errval{ELOOP}, \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM} e
- \errval{ENOTDIR} nel loro significato generico.}
+ \end{errlist} ed inoltre \errval{EFAULT}, \errval{EIO}, \errval{ELOOP},
+ \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM} e \errval{ENOTDIR}
+ nel loro significato generico.}
\end{funcproto}
La funzione legge il \textit{pathname} a cui fa riferimento il collegamento
-simbolico indicato dall'argomento \param{path} scrivendolo sul
-buffer \param{buff} di dimensione \param{size}. Si tenga presente che la
-funzione non termina la stringa con un carattere nullo e che se questa è
-troppo lunga la tronca alla dimensione specificata da \param{size} per evitare
-di sovrascrivere oltre le dimensioni del buffer.
+simbolico indicato dall'argomento \param{pathname} scrivendolo sul buffer
+\param{buff} di dimensione \param{size}. Si tenga presente che la funzione non
+termina la stringa con un carattere nullo e che se questa è troppo lunga la
+tronca alla dimensione specificata da \param{size} per evitare di scrivere
+dati oltre le dimensioni del buffer.
\begin{figure}[htb]
\centering
- \includegraphics[width=8.5cm]{img/link_loop}
+ \includegraphics[width=8cm]{img/link_loop}
\caption{Esempio di loop nel filesystem creato con un collegamento
simbolico.}
\label{fig:file_link_loop}
dei nomi che non possono essere eliminati facilmente. Invece è sempre
possibile, ed in genere anche molto utile, creare un collegamento simbolico ad
una directory, anche se in questo caso si potranno ottenere anche dei
-\textit{loop}. La situazione è illustrata in fig.~\ref{fig:file_link_loop},
-che riporta la struttura della directory \file{/boot}. Come si vede si è
-creato al suo interno un collegamento simbolico che punta di nuovo a
+\textit{loop}.
+
+La situazione è illustrata in fig.~\ref{fig:file_link_loop}, che riporta la
+struttura della directory \file{/boot}. Come si vede si è creato al suo
+interno un collegamento simbolico che punta di nuovo a
\file{/boot}.\footnote{il \textit{loop} mostrato in
- fig.~\ref{fig:file_link_loop} è stato usato per poter permettere a
- \cmd{grub} (un bootloader in grado di leggere direttamente da vari
- filesystem il file da lanciare come sistema operativo) di vedere i file
- contenuti nella directory \file{/boot} con lo stesso \textit{pathname} con
- cui verrebbero visti dal sistema operativo, anche se essi si trovano, come
- accade spesso, su una partizione separata (che \cmd{grub} all'avvio vedrebbe
- come \file{/}).}
-
-Questo però può causare problemi per tutti quei programmi che effettuano la
-scansione di una directory senza tener conto dei collegamenti simbolici, ad
-esempio se lanciassimo un comando del tipo \code{grep -r linux *}, il loop
-nella directory porterebbe il comando ad esaminare \file{/boot},
-\file{/boot/boot}, \file{/boot/boot/boot} e così via.
+ fig.~\ref{fig:file_link_loop} è stato usato per poter permettere a al
+ \textit{bootloader} \cmd{grub} di vedere i file contenuti nella directory
+ \file{/boot} con lo stesso \textit{pathname} con cui verrebbero visti dal
+ sistema operativo, anche quando si trovano, come accade spesso, su una
+ partizione separata (che \cmd{grub} all'avvio vedrebbe come \file{/}).} Un
+\textit{loop} di di questo tipo però può causare problemi per tutti i
+programmi che effettuano la scansione di una directory, e ad esempio se
+lanciassimo un comando come \code{grep -r linux *}, il \textit{loop} nella
+directory porterebbe ad esaminare \file{/boot}, \file{/boot/boot},
+\file{/boot/boot/boot} e così via.
Per questo motivo il kernel e le librerie prevedono che nella risoluzione di
un \textit{pathname} possano essere seguiti fino ad un certo numero massimo di
collegamenti simbolici, il cui valore limite è specificato dalla costante
-\constd{MAXSYMLINKS}. Qualora questo limite venga superato viene generato un
-errore ed \var{errno} viene impostata al valore \errcode{ELOOP}, che nella
-quasi totalità dei casi indica appunto che si è creato un collegamento
-simbolico che fa riferimento ad una directory del suo stesso
-\textit{pathname}.
-
-Un altro punto da tenere sempre presente è che, come abbiamo accennato, un
-collegamento simbolico può fare riferimento anche ad un file che non esiste;
-ad esempio possiamo usare il comando \cmd{ln} per creare un collegamento
-simbolico nella nostra directory con:
-\begin{Console}
-piccardi@hain:~/gapil$ \textbf{ln -s /tmp/tmp_file symlink}
-\end{Console}
-%$
-e questo avrà successo anche se \file{/tmp/tmp\_file} non esiste:
-\begin{Console}
-piccardi@hain:~/gapil$ \textbf{ls symlink}
-symlink
-\end{Console}
-%$
-ma questo può generare confusione, perché accedendo in sola lettura a
-\file{symlink}, ad esempio con \cmd{cat}, otterremmo un errore:
-\begin{Console}
-piccardi@hain:~/gapil$ \textbf{cat symlink}
-cat: symlink: No such file or directory
-\end{Console}
-%$
-con un errore che può sembrare sbagliato, dato che \cmd{ls} ci ha mostrato
-l'esistenza di \file{symlink}, se invece scrivessimo su \file{symlink}
-otterremmo la creazione di \file{/tmp/tmp\_file} senza errori.
+\constd{MAXSYMLINKS}. Se il limite viene superato si ha un errore ed
+\var{errno} viene impostata al valore \errcode{ELOOP}, che nella quasi
+totalità dei casi indica appunto che si è creato un collegamento simbolico che
+fa riferimento ad una directory del suo stesso \textit{pathname}.
\itindend{symbolic~link}
\index{collegamento!simbolico|)}
Un'altra funzione relativa alla gestione dei nomi dei file, anche se a prima
-vista parrebbe riguardare un argomento completamente diverso, è quella che per
-la cancellazione di un file. In realtà una \textit{system call} che serva
-proprio a cancellare un file non esiste neanche perché, come accennato in
+vista parrebbe riguardare un argomento completamente diverso, è quella per la
+cancellazione di un file. In realtà una \textit{system call} che serva proprio
+a cancellare un file non esiste neanche perché, come accennato in
sez.~\ref{sec:file_filesystem}, quando in un sistema unix-like si richiede la
-rimozione di un file quella che si va a cancellare è soltanto la voce che
+rimozione di un file, quello che si va a cancellare è soltanto la voce che
referenzia il suo \textit{inode} all'interno di una directory.
La funzione di sistema che consente di effettuare questa operazione, il cui
nel qual caso \var{errno} assumerà uno dei valori:\footnotemark
\begin{errlist}
\item[\errcode{EACCES}] non si ha il permesso di scrittura sulla directory
- che contiene \param{pathname} o di attraversamento di una delle directory
- superiori.
+ che contiene \param{pathname} o quello di attraversamento per una delle
+ directory superiori.
+ \item[\errcode{EBUSY}] \param{pathname} non può essere rimosso perché è in
+ uso da parte del sistema (in particolare per i cosiddetti \textit{silly
+ renames} di NFS).
\item[\errcode{EISDIR}] \param{pathname} si riferisce ad una
directory.
\item[\errcode{EPERM}] il filesystem non consente l'operazione, o la
directory che contiene \param{pathname} ha lo \textit{sticky bit} e non si
- è il proprietario o non si hanno privilegi amministrativi.
+ è il proprietario del file o non si hanno privilegi amministrativi.
\end{errlist} ed inoltre \errval{EFAULT}, \errval{EIO}, \errval{ELOOP},
\errval{ENOENT}, \errval{ENOMEM}, \errval{ENOTDIR}, \errval{EROFS} nel loro
significato generico.}
La funzione elimina il nome specificato dall'argomento \param{pathname} nella
directory che lo contiene e decrementa il numero di riferimenti nel relativo
-\textit{inode}.\footnote{come per \func{link} queste due operazioni sono
- effettuate all'interno della \textit{system call} in maniera atomica.} Nel
-caso di socket, \textit{fifo} o file di dispositivo rimuove il nome, ma come
-per i file normali i processi che hanno aperto uno di questi oggetti possono
-continuare ad utilizzarli. Nel caso di cancellazione di un collegamento
-simbolico, che consiste solo nel rimando ad un altro file, questo viene
-immediatamente eliminato.
+\textit{inode}; come per \func{link} queste due operazioni sono effettuate
+all'interno della \textit{system call} in maniera atomica rispetto ai
+processi.
+
+Si ricordi che, anche se se ne è rimosso il nome, un file viene realmente
+cancellato soltanto quando il numero di collegamenti mantenuto
+nell'\textit{inode} diventa nullo; solo allora l'\textit{inode} viene
+disallocato e lo spazio che il file occupava sul disco viene liberato.
+
+Si tenga presente comunque che a questo si aggiunge sempre un'ulteriore
+condizione e cioè che non ci siano processi che stiano ancora lavorando sul il
+file. Come vedremo in sez.~\ref{sec:file_unix_interface} il kernel una tabella
+di tutti file aperti da ciascun processo, che a sua volta contiene i
+riferimenti agli \textit{inode} ad essi relativi. Prima di procedere alla
+cancellazione dello spazio occupato su disco dal contenuto di un file il
+kernel controlla anche questa tabella, per verificare che anche in essa non ci
+sia più nessun riferimento all'\textit{inode} in questione, assicurandosi con
+questo che nessun processo stia ancora usando il file.
+
+Nel caso di socket, \textit{fifo} o file di dispositivo la funzione rimuove il
+nome, e come per i file normali i processi che hanno aperto uno di questi
+oggetti possono continuare ad utilizzarli. Nel caso di cancellazione di un
+\textit{link} simbolico, che consiste solo nel rimando ad un altro file,
+questo viene immediatamente eliminato e non sarà più utilizzabile.
Per cancellare una voce in una directory è necessario avere il permesso di
scrittura su di essa, dato che si va a rimuovere una voce dal suo contenuto, e
il diritto di esecuzione/attraversamento sulla directory che la contiene
(affronteremo in dettaglio l'argomento dei permessi di file e directory in
-sez.~\ref{sec:file_access_control}). Se inoltre lo \textit{sticky bit} (vedi
-sez.~\ref{sec:file_special_perm}) è impostato occorrerà anche essere
-proprietari del file o proprietari della directory o avere i privilegi di
-amministratore.
-
-Si ricordi inoltre che anche se se ne è rimosso il nome da una directory, un
-file non viene eliminato dal disco fintanto che tutti i riferimenti ad esso
-sono stati cancellati: solo quando il numero di collegamenti mantenuto
-nell'\textit{inode} diventa nullo, questo viene disallocato e lo spazio
-occupato su disco viene liberato. Si tenga presente comunque che a questo si
-aggiunge sempre un'ulteriore condizione e cioè che non ci siano processi che
-abbiano il suddetto file aperto.\footnote{come vedremo in
- sez.~\ref{sec:file_unix_interface} il kernel mantiene anche una tabella dei
- file aperti nei vari processi, che a sua volta contiene i riferimenti agli
- \textit{inode} ad essi relativi; prima di procedere alla cancellazione dello
- spazio occupato su disco dal contenuto di un file il kernel controlla anche
- questa tabella, per verificare che anche in essa non ci sia più nessun
- riferimento all'\textit{inode} in questione.}
-
-Questa caratteristica del sistema può essere usata per essere sicuri di non
-lasciare file temporanei su disco in caso di crash di un programma. La tecnica
-è quella di aprire un nuovo file e chiamare \func{unlink} su di esso subito
+sez.~\ref{sec:file_access_control}). Se inoltre per la directory è impostato
+lo \textit{sticky bit} (vedi sez.~\ref{sec:file_special_perm}), occorrerà
+anche essere proprietari del file o proprietari della directory o avere i
+privilegi di amministratore.
+
+Questa caratteristica del sistema, che consente di usare un file anche se lo
+si è ``cancellato'', può essere usata per essere sicuri di non lasciare file
+temporanei su disco in caso di uscita imprevista di un programma. La tecnica è
+quella di aprire un nuovo file e chiamare \func{unlink} su di esso subito
dopo, in questo modo il contenuto del file sarà sempre disponibile all'interno
del processo attraverso il suo file descriptor (vedi sez.~\ref{sec:file_fd}),
-ma non ne resta traccia in nessuna directory, e lo spazio occupato su disco
-viene immediatamente rilasciato alla conclusione del processo, quando tutti i
-file vengono chiusi.
+ma non ne resterà traccia in nessuna directory, inoltre lo spazio occupato su
+disco verrà immediatamente rilasciato alla conclusione del processo, quando
+tutti i file vengono chiusi.
Al contrario di quanto avviene con altri Unix, in Linux non è possibile usare
-la funzione \func{unlink} sulle directory, nel qual caso si otterrebbe un
+la funzione \func{unlink} sulle directory, che in tal caso fallisce con un
errore di \errcode{EISDIR}. Per cancellare una directory si deve usare la
apposita funzione di sistema \func{rmdir} (che vedremo in
sez.~\ref{sec:file_dir_creat_rem}), oppure la funzione \func{remove}.
+
Quest'ultima è la funzione prevista dallo standard ANSI C per effettuare una
-cancellazione generica di un file o di una directory e funziona anche per i
-sistemi operativo che non supportano gli \textit{hard link}. Nei sistemi
-unix-like \funcd{remove} è equivalente ad usare in maniera trasparente
+cancellazione generica di un file o di una directory e viene usata in generale
+anche per i sistemi operativi che non supportano gli \textit{hard link}. Nei
+sistemi unix-like \funcd{remove} è equivalente ad usare in maniera trasparente
\func{unlink} per i file ed \func{rmdir} per le directory; il suo prototipo è:
\begin{funcproto}{
\func{unlink} e \func{rmdir}.}
\end{funcproto}
-La funzione utilizza la funzione \func{unlink} per cancellare i file e la
-funzione \func{rmdir} (vedi sez.~\ref{sec:file_dir_creat_rem}) per cancellare
-le directory.\footnote{questo vale usando la \acr{glibc}; nella \acr{libc4} e
- nella \acr{libc5} la funzione \func{remove} era un semplice alias alla
- funzione \func{unlink} e quindi non poteva essere usata per le directory.}
-Si tenga presente che per alcune implementazioni del protocollo NFS utilizzare
-questa funzione può comportare la scomparsa di file ancora in uso.
+La funzione utilizza la funzione \func{unlink} per cancellare i file (e si
+applica anche a link simbolici, socket, \textit{fifo} e file di dispositivo) e
+la funzione \func{rmdir} (vedi sez.~\ref{sec:file_dir_creat_rem}) per
+cancellare le directory.\footnote{questo vale usando la \acr{glibc}; nella
+ \acr{libc4} e nella \acr{libc5} la funzione \func{remove} era un semplice
+ alias alla funzione \func{unlink} e quindi non poteva essere usata per le
+ directory.} Si tenga presente che, per alcune limitazioni del protocollo
+NFS, utilizzare questa funzione su file che usano questo filesystem di rete
+può comportare la scomparsa di file ancora in uso.
Infine per cambiare nome ad un file o a una directory si usa la funzione di
sistema \funcd{rename},\footnote{la funzione è definita dallo standard ANSI C,
{La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EACCESS}] non c'è permesso di scrivere nelle directory
+ \item[\errcode{EACCESS}] manca il permesso di scrittura sulle directory
contenenti \param{oldpath} e \param{newpath} o di attraversare
- quelle dei loro \textit{pathname} o di scrivere su \param{newpath}
+ il loro \textit{pathname} o di scrivere su \param{newpath}
se questa è una directory.
\item[\errcode{EBUSY}] o \param{oldpath} o \param{newpath} sono in uso da
parte di qualche processo (come directory di lavoro o come radice) o del
in ``\file{.}'' e ``\file{..}'' anche se validi in altri contesti, causeranno
il fallimento della funzione.
+Inoltre per eseguire la cancellazione, oltre ad essere vuota, occorre anche
+che la directory non sia utilizzata, questo vuol dire anche che non deve
+essere la directory di lavoro (vedi sez.~\ref{sec:file_work_dir}) o la
+directory radice (vedi sez.~\ref{sec:file_chroot}) di nessun processo, od
+essere utilizzata come \textit{mount point}.
+
Se la directory cancellata risultasse aperta in qualche processo per una
lettura dei suoi contenuti (vedi sez.~\ref{sec:file_dir_read}), pur
scomparendo dal filesystem e non essendo più possibile accedervi o crearvi
\textit{stream} sulla prima voce contenuta nella directory.
Si tenga presente che comunque la funzione opera associando il
-\textit{directory stream} ad un opportuno file descriptor sottostante, sul
-quale vengono compiute le operazioni. Questo viene sempre aperto impostando il
-flag di \textit{close-on-exec} (si ricordi quanto detto in
-sez.~\ref{sec:proc_exec}), così da evitare che resti aperto in caso di
-esecuzione di un altro programma.
-
-Nel caso in cui sia necessario conoscere il \textit{file descriptor} associato
-ad un \textit{directory stream} si può usare la funzione
+\textit{directory stream} ad un opportuno file descriptor (vedi
+sez.~\ref{sec:file_fd}) sottostante, sul quale vengono compiute le
+operazioni. Questo viene sempre aperto impostando il flag di
+\textit{close-on-exec} (si ricordi quanto detto in sez.~\ref{sec:proc_exec}),
+così da evitare che resti aperto in caso di esecuzione di un altro programma.
+
+Nel caso in cui sia necessario conoscere il file descriptor associato ad un
+\textit{directory stream} si può usare la funzione
\funcd{dirfd},\footnote{questa funzione è una estensione introdotta con BSD
4.3-Reno ed è presente in Linux con le libc5 (a partire dalla versione
5.1.2) e con la \acr{glibc} ma non presente in POSIX fino alla revisione
\func{versionsort}, che ordina i nomi tenendo conto del numero di versione,
cioè qualcosa per cui \texttt{file10} viene comunque dopo \texttt{file4}.
-\begin{figure}[!htbp]
+\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{\codesamplewidth}
\includecodesample{listati/my_ls.c}
nome del file e la dimensione riportata in \var{data}.
Dato che la funzione verrà chiamata all'interno di \myfunc{dir\_scan} per ogni
-voce presente questo è sufficiente a stampare la lista completa dei file e
+voce presente, questo è sufficiente a stampare la lista completa dei file e
delle relative dimensioni. Si noti infine come si restituisca sempre 0 come
valore di ritorno per indicare una esecuzione senza errori.
-\begin{figure}[!htbp]
+\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{\codesamplewidth}
\includecodesample{listati/dir_scan.c}
caso sarà \code{do\_ls}), ritornando con un codice di errore (\texttt{\small
28}) qualora questa presenti una anomalia, identificata da un codice di
ritorno negativo. Una volta terminato il ciclo la funzione si conclude con la
-chiusura (\texttt{\small 32}) dello \textit{stream}\footnote{nel nostro caso,
+chiusura (\texttt{\small 31}) dello \textit{stream}\footnote{nel nostro caso,
uscendo subito dopo la chiamata, questo non servirebbe, in generale però
l'operazione è necessaria, dato che la funzione può essere invocata molte
volte all'interno dello stesso processo, per cui non chiudere i
\index{directory~di~lavoro|(}
Come accennato in sez.~\ref{sec:proc_fork} a ciascun processo è associata una
-directory nel filesystem,\footnote{questa viene mantenuta all'interno dei dati
- della sua \kstruct{task\_struct} (vedi fig.~\ref{fig:proc_task_struct}), più
- precisamente nel campo \texttt{pwd} della sotto-struttura
- \kstruct{fs\_struct}.} che è chiamata \textsl{directory corrente} o
-\textsl{directory di lavoro} (in inglese \textit{current working directory}).
-La directory di lavoro è quella da cui si parte quando un \textit{pathname} è
-espresso in forma relativa, dove il ``\textsl{relativa}'' fa riferimento
-appunto a questa directory.
+directory nell'albero dei file,\footnote{questa viene mantenuta all'interno
+ dei dati della sua \kstruct{task\_struct} (vedi
+ fig.~\ref{fig:proc_task_struct}), più precisamente nel campo \texttt{pwd}
+ della sotto-struttura \kstruct{fs\_struct}.} che è chiamata
+\textsl{directory corrente} o \textsl{directory di lavoro} (in inglese
+\textit{current working directory}). La directory di lavoro è quella da cui
+si parte quando un \textit{pathname} è espresso in forma relativa, dove il
+``\textsl{relativa}'' fa riferimento appunto a questa directory.
Quando un utente effettua il login, questa directory viene impostata alla
\textit{home directory} del suo account. Il comando \cmd{cd} della shell
sez.~\ref{sec:proc_fork}), la directory di lavoro della shell diventa anche la
directory di lavoro di qualunque comando da essa lanciato.
-Dato che è il kernel che tiene traccia per ciascun processo
-dell'\textit{inode} della directory di lavoro, per ottenerne il
-\textit{pathname} occorre usare una apposita funzione,
-\funcd{getcwd},\footnote{con Linux \func{getcwd} è una \textit{system call}
- dalla versione 2.1.9, in precedenza il valore doveva essere ottenuto tramite
- il filesystem \texttt{/proc} da \procfile{/proc/self/cwd}.} il cui prototipo
-è:
+Dato che è il kernel che tiene traccia dell'\textit{inode} della directory di
+lavoro di ciascun processo, per ottenerne il \textit{pathname} occorre usare
+una apposita funzione, \funcd{getcwd},\footnote{con Linux \func{getcwd} è una
+ \textit{system call} dalla versione 2.1.9, in precedenza il valore doveva
+ essere ottenuto tramite il filesystem \texttt{/proc} da
+ \procfile{/proc/self/cwd}.} il cui prototipo è:
\begin{funcproto}{
\fhead{unistd.h}
\item[\errcode{ERANGE}] l'argomento \param{size} è più piccolo della
lunghezza del \textit{pathname}.
\end{errlist}
- ed inoltre \errcode{EFAULT} nel suo significato generico.}
+ ed inoltre \errcode{EFAULT} ed \errcode{ENOMEM} nel loro significato
+ generico.}
\end{funcproto}
La funzione restituisce il \textit{pathname} completo della directory di
esso ecceda le dimensioni specificate con \param{size} la funzione restituisce
un errore.
-Si può anche specificare un puntatore nullo come
-\param{buffer},\footnote{questa è un'estensione allo standard POSIX.1,
- supportata da Linux e dalla \acr{glibc}.} nel qual caso la stringa sarà
-allocata automaticamente per una dimensione pari a \param{size} qualora questa
-sia diversa da zero, o della lunghezza esatta del \textit{pathname}
-altrimenti. In questo caso ci si deve ricordare di disallocare la stringa con
-\func{free} una volta cessato il suo utilizzo.
+A partire dal kernel Linux 2.6.36 il nome può avere come prefisso la stringa
+\texttt{(unreachable)} se la directory di lavoro resta fuori dalla directory
+radice del processo dopo un \func{chroot} (torneremo su questi argomenti in
+sez.~\ref{sec:file_chroot}); pertanto è sempre opportuno controllare il primo
+carattere della stringa restituita dalla funzione per evitare di interpretare
+mare un \textit{pathname} irraggiungibile.
+
+Come estensione allo standard POSIX.1, supportata da Linux e dalla
+\acr{glibc}, si può anche specificare un puntatore nullo come \param{buffer}
+nel qual caso la stringa sarà allocata automaticamente per una dimensione pari
+a \param{size} qualora questa sia diversa da zero, o della lunghezza esatta
+del \textit{pathname} altrimenti. In questo caso ci si deve ricordare di
+disallocare la stringa con \func{free} una volta cessato il suo utilizzo.
Un uso comune di \func{getcwd} è quello di salvarsi la directory di lavoro
all'avvio del programma per poi potervi tornare in un tempo successivo, un
la ragione principale per cui questa funzione è deprecata, e non la tratteremo.
Una seconda funzione usata per ottenere la directory di lavoro è
-\funcm{get\_current\_dir\_name},\footnote{la funzione è una estensione GNU e
- presente solo nella \acr{glibc}.} che non prende nessun argomento ed è
-sostanzialmente equivalente ad una \code{getcwd(NULL, 0)}, con la differenza
-che se disponibile essa ritorna il valore della variabile di ambiente
-\envvar{PWD}, che essendo costruita dalla shell può contenere un
-\textit{pathname} comprendente anche dei collegamenti simbolici. Usando
-\func{getcwd} infatti, essendo il \textit{pathname} ricavato risalendo
-all'indietro l'albero della directory, si perderebbe traccia di ogni passaggio
-attraverso eventuali collegamenti simbolici.
+\funcm{get\_current\_dir\_name} (la funzione è una estensione GNU e presente
+solo nella \acr{glibc}) che non prende nessun argomento ed è sostanzialmente
+equivalente ad una \code{getcwd(NULL, 0)}, con la differenza che se
+disponibile essa ritorna il valore della variabile di ambiente \envvar{PWD},
+che essendo costruita dalla shell può contenere un \textit{pathname}
+comprendente anche dei collegamenti simbolici. Usando \func{getcwd} infatti,
+essendo il \textit{pathname} ricavato risalendo all'indietro l'albero della
+directory, si perderebbe traccia di ogni passaggio attraverso eventuali
+collegamenti simbolici.
Per cambiare la directory di lavoro si può usare la funzione di sistema
\funcd{chdir}, equivalente del comando di shell \cmd{cd}, il cui nome sta
\begin{errlist}
\item[\errcode{EACCES}] manca il permesso di ricerca su uno dei componenti
di \param{pathname}.
+ \item[\errcode{ENAMETOOLONG}] il nome indicato in \param{path} è troppo lungo.
\item[\errcode{ENOTDIR}] non si è specificata una directory.
\end{errlist}
- ed inoltre \errval{EFAULT}, \errval{EIO}, \errval{ELOOP},
- \errval{ENAMETOOLONG}, \errval{ENOENT} e \errval{ENOMEM} nel loro
- significato generico.}
+ ed inoltre \errval{EFAULT}, \errval{EIO}, \errval{ELOOP}, \errval{ENOENT} e
+ \errval{ENOMEM} nel loro significato generico.}
\end{funcproto}
La funzione cambia la directory di lavoro in \param{pathname} ed
Finora abbiamo parlato esclusivamente di file, directory e collegamenti
simbolici, ma in sez.~\ref{sec:file_file_types} abbiamo visto che il sistema
prevede anche degli altri tipi di file, che in genere vanno sotto il nome
-generico di \textsl{file speciali}, come i file di dispositivo, le \textit{fifo} ed i
-socket.
+generico di \textsl{file speciali}, come i file di dispositivo, le
+\textit{fifo} ed i socket.
La manipolazione delle caratteristiche di questi file speciali, il cambiamento
di nome o la loro cancellazione può essere effettuata con le stesse funzioni
la specifica \func{mkfifo}.} l'uso per la creazione di un file ordinario, di
una \textit{fifo} o di un socket è consentito anche agli utenti normali.
-I nuovi \textit{inode} creati con \func{mknod} apparterranno al proprietario e
-al gruppo del processo (usando \ids{UID} e \ids{GID} del gruppo effettivo) che
-li ha creati a meno non sia presente il bit \acr{sgid} per la directory o sia
+Gli \textit{inode} creati con \func{mknod} apparterranno al proprietario e al
+gruppo del processo (usando \ids{UID} e \ids{GID} del gruppo effettivo) che li
+ha creati a meno non sia presente il bit \acr{sgid} per la directory o sia
stata attivata la semantica BSD per il filesystem (si veda
sez.~\ref{sec:file_ownership_management}) in cui si va a creare
l'\textit{inode}, nel qual caso per il gruppo verrà usato il \ids{GID} del
``\textit{symlink attack}'' dove nell'intervallo fra la generazione di un nome
e l'accesso allo stesso, viene creato un collegamento simbolico con quel nome
verso un file diverso, ottenendo, se il programma sotto attacco ne ha la
-capacità, un accesso privilegiato.
+capacità, un accesso privilegiato.\footnote{dal kernel 3.6 sono state
+ introdotte delle contromisure, illustrate in
+ sez.~\ref{sec:procadv_security_misc}, che rendono impraticabili questo tipo
+ di attacchi, ma questa non è una buona scusa per ignorare il problema.}
\itindend{symlink~attack}
\end{errlist}}
\end{funcproto}
-
Come per \func{mktemp} anche in questo caso \param{template} non può essere
una stringa costante. La funzione apre un file in lettura/scrittura con la
funzione \func{open}, usando l'opzione \const{O\_EXCL} (si veda
\func{mkstemp}.}
\end{funcproto}
\noindent la cui sola differenza è la presenza dell'ulteriore argomento
-\var{flags} che consente di specificare i flag da passare ad \func{open}
-nell'apertura del file.
+\var{flags} che consente di specificare alcuni ulteriori flag (come
+\const{O\_APPEND}, \const{O\_CLOEXEC}, \const{O\_SYNC}, il cui significato
+vedremo in sez.~\ref{sec:file_open_close}) da passare ad \func{open}
+nell'apertura del file.\footnote{si tenga presente che \func{mkostemp}
+ utilizza già \const{O\_CREAT}, \const{O\_EXCL} e \const{O\_RDWR}, che non è
+ il caso di riindicare, dato che ciò potrebbe portare ad errori in altri
+ sistemi operativi.}
+
+Di queste due funzioni sono state poi introdotte, a partire dalla \acr{glibc}
+2.11 due varianti, \funcd{mkstemps} e \funcd{mkostemps}, che consentono di
+indicare anche un suffisso, i loro prototipi sono:
+\begin{funcproto}{
+\fhead{stlib.h}
+\fdecl{int mkstemps(char *template, int suffixlen)}
+\fdesc{Apre un file temporaneo.}
+\fdecl{int mkostemps(char *template, int suffixlen, int flags)}
+\fdesc{Apre un file temporaneo.}
+}
-In OpenBSD è stata introdotta un'altra funzione simile alle precedenti,
-\funcd{mkdtemp}, che crea invece una directory temporanea;\footnote{la
- funzione è stata introdotta nella \acr{glibc} a partire dalla versione
- 2.1.91 ed inserita nello standard POSIX.1-2008.} il suo prototipo è:
+{Le funzioni hanno gli stessi valori di ritorno e gli stessi errori di
+ \func{mkstemp} con lo stesso significato, tranne \errval{EINVAL} che viene
+ restituito se \param{template} non è di lunghezza pari ad almeno
+ $6+$\param{suffixlen} ed i 6 caratteri prima del suffisso non sono
+ \code{XXXXXX}.}
+\end{funcproto}
+
+Le due funzioni, un'estensione non standard fornita dalla \acr{glibc}, sono
+identiche a \funcd{mkstemp} e \funcd{mkostemp}, ma consentono di avere un nome
+del file nella forma \texttt{prefissoXXXXXXsuffisso} dove la lunghezza del
+suffisso deve essere indicata con \param{suffixlen}.
+
+Infine con OpenBSD è stata introdotta un'altra funzione simile alle
+precedenti, \funcd{mkdtemp}, che crea invece una directory
+temporanea;\footnote{la funzione è stata introdotta nella \acr{glibc} a
+ partire dalla versione 2.1.91 ed inserita nello standard POSIX.1-2008.} il
+suo prototipo è:
\begin{funcproto}{
\fhead{stlib.h}
La funzione crea una directory temporanea il cui nome è ottenuto sostituendo
le \code{XXXXXX} finali di \param{template} con permessi \code{0700} (si veda
sez.~\ref{sec:file_perm_overview} per i dettagli). Dato che la creazione della
-directory è sempre esclusiva i precedenti problemi di \textit{race condition}
+directory è sempre atomica i precedenti problemi di \textit{race condition}
non si pongono.
-
\section{La manipolazione delle caratteristiche dei file}
\label{sec:file_infos}
campi di \struct{stat} su cui non torneremo in maggior dettaglio nel resto di
questa sezione:
\begin{itemize*}
-
\item Il campo \var{st\_nlink} contiene il numero di \textit{hard link} che
fanno riferimento al file (il cosiddetto \textit{link count}) di cui abbiamo
già parlato in numerose occasioni.
-
\item Il campo \var{st\_ino} contiene il numero di \textit{inode} del file,
quello viene usato all'interno del filesystem per identificarlo e che può
essere usato da un programma per determinare se due \textit{pathname} fanno
riferimento allo stesso file.
-
\item Il campo \var{st\_dev} contiene il numero del dispositivo su cui risiede
il file (o meglio il suo filesystem). Si tratta dello stesso numero che si
usa con \func{mknod} e che può essere decomposto in \textit{major number} e
\textit{minor number} con le macro \macro{major} e \macro{minor} viste in
sez.~\ref{sec:file_mknod}.
-
\item Il campo \var{st\_rdev} contiene il numero di dispositivo associato al
file stesso ed ovviamente ha un valore significativo soltanto quando il file
è un dispositivo a caratteri o a blocchi.
-
\item Il campo \var{st\_blksize} contiene la dimensione dei blocchi di dati
usati nell'I/O su disco, che è anche la dimensione usata per la
bufferizzazione dei dati dalle librerie del C per l'interfaccia degli
\textit{stream}. Leggere o scrivere blocchi di dati in dimensioni inferiori
a questo valore è inefficiente in quanto le operazioni su disco usano
comunque trasferimenti di questa dimensione.
-
\end{itemize*}
-% 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)
+Nell'evoluzione del kernel la \textit{system call} che fornisce \func{stat} è
+stata modificata più volte per tener conto dei cambiamenti fatti alla
+struttura \struct{stat},\footnote{questo ha significato l'utilizzo a basso
+ livello di diverse \textit{system call} e diverse versioni della struttura.}
+in particolare a riguardo ai tempi dei file, di cui è stata aumentata la
+precisione (torneremo su questo in sez.~\ref{sec:file_file_times}) ma anche
+per gli aggiornamenti fatti ai campi \var{st\_ino}, \var{st\_uid} e
+\var{st\_gid}.
+
+Sulle piattaforme a 32 bit questi cambiamenti, che han visto un aumento delle
+dimensioni dei campi della struttura per adattarli alle nuove esigenze, sono
+mascherati dalla \acr{glibc} che attraverso \func{stat} invoca la versione più
+recente della \textit{system call} e rimpacchetta i dati se questo è
+necessario per eseguire dei vecchi programmi. Nelle piattaforme a 64 bit
+invece è presente un'unica versione della \textit{system call} e la struttura
+\struct{stat} ha campi di dimensione sufficiente.
+
+Infine a partire dal kernel 2.6.16 è stata introdotta una ulteriore funzione
+della famiglia, \func{fstatat} che consente di trattare con sicurezza i
+\textit{pathname} relativi, la tratteremo in sez.~\ref{sec:file_openat},
+insieme alla nuova \textit{system call} \func{statx}, introdotta dal kernel
+4.11 per estendere l'interfaccia di \func{stat} e le informazioni che essa può
+restituire.
\subsection{I tipi di file}
funzioni della famiglia \func{stat} all'interno del campo \var{st\_mode} di
una struttura \struct{stat}.
-Il campo \var{st\_mode} è una maschera binaria in cui l'informazione viene
-suddivisa nei vari bit che compongono, ed oltre a quelle sul tipo di file,
-contiene anche le informazioni relative ai permessi su cui torneremo in
-sez.~\ref{sec:file_perm_overview}. Dato che i valori numerici usati per
-definire il tipo di file possono variare a seconda delle implementazioni, lo
-standard POSIX definisce un insieme di macro che consentono di verificare il
-tipo di file in maniera standardizzata.
-
\begin{table}[htb]
\centering
\footnotesize
\label{tab:file_type_macro}
\end{table}
+Il campo \var{st\_mode} è una maschera binaria in cui l'informazione viene
+suddivisa nei vari bit che compongono, ed oltre a quelle sul tipo di file,
+contiene anche le informazioni relative ai permessi su cui torneremo in
+sez.~\ref{sec:file_perm_overview}. Dato che i valori numerici usati per
+definire il tipo di file possono variare a seconda delle implementazioni, lo
+standard POSIX definisce un insieme di macro che consentono di verificare il
+tipo di file in maniera standardizzata.
+
Queste macro vengono usate anche da Linux che supporta pure le estensioni allo
standard per i collegamenti simbolici e i socket definite da BSD.\footnote{le
ultime due macro di tab.~\ref{tab:file_type_macro}, che non sono presenti
\label{sec:file_file_size}
Abbiamo visto in fig.~\ref{fig:file_stat_struct} che campo \var{st\_size} di
-una struttura \struct{stat} contiene la dimensione del file in byte. Questo
-però è vero solo se si tratta di un file regolare, mentre nel caso di un
-collegamento simbolico la dimensione è quella del \textit{pathname} che il
-collegamento stesso contiene, infine per le \textit{fifo} ed i file di dispositivo
-questo campo è sempre nullo.
-
-Il campo \var{st\_blocks} invece definisce la lunghezza del file in blocchi di
-512 byte. La differenza con \var{st\_size} è che in questo caso si fa
-riferimento alla quantità di spazio disco allocata per il file, e non alla
-dimensione dello stesso che si otterrebbe leggendolo sequenzialmente.
+una struttura \struct{stat} contiene la dimensione del file in byte. In realtà
+questo è vero solo se si tratta di un file regolare contenente dei dati; nel
+caso di un collegamento simbolico invece la dimensione è quella del
+\textit{pathname} che il collegamento stesso contiene, e per una directory
+quella dello spazio occupato per le voci della stessa (che dipende da come
+queste vengono mantenute dal filesystem), infine per le \textit{fifo}, i socket
+ed i file di dispositivo questo campo è sempre nullo.
+
+Il campo \var{st\_blocks} invece definisce la lunghezza del file espressa in
+numero di blocchi di 512 byte. La differenza con \var{st\_size} è che in
+questo caso si fa riferimento alla quantità di spazio disco allocata per il
+file, e non alla dimensione dello stesso che si otterrebbe leggendolo
+sequenzialmente.
Si deve tener presente infatti che la lunghezza del file riportata in
\var{st\_size} non è detto che corrisponda all'occupazione dello spazio su
In questo caso si avranno risultati differenti a seconda del modo in cui si
calcola la lunghezza del file, ad esempio il comando \cmd{du}, (che riporta il
numero di blocchi occupati) potrà dare una dimensione inferiore, mentre se si
-legge dal file (ad esempio usando il comando \cmd{wc -c}), dato che in tal
-caso per i ``\textsl{buchi}'' vengono restituiti degli zeri, si avrà lo stesso
-risultato di \cmd{ls}.
+legge il contenuto del file (ad esempio usando il comando \cmd{wc -c}), dato
+che in tal caso per i ``\textsl{buchi}'' vengono restituiti degli zeri, si
+avrà lo stesso risultato di \cmd{ls}.
Se è sempre possibile allargare un file, scrivendoci sopra o usando la
funzione \func{lseek} (vedi sez.~\ref{sec:file_lseek}) per spostarsi oltre la
nuova fine del file.
Un file può sempre essere troncato a zero aprendolo con il flag
-\const{O\_TRUNC}, ma questo è un caso particolare; per qualunque altra
-dimensione si possono usare le due funzioni di sistema \funcd{truncate} e
-\funcd{ftruncate}, i cui prototipi sono:
+\const{O\_TRUNC} (vedi sez.~\ref{sec:file_open_close}), ma questo è un caso
+particolare; per qualunque altra dimensione si possono usare le due funzioni
+di sistema \funcd{truncate} e \funcd{ftruncate}, i cui prototipi sono:
\begin{funcproto}{
\fhead{unistd.h}
pertanto funzioni come \func{access} o \func{stat} non hanno alcuna influenza
sui tre tempi. Il comando \cmd{ls} (quando usato con le opzioni \cmd{-l} o
\cmd{-t}) mostra i tempi dei file secondo lo schema riportato nell'ultima
-colonna di tab.~\ref{tab:file_file_times}. Si noti anche come non esista, a
-differenza di altri sistemi operativi, un \textsl{tempo di creazione} di un
-file.
+colonna di tab.~\ref{tab:file_file_times}. Si noti anche come in
+tab.~\ref{tab:file_file_times} non venga riportato il \textsl{tempo di
+ creazione} di un file; in un sistema unix-like infatti questo non esiste, e
+non è previsto dall'interfaccia classica, ma essendo usato da altri sistemi
+operativi (in particolare Windows) in tutti i filesystem più recenti ne viene
+supportata la registrazione, ed a partire dal kernel 4.11 è diventato
+possibile anche ottenerne la lettura con la nuova \textit{system call}
+\func{statx} (che tratteremo in sez.~\ref{sec:file_openat}).
L'aggiornamento del tempo di ultimo accesso è stato a lungo considerato un
difetto progettuale di Unix, questo infatti comporta la necessità di
in termini di prestazioni, che di consumo di risorse come la batteria per i
portatili, o i cicli di riscrittura per i dischi su memorie riscrivibili.
-
-Per questo motivo abbiamo visto in sez.~\ref{sec:filesystem_mounting} come
-nello sviluppo del kernel siano stati introdotti degli opportuni \textit{mount
- flag} che consentissero di evitare di aggiornare continuamente una
-informazione che nella maggior parte dei casi non interessa. Per questo i
-valori che si possono trovare per l'\textit{access time} dipendono dalle
-opzioni di montaggio, ed anche, essendo stato cambiato il comportamento di
-default a partire dalla versione 2.6.30, dal kernel che si sta usando.
-
-In generale quello che si ha con i kernel più recenti è che il tempo di ultimo
-accesso viene aggiornato solo se è precedente al tempo di ultima modifica o
-cambiamento, o se è passato più di un giorno dall'ultimo accesso. Così si può
-rendere evidente che vi è stato un accesso dopo una modifica e che il file
-viene comunque osservato regolarmente, conservando tutte le informazioni
-veramente utili senza dover consumare risorse in scritture continue per
-mantenere costantemente aggiornata una informazione che a questo punto non ha
-più nessuna rilevanza pratica.\footnote{qualora ce ne fosse la necessità è
- comunque possibile, tramite l'opzione di montaggio \texttt{strictatime},
- richiedere in ogni caso il comportamento tradizionale.}
+Per questo motivo abbiamo visto in sez.~\ref{sec:filesystem_mounting} come nel
+corso dello sviluppo del kernel siano stati introdotti degli opportuni
+\textit{mount flag} che consentono di evitare di aggiornare continuamente una
+informazione che nella maggior parte dei casi non ha un interesse
+rilevante. Per questo motivo i valori dell'\textit{access time} possono
+dipendere dalle opzioni di montaggio, ed anche, essendo stato cambiato il
+comportamento di default a partire dalla versione 2.6.30, dal kernel che si
+sta usando.
+
+In generale quello che avviene con i kernel più recenti è che il tempo di
+ultimo accesso viene aggiornato solo se è precedente al tempo di ultima
+modifica o cambiamento, o se è cambiato ed passato più di un giorno
+dall'ultimo aggiornamento. Così si può rendere evidente che vi è stato un
+accesso dopo una modifica, e che il file viene comunque osservato a cadenza
+regolare, conservando le informazioni veramente utili senza consumare
+inutilmente risorse in continue scritture per mantenere costantemente
+aggiornata una informazione che a questo punto non ha più nessuna rilevanza
+pratica.\footnote{qualora ce ne fosse la necessità è comunque possibile,
+ tramite l'opzione di montaggio \texttt{strictatime}, richiedere in ogni caso
+ il comportamento tradizionale.}
\begin{table}[htb]
\centering
A partire dal kernel 2.6 la risoluzione dei tempi dei file, che nei campi di
tab.~\ref{tab:file_file_times} è espressa in secondi, è stata portata ai
-nanosecondi per la gran parte dei filesystem. La ulteriore informazione può
-essere acceduta attraverso altri campi appositamente aggiunti alla struttura
+nanosecondi per la gran parte dei filesystem. L'ulteriore informazione può
+essere ottenuta attraverso altri campi appositamente aggiunti alla struttura
\struct{stat}. Se si sono definite le macro \macro{\_BSD\_SOURCE} o
\macro{\_SVID\_SOURCE} questi sono \var{st\_atim.tv\_nsec},
\var{st\_mtim.tv\_nsec} e \var{st\_ctim.tv\_nsec} se queste non sono definite,
\label{fig:sys_timeval_struct}
\end{figure}
+
+% Oltre ad \func{utimes} su Linux sono presenti altre due funzioni per la
+% manipolazione dei tempi dei file,\footnote{le due funzioni non sono definite
+% in nessuno standard, ma sono presenti, oltre che su Linux, anche su BSD;
+% sono accessibili definendo \macro{\_DEFAULT\_SOURCE} dalla \acr{glibc} 2.19
+% o \macro{\_GNU\_SOURCE} prima.} la prima è \funcd{futimes} e consente di
+% effettuare la modifica utilizzando un file già aperto, il suo prototipo è:
+
+% \begin{funcproto}{
+% \fhead{sys/time.h}
+% \fdecl{int futimes(int fd, const struct timeval tv[2])}
+% \fdesc{Cambia i tempi di un file già aperto.}
+% }
+
+% {La funzione ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
+% caso \var{errno} assumerà uno gli stessi valori di \func{utimes} ed inoltre:
+% \begin{errlist}
+% \item[\errcode{EBADF}] \param{fd} non è un file descriptor.
+% \item[\errcode{ENOSYS}] il filesystem \texttt{/proc} non è accessibile.
+% \end{errlist}}
+% \end{funcproto}
+
+% La seconda funzione, introdotta a partire dal kernel 2.6.22, è
+% \funcd{lutimes}, e consente rispettivamente di modificare i tempi di un
+% collegamento simbolico; il suo prototipo è:
+
+% \begin{funcproto}{
+% \fhead{sys/time.h}
+% \fdecl{int lutimes(const char *filename, const struct timeval tv[2])}
+% \fdesc{Cambia i tempi di un collegamento simbolico.}
+% }
+
+% {La funzione ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
+% caso \var{errno} assumerà uno gli stessi valori di \func{utimes}, con in più:
+% \begin{errlist}
+% \item[\errcode{ENOSYS}] la funzione non è supportata.
+% \end{errlist}}
+% \end{funcproto}
+
+% Le due funzioni hanno lo stesso comportamento di \texttt{utimes} e richiedono
+% gli stessi privilegi per poter operare, la differenza è che con \func{futimes}
+% si può indicare il file su cui operare se questo è già aperto facendo
+% riferimento al suo file descriptor, mentre con \func{lutimes}, nel caso in cui
+% \param{filename} sia un collegamento simbolico, saranno modificati i suoi
+% tempi invece di quelli del file a cui esso punta.
+
Oltre ad \func{utimes} su Linux sono presenti altre due funzioni,\footnote{le
due funzioni non sono definite in nessuno standard, ma sono presenti, oltre
- che su Linux, anche su BSD.} \funcd{futimes} e \funcd{lutimes}, che
-consentono rispettivamente di effettuare la modifica utilizzando un file già
-aperto o di eseguirla direttamente su un collegamento simbolico. I relativi
-prototipi sono:
+ che su Linux, anche su BSD; sono accessibili definendo
+ \macro{\_DEFAULT\_SOURCE} dalla \acr{glibc} 2.19 o \macro{\_GNU\_SOURCE}
+ prima.} \funcd{futimes} e \funcd{lutimes}, che consentono rispettivamente
+di effettuare la modifica utilizzando un file già aperto o di eseguirla
+direttamente su un collegamento simbolico. I relativi prototipi sono:
\begin{funcproto}{
\fhead{sys/time.h}
per \func{futimes}:
\begin{errlist}
\item[\errcode{EBADF}] \param{fd} non è un file descriptor.
- \item[\errcode{ENOSYS}] il filesystem \texttt{/proc} non è accessibile.
+ \item[\errcode{ENOSYS}] il filesystem \texttt{/proc} non è accessibile per
+ \func{futimes} o la funzione non è supportata per \func{lutimes}.
\end{errlist}}
\end{funcproto}
Nonostante il kernel nelle versioni più recenti supporti, come accennato,
risoluzioni dei tempi dei file fino al nanosecondo, le funzioni fin qui
esaminate non consentono di impostare valori con questa precisione. Per questo
-sono state introdotte due nuove funzioni di sistema, \funcd{futimens} e
-\funcd{utimensat}, in grado di eseguire questo compito; i rispettivi prototipi
-sono:
+sono state introdotte due nuove funzioni di sistema, \func{utimensat} (che
+vedremo in sez.~\ref{sec:file_openat} insieme alle altre
+\textit{at-functions}), e \funcd{futimens}, il cui prototipo è:
\begin{funcproto}{
\fhead{sys/time.h}
-\fdecl{futimens(int fd, const struct timespec times[2])}
+\fdecl{int futimens(int fd, const struct timespec times[2])}
\fdesc{Cambia i tempi di un file già aperto.}
-\fdecl{int utimensat(int dirfd, const char *pathname, const struct
- timespec times[2], int flags)}
-\fdesc{Cambia i tempi di un file.}
}
-{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
- caso \var{errno} assumerà uno dei valori:
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EACCES}] si è richiesta l'impostazione del tempo corrente ma
non si ha il permesso di scrittura sul file, o non si è proprietari del
file o non si hanno i privilegi di amministratore; oppure il file è
immutabile (vedi sez.~\ref{sec:file_perm_overview}).
- \item[\errcode{EBADF}] \param{fd} non è un file descriptor valido (solo
- \func{futimens}), oppure \param{dirfd} non è \const{AT\_FDCWD} o un file
- descriptor valido (solo \func{utimensat}).
- \item[\errcode{EFAULT}] \param{times} non è un puntatore valido (per
- entrambe), oppure \param{dirfd} è \const{AT\_FDCWD} ma \param{pathname} è
- \var{NULL} o non è un puntatore valido (solo \func{utimensat}).
- \item[\errcode{EINVAL}] si sono usati dei valori non corretti per i tempi
- di \param{times} (per entrambe), oppure è si usato un valore non valido
- per \param{flags}, oppure \param{pathname} è \var{NULL}, \param{dirfd} non
- è \const{AT\_FDCWD} e \param{flags} contiene \const{AT\_SYMLINK\_NOFOLLOW}
- (solo \func{utimensat}).
+ \item[\errcode{EBADF}] \param{fd} non è un file descriptor valido.
+ \item[\errcode{EFAULT}] \param{times} non è un puntatore valido.
+ \item[\errcode{EINVAL}] si sono usati dei valori non corretti per i tempi di
+ \param{times}.
\item[\errcode{EPERM}] si è richiesto un cambiamento nei tempi non al tempo
corrente, ma non si è proprietari del file o non si hanno i privilegi di
amministratore; oppure il file è immutabile o \textit{append-only} (vedi
sez.~\ref{sec:file_perm_overview}).
- \item[\errcode{ESRCH}] non c'è il permesso di attraversamento per una delle
- componenti di \param{pathname} (solo \func{utimensat})
\end{errlist}
- ed inoltre per entrambe \errval{EROFS} e per \func{utimensat}
- \errval{ELOOP}, \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOTDIR} nel
- loro significato generico.}
+ ed inoltre per entrambe \errval{EROFS} nel suo significato generico.}
\end{funcproto}
-Entrambe le funzioni utilizzano per indicare i valori dei tempi un
-vettore \param{times} di due strutture \struct{timespec}, la cui definizione è
-riportata in fig.~\ref{fig:sys_timespec_struct}, che permette di specificare
-un valore dei tempi con una precisione fino al nanosecondo.
+La funzione è sostanzialmente una estensione di \func{futimes} che consente di
+specificare i tempi con precisione maggiore. Per questo per indicare i valori
+dei tempi da impostare utilizza un vettore \param{times} di due strutture
+\struct{timespec} che permettono di indicare il valore del tempo con una
+precisione fino al nanosecondo (se ne è riportata la definizione in
+fig.~\ref{fig:sys_timespec_struct}).
\begin{figure}[!htb]
\footnotesize \centering
Come per le precedenti funzioni il primo elemento di \param{times} indica il
tempo di ultimo accesso ed il secondo quello di ultima modifica, e se si usa
il valore \val{NULL} verrà impostato il tempo corrente sia per l'ultimo
-accesso che per l'ultima modifica. Nei singoli elementi di \param{times} si
-possono inoltre utilizzare due valori speciali per il campo \var{tv\_nsec}:
-con \constd{UTIME\_NOW} si richiede l'uso del tempo corrente, mentre con
-\constd{UTIME\_OMIT} si richiede di non impostare il tempo. Si può così
-aggiornare in maniera specifica soltanto uno fra il tempo di ultimo accesso e
-quello di ultima modifica. Quando si usa uno di questi valori speciali per
-\var{tv\_nsec} il corrispondente valore di \var{tv\_sec} viene ignorato.
-
-Queste due funzioni sono una estensione definita nella revisione POSIX.1-2008
-dello standard POSIX, in Linux sono state introdotte a partire dal kernel
-2.6.22,\footnote{si tenga presente però che per kernel precedenti il 2.6.26 le
- due funzioni sono difettose nel rispetto di alcuni requisiti minori dello
- standard e nel controllo della correttezza dei tempi, per i dettagli dei
- quali si rimanda alla pagina di manuale.} e supportate dalla \acr{glibc} a
-partire dalla versione 2.6.\footnote{in precedenza, a partire dal kernel
- 2.6.16, era stata introdotta una \textit{system call} \funcm{futimesat}
- seguendo una bozza della revisione dello standard poi modificata; questa
- funzione, sostituita da \func{utimensat}, è stata dichiarata obsoleta, non è
- supportata da nessuno standard e non deve essere più utilizzata: pertanto
- non ne parleremo.} La prima è sostanzialmente una estensione di
-\func{futimes} che consente di specificare i tempi con precisione maggiore, la
-seconda supporta invece, rispetto ad \func{utimes}, una sintassi più complessa
-che consente una indicazione sicura del file su cui operare specificando la
-directory su cui si trova tramite il file descriptor \param{dirfd} ed il suo
-nome come \textit{pathname relativo} in \param{pathname}.\footnote{su Linux
- solo \func{utimensat} è una \textit{system call} e \func{futimens} è una
- funzione di libreria, infatti se \param{pathname} è \var{NULL} \param{dirfd}
- viene considerato un file descriptor ordinario e il cambiamento del tempo
- applicato al file sottostante, qualunque esso sia, per cui
- \code{futimens(fd, times}) è del tutto equivalente a \code{utimensat(fd,
- NULL, times, 0)}.}
-
-Torneremo su questa sintassi e sulla sua motivazione in
-sez.~\ref{sec:file_openat}, quando tratteremo tutte le altre funzioni (le
-cosiddette \textit{at-functions}) che la utilizzano; essa prevede comunque
-anche la presenza dell'argomento \param{flags} con cui attivare flag di
-controllo che modificano il comportamento della funzione, nel caso specifico
-l'unico valore consentito è \const{AT\_SYMLINK\_NOFOLLOW} che indica alla
-funzione di non dereferenziare i collegamenti simbolici, cosa che le permette
-di riprodurre le funzionalità di \func{lutimes}.
+accesso che per l'ultima modifica.
+Nei singoli elementi di \param{times} si possono inoltre utilizzare due valori
+speciali per il campo \var{tv\_nsec}: con \constd{UTIME\_NOW} si richiede
+l'uso del tempo corrente, mentre con \constd{UTIME\_OMIT} si richiede di non
+impostare il tempo. Si può così aggiornare in maniera specifica soltanto uno
+fra il tempo di ultimo accesso e quello di ultima modifica. Quando si usa uno
+di questi valori speciali per \var{tv\_nsec} il corrispondente valore di
+\var{tv\_sec} viene ignorato.
+Questa funzione e \func{utimensat} sono una estensione definita nella
+revisione POSIX.1-2008 dello standard POSIX; in Linux sono state introdotte a
+partire dal kernel 2.6.22, e sono supportate dalla \acr{glibc} a partire dalla
+versione 2.6, si tenga presente però che per kernel precedenti il 2.6.26 le
+due funzioni sono difettose nel rispetto di alcuni requisiti minori dello
+standard e nel controllo della correttezza dei tempi, per i dettagli dei quali
+si rimanda alla pagina di manuale.
\section{Il controllo di accesso ai file}
Una delle caratteristiche fondamentali di tutti i sistemi unix-like è quella
del controllo di accesso ai file, che viene implementato per qualunque
-filesystem standard.\footnote{per standard si intende che implementa le
- caratteristiche previste dallo standard POSIX; in Linux sono utilizzabili
- anche filesystem di altri sistemi operativi, che non supportano queste
- caratteristiche.} In questa sezione ne esamineremo i concetti essenziali e
-le funzioni usate per gestirne i vari aspetti.
+filesystem standard.\footnote{per filesystem standard si intende un filesystem
+ che implementi le caratteristiche previste dallo standard POSIX; in Linux
+ sono utilizzabili anche filesystem di altri sistemi operativi, che non
+ supportano queste caratteristiche.} In questa sezione ne esamineremo i
+concetti essenziali e le funzioni usate per gestirne i vari aspetti.
\subsection{I permessi per l'accesso ai file}
\begin{figure}[htb]
\centering
- \includegraphics[width=6cm]{img/fileperm}
+ \includegraphics[width=8cm]{img/fileperm}
\caption{Lo schema dei bit utilizzati per specificare i permessi di un file
contenuti nel campo \var{st\_mode} di \struct{stat}.}
\label{fig:file_perm_bit}
(in sez.~\ref{sec:file_special_perm}), lo schema di allocazione dei bit è
riportato in fig.~\ref{fig:file_perm_bit}. Come tutte le altre proprietà di
un file anche i permessi sono memorizzati nell'\textit{inode}, e come
-accennato in sez.~\ref{sec:file_types} essi sono vengono restituiti in una
-parte del campo \var{st\_mode} della struttura \struct{stat} (si veda di nuovo
+accennato in sez.~\ref{sec:file_types} essi vengono restituiti in una parte
+del campo \var{st\_mode} della struttura \struct{stat} (si veda di nuovo
fig.~\ref{fig:file_stat_struct}).
-In genere ci si riferisce ai tre livelli dei privilegi usando le lettere
-\texttt{u} (per \textit{user}), \texttt{g} (per \textit{group}) e \texttt{o}
-(per \textit{other}), inoltre se si vuole indicare tutti i raggruppamenti
-insieme si usa la lettera \texttt{a} (per \textit{all}). Si tenga ben presente
-questa distinzione dato che in certi casi, mutuando la terminologia in uso a
-suo tempo nel VMS, si parla dei permessi base come di permessi per
-\textit{owner}, \textit{group} ed \textit{all}, le cui iniziali possono dar
-luogo a confusione. Le costanti che permettono di accedere al valore numerico
-di questi bit nel campo \var{st\_mode}, già viste in
-tab.~\ref{tab:file_mode_flags}, sono riportate per chiarezza una seconda volta
-in tab.~\ref{tab:file_bit_perm}.
-
\begin{table}[htb]
\centering
\footnotesize
\label{tab:file_bit_perm}
\end{table}
+
+In genere ci si riferisce ai tre livelli dei privilegi usando le lettere
+\texttt{u} (per \textit{user}), \texttt{g} (per \textit{group}) e \texttt{o}
+(per \textit{other}), inoltre se si vuole indicare tutti i raggruppamenti
+insieme si usa la lettera \texttt{a} (per \textit{all}). Si tenga ben presente
+questa distinzione dato che in certi casi, mutuando la terminologia in uso a
+suo tempo nel VMS, si parla dei permessi base come di permessi per
+\textit{owner}, \textit{group} ed \textit{all}, le cui iniziali possono dar
+luogo a confusione. Le costanti che permettono di accedere al valore numerico
+di questi bit nel campo \var{st\_mode}, già viste in
+tab.~\ref{tab:file_mode_flags}, sono riportate per chiarezza una seconda volta
+in tab.~\ref{tab:file_bit_perm}.
+
I permessi vengono usati in maniera diversa dalle varie funzioni, e a seconda
che si riferiscano a dei file, dei collegamenti simbolici o delle directory;
qui ci limiteremo ad un riassunto delle regole generali, entrando nei dettagli
esecuzione e di quello di scrittura per la directory di destinazione. Gli
stessi permessi occorrono per cancellare un file da una directory (si ricordi
che questo non implica necessariamente la rimozione del contenuto del file dal
-disco). Per la cancellazione non è necessario nessun tipo di permesso per il
-file stesso dato che, come illustrato in sez.~\ref{sec:link_symlink_rename}
-esso non viene toccato, nella cancellazione infatti viene solo modificato il
+disco).
+
+Per la cancellazione non è necessario nessun tipo di permesso per il file
+stesso dato che, come illustrato in sez.~\ref{sec:link_symlink_rename} esso
+non viene toccato, nella cancellazione infatti viene solo modificato il
contenuto della directory, rimuovendo la voce che ad esso fa riferimento. Lo
stesso vale per poter rinominare o spostare il file in altra directory, in
entrambi i casi occorrerà il permesso di scrittura sulle directory che si
\subsection{Le funzioni per la gestione dei permessi dei file}
\label{sec:file_perm_management}
-Come visto in sez.~\ref{sec:file_access_control} il controllo di accesso ad un
-file viene fatto utilizzando l'\ids{UID} ed il \ids{GID} effettivo del processo;
-ci sono casi però in cui si può voler effettuare il controllo con l'\ids{UID}
-reale ed il \ids{GID} reale, vale a dire usando i valori di \ids{UID} e
-\ids{GID} relativi all'utente che ha lanciato il programma, e che, come
-accennato in sez.~\ref{sec:file_special_perm} e spiegato in dettaglio in
+Come visto in sez.~\ref{sec:file_perm_overview} il controllo di accesso ad un
+file viene fatto utilizzando l'\ids{UID} ed il \ids{GID} effettivo del
+processo; ci sono casi però in cui si può voler effettuare il controllo con
+l'\ids{UID} reale ed il \ids{GID} reale, vale a dire usando i valori di
+\ids{UID} e \ids{GID} relativi all'utente che ha lanciato il programma, e che,
+come accennato in sez.~\ref{sec:file_special_perm} e spiegato in dettaglio in
sez.~\ref{sec:proc_perms}, non è detto siano uguali a quelli effettivi.
Per far questo si può usare la funzione di sistema \funcd{access}, il cui
tratteremo insieme alle altre \textit{at-functions} in
sez.~\ref{sec:file_openat}.
+
Del tutto analoghe a \func{access} sono le due funzioni \funcm{euidaccess} e
\funcm{eaccess} che ripetono lo stesso controllo usando però gli
identificatori del gruppo effettivo, verificando quindi le effettive capacità
anche gli stessi valori e restituiscono gli stessi risultati e gli stessi
codici di errore.
-Per cambiare i permessi di un file il sistema mette ad disposizione due
-funzioni \funcd{chmod} e \funcd{fchmod}, che operano rispettivamente su un
-filename e su un file descriptor, i loro prototipi sono:
+Le due funzioni non sono previste da nessuno standard, ed utilizzabili solo
+avendo definito \macro{\_GNU\_SOURCE}; inoltre qualora le si vogliano
+utilizzare per verificare che un processo abbia i permessi per accedere ad un
+file prima di farlo effettivamente, ci si esporrebbe ad una \textit{race
+ condition}, dato che i permessi potrebbero cambiare nell'intervallo fra il
+controllo e l'accesso effettivo. Per questo motivo in questo caso è molto più
+semplice e sicuro tentare direttamente l'accesso, e trattare opportunamente
+l'eventuale fallimento per mancanza di permessi.
+
+Per cambiare i permessi di un file sono invece disponibili due funzioni di
+sistema \funcd{chmod} e \funcd{fchmod}, che operano rispettivamente usando il
+\textit{pathname} di un file o se questo è già aperto sul relativo file
+descriptor; i loro prototipi sono:
\begin{funcproto}{
\fhead{sys/types.h}
Entrambe le funzioni utilizzano come secondo argomento \param{mode}, una
variabile dell'apposito tipo primitivo \type{mode\_t} (vedi
-tab.~\ref{tab:intro_primitive_types}) utilizzato per specificare i permessi
-sui file.
+tab.~\ref{tab:intro_primitive_types}), che è una maschera binaria da
+utilizzare per specificare i permessi sui file.
\begin{table}[!htb]
\centering
\label{tab:file_permission_const}
\end{table}
-Le costanti con cui specificare i singoli bit di \param{mode} sono riportate
-in tab.~\ref{tab:file_permission_const}, e corrispondono agli stessi valori
-usati per \var{st\_mode} in tab.~\ref{tab:file_mode_flags}. Il valore
-di \param{mode} può essere ottenuto combinando fra loro con un OR binario le
-costanti simboliche relative ai vari bit, o specificato direttamente, come per
-l'omonimo comando di shell, con un valore numerico (la shell lo vuole in
-ottale, dato che i bit dei permessi sono divisibili in gruppi di tre), che si
-può calcolare direttamente usando lo schema di utilizzo dei bit illustrato in
+Si sono riportate in tab.~\ref{tab:file_permission_const} le costanti con cui
+indicare i singoli bit di \param{mode}; si noti come corrispondano agli stessi
+valori usati per \var{st\_mode} già visti in tab.~\ref{tab:file_mode_flags}.
+Il valore di \param{mode} può essere ottenuto combinando fra loro con un OR
+binario le costanti simboliche relative ai vari bit, o specificato
+direttamente, come per l'omonimo comando di shell \texttt{chmod}, con un
+valore numerico (con la shell in genere lo si scrive in ottale, dato che i bit
+dei permessi sono divisibili in gruppi di tre), che si può calcolare
+direttamente usando lo schema di utilizzo dei bit illustrato in
fig.~\ref{fig:file_perm_bit}.
Ad esempio i permessi standard assegnati ai nuovi file (lettura e scrittura
per il proprietario, sola lettura per il gruppo e gli altri) sono
-corrispondenti al valore ottale $0644$, un programma invece avrebbe anche il
-bit di esecuzione attivo, con un valore di $0755$, se si volesse attivare il
-bit \acr{suid} il valore da fornire sarebbe $4755$.
+corrispondenti al valore ottale \texttt{0644}, un programma invece avrebbe
+anche il bit di esecuzione attivo, con un valore ottale di \texttt{0755}, se
+infine si volesse attivare anche il bit \acr{suid} il valore ottale da fornire
+sarebbe \texttt{4755}.
Il cambiamento dei permessi di un file eseguito attraverso queste funzioni ha
comunque alcune limitazioni, previste per motivi di sicurezza. L'uso delle
funzioni infatti è possibile solo se l'\ids{UID} effettivo del processo
-corrisponde a quello del proprietario del file o dell'amministratore,
-altrimenti esse falliranno con un errore di \errcode{EPERM}.
+chiamante corrisponde a quello del proprietario del file o se il processo ha i
+privilegi di amministratore,\footnote{per la precisione la capacità
+ \const{CAP\_FOWNER}, vedi sez.~\ref{sec:proc_capabilities}.} in caso
+contrario esse falliranno con un errore di \errcode{EPERM}.
Ma oltre a questa regola generale, di immediata comprensione, esistono delle
limitazioni ulteriori. Per questo motivo, anche se si è proprietari del file,
\end{enumerate*}
Per alcuni filesystem\footnote{i filesystem più comuni (\textsl{ext2},
- \textsl{ext3}, \textsl{ext4}, \textsl{ReiserFS}) supportano questa
- caratteristica, che è mutuata da BSD.} è inoltre prevista un'ulteriore
-misura di sicurezza, volta a scongiurare l'abuso dei bit \acr{suid} e
-\acr{sgid}; essa consiste nel cancellare automaticamente questi bit dai
-permessi di un file qualora un processo che non appartenga
+ \textsl{ext3}, \textsl{ext4}, \textsl{xfs}, \texttt{btrfs}) supportano
+ questa caratteristica, che è mutuata da BSD.} è inoltre prevista
+un'ulteriore misura di sicurezza, volta a scongiurare l'abuso dei bit
+\acr{suid} e \acr{sgid}; essa consiste nel cancellare automaticamente questi
+bit dai permessi di un file qualora un processo che non appartenga
all'amministratore\footnote{per la precisione un processo che non dispone
della capacità \const{CAP\_FSETID}, vedi sez.~\ref{sec:proc_capabilities}.}
effettui una scrittura. In questo modo anche se un utente malizioso scopre un
gruppo, in quanto di default i permessi assegnati al gruppo non sono
sufficienti per un accesso in scrittura; in questo caso si deve aver cura di
usare prima della creazione dei file un valore per \textit{umask} lasci il
-permesso di scrittura.\footnote{in tal caso si può assegnare agli utenti del
- gruppo una \textit{umask} di $002$, anche se la soluzione migliore in questo
- caso è usare una ACL di default (vedi sez.~\ref{sec:file_ACL}).}
+permesso di scrittura per il gruppo.\footnote{in tal caso si può assegnare
+ agli utenti del gruppo una \textit{umask} di $002$, anche se la soluzione
+ migliore in questo caso è usare una ACL di default (vedi
+ sez.~\ref{sec:file_ACL}).}
Come avviene nel caso dei permessi esistono anche delle appropriate funzioni
-di sistema, \funcd{chown} \funcd{fchown} e \funcd{lchown}, che permettono di
+di sistema, \funcd{chown}, \funcd{fchown} e \funcd{lchown}, che permettono di
cambiare sia l'utente che il gruppo a cui un file appartiene; i rispettivi
prototipi sono:
\fdesc{Cambiano proprietario e gruppo proprietario di un file.}
}
-{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EPERM}] l'\ids{UID} effettivo non corrisponde a quello del
Per risolvere questo problema alcuni sistemi unix-like (e fra questi anche
Linux) hanno introdotto un meccanismo generico, detto \textit{Extended
Attributes} che consente di associare delle informazioni ulteriori ai
-singoli file.\footnote{essi ad esempio vengono usati per le ACL, che
- tratteremo in sez.~\ref{sec:file_ACL} e le \textit{file capabilities}, che
- vedremo in sez.~\ref{sec:proc_capabilities}.} Gli \textsl{attributi estesi}
-non sono altro che delle coppie nome/valore che sono associate permanentemente
-ad un oggetto sul filesystem, analoghi di quello che sono le variabili di
-ambiente (vedi sez.~\ref{sec:proc_environ}) per un processo.
+singoli file; ad esempio vengono usati per la gestione delle ACL, che
+tratteremo in sez.~\ref{sec:file_ACL} e per le \textit{file capabilities}, che
+vedremo in sez.~\ref{sec:proc_capabilities}. Gli \textsl{attributi estesi}
+(abbreviati in \textsl{xattr}) non sono altro che delle coppie nome/valore che
+sono associate permanentemente ad un oggetto sul filesystem, analoghi di
+quello che sono le variabili di ambiente (vedi sez.~\ref{sec:proc_environ})
+per un processo.
Altri sistemi (come Solaris, MacOS e Windows) hanno adottato un meccanismo
diverso in cui ad un file sono associati diversi flussi di dati, su cui
Si tenga presente che non tutti i filesystem supportano gli \textit{Extended
Attributes}; al momento della scrittura di queste dispense essi sono
presenti solo sui vari \textsl{extN}, \textsl{ReiserFS}, \textsl{JFS},
-\textsl{XFS} e \textsl{Btrfs}.\footnote{l'elenco è aggiornato a Luglio 2011.}
-Inoltre a seconda della implementazione ci possono essere dei limiti sulla
-quantità di attributi che si possono utilizzare.\footnote{ad esempio nel caso
- di \textsl{ext2} ed \textsl{ext3} è richiesto che essi siano contenuti
+\textsl{XFS}, \textsl{Btrfs}, \textsl{Lustre} e \textsl{OCFS2}. Inoltre a
+seconda della implementazione ci possono essere dei limiti sulla quantità di
+attributi che si possono utilizzare.\footnote{ad esempio nel caso di
+ \textsl{ext2} ed \textsl{ext3} è richiesto che essi siano contenuti
all'interno di un singolo blocco, pertanto con dimensioni massime pari a
1024, 2048 o 4096 byte a seconda delle dimensioni di quest'ultimo impostate
- in fase di creazione del filesystem, mentre con \textsl{XFS} non ci sono
- limiti ed i dati vengono memorizzati in maniera diversa (nell'\textit{inode}
- stesso, in un blocco a parte, o in una struttura ad albero dedicata) per
- mantenerne la scalabilità.} Infine lo spazio utilizzato per mantenere gli
-attributi estesi viene tenuto in conto per il calcolo delle quote di utente e
-gruppo proprietari del file.
+ in fase di creazione del filesystem, mentre con \textsl{XFS} e
+ \textsl{Btrfs} non ci sono limiti ed i dati vengono memorizzati in maniera
+ diversa (nell'\textit{inode} stesso, in un blocco a parte, o in una
+ struttura ad albero dedicata) per mantenerne la scalabilità; lasciamo i
+ dettagli dei vari filesystem alla documentazione accessibile con \texttt{man
+ xattr}.} Infine lo spazio utilizzato per mantenere gli attributi estesi
+viene tenuto in conto per il calcolo delle quote di utente e gruppo
+proprietari del file.
Come meccanismo per mantenere informazioni aggiuntive associate al singolo
file, gli \textit{Extended Attributes} possono avere usi anche molto diversi
specificato nella forma \texttt{namespace.attribute}, dove \texttt{namespace}
fa riferimento alla classe a cui l'attributo appartiene, mentre
\texttt{attribute} è il nome ad esso assegnato. In tale forma il nome di un
-attributo esteso deve essere univoco. Al momento\footnote{della scrittura di
- questa sezione, kernel 2.6.23, ottobre 2007.} sono state definite le quattro
-classi di attributi riportate in tab.~\ref{tab:extended_attribute_class}.
+attributo esteso deve essere univoco. Al momento sono state definite le
+quattro classi di attributi riportate in
+tab.~\ref{tab:extended_attribute_class}.
\begin{table}[htb]
\centering
di meccanismi evoluti di controllo di accesso come
\textit{SELinux} o le \textit{capabilities} dei
file di sez.~\ref{sec:proc_capabilities}.\\
- \texttt{system} & Gli \textit{extended security attributes}: sono usati
+ \texttt{system} & Gli \textit{extended system attributes}: sono usati
dal kernel per memorizzare dati di sistema associati ai
file come le ACL (vedi sez.~\ref{sec:file_ACL}) o le
\textit{capabilities} (vedi
sez.~\ref{sec:proc_capabilities}).\\
\texttt{trusted}& I \textit{trusted extended attributes}: vengono
- utilizzati per poter realizzare in user space
+ utilizzati per poter realizzare in \textit{user space}
meccanismi che consentano di mantenere delle
informazioni sui file che non devono essere accessibili
ai processi ordinari.\\
Dato che uno degli usi degli \textit{Extended Attributes} è di impiegarli per
-realizzare delle estensioni (come le ACL, \textit{SELinux}, ecc.) al
-tradizionale meccanismo dei controlli di accesso di Unix, l'accesso ai loro
+realizzare delle estensioni al tradizionale meccanismo dei controlli di
+accesso di Unix (come le ACL, \textit{SELinux}, ecc.), l'accesso ai loro
valori viene regolato in maniera diversa a seconda sia della loro classe che
di quali, fra le estensioni che li utilizzano, sono poste in uso. In
particolare, per ciascuna delle classi riportate in
modulo di sicurezza che si sta utilizzando al momento (ciascuno avrà le
sue). Se non è stato caricato nessun modulo di sicurezza l'accesso in
lettura sarà consentito a tutti i processi, mentre quello in scrittura solo
- ai processi con privilegi amministrativi dotati della capacità
- \const{CAP\_SYS\_ADMIN}.
+ ai processi con privilegi amministrativi (per la precisione dotati della
+ capacità \const{CAP\_SYS\_ADMIN}, vedi sez.~\ref{sec:proc_capabilities}).
\item[\texttt{system}] Anche l'accesso agli \textit{extended system
attributes} dipende dalle politiche di accesso che il kernel realizza
ai processi che hanno la capacità di eseguire una ricerca sul file (cioè
hanno il permesso di lettura sulla directory che contiene il file) ed in
scrittura al proprietario del file o ai processi dotati della capacità
- \const{CAP\_FOWNER}.\footnote{vale a dire una politica di accesso analoga a
- quella impiegata per gli ordinari permessi dei file.}
+ \const{CAP\_FOWNER}, vale a dire una politica di accesso analoga a quella
+ impiegata per gli ordinari permessi dei file.
\item[\texttt{trusted}] L'accesso ai \textit{trusted extended attributes}, sia
per la lettura che per la scrittura, è consentito soltanto ai processi con
privilegi amministrativi dotati della capacità \const{CAP\_SYS\_ADMIN}. In
- questo modo si possono utilizzare questi attributi per realizzare in user
- space dei meccanismi di controllo che accedono ad informazioni non
- disponibili ai processi ordinari.
+ questo modo si possono utilizzare questi attributi per realizzare in
+ \textit{user space} dei meccanismi di controllo che accedono ad informazioni
+ non disponibili ai processi ordinari.
\item[\texttt{user}] L'accesso agli \textit{extended user attributes} è
regolato dai normali permessi dei file: occorre avere il permesso di lettura
due casi hanno a che fare con il contenuto del file, e nella discussione
relativa all'uso degli \textit{extended user attributes} nessuno è mai stato
capace di indicare una qualche forma sensata di utilizzo degli stessi per
- collegamenti simbolici o file di dispositivo, e neanche per le \textit{fifo} o i
- socket. Per questo motivo essi sono stati completamente disabilitati per
- tutto ciò che non sia un file regolare o una directory.\footnote{si può
- verificare la semantica adottata consultando il file \texttt{fs/xattr.c}
- dei sorgenti del kernel.} Inoltre per le directory è stata introdotta una
- ulteriore restrizione, dovuta di nuovo alla presenza ordinaria di permessi
- di scrittura completi su directory come \texttt{/tmp}. Per questo motivo,
- per evitare eventuali abusi, se una directory ha lo \textit{sticky bit}
- attivo sarà consentito scrivere i suoi \textit{extended user attributes}
- soltanto se si è proprietari della stessa, o si hanno i privilegi
- amministrativi della capacità \const{CAP\_FOWNER}.
+ collegamenti simbolici o file di dispositivo, e neanche per le \textit{fifo}
+ o i socket.
+
+ Per questo motivo essi sono stati completamente disabilitati per tutto ciò
+ che non sia un file regolare o una directory.\footnote{si può verificare la
+ semantica adottata consultando il file \texttt{fs/xattr.c} dei sorgenti
+ del kernel.} Inoltre per le directory è stata introdotta una ulteriore
+ restrizione, dovuta di nuovo alla presenza ordinaria di permessi di
+ scrittura completi su directory come \texttt{/tmp}. Per questo motivo, per
+ evitare eventuali abusi, se una directory ha lo \textit{sticky bit} attivo
+ sarà consentito scrivere i suoi \textit{extended user attributes} soltanto
+ se si è proprietari della stessa, o si hanno i privilegi amministrativi
+ della capacità \const{CAP\_FOWNER}.
\end{basedescript}
Le funzioni per la gestione degli attributi estesi, come altre funzioni di
indicato comprensivo di prefisso del \textit{namespace} cui appartiene (uno
dei valori di tab.~\ref{tab:extended_attribute_class}) nella forma
\texttt{namespace.attributename}, come stringa terminata da un carattere NUL.
-Il suo valore verrà restituito nel buffer puntato dall'argomento \param{value}
-per una dimensione massima di \param{size} byte;\footnote{gli attributi estesi
- possono essere costituiti arbitrariamente da dati testuali o binari.} se
-quest'ultima non è sufficiente si avrà un errore di \errcode{ERANGE}.
+Il valore dell'attributo richiesto verrà restituito nel buffer puntato
+dall'argomento \param{value} per una dimensione massima di \param{size} byte
+(gli attributi estesi possono essere costituiti arbitrariamente da dati
+testuali o binari); se quest'ultima non è sufficiente si avrà un errore di
+\errcode{ERANGE}.
Per evitare di dover indovinare la dimensione di un attributo per tentativi si
può eseguire una interrogazione utilizzando un valore nullo per \param{size};
in questo caso non verrà letto nessun dato, ma verrà restituito come valore di
ritorno della funzione chiamata la dimensione totale dell'attributo esteso
richiesto, che si potrà usare come stima per allocare un buffer di dimensioni
-sufficienti.\footnote{si parla di stima perché anche se le funzioni
- restituiscono la dimensione esatta dell'attributo al momento in cui sono
- eseguite, questa potrebbe essere modificata in qualunque momento da un
- successivo accesso eseguito da un altro processo.}
+sufficienti.
+
+Si tenga conto che questa è comunque una stima perché anche se le funzioni
+restituiscono la dimensione esatta dell'attributo al momento in cui sono
+eseguite, questa potrebbe essere modificata in qualunque momento da un
+successivo accesso eseguito da un altro processo, pertanto si verifichi sempre
+il valore di ritorno ed il codice di errore della funzione usata, senza dare
+per scontato che essa abbia sempre successo.
-Un secondo gruppo di funzioni è quello che consente di impostare il valore di
-un attributo esteso, queste sono \funcd{setxattr}, \funcd{lsetxattr} e
-\funcd{fsetxattr}, e consentono di operare rispettivamente su un file, su un
-collegamento simbolico o specificando un file descriptor; i loro prototipi sono:
+Un secondo gruppo di funzioni sono quelle che consentono di impostare il
+valore di un attributo esteso, le funzioni sono \funcd{setxattr},
+\funcd{lsetxattr} e \funcd{fsetxattr} e consentono di operare rispettivamente
+su un file, su un collegamento simbolico o utilizzando un file descriptor; i
+rispettivi prototipi sono:
\begin{funcproto}{
\fhead{sys/types.h}
\fhead{attr/xattr.h}
-\fdecl{int setxattr(const char *path, const char *name, const void *value,
- size\_t size, int flags)}
-\fdecl{int lsetxattr(const char *path, const char *name, const void *value,
- size\_t size, int flags)}
-\fdecl{int fsetxattr(int filedes, const char *name, const void *value, size\_t
- size, int flags)}
+\fdecl{int setxattr(const char *path, const char *name, const void *value,\\
+ \phantom{int setxattr(}size\_t size, int flags)}
+\fdecl{int lsetxattr(const char *path, const char *name, const void *value,\\
+ \phantom{int lsetxattr(}size\_t size, int flags)}
+\fdecl{int fsetxattr(int filedes, const char *name, const void *value,\\
+ \phantom{int fsetxattr(}size\_t size, int flags)}
\fdesc{Impostano il valore di un attributo esteso.}
}
permessi di accesso all'attributo.}
\end{funcproto}
-Le tre funzioni prendono come primo argomento un valore adeguato al loro
-scopo, usato in maniera del tutto identica a quanto visto in precedenza per le
-analoghe che leggono gli attributi estesi. Il secondo argomento \param{name}
-deve indicare, anche in questo caso con gli stessi criteri appena visti per le
-analoghe \func{getxattr}, \func{lgetxattr} e \func{fgetxattr}, il nome
-(completo di suffisso) dell'attributo su cui si vuole operare.
-
-Il valore che verrà assegnato all'attributo dovrà essere preparato nel buffer
-puntato da \param{value}, e la sua dimensione totale (in byte) sarà indicata
-dall'argomento \param{size}. Infine l'argomento \param{flag} consente di
-controllare le modalità di sovrascrittura dell'attributo esteso, esso può
-prendere due valori: con \constd{XATTR\_REPLACE} si richiede che l'attributo
-esista, nel qual caso verrà sovrascritto, altrimenti si avrà errore, mentre
-con \constd{XATTR\_CREATE} si richiede che l'attributo non esista, nel qual
-caso verrà creato, altrimenti si avrà errore ed il valore attuale non sarà
-modificato. Utilizzando per \param{flag} un valore nullo l'attributo verrà
-modificato se è già presente, o creato se non c'è.
+Le tre funzioni prendono come primo argomento un valore adeguato al loro scopo
+(un \textit{pathname} le prime due, un file descriptor la terza), usato in
+maniera del tutto identica a quanto visto in precedenza per le analoghe che
+leggono gli attributi estesi.
+
+Il secondo argomento, \param{name}, deve indicare, anche in questo caso con
+gli stessi criteri appena visti per le analoghe \func{getxattr},
+\func{lgetxattr} e \func{fgetxattr}, il nome (completo di suffisso)
+dell'attributo su cui si vuole operare. Il valore che verrà assegnato
+all'attributo dovrà essere preparato nel buffer puntato da \param{value}, e la
+sua dimensione totale (in byte) dovrà essere indicata dall'argomento
+\param{size}.
+
+Infine l'argomento \param{flag} consente di controllare le modalità di
+sovrascrittura dell'attributo esteso, esso può prendere due valori: con
+\constd{XATTR\_REPLACE} si richiede che l'attributo esista, nel qual caso
+verrà sovrascritto ed altrimenti si avrà errore; con \constd{XATTR\_CREATE} si
+richiede che l'attributo non esista, nel qual caso verrà creato, altrimenti si
+avrà errore ed il valore attuale non sarà modificato. Utilizzando per
+\param{flag} un valore nullo l'attributo verrà modificato se è già presente, o
+creato se non c'è.
Le funzioni finora illustrate permettono di leggere o scrivere gli attributi
-estesi, ma sarebbe altrettanto utile poter vedere quali sono gli attributi
-presenti; a questo provvedono le funzioni di sistema \funcd{listxattr},
-\funcd{llistxattr} e \funcd{flistxattr} i cui prototipi sono:
+estesi presenti su un file, ma sarebbe altrettanto utile poter sapere quali
+sono questi attributi; per questo sono disponibili le ulteriori tre funzioni
+di sistema \funcd{listxattr}, \funcd{llistxattr} e \funcd{flistxattr} i cui
+prototipi sono:
\begin{funcproto}{
\fhead{sys/types.h}
Il modello classico dei permessi di Unix, per quanto funzionale ed efficiente,
è comunque piuttosto limitato e per quanto possa aver coperto per lunghi anni
le esigenze più comuni con un meccanismo semplice e potente, non è in grado di
-rispondere in maniera adeguata a situazioni che richiedono una gestione
+rispondere in maniera adeguata a situazioni che richiedono una gestione più
complessa dei permessi di accesso.\footnote{già un requisito come quello di
dare accesso in scrittura ad alcune persone ed in sola lettura ad altre non
si può soddisfare in maniera semplice.}
compilatore con l'opzione \texttt{-lacl}. Si tenga presente inoltre che le ACL
devono essere attivate esplicitamente montando il filesystem\footnote{che deve
supportarle, ma questo è ormai vero per praticamente tutti i filesystem più
- comuni, con l'eccezione di NFS per il quale esiste però un supporto
- sperimentale.} su cui le si vogliono utilizzare con l'opzione \texttt{acl}
+ comuni, con l'eccezione di NFS per il quale esiste però il supporto per le
+ versioni NFSv2 e NFSv3 del protocollo, con NFSv4 esistono invece delle ACL
+ native che hannno una semantica diversa, su cui si possono mappare le ACL
+ POSIX, su quelle di NFSv4, ma l'inverso è possibile solo in forma
+ incompleta.} su cui le si vogliono utilizzare con l'opzione \texttt{acl}
attiva. Dato che si tratta di una estensione è infatti opportuno utilizzarle
soltanto laddove siano necessarie.
vengono sempre utilizzati gli identificatori del gruppo \textit{effective} del
processo, ma in caso di presenza di una ACL sul file, i passi attraverso i
quali viene stabilito se il processo ha il diritto di accesso sono i seguenti:
-\begin{enumerate}
+\begin{enumerate*}
\item Se l'\ids{UID} del processo è nullo (se cioè si è l'amministratore)
l'accesso è sempre garantito senza nessun controllo.\footnote{più
precisamente se si devono avere le capacità \const{CAP\_DAC\_OVERRIDE} per
\end{itemize*}
\item Se la voce \const{ACL\_USER\_OBJ} contiene il permesso richiesto,
l'accesso è consentito, altrimenti l'accesso è negato.
-\end{enumerate}
+\end{enumerate*}
I passi di controllo vengono eseguiti esattamente in questa sequenza, e la
decisione viene presa non appena viene trovata una corrispondenza con gli
% LocalWords: setmntent getmntent addmntent endmntent hasmntopt such offsetof
% LocalWords: member scan attack EOVERFLOW BITS blkcnt rdev FDCWD functions
% LocalWords: faccessat grpid lacl AppArmor capsetp mygetfacl table Tb MSK
-% LocalWords: LAZYTIME submount peer
+% LocalWords: LAZYTIME submount peer protected hardlink symlinks silly RDWR
+% LocalWords: renames unreachable CLOEXEC mkstemps mkostemps suffixlen Aug
+% LocalWords: prefissoXXXXXXsuffisso nell'I fstatat statx sull' drwxrwxrwt
+% LocalWords: Disalloca
%%% Local Variables:
%%% mode: latex
projects / gapil.git / blobdiff