%% filedir.tex
%%
-%% Copyright (C) 2000-2015 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2018 Simone Piccardi. Permission is granted to
%% copy, distribute and/or modify this document under the terms of the GNU Free
%% Documentation License, Version 1.1 or any later version published by the
%% Free Software Foundation; with the Invariant Sections being "Un preambolo",
entry}. Le \textit{dentry} sono gli oggetti che il kernel usa per eseguire
la \textit{pathname resolution}, ciascuna di esse corrisponde ad un
\textit{pathname} e contiene il riferimento ad un \textit{inode}, che come
-vedremo a breve è l'oggetto usato dal kernel per identificare un un
+vedremo a breve è l'oggetto usato dal kernel per identificare un
file.\footnote{in questo caso si parla di file come di un qualunque oggetto
generico che sta sul filesystem e non dell'oggetto file del VFS cui
accennavamo prima.} La \textit{dentry} ottenuta dalla chiamata alla funzione
\hline
\end{tabular}
\caption{Le principali operazioni sugli \textit{inode} definite tramite
- \kstruct{inode\_operation}.}
+ \kstructd{inode\_operation}.}
\label{tab:file_inode_operations}
\end{table}
sez.~\ref{sec:file_asyncronous_io}) sul file.\\
\hline
\end{tabular}
- \caption{Operazioni sui file definite tramite \kstruct{file\_operation}.}
+ \caption{Operazioni sui file definite tramite \kstructd{file\_operation}.}
\label{tab:file_file_operations}
\end{table}
alle funzioni presenti nelle due strutture \kstruct{inode\_operation} e
\kstruct{file\_operation}. Ovviamente non è detto che tutte le operazioni
possibili siano poi disponibili in tutti i casi, ad esempio \code{llseek} non
-sarà presente per un dispositivo come la porta seriale o per una fifo, mentre
-sui file del filesystem \texttt{vfat} non saranno disponibili i permessi, ma
-resta il fatto che grazie al VFS le \textit{system call} per le operazioni sui
-file possono restare sempre le stesse nonostante le enormi differenze che
-possono esserci negli oggetti a cui si applicano.
+sarà presente per un dispositivo come la porta seriale o per una
+\textit{fifo}, mentre sui file del filesystem \texttt{vfat} non saranno
+disponibili i permessi, ma resta il fatto che grazie al VFS le \textit{system
+ call} per le operazioni sui file possono restare sempre le stesse nonostante
+le enormi differenze che possono esserci negli oggetti a cui si applicano.
\itindend{Virtual~File~System~(VFS)}
che lo compongono, detti anche \textit{mount flags}, devono essere impostati
con un OR aritmetico dei valori dalle costanti riportate nell'elenco seguente:
-\begin{basedescript}{\desclabelwidth{2.cm}\desclabelstyle{\nextlinelabel}}
+\begin{basedescript}{\desclabelwidth{1.9cm}\desclabelstyle{\nextlinelabel}}
\itindbeg{bind~mount}
\item[\constd{MS\_BIND}] Effettua un cosiddetto \textit{bind mount}, in cui è
possibile montare una directory di un filesystem in un'altra directory,
\textit{pathname} relativi all'interno del filesystem non possa fallire.
\item[\constd{MS\_NOATIME}] Viene disabilitato sul filesystem l'aggiornamento
- degli \textit{access time} (vedi sez.~\ref{sec:file_file_times}) per
- qualunque tipo di file. Dato che l'aggiornamento degli \textit{access time}
+ dell'\textit{access time} (vedi sez.~\ref{sec:file_file_times}) per
+ qualunque tipo di file. Dato che l'aggiornamento dell'\textit{access time}
è una funzionalità la cui utilità è spesso irrilevante ma comporta un costo
elevato visto che una qualunque lettura comporta comunque una scrittura su
disco,\footnote{e questo ad esempio ha conseguenze molto pesanti nell'uso
di accedere anche a risorse cui non dovrebbe.
\item[\constd{MS\_NODIRATIME}] Viene disabilitato sul filesystem
- l'aggiornamento degli \textit{access time} (vedi
- sez.~\ref{sec:file_file_times}), ma soltanto per le directory. Costituisce
+ l'aggiornamento dell'\textit{access time} (vedi
+ sez.~\ref{sec:file_file_times}) ma soltanto per le directory. Costituisce
una alternativa per \const{MS\_NOATIME}, che elimina l'informazione per le
directory, che in pratica che non viene mai utilizzata, mantenendola per i
file in cui invece ha un impiego, sia pur limitato.
% TODO trattare l'opzione \texttt{lazytime} introdotta con il kernel 4.0,
% vedi http://lwn.net/Articles/621046/
-\item[\constd{MS\_RELATIME}] Indica di effettuare l'aggiornamento degli
- \textit{access time} sul filesystem soltanto quando questo risulti
+\item[\constd{MS\_RELATIME}] Indica di effettuare l'aggiornamento
+ dell'\textit{access time} sul filesystem soltanto quando questo risulti
antecedente il valore corrente del \textit{modification time} o del
\textit{change time} (per i tempi dei file si veda
sez.~\ref{sec:file_file_times}). L'opzione è disponibile a partire dal
\label{fig:sys_statfs}
\end{figure}
-\conffilebeg{/etc/mtab} La \acr{glibc} provvede infine una serie di funzioni
-per la gestione dei due file \conffiled{/etc/fstab}\footnote{più precisamente
- \funcm{setfsent}, \funcm{getfsent}, \funcm{getfsfile}, \funcm{getfsspec},
- \funcm{endfsent}.} ed \conffile{/etc/mtab}\footnote{più precisamente
- \funcm{setmntent}, \funcm{getmntent},\funcm{getmntent\_r},
- \funcm{addmntent},\funcm{endmntent}, \funcm{hasmntopt}.} che
-convenzionalmente sono usati in quasi tutti i sistemi unix-like per mantenere
-rispettivamente le informazioni riguardo ai filesystem da montare e a quelli
-correntemente montati. Le funzioni servono a leggere il contenuto di questi
-file in opportune strutture \structd{fstab} e \structd{mntent}, e, nel caso di
-\conffile{/etc/mtab}, per inserire e rimuovere le voci presenti nel file.
+\conffilebeg{/etc/mtab}
+
+La \acr{glibc} provvede infine una serie di funzioni per la gestione dei due
+file \conffiled{/etc/fstab}\footnote{più precisamente \funcm{setfsent},
+ \funcm{getfsent}, \funcm{getfsfile}, \funcm{getfsspec}, \funcm{endfsent}.}
+ed \conffile{/etc/mtab}\footnote{più precisamente \funcm{setmntent},
+ \funcm{getmntent},\funcm{getmntent\_r}, \funcm{addmntent},\funcm{endmntent},
+ \funcm{hasmntopt}.} che convenzionalmente sono usati in quasi tutti i
+sistemi unix-like per mantenere rispettivamente le informazioni riguardo ai
+filesystem da montare e a quelli correntemente montati. Le funzioni servono a
+leggere il contenuto di questi file in opportune strutture \structd{fstab} e
+\structd{mntent}, e, nel caso di \conffile{/etc/mtab}, per inserire e
+rimuovere le voci presenti nel file.
In generale si dovrebbero usare queste funzioni, in particolare quelle
relative a \conffile{/etc/mtab}, quando si debba scrivere un programma che
disponibile e sempre aggiornata. Per questo motivo tralasceremo la
trattazione, di queste funzioni, rimandando al manuale della \acr{glibc}
\cite{GlibcMan} per la documentazione completa.
+
\conffileend{/etc/mtab}
% TODO (bassa priorità) scrivere delle funzioni (getfsent e getmntent &C)
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, 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.
+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.
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
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 libc4 e nella
- 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.
+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.
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,
\end{funcproto}
La funzione apre un \textit{directory stream} per la directory
-\param{dirname}, ritornando il puntatore ad un oggetto di tipo \type{DIR} (che
+\param{dirname}, ritornando il puntatore ad un oggetto di tipo \typed{DIR} (che
è il tipo opaco usato dalle librerie per gestire i \textit{directory stream})
da usare per tutte le operazioni successive, la funzione inoltre posiziona lo
\textit{stream} sulla prima voce contenuta nella directory.
della stringa.
Per quanto riguarda il significato dei campi opzionali, il campo \var{d\_type}
-indica il tipo di file (se fifo, directory, collegamento simbolico, ecc.), e
-consente di evitare una successiva chiamata a \func{lstat} (vedi
+indica il tipo di file (se \textit{fifo}, directory, collegamento simbolico,
+ecc.), e consente di evitare una successiva chiamata a \func{lstat} (vedi
sez.~\ref{sec:file_stat}) per determinarlo. I suoi possibili valori sono
riportati in tab.~\ref{tab:file_dtype_macro}. Si tenga presente che questo
valore è disponibile solo per i filesystem che ne supportano la restituzione
\constd{DT\_REG} & File normale.\\
\constd{DT\_DIR} & Directory.\\
\constd{DT\_LNK} & Collegamento simbolico.\\
- \constd{DT\_FIFO} & Fifo.\\
+ \constd{DT\_FIFO} & \textit{Fifo}.\\
\constd{DT\_SOCK} & Socket.\\
\constd{DT\_CHR} & Dispositivo a caratteri.\\
\constd{DT\_BLK} & Dispositivo a blocchi.\\
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 fifo ed i
+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
\item[\errcode{EEXIST}] \param{pathname} esiste già o è un collegamento
simbolico.
\item[\errcode{EINVAL}] il valore di \param{mode} non indica un file, una
- fifo, un socket o un dispositivo.
+ \textit{fifo}, un socket o un dispositivo.
\item[\errcode{EPERM}] non si hanno privilegi sufficienti a creare
l'\texttt{inode}, o il filesystem su cui si è cercato di
creare \param{pathname} non supporta l'operazione.
\const{S\_IFREG} per un file regolare (che sarà creato vuoto),
\const{S\_IFBLK} per un dispositivo a blocchi, \const{S\_IFCHR} per un
dispositivo a caratteri, \const{S\_IFSOCK} per un socket e \const{S\_IFIFO}
-per una fifo;\footnote{con Linux la funzione non può essere usata per creare
- directory o collegamenti simbolici, si dovranno usare le funzioni
+per una \textit{fifo};\footnote{con Linux la funzione non può essere usata per
+ creare directory o collegamenti simbolici, si dovranno usare le funzioni
\func{mkdir} e \func{symlink} a questo dedicate.} un valore diverso
comporterà l'errore \errcode{EINVAL}. Inoltre \param{pathname} non deve
esistere, neanche come collegamento simbolico.
mentre è presente in SVr4 e 4.4BSD, ma esistono differenze nei comportamenti
e nei codici di errore, tanto che questa è stata introdotta in POSIX.1-2001
con una nota che la definisce portabile solo quando viene usata per creare
- delle fifo, ma comunque deprecata essendo utilizzabile a tale scopo la
- specifica \func{mkfifo}.} l'uso per la creazione di un file ordinario, di
-una fifo o di un socket è consentito anche agli utenti normali.
+ delle \textit{fifo}, ma comunque deprecata essendo utilizzabile a tale scopo
+ 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
Dato che la funzione di sistema \func{mknod} presenta diverse varianti nei
vari sistemi unix-like, lo standard POSIX.1-2001 la dichiara portabile solo in
-caso di creazione delle fifo, ma anche in questo caso alcune combinazioni
-degli argomenti restano non specificate, per cui nello stesso standard è stata
-introdotta una funzione specifica per creare una fifo deprecando l'uso di
-\func{mknod} a tale riguardo. La funzione è \funcd{mkfifo} ed il suo
-prototipo è:
+caso di creazione delle \textit{fifo}, ma anche in questo caso alcune
+combinazioni degli argomenti restano non specificate, per cui nello stesso
+standard è stata introdotta una funzione specifica per creare una
+\textit{fifo} deprecando l'uso di \func{mknod} a tale riguardo. La funzione è
+\funcd{mkfifo} ed il suo prototipo è:
\begin{funcproto}{
\fhead{sys/types.h}
\fhead{sys/stat.h}
\fdecl{int mkfifo(const char *pathname, mode\_t mode)}
-\fdesc{Crea una fifo.}
+\fdesc{Crea una \textit{fifo}.}
}
{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
caso \var{errno} assumerà \errval{EACCES}, \errval{EEXIST},
\errval{EROFS} nel loro significato generico.}
\end{funcproto}
-La funzione crea la fifo \param{pathname} con i permessi \param{mode}. Come
-per \func{mknod} il file \param{pathname} non deve esistere (neanche come
-collegamento simbolico); al solito i permessi specificati da \param{mode}
-vengono modificati dal valore di \textit{umask} (vedi
-sez.~\ref{sec:file_perm_management}).
+La funzione crea la \textit{fifo} \param{pathname} con i
+permessi \param{mode}. Come per \func{mknod} il file \param{pathname} non deve
+esistere (neanche come collegamento simbolico); al solito i permessi
+specificati da \param{mode} vengono modificati dal valore di \textit{umask}
+(vedi sez.~\ref{sec:file_perm_management}).
\index{file!speciali|)}
Si noti come i vari membri della struttura siano specificati come tipi
primitivi del sistema, di quelli definiti in
tab.~\ref{tab:intro_primitive_types}, e dichiarati in \headfile{sys/types.h},
-con l'eccezione di \type{blksize\_t} e \type{blkcnt\_t} che sono nuovi tipi
+con l'eccezione di \typed{blksize\_t} e \typed{blkcnt\_t} che sono nuovi tipi
introdotti per rendersi indipendenti dalla piattaforma.
Benché la descrizione dei commenti di fig.~\ref{fig:file_stat_struct} sia
\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)
\subsection{I tipi di file}
\macrod{S\_ISDIR}\texttt{(m)} & Directory.\\
\macrod{S\_ISCHR}\texttt{(m)} & Dispositivo a caratteri.\\
\macrod{S\_ISBLK}\texttt{(m)} & Dispositivo a blocchi.\\
- \macrod{S\_ISFIFO}\texttt{(m)} & Fifo.\\
+ \macrod{S\_ISFIFO}\texttt{(m)} & \textit{Fifo}.\\
\macrod{S\_ISLNK}\texttt{(m)} & Collegamento simbolico.\\
\macrod{S\_ISSOCK}\texttt{(m)} & Socket.\\
\hline
\constd{S\_IFBLK} & 0060000 & Dispositivo a blocchi.\\
\constd{S\_IFDIR} & 0040000 & Directory.\\
\constd{S\_IFCHR} & 0020000 & Dispositivo a caratteri.\\
- \constd{S\_IFIFO} & 0010000 & Fifo.\\
+ \constd{S\_IFIFO} & 0010000 & \textit{Fifo}.\\
\hline
\constd{S\_ISUID} & 0004000 & Set user ID (\acr{suid}) bit, vedi
sez.~\ref{sec:file_special_perm}).\\
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 fifo ed i file di dispositivo
+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
\footnotesize
\begin{tabular}[c]{|l|c|c|c|c|c|c|l|}
\hline
- \multicolumn{1}{|p{2.8cm}|}{\centering{\vspace{6pt}\textbf{Funzione}}} &
+ \multicolumn{1}{|p{2.3cm}|}{\centering{\vspace{6pt}\textbf{Funzione}}} &
\multicolumn{3}{|p{3.2cm}|}{\centering{
\textbf{File o directory del riferimento}}}&
\multicolumn{3}{|p{3.2cm}|}{\centering{
\textbf{Directory contenente il riferimento}}}
- &\multicolumn{1}{|p{3.4cm}|}{\centering{\vspace{6pt}\textbf{Note}}} \\
+ &\multicolumn{1}{|p{3.cm}|}{\centering{\vspace{6pt}\textbf{Note}}} \\
\cline{2-7}
\cline{2-7}
- \multicolumn{1}{|p{2.8cm}|}{}
+ \multicolumn{1}{|p{2.3cm}|}{}
&\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(a)}}}
&\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(m)}}}
&\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(c)}}}
se esegue \func{rmdir}\\
\func{rename}
& -- & -- &$\bullet$& -- &$\bullet$&$\bullet$&
- per entrambi gli argomenti\\
+ per ambo gli argomenti\\
\func{rmdir}
& -- & -- & -- & -- &$\bullet$&$\bullet$&\\
- \func{truncate}, \func{ftruncate}
+ \func{truncate}
+ & -- &$\bullet$&$\bullet$& -- & -- & -- &\\
+ \func{ftruncate}
& -- &$\bullet$&$\bullet$& -- & -- & -- &\\
\func{unlink}
& -- & -- &$\bullet$& -- &$\bullet$&$\bullet$&\\
\textbf{\var{st\_mode}} bit & \textbf{Significato} \\
\hline
\hline
- \constd{S\_IRUSR} & \textit{user-read}, l'utente può leggere.\\
- \constd{S\_IWUSR} & \textit{user-write}, l'utente può scrivere.\\
- \constd{S\_IXUSR} & \textit{user-execute}, l'utente può eseguire.\\
+ \const{S\_IRUSR} & \textit{user-read}, l'utente può leggere.\\
+ \const{S\_IWUSR} & \textit{user-write}, l'utente può scrivere.\\
+ \const{S\_IXUSR} & \textit{user-execute}, l'utente può eseguire.\\
\hline
- \constd{S\_IRGRP} & \textit{group-read}, il gruppo può leggere.\\
- \constd{S\_IWGRP} & \textit{group-write}, il gruppo può scrivere.\\
- \constd{S\_IXGRP} & \textit{group-execute}, il gruppo può eseguire.\\
+ \const{S\_IRGRP} & \textit{group-read}, il gruppo può leggere.\\
+ \const{S\_IWGRP} & \textit{group-write}, il gruppo può scrivere.\\
+ \const{S\_IXGRP} & \textit{group-execute}, il gruppo può eseguire.\\
\hline
- \constd{S\_IROTH} & \textit{other-read}, tutti possono leggere.\\
- \constd{S\_IWOTH} & \textit{other-write}, tutti possono scrivere.\\
- \constd{S\_IXOTH} & \textit{other-execute}, tutti possono eseguire.\\
+ \const{S\_IROTH} & \textit{other-read}, tutti possono leggere.\\
+ \const{S\_IWOTH} & \textit{other-write}, tutti possono scrivere.\\
+ \const{S\_IXOTH} & \textit{other-execute}, tutti possono eseguire.\\
\hline
\end{tabular}
\caption{I bit dei permessi di accesso ai file, come definiti in
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}) utilizzato per specificare i permessi
+sui file.
\begin{table}[!htb]
\centering
\textbf{\param{mode}} & \textbf{Valore} & \textbf{Significato} \\
\hline
\hline
- \constd{S\_ISUID} & 04000 & Set user ID bit.\\
- \constd{S\_ISGID} & 02000 & Set group ID bit.\\
- \constd{S\_ISVTX} & 01000 & Sticky bit.\\
+ \const{S\_ISUID} & 04000 & Set user ID bit.\\
+ \const{S\_ISGID} & 02000 & Set group ID bit.\\
+ \const{S\_ISVTX} & 01000 & Sticky bit.\\
\hline
- \constd{S\_IRWXU} & 00700 & L'utente ha tutti i permessi.\\
- \constd{S\_IRUSR} & 00400 & L'utente ha il permesso di lettura.\\
- \constd{S\_IWUSR} & 00200 & L'utente ha il permesso di scrittura.\\
- \constd{S\_IXUSR} & 00100 & L'utente ha il permesso di esecuzione.\\
+ \const{S\_IRWXU} & 00700 & L'utente ha tutti i permessi.\\
+ \const{S\_IRUSR} & 00400 & L'utente ha il permesso di lettura.\\
+ \const{S\_IWUSR} & 00200 & L'utente ha il permesso di scrittura.\\
+ \const{S\_IXUSR} & 00100 & L'utente ha il permesso di esecuzione.\\
\hline
- \constd{S\_IRWXG} & 00070 & Il gruppo ha tutti i permessi.\\
- \constd{S\_IRGRP} & 00040 & Il gruppo ha il permesso di lettura.\\
- \constd{S\_IWGRP} & 00020 & Il gruppo ha il permesso di scrittura.\\
- \constd{S\_IXGRP} & 00010 & Il gruppo ha il permesso di esecuzione.\\
+ \const{S\_IRWXG} & 00070 & Il gruppo ha tutti i permessi.\\
+ \const{S\_IRGRP} & 00040 & Il gruppo ha il permesso di lettura.\\
+ \const{S\_IWGRP} & 00020 & Il gruppo ha il permesso di scrittura.\\
+ \const{S\_IXGRP} & 00010 & Il gruppo ha il permesso di esecuzione.\\
\hline
- \constd{S\_IRWXO} & 00007 & Gli altri hanno tutti i permessi.\\
- \constd{S\_IROTH} & 00004 & Gli altri hanno il permesso di lettura.\\
- \constd{S\_IWOTH} & 00002 & Gli altri hanno il permesso di scrittura.\\
- \constd{S\_IXOTH} & 00001 & Gli altri hanno il permesso di esecuzione.\\
+ \const{S\_IRWXO} & 00007 & Gli altri hanno tutti i permessi.\\
+ \const{S\_IROTH} & 00004 & Gli altri hanno il permesso di lettura.\\
+ \const{S\_IWOTH} & 00002 & Gli altri hanno il permesso di scrittura.\\
+ \const{S\_IXOTH} & 00001 & Gli altri hanno il permesso di esecuzione.\\
\hline
\end{tabular}
\caption{Valori delle costanti usate per indicare i vari bit di
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 fifo o i
+ 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}
esplicitamente l'uso della suddetta libreria invocando il compilatore con
l'opzione \texttt{-lattr}.
-Per poter leggere gli attributi estesi sono disponibili tre diverse funzioni
-di sistema, \funcd{getxattr}, \funcd{lgetxattr} e \funcd{fgetxattr}, che
+Per leggere gli attributi estesi sono disponibili tre diverse funzioni di
+sistema, \funcd{getxattr}, \funcd{lgetxattr} e \funcd{fgetxattr}, che
consentono rispettivamente di richiedere gli attributi relativi a un file, a
un collegamento simbolico e ad un file descriptor; i rispettivi prototipi
sono:
La funzione alloca ed inizializza un'area di memoria che verrà usata per
mantenere i dati di una ACL contenente fino ad un massimo di \param{count}
-voci. La funzione ritorna un valore di tipo \type{acl\_t} da usare in tutte le
+voci. La funzione ritorna un valore di tipo \typed{acl\_t} da usare in tutte le
altre funzioni che operano sulla ACL. La funzione si limita alla allocazione
iniziale e non inserisce nessun valore nella ACL che resta vuota.
-Si tenga presente che pur essendo \type{acl\_t} un tipo opaco che identifica
+Si tenga presente che pur essendo \typed{acl\_t} un tipo opaco che identifica
``\textsl{l'oggetto}'' ACL, il valore restituito dalla funzione non è altro
che un puntatore all'area di memoria allocata per i dati richiesti. Pertanto
in caso di fallimento verrà restituito un puntatore nullo di tipo
funzione, che può richiedere anche la ACL relativa ad una directory, il
secondo argomento \param{type} consente di specificare se si vuole ottenere la
ACL di default o quella di accesso. Questo argomento deve essere di tipo
-\type{acl\_type\_t} e può assumere solo i due valori riportati in
+\typed{acl\_type\_t} e può assumere solo i due valori riportati in
tab.~\ref{tab:acl_type}.
\begin{table}[htb]
}
\end{funcproto}
-La funzione è del tutto è analoga a \funcd{acl\_set\_file} ma opera
+La funzione è del tutto è analoga a \func{acl\_set\_file} ma opera
esclusivamente sui file identificati tramite un file descriptor. Non dovendo
avere a che fare con directory (e con la conseguente possibilità di avere una
ACL di default) la funzione non necessita che si specifichi il tipo di ACL,
Se si vuole operare direttamente sui contenuti di un oggetto di tipo
\type{acl\_t} infatti occorre fare riferimento alle singole voci tramite gli
-opportuni puntatori di tipo \type{acl\_entry\_t}, che possono essere ottenuti
+opportuni puntatori di tipo \typed{acl\_entry\_t}, che possono essere ottenuti
dalla funzione \funcm{acl\_get\_entry} (per una voce esistente) o dalla
funzione \funcm{acl\_create\_entry} per una voce da aggiungere. Nel caso della
prima funzione si potrà poi ripetere la lettura per ottenere i puntatori alle
singole voci successive alla prima.
-Una volta ottenuti detti puntatori si potrà operare sui contenuti delle singole
-voci; con le funzioni \funcm{acl\_get\_tag\_type}, \funcm{acl\_get\_qualifier},
-\funcm{acl\_get\_permset} si potranno leggere rispettivamente tipo,
-qualificatore e permessi mentre con le corrispondente funzioni
+Una volta ottenuti detti puntatori si potrà operare sui contenuti delle
+singole voci: con le funzioni \funcm{acl\_get\_tag\_type},
+\funcm{acl\_get\_qualifier}, \funcm{acl\_get\_permset} si potranno leggere
+rispettivamente tipo, qualificatore e permessi, mentre con le corrispondenti
\funcm{acl\_set\_tag\_type}, \funcm{acl\_set\_qualifier},
-\funcm{acl\_set\_permset} si possono impostare i valori; in entrambi i casi
-vengono utilizzati tipi di dato ad hoc.\footnote{descritti nelle singole
- pagine di manuale.} Si possono poi copiare i valori di una voce da una ACL
-ad un altra con \funcm{acl\_copy\_entry} o eliminare una voce da una ACL con
+\funcm{acl\_set\_permset} si potranno impostare i valori; in entrambi i casi
+vengono utilizzati tipi di dato ad hoc, descritti nelle pagine di manuale. Si
+possono poi copiare i valori di una voce da una ACL ad un altra con
+\funcm{acl\_copy\_entry} o eliminare una voce da una ACL con
\funcm{acl\_delete\_entry} e verificarne la validità prima di usarla con
\funcm{acl\_valid} o \funcm{acl\_check}.
si è distribuito il programma \texttt{mygetfacl.c}, che consente di leggere le
ACL di un file, passato come argomento.
-\begin{figure}[!htbp]
+\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{\codesamplewidth}
\includecodesample{listati/mygetfacl.c}
\begin{figure}[!htb]
\footnotesize \centering
- \begin{minipage}[c]{0.9\textwidth}
+ \begin{minipage}[c]{0.95\textwidth}
\includestruct{listati/dqblk.h}
\end{minipage}
\normalsize
Per i kernel fino al 2.6.25, o se non si attiva il supporto per le
\textit{file capabilities}, il \textit{capabilities bounding set} è un
parametro generale di sistema, il cui valore viene riportato nel file
-\sysctlfile{kernel/cap-bound}. Il suo valore iniziale è definito in sede di
+\sysctlfiled{kernel/cap-bound}. Il suo valore iniziale è definito in sede di
compilazione del kernel, e da sempre ha previsto come default la presenza di
tutte le \textit{capabilities} eccetto \const{CAP\_SETPCAP}. In questa
situazione solo il primo processo eseguito nel sistema (quello con
(\const{IOPRIO\_CLASS\_RT} e prima del kernel 2.6.25 anche
\const{IOPRIO\_CLASS\_IDLE}) per lo scheduling dell'I/O (vedi
sez.~\ref{sec:io_priority}), superare il limite di sistema sul numero massimo
-di file aperti,\footnote{quello indicato da \sysctlfile{fs/file-max}.}
+di file aperti,\footnote{quello indicato da \sysctlfiled{fs/file-max}.}
effettuare operazioni privilegiate sulle chiavi mantenute dal kernel (vedi
sez.~\ref{sec:keyctl_management}), usare la funzione \func{lookup\_dcookie},
usare \const{CLONE\_NEWNS} con \func{unshare} e \func{clone}, (vedi
Le funzioni dell'interfaccia alle \textit{capabilities} definite nelle bozze
dello standard POSIX.1e prevedono l'uso di un tipo di dato opaco,
-\type{cap\_t}, come puntatore ai dati mantenuti nel cosiddetto
+\typed{cap\_t}, come puntatore ai dati mantenuti nel cosiddetto
\textit{capability state},\footnote{si tratta in sostanza di un puntatore ad
una struttura interna utilizzata dalle librerie, i cui campi non devono mai
essere acceduti direttamente.} in sono memorizzati tutti i dati delle
\constd{CAP\_INHERITABLE}& Capacità dell'insieme \textsl{ereditabile}.\\
\hline
\end{tabular}
- \caption{Valori possibili per il tipo di dato \type{cap\_flag\_t} che
+ \caption{Valori possibili per il tipo di dato \typed{cap\_flag\_t} che
identifica gli insiemi delle \textit{capabilities}.}
\label{tab:cap_set_identifier}
\end{table}
indica su quale dei tre insiemi si intende operare, sempre con i valori di
tab.~\ref{tab:cap_set_identifier}. La capacità che si intende controllare o
impostare invece deve essere specificata attraverso una variabile di tipo
-\type{cap\_value\_t}, che può prendere come valore uno qualunque di quelli
+\typed{cap\_value\_t}, che può prendere come valore uno qualunque di quelli
riportati in tab.~\ref{tab:proc_capabilities}, in questo caso però non è
possibile combinare diversi valori in una maschera binaria, una variabile di
tipo \type{cap\_value\_t} può indicare una sola capacità.\footnote{in
\constd{CAP\_SET} & La capacità è impostata.\\
\hline
\end{tabular}
- \caption{Valori possibili per il tipo di dato \type{cap\_flag\_value\_t} che
+ \caption{Valori possibili per il tipo di dato \typed{cap\_flag\_value\_t} che
indica lo stato di una capacità.}
\label{tab:cap_value_type}
\end{table}
projects / gapil.git / blobdiff