%% filedir.tex
%%
-%% Copyright (C) 2000-2007 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2009 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",
Finora abbiamo parlato esclusivamente di file, directory e link simbolici; in
sez.~\ref{sec:file_file_types} abbiamo visto però che il sistema prevede pure
degli altri tipi di file speciali, come i \index{file!di~dispositivo} file di
-dispositivo e le fifo (i socket sono un caso a parte, che tratteremo in
-cap.~\ref{cha:socket_intro}).
-
-La manipolazione delle caratteristiche di questi file e la loro cancellazione
-può essere effettuata con le stesse funzioni che operano sui file regolari; ma
-quando li si devono creare sono necessarie delle funzioni apposite. La prima
-di queste funzioni è \funcd{mknod}, il suo prototipo è:
+dispositivo, le fifo ed i socket (questi ultimi sono un caso a parte, essendo
+associati anche alla comunicazione via rete, per cui ci saranno trattati in
+dettaglio a partire da cap.~\ref{cha:socket_intro}).
+
+La manipolazione delle caratteristiche di questi diversi tipi di file e la
+loro cancellazione può essere effettuata con le stesse funzioni che operano
+sui file regolari; ma quando li si devono creare sono necessarie delle
+funzioni apposite. La prima di queste funzioni è \funcd{mknod}, il cui
+prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/stat.h}
\errval{ENOSPC}, \errval{EROFS}.}
\end{functions}
-La funzione permette di creare un file speciale, ma si può usare anche per
-creare file regolari e fifo; l'argomento \param{mode} specifica il tipo di
-file che si vuole creare ed i relativi permessi, secondo i valori riportati in
-tab.~\ref{tab:file_mode_flags}, che vanno combinati con un OR binario. I
-permessi sono comunque modificati nella maniera usuale dal valore di
-\itindex{umask} \textit{umask} (si veda sez.~\ref{sec:file_perm_management}).
-
-Per il tipo di file può essere specificato solo uno fra: \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}
-e \const{S\_IFIFO} per una fifo. Un valore diverso comporterà l'errore
-\errcode{EINVAL}. Qualora si sia specificato in \param{mode} un file di
-dispositivo (\const{S\_IFBLK} o \const{S\_IFCHR}), il valore di \param{dev}
-dovrà essere usato per indicare a quale dispositivo si fa riferimento con il
-relativo numero.
-
-Solo l'amministratore può creare un file di dispositivo usando questa funzione
-(il processo deve avere la \textit{capability} \const{CAP\_MKNOD}); ma in
-Linux\footnote{la funzione non è prevista dallo standard POSIX, e deriva da
- SVr4, con appunto questa differenza e diversi codici di errore.} l'uso per
-la creazione di un file ordinario, di una fifo o di un socket è consentito
-anche agli utenti normali.
+La funzione, come suggerisce il nome, permette di creare un ``\textsl{nodo}''
+sul filesystem, e viene in genere utilizzata per creare i file di dispositivo,
+ma si può usare anche per creare file regolari. L'argomento
+\param{mode} specifica sia il tipo di file che si vuole creare che i relativi
+permessi, secondo i valori riportati in tab.~\ref{tab:file_mode_flags}, che
+vanno combinati con un OR binario. I permessi sono comunque modificati nella
+maniera usuale dal valore di \itindex{umask} \textit{umask} (si veda
+sez.~\ref{sec:file_perm_management}).
+
+Per il tipo di file può essere specificato solo uno fra i seguenti valori:
+\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 link simbolici, si dovranno usare le funzioni \func{mkdir} e
+ \func{symlink} a questo dedicate.} un valore diverso comporterà l'errore
+\errcode{EINVAL}.
+
+Qualora si sia specificato in \param{mode} un file di dispositivo (vale a dire
+o \const{S\_IFBLK} o \const{S\_IFCHR}), il valore di \param{dev} dovrà essere
+usato per indicare a quale dispositivo si fa riferimento, altrimenti il suo
+valore verrà ignorato. Solo l'amministratore può creare un file di
+dispositivo usando questa funzione (il processo deve avere la
+\textit{capability} \const{CAP\_MKNOD}), ma in Linux\footnote{questo è un
+ comportamento specifico di Linux, la funzione non è prevista dallo standard
+ POSIX.1 originale, 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.
I nuovi \itindex{inode} \textit{inode} creati con \func{mknod} apparterranno
al proprietario e al gruppo del processo che li ha creati, a meno che non si
sez.~\ref{sec:file_ownership_management}) in cui si va a creare
\itindex{inode} l'\textit{inode}.
-Per creare una fifo (un file speciale, su cui torneremo in dettaglio in
-sez.~\ref{sec:ipc_named_pipe}) lo standard POSIX specifica l'uso della funzione
-\funcd{mkfifo}, il cui prototipo è:
+Nella creazione di un file di dispositivo occorre poi specificare
+correttamente il valore di \param{dev}; questo infatti è di tipo
+\type{dev\_t}, che è un tipo primitivo (vedi
+tab.~\ref{tab:intro_primitive_types}) riservato per indicare un
+\textsl{numero} di dispositivo; il kernel infatti identifica ciascun
+dispositivo con un valore numerico. Originariamente questo era un intero a 16
+bit diviso in due parti di 8 bit chiamate rispettivamente
+\itindex{major~number} \textit{major number} e \itindex{minor~number}
+\textit{minor number}, che sono poi i due numeri mostrati dal comando
+\texttt{ls -l} al posto della dimensione quando lo si esegue su un file di
+dispositivo.
+
+Il \itindex{major~number} \textit{major number} identifica una classe di
+dispositivi (ad esempio la seriale, o i dischi IDE) e serve in sostanza per
+indicare al kernel quale è il modulo che gestisce quella classe di
+dispositivi; per identificare uno specifico dispositivo di quella classe (ad
+esempio una singola porta seriale, o una partizione di un disco) si usa invece
+il \itindex{minor~number} \textit{minor number}. L'elenco aggiornato di questi
+numeri con le relative corrispondenze ai vari dispositivi può essere trovato
+nel file \texttt{Documentation/devices.txt} allegato alla documentazione dei
+sorgenti del kernel.
+
+Data la crescita nel numero di dispositivi supportati, ben presto il limite
+massimo di 256 si è rivelato troppo basso, e nel passaggio dai kernel della
+serie 2.4 alla serie 2.6 è stata aumentata a 32 bit la dimensione del tipo
+\type{dev\_t}, con delle dimensioni passate a 12 bit per il
+\itindex{major~number} \textit{major number} e 20 bit per il
+\itindex{minor~number} \textit{minor number}. La transizione però ha anche
+comportato il passaggio di \type{dev\_t} a tipo opaco, e la necessità di
+specificare il numero tramite delle opportune macro, così da non avere
+problemi di compatibilità con eventuali ulteriori estensioni.
+
+Le macro sono definite nel file \file{sys/sysmacros.h}, che viene
+automaticamente incluso quando si include \file{sys/types.h}; si possono
+pertanto ottenere i valori del \itindex{major~number} \textit{major number} e
+\itindex{minor~number} \textit{minor number} di un dispositivo rispettivamente
+con le macro \macro{major} e \macro{minor}:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \funcdecl{int \macro{major}(dev\_t dev)}
+ Restituisce il \itindex{major~number} \textit{major number} del dispositivo
+ \param{dev}.
+
+ \funcdecl{int \macro{minor}(dev\_t dev)}
+ Restituisce il \itindex{minor~number} \textit{minor number} del dispositivo
+ \param{dev}.
+\end{functions}
+\noindent mentre una volta che siano noti \itindex{major~number} \textit{major
+ number} e \itindex{minor~number} \textit{minor number} si potrà costruire il
+relativo identificativo con la macro \macro{makedev}:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \funcdecl{dev\_t \macro{minor}(int major, int minor)}
+
+ Restituisce l'identificativo di un dispositivo dati \itindex{major~number}
+ \textit{major number} e \itindex{minor~number} \textit{minor number}.
+\end{functions}
+
+Infine con lo standard POSIX.1-2001 è stata introdotta una funzione specifica
+per creare una fifo (tratteremo le fifo in in sez.~\ref{sec:ipc_named_pipe});
+la funzione è \funcd{mkfifo} ed il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h} \headdecl{sys/stat.h}
Tutto questo si riflette nello standard POSIX\footnote{le funzioni sono
previste pure in BSD e SVID.} che ha introdotto una apposita interfaccia per
la lettura delle directory, basata sui cosiddetti \textit{directory stream}
-(chiamati così per l'analogia con i file stream dell'interfaccia standard di
-cap.~\ref{cha:files_std_interface}). La prima funzione di questa interfaccia è
-\funcd{opendir}, il cui prototipo è:
+(chiamati così per l'analogia con i file stream dell'interfaccia standard ANSI
+C di cap.~\ref{cha:files_std_interface}). La prima funzione di questa
+interfaccia è \funcd{opendir}, il cui prototipo è:
\begin{functions}
\headdecl{sys/types.h} \headdecl{dirent.h}
per cambiare la directory di lavoro (vedi sez.~\ref{sec:file_work_dir}) a
quella relativa allo stream che si sta esaminando.
-La lettura di una voce della directory viene effettuata attraverso la funzione
-\funcd{readdir}; il suo prototipo è:
+Viceversa se si è aperto un file descriptor corrispondente ad una directory è
+possibile associarvi un \textit{directory stream} con la funzione
+\funcd{fopendir},\footnote{questa funzione è però disponibile solo a partire
+ dalla versione 2.4 delle \acr{glibc}, e pur essendo candidata per
+ l'inclusione nella successiva revisione dello standard POSIX.1-2001, non è
+ ancora presente in nessuna specifica formale.} il cui prototipo è:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{dirent.h}
+
+ \funcdecl{DIR * fopendir(int fd)}
+
+ Associa un \textit{directory stream} al file descriptor \param{fd}.
+
+ \bodydesc{La funzione restituisce un puntatore al \textit{directory stream}
+ in caso di successo e \val{NULL} per un errore, nel qual caso \var{errno}
+ assumerà il valore \errval{EBADF}.}
+\end{functions}
+
+La funzione è identica a \func{opendir}, ma ritorna un \textit{directory
+ stream} facendo riferimento ad un file descriptor \param{fd} che deve essere
+stato aperto in precedenza e la funzione darà un errore qualora questo non
+corrisponda ad una directory. Una volta utilizzata il file descriptor verrà
+usato dalle funzioni che operano sul \textit{directory stream} e non deve
+essere più utilizzato direttamente all'interno del proprio programma.
+
+Una volta che si sia aperto un \textit{directory stream} la lettura del
+contenuto della directory viene effettuata attraverso la funzione
+\funcd{readdir}, il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h} \headdecl{dirent.h}
\end{functions}
La funzione legge la voce corrente nella directory, posizionandosi sulla voce
-successiva. I dati vengono memorizzati in una struttura \struct{dirent} (la
-cui definizione\footnote{la definizione è quella usata a Linux, che si trova
- nel file \file{/usr/include/bits/dirent.h}, essa non contempla la presenza
- del campo \var{d\_namlen} che indica la lunghezza del nome del file (ed
- infatti la macro \macro{\_DIRENT\_HAVE\_D\_NAMLEN} non è definita).} è
-riportata in fig.~\ref{fig:file_dirent_struct}). La funzione restituisce il
-puntatore alla struttura; si tenga presente però che quest'ultima è allocata
-staticamente, per cui viene sovrascritta tutte le volte che si ripete la
-lettura di una voce sullo stesso stream.
-
-Di questa funzione esiste anche una versione rientrante, \func{readdir\_r},
-che non usa una struttura allocata staticamente, e può essere utilizzata anche
-con i thread; il suo prototipo è:
+successiva. Pertanto se si vuole leggere l'intero contenuto di una directory
+occorrerà ripetere l'esecuzione della funzione fintanto che non si siano
+esaurite tutte le voci in essa presenti.
+
+I dati vengono memorizzati in una struttura \struct{dirent} (la cui
+definizione\footnote{la definizione è quella usata a Linux, che si trova nel
+ file \file{/usr/include/bits/dirent.h}, essa non contempla la presenza del
+ campo \var{d\_namlen} che indica la lunghezza del nome del file (ed infatti
+ la macro \macro{\_DIRENT\_HAVE\_D\_NAMLEN} non è definita).} è riportata in
+fig.~\ref{fig:file_dirent_struct}). La funzione restituisce il puntatore alla
+struttura; si tenga presente però che quest'ultima è allocata staticamente,
+per cui viene sovrascritta tutte le volte che si ripete la lettura di una voce
+sullo stesso \textit{directory stream}.
+
+Di questa funzione esiste anche una versione \index{funzioni!rientranti}
+rientrante, \func{readdir\_r}, che non usa una struttura allocata
+staticamente, e può essere utilizzata anche con i \itindex{thread}
+\textit{thread}, il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h} \headdecl{dirent.h}
struttura precedentemente allocata e specificata dall'argomento \param{entry}
(anche se non è assicurato che la funzione usi lo spazio fornito dall'utente).
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \includestruct{listati/dirent.c}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{dirent} per la lettura delle informazioni dei
+ file.}
+ \label{fig:file_dirent_struct}
+\end{figure}
+
I vari campi di \struct{dirent} contengono le informazioni relative alle voci
presenti nella directory; sia BSD che SVr4\footnote{lo standard POSIX prevede
invece solo la presenza del campo \var{d\_fileno}, identico \var{d\_ino},
di \itindex{inode} \textit{inode} cui il file è associato (di solito
corrisponde al campo \var{st\_ino} di \struct{stat}).
-\begin{figure}[!htb]
- \footnotesize \centering
- \begin{minipage}[c]{15cm}
- \includestruct{listati/dirent.c}
- \end{minipage}
- \normalsize
- \caption{La struttura \structd{dirent} per la lettura delle informazioni dei
- file.}
- \label{fig:file_dirent_struct}
-\end{figure}
-
La presenza di ulteriori campi opzionali è segnalata dalla definizione di
altrettante macro nella forma \code{\_DIRENT\_HAVE\_D\_XXX} dove \code{XXX} è
il nome del relativo campo; nel nostro caso sono definite le macro
\end{table}
Per quanto riguarda il significato dei campi opzionali, il campo \var{d\_type}
-indica il tipo di file (fifo, directory, link simbolico, ecc.); i suoi
+indica il tipo di file (fifo, directory, link simbolico, ecc.). I suoi
possibili valori\footnote{fino alla versione 2.1 delle \acr{glibc} questo
campo, pur presente nella struttura, non era implementato, e resta sempre al
valore \const{DT\_UNKNOWN}.} sono riportati in
funzione che permette di eseguire una scansione completa (con tanto di ricerca
ed ordinamento) del contenuto di una directory; la funzione è
\funcd{scandir}\footnote{in Linux questa funzione è stata introdotta fin dalle
- libc4.} ed il suo prototipo è:
+ \acr{libc4}.} ed il suo prototipo è:
\begin{prototype}{dirent.h}{int scandir(const char *dir,
struct dirent ***namelist, int(*filter)(const struct dirent *),
int(*compar)(const struct dirent **, const struct dirent **))}
\end{functions}
La funzione \func{alphasort} deriva da BSD ed è presente in Linux fin dalle
-libc4\footnote{la versione delle libc4 e libc5 usa però come argomenti dei
- puntatori a delle strutture \struct{dirent}; le glibc usano il prototipo
- originario di BSD, mostrato anche nella definizione, che prevede puntatori a
- \ctyp{void}.} e deve essere specificata come argomento \param{compare} per
-ottenere un ordinamento alfabetico (secondo il valore del campo \var{d\_name}
-delle varie voci). Le \acr{glibc} prevedono come estensione\footnote{le glibc,
- a partire dalla versione 2.1, effettuano anche l'ordinamento alfabetico
- tenendo conto delle varie localizzazioni, usando \func{strcoll} al posto di
- \func{strcmp}.} anche \func{versionsort}, che ordina i nomi tenendo conto
-del numero di versione (cioè qualcosa per cui \texttt{file10} viene comunque
-dopo \texttt{file4}.)
+\acr{libc4}\footnote{la versione delle \acr{libc4} e \acr{libc5} usa però come
+ argomenti dei puntatori a delle strutture \struct{dirent}; le glibc usano il
+ prototipo originario di BSD, mostrato anche nella definizione, che prevede
+ puntatori a \ctyp{void}.} e deve essere specificata come argomento
+\param{compar} per ottenere un ordinamento alfabetico (secondo il valore del
+campo \var{d\_name} delle varie voci). Le \acr{glibc} prevedono come
+estensione\footnote{le glibc, a partire dalla versione 2.1, effettuano anche
+ l'ordinamento alfabetico tenendo conto delle varie localizzazioni, usando
+ \func{strcoll} al posto di \func{strcmp}.} anche \func{versionsort}, che
+ordina i nomi tenendo conto del numero di versione (cioè qualcosa per cui
+\texttt{file10} viene comunque dopo \texttt{file4}.)
Un semplice esempio dell'uso di queste funzioni è riportato in
fig.~\ref{fig:file_my_ls}, dove si è riportata la sezione principale di un
(\texttt{\small 27}) la funzione di elaborazione \var{compare} (che nel nostro
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 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 gli stream comporterebbe un
- consumo progressivo di risorse, con conseguente rischio di esaurimento delle
- stesse} e la restituzione (\texttt{\small 33}) del codice di operazioni
-concluse con successo.
+ritorno negativo). Una volta terminato il ciclo la funzione si conclude con la
+chiusura (\texttt{\small 32}) dello 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
+ \textit{directory stream} comporterebbe un consumo progressivo di risorse,
+ con conseguente rischio di esaurimento delle stesse.} e la restituzione
+(\texttt{\small 33}) del codice di operazioni concluse con successo.
\subsection{La directory di lavoro}
\itindbeg{pathname}
-A ciascun processo è associata una directory nel filesystem che è chiamata
-\textsl{directory corrente} o \textsl{directory di lavoro} (in inglese
-\textit{current working directory}) che è quella a cui si fa riferimento
-quando un \itindsub{pathname}{relativo}\textit{pathname} è espresso in forma
-relativa, dove il ``\textsl{relativa}'' fa riferimento appunto a questa
-directory.
+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 \struct{task\_struct} (vedi fig.~\ref{fig:proc_task_struct}), più
+ precisamente nel campo \texttt{pwd} della sotto-struttura
+ \struct{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
+\itindsub{pathname}{relativo} \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 corrente della shell diventa anche la
directory corrente di qualunque comando da essa lanciato.
-In genere il kernel tiene traccia per ciascun processo \itindex{inode}
-dell'\textit{inode} della directory di lavoro, per ottenere il
+Dato che è il kernel che tiene traccia per ciascun processo \itindex{inode}
+dell'\textit{inode} della directory di lavoro, per ottenerne il
\textit{pathname} occorre usare una apposita funzione di libreria,
-\funcd{getcwd}, il cui prototipo è:
+\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{prototype}{unistd.h}{char *getcwd(char *buffer, size\_t size)}
Legge il \textit{pathname} della directory di lavoro corrente.
\item[\errcode{EACCES}] manca il permesso di lettura o di ricerca su uno dei
componenti del \textit{pathname} (cioè su una delle directory superiori
alla corrente).
+ \item[\errcode{ENOENT}] la directory di lavoro è stata eliminata.
\end{errlist}}
\end{prototype}
La funzione restituisce il \textit{pathname} completo della directory di
-lavoro nella stringa puntata da \param{buffer}, che deve essere
+lavoro corrente nella stringa puntata da \param{buffer}, che deve essere
precedentemente allocata, per una dimensione massima di \param{size}. Il
-buffer deve essere sufficientemente lungo da poter contenere il
+buffer deve essere sufficientemente largo da poter contenere il
\textit{pathname} completo più lo zero di terminazione della stringa. Qualora
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.} 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 una volta cessato il suo utilizzo.
+ 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 una
+volta cessato il suo utilizzo.
Di questa funzione esiste una versione \code{char *getwd(char *buffer)} fatta
per compatibilità all'indietro con BSD, che non consente di specificare la
buffer sia sufficiente a contenere il nome del file, e questa è la ragione
principale per cui questa funzione è deprecata.
-Una seconda funzione simile è \code{char *get\_current\_dir\_name(void)} che è
-sostanzialmente equivalente ad una \code{getcwd(NULL, 0)}, con la sola
-differenza che essa ritorna il valore della variabile di ambiente \val{PWD},
-che essendo costruita dalla shell può contenere un \textit{pathname}
-comprendente anche dei link 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 link simbolici.
+Un uso comune di \func{getcwd} è quello di salvare la directory di lavoro
+iniziale per poi potervi tornare in un tempo successivo, un metodo alternativo
+più veloce, se non si è a corto di file descriptor, è invece quello di aprire
+la directory corrente (vale a dire ``\texttt{.}'') e tornarvi in seguito con
+\func{fchdir}.
+
+Una seconda usata per ottenere la directory di lavoro è \code{char
+ *get\_current\_dir\_name(void)} che è sostanzialmente equivalente ad una
+\code{getcwd(NULL, 0)}, con la sola differenza che essa ritorna il valore
+della variabile di ambiente \val{PWD}, che essendo costruita dalla shell può
+contenere un \textit{pathname} comprendente anche dei link 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 link simbolici.
Per cambiare la directory di lavoro si può usare la funzione \funcd{chdir}
(equivalente del comando di shell \cmd{cd}) il cui nome sta appunto per
massimo di \const{TMP\_MAX} volte. Al nome viene automaticamente aggiunto come
prefisso la directory specificata da \const{P\_tmpdir}.
-Di questa funzione esiste una versione rientrante, \func{tmpnam\_r}, che non
-fa nulla quando si passa \val{NULL} come argomento. Una funzione simile,
-\funcd{tempnam}, permette di specificare un prefisso per il file
-esplicitamente, il suo prototipo è:
+Di questa funzione esiste una versione \index{funzioni!rientranti} rientrante,
+\func{tmpnam\_r}, che non fa nulla quando si passa \val{NULL} come argomento.
+Una funzione simile, \funcd{tempnam}, permette di specificare un prefisso per
+il file esplicitamente, il suo prototipo è:
\begin{prototype}{stdio.h}{char *tempnam(const char *dir, const char *pfx)}
Restituisce il puntatore ad una stringa contente un nome di file valido e
non esistente al momento dell'invocazione.
\end{prototype}
La funzione alloca con \code{malloc} la stringa in cui restituisce il nome,
-per cui è sempre rientrante, occorre però ricordarsi di disallocare il
-puntatore che restituisce. L'argomento \param{pfx} specifica un prefisso di
-massimo 5 caratteri per il nome provvisorio. La funzione assegna come
-directory per il file temporaneo (verificando che esista e sia accessibili),
-la prima valida delle seguenti:
-\begin{itemize*}
-\item La variabile di ambiente \const{TMPNAME} (non ha effetto se non è
+per cui è sempre \index{funzioni!rientranti} rientrante, occorre però
+ricordarsi di disallocare con \code{free} il puntatore che restituisce.
+L'argomento \param{pfx} specifica un prefisso di massimo 5 caratteri per il
+nome provvisorio. La funzione assegna come directory per il file temporaneo
+(verificando che esista e sia accessibili), la prima valida delle seguenti:
+\begin{itemize}
+\item La variabile di ambiente \const{TMPDIR} (non ha effetto se non è
definita o se il programma chiamante è \itindex{suid~bit} \acr{suid} o
\itindex{sgid~bit} \acr{sgid}, vedi sez.~\ref{sec:file_special_perm}).
\item il valore dell'argomento \param{dir} (se diverso da \val{NULL}).
\item Il valore della costante \const{P\_tmpdir}.
\item la directory \file{/tmp}.
-\end{itemize*}
+\end{itemize}
In ogni caso, anche se la generazione del nome è casuale, ed è molto difficile
ottenere un nome duplicato, nulla assicura che un altro processo non possa
esistente.
Per evitare di dovere effettuare a mano tutti questi controlli, lo standard
-POSIX definisce la funzione \funcd{tmpfile}, il cui prototipo è:
+POSIX definisce la funzione \funcd{tmpfile}, che permette di ottenere in
+maniera sicura l'accesso ad un file temporaneo, il suo prototipo è:
\begin{prototype}{stdio.h}{FILE *tmpfile (void)}
Restituisce un file temporaneo aperto in lettura/scrittura.
ed inoltre \errval{EFAULT}, \errval{EMFILE}, \errval{ENFILE},
\errval{ENOSPC}, \errval{EROFS} e \errval{EACCES}.}
\end{prototype}
-\noindent essa restituisce direttamente uno stream già aperto (in modalità
+
+La funzione restituisce direttamente uno stream già aperto (in modalità
\code{r+b}, si veda sez.~\ref{sec:file_fopen}) e pronto per l'uso, che viene
automaticamente cancellato alla sua chiusura o all'uscita dal programma. Lo
standard non specifica in quale directory verrà aperto il file, ma le
\acr{glibc} prima tentano con \const{P\_tmpdir} e poi con \file{/tmp}. Questa
-funzione è rientrante e non soffre di problemi di \itindex{race~condition}
-\textit{race condition}.
+funzione è \index{funzioni!rientranti} rientrante e non soffre di problemi di
+\itindex{race~condition} \textit{race condition}.
Alcune versioni meno recenti di Unix non supportano queste funzioni; in questo
caso si possono usare le vecchie funzioni \funcd{mktemp} e \func{mkstemp} che
Dato che uno degli usi degli \textit{Extended Attributes} è quello che li
-impiega per realizzare delle estensioni (come le ACL, \index{SELinux} SELinux,
-ecc.) al tradizionale meccanismo dei controlli di accesso di Unix, l'accesso
-ai loro valori viene regolato in maniera diversa a seconda sia della loro
-classe sia di quali, fra le estensioni che li utilizzano, sono poste in uso.
-In particolare, per ciascuna delle classi riportate in
-tab.~\ref{tab:extended_attribute_class}, si hanno i seguenti casi:
+impiega per realizzare delle estensioni (come le \itindex{Access~Control~List}
+ACL, \index{SELinux} SELinux, ecc.) al tradizionale meccanismo dei controlli
+di accesso di Unix, l'accesso ai loro valori viene regolato in maniera diversa
+a seconda sia della loro classe sia di quali, fra le estensioni che li
+utilizzano, sono poste in uso. In particolare, per ciascuna delle classi
+riportate in tab.~\ref{tab:extended_attribute_class}, si hanno i seguenti
+casi:
\begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}}
\item[\texttt{security}] L'accesso agli \textit{extended security attributes}
dipende dalle politiche di sicurezza stabilite da loro stessi tramite
\item[\texttt{system}] Anche l'accesso agli \textit{extended system
attributes} dipende dalle politiche di accesso che il kernel realizza
anche utilizzando gli stessi valori in essi contenuti. Ad esempio nel caso
- delle ACL l'accesso è consentito in lettura 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 \textit{capability} \index{capabilities}
- \const{CAP\_FOWNER}.\footnote{vale a dire una politica di accesso analoga a
- quella impiegata per gli ordinari permessi dei file.}
+ delle \itindex{Access~Control~List} ACL l'accesso è consentito in lettura 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 \textit{capability}
+ \index{capabilities} \const{CAP\_FOWNER}.\footnote{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
questa funzione è una estensione specifica di Linux, e non è presente nella
bozza dello standard POSIX.1e.
+Per quanto utile per la visualizzazione o l'impostazione da comando delle ACL,
+la forma testuale non è la più efficiente per poter memorizzare i dati
+relativi ad una ACL, ad esempio quando si vuole eseguirne una copia a scopo di
+archiviazione. Per questo è stata prevista la possibilità di utilizzare una
+rappresentazione delle ACL in una apposita forma binaria contigua e
+persistente. È così possibile copiare il valore di una ACL in un buffer e da
+questa rappresentazione tornare indietro e generare una ACL.
+
+Lo standard POSIX.1e prevede a tale scopo tre funzioni, la prima e più
+semplice è \funcd{acl\_size}, che consente di ottenere la dimensione che avrà
+la citata rappresentazione binaria, in modo da poter allocare per essa un
+buffer di dimensione sufficiente, il suo prototipo è:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/acl.h}
+
+ \funcdecl{ssize\_t acl\_size(acl\_t acl)}
+
+ Determina la dimensione della rappresentazione binaria di una ACL.
+
+ \bodydesc{La funzione restituisce in caso di successo la dimensione in byte
+ della rappresentazione binaria della ACL indicata da \param{acl} e $-1$ in
+ caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida.
+ \end{errlist}
+
+}
+\end{functions}
+
+Prima di effettuare la lettura della rappresentazione binaria è sempre
+necessario allocare un buffer di dimensione sufficiente a contenerla, pertanto
+prima si dovrà far ricorso a \funcd{acl\_size} per ottenere tale dimensione e
+poi allocare il buffer con una delle funzioni di
+sez.~\ref{sec:proc_mem_alloc}. Una volta terminato l'uso della
+rappresentazione binaria, il buffer dovrà essere esplicitamente disallocato.
+
+La funzione che consente di leggere la rappresentazione binaria di una ACL è
+\funcd{acl\_copy\_ext}, il cui prototipo è:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/acl.h}
+
+ \funcdecl{ssize\_t acl\_copy\_ext(void *buf\_p, acl\_t acl, ssize\_t size)}
+
+ Ottiene la rappresentazione binaria di una ACL.
+
+ \bodydesc{La funzione restituisce in caso di successo la dimensione in byte
+ della rappresentazione binaria della ACL indicata da \param{acl} e $-1$ in
+ caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida o
+ \param{size} è negativo o nullo.
+ \item[\errcode{ERANGE}] il valore di \param{size} è più piccolo della
+ dimensione della rappresentazione della ACL.
+ \end{errlist}
+
+}
+\end{functions}
+
+La funzione salverà la rappresentazione binaria della ACL indicata da
+\param{acl} sul buffer posto all'indirizzo \param{buf\_p} e lungo \param{size}
+byte, restituendo la dimensione della stessa come valore di ritorno. Qualora
+la dimensione della rappresentazione ecceda il valore di \param{size} la
+funzione fallirà con un errore di \errcode{ERANGE}. La funzione non ha nessun
+effetto sulla ACL indicata da \param{acl}.
+
+Viceversa se si vuole ripristinare una ACL a partire dalla rappresentazione
+binaria della stessa disponibile in un buffer si potrà usare la funzione
+\funcd{acl\_copy\_int}, il cui prototipo è:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/acl.h}
+
+ \funcdecl{ssize\_t acl\_copy\_int(const void *buf\_p)}
+
+ Ripristina la rappresentazione binaria di una ACL.
+
+ \bodydesc{La funzione restituisce un oggetto di tipo \type{acl\_t} in caso
+ di successo e \code{(acl\_t)NULL} in caso di errore, nel qual caso
+ \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] il buffer all'indirizzo \param{buf\_p} non contiene
+ una rappresentazione corretta di una ACL.
+ \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare un oggetto
+ \type{acl\_t} per la ACL richiesta.
+ \end{errlist}
+
+}
+\end{functions}
+
+La funzione in caso di successo alloca autonomamente un oggetto di tipo
+\type{acl\_t} che viene restituito come valore di ritorno con il contenuto
+della ACL rappresentata dai dati contenuti nel buffer puntato da
+\param{buf\_p}. Si ricordi che come per le precedenti funzioni l'oggetto
+\type{acl\_t} dovrà essere disallocato esplicitamente al termine del suo
+utilizzo.
+
+Una volta che si disponga della ACL desiderata, questa potrà essere impostata
+su un file o una directory. Per far questo sono disponibili due funzioni; la
+prima è \funcd{acl\_set\_file}, il cui prototipo è:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/acl.h}
+
+ \funcdecl{int acl\_set\_file(const char *path, acl\_type\_t type, acl\_t
+ acl)}
+
+ Imposta una ACL su un file.
+
+ \bodydesc{La funzione restituisce $0$ in caso di successo e $-1$ in caso di
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EACCES}] o un generico errore di accesso a \param{path} o il
+ valore di \param{type} specifica una ACL il cui tipo non può essere
+ assegnato a \param{path}.
+ \item[\errcode{EINVAL}] o \param{acl} non è una ACL valida, o \param{type}
+ ha in valore non corretto.
+ \item[\errcode{ENOSPC}] non c'è spazio disco sufficiente per contenere i
+ dati aggiuntivi della ACL.
+ \item[\errcode{ENOTSUP}] si è cercato di impostare una ACL su un file
+ contenuto in un filesystem che non supporta le ACL.
+ \end{errlist}
+ ed inoltre \errval{ENOENT}, \errval{ENOTDIR}, \errval{ENAMETOOLONG},
+ \errval{EROFS}, \errval{EPERM}.
+}
+\end{functions}
+
+La funzione ...
+
+%TODO: finire
+
+La seconda funzione che consente di impostare una ACL è
+\funcd{acl\_set\_fd}, il cui prototipo è:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/acl.h}
+
+ \funcdecl{int acl\_set\_fd(int fd, acl\_t acl)}
+
+ Imposta una ACL su un file descriptor.
+
+ \bodydesc{La funzione restituisce $0$ in caso di successo e $-1$ in caso di
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EBADF}].
+ \item[\errcode{EINVAL}] o \param{acl} non è una ACL valida, o \param{type}
+ ha in valore non corretto.
+ \item[\errcode{ENOSPC}] non c'è spazio disco sufficiente per contenere i
+ dati aggiuntivi della ACL.
+ \item[\errcode{ENOTSUP}] si è cercato di impostare una ACL su un file
+ contenuto in un filesystem che non supporta le ACL.
+ \end{errlist}
+ ed inoltre \errval{EBADF}, \errval{EROFS}, \errval{EPERM}.
+}
+\end{functions}
+
+Le funzioni viste finora operano a livello di una intera ACL, eseguendo in una
+sola volta tutte le operazioni relative a tutte le voci in essa contenuta. In
+generale è possibile modificare un singolo valore all'interno di una singola
+voce direttamente con le funzioni previste dallo standardo POSIX.1e. Queste
+funzioni però sono alquanto macchinose da utilizzare per cui è probabilmente
+più semplice operare direttamente sulla rappresentazione testuale. Questo è il
+motivo per non tratteremo nei dettagli dette funzioni, fornendone solo una
+descrizione sommaria; chi fosse interessato potrà ricorrere alle pagina di
+manuale.
+
+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
+dalla funzione \funcd{acl\_get\_entry} (per una voce esistente) o dalla
+funzione \funcd{acl\_create\_entry} per una voce da aggiungere. Nel caso della
+prima funzione si potrà poi ripetere la lettura per ottenere i puntatori alle
+singoli voci.
+
+Una volta ottenuti detti puntatori si porà operare sui contenuti delle singole
+voci ...
+
+
+%TODO: finire
\itindend{Access~Control~List}
\itindsub{pathname}{assoluto} \textit{pathname} assoluti a partire sempre
dalla stessa directory, che corrisponde alla radice del sistema.
-In certe situazioni però, per motivi di sicurezza, è utile poter impedire che
-un processo possa accedere a tutto il filesystem; per far questo si può
-cambiare la sua directory radice con la funzione \funcd{chroot}, il cui
-prototipo è:
+In certe situazioni però è utile poter impedire che un processo possa accedere
+a tutto il filesystem; per far questo si può cambiare la sua directory radice
+con la funzione \funcd{chroot}, il cui prototipo è:
\begin{prototype}{unistd.h}{int chroot(const char *path)}
Cambia la directory radice del processo a quella specificata da
\param{path}.
comunque accedere a tutto il resto del filesystem usando
\itindsub{pathname}{relativo}\textit{pathname} relativi, i quali, partendo
dalla directory di lavoro che è fuori della \textit{chroot jail}, potranno
-(con l'uso di \texttt{..}) risalire fino alla radice effettiva del filesystem.
+(con l'uso di ``\texttt{..}'') risalire fino alla radice effettiva del
+filesystem.
Ma se ad un processo restano i privilegi di amministratore esso potrà comunque
portare la sua directory di lavoro fuori dalla \textit{chroot jail} in cui si
-
% LocalWords: sez like filesystem unlink MacOS Windows VMS inode kernel unistd
% LocalWords: un'etichetta int const char oldpath newpath errno EXDEV EPERM st
% LocalWords: EEXIST EMLINK EACCES ENAMETOOLONG ENOTDIR EFAULT ENOMEM EROFS ls
% LocalWords: fsetxattr flags XATTR REPLACE listxattr llistxattr flistxattr by
% LocalWords: removexattr lremovexattr fremovexattr attributename lacl acl
% LocalWords: OBJ setfacl len any prefix separator options NUMERIC IDS SMART
+% LocalWords: INDENT major number IDE Documentation makedev fopendir proc
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "gapil"
%%% End:
-% LocalWords: INDENT
projects / gapil.git / blobdiff