%% 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",
\section{La gestione di file e directory}
\label{sec:file_dir}
-Come già accennato in sez.~\ref{sec:file_filesystem} in un sistema unix-like la
-gestione dei file ha delle caratteristiche specifiche che derivano
-direttamente dall'architettura del sistema.
-
-In questa sezione esamineremo le funzioni usate per la manipolazione di file e
-directory, per la creazione di link simbolici e diretti, per la gestione e la
-lettura delle directory.
+Come già accennato in sez.~\ref{sec:file_filesystem} in un sistema unix-like
+la gestione dei file ha delle caratteristiche specifiche che derivano
+direttamente dall'architettura del sistema. In questa sezione esamineremo le
+funzioni usate per la manipolazione di file e directory, per la creazione di
+link simbolici e diretti, per la gestione e la lettura delle directory.
In particolare ci soffermeremo sulle conseguenze che derivano
dall'architettura dei filesystem illustrata nel capitolo precedente per quanto
-riguarda il comportamento delle varie funzioni.
+riguarda il comportamento e gli effetti delle varie funzioni.
\subsection{Le funzioni \func{link} e \func{unlink}}
fare questa operazione.
Come spiegato in sez.~\ref{sec:file_filesystem} l'accesso al contenuto di un
-file su disco avviene passando attraverso il suo \index{inode} inode, che è la
-struttura usata dal kernel che lo identifica univocamente all'interno di un
-singolo filesystem. Il nome del file che si trova nella voce di una directory
-è solo un'etichetta, mantenuta all'interno della directory, che viene
-associata ad un puntatore che fa riferimento al suddetto inode.
+file su disco avviene passando attraverso il suo \itindex{inode}
+\textit{inode}, che è la struttura usata dal kernel che lo identifica
+univocamente all'interno di un singolo filesystem. Il nome del file che si
+trova nella voce di una directory è solo un'etichetta, mantenuta all'interno
+della directory, che viene associata ad un puntatore che fa riferimento al
+suddetto \textit{inode}.
Questo significa che, fintanto che si resta sullo stesso filesystem, la
realizzazione di un link è immediata, ed uno stesso file può avere tanti nomi
-diversi, dati da altrettante diverse associazioni allo stesso \index{inode}
-inode di etichette diverse in directory diverse. Si noti anche che nessuno di
-questi nomi viene ad assumere una particolare preferenza o originalità
-rispetto agli altri, in quanto tutti fanno comunque riferimento allo stesso
-\index{inode} inode.
+diversi, dati da altrettante associazioni diverse allo stesso \itindex{inode}
+\textit{inode} effettuate tramite ``etichette'' diverse in directory
+diverse. Si noti anche che nessuno di questi nomi viene ad assumere una
+particolare preferenza o originalità rispetto agli altri, in quanto tutti
+fanno comunque riferimento allo stesso \itindex{inode} \textit{inode}.
Per aggiungere ad una directory una voce che faccia riferimento ad un
-\index{inode} inode già esistente si utilizza la funzione \func{link}; si
-suole chiamare questo tipo di associazione un collegamento diretto (o
-\textit{hard link}). Il prototipo della funzione è:
+\itindex{inode} \textit{inode} già esistente si utilizza la funzione
+\func{link}; si suole chiamare questo tipo di associazione un collegamento
+diretto, o \textit{hard link}. Il prototipo della funzione è il seguente:
\begin{prototype}{unistd.h}
{int link(const char *oldpath, const char *newpath)}
Crea un nuovo collegamento diretto.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
errore nel qual caso \var{errno} viene impostata ai valori:
\begin{errlist}
- \item[\errcode{EXDEV}] i file \param{oldpath} e \param{newpath} non sono
- sullo stesso filesystem.
+ \item[\errcode{EXDEV}] i file \param{oldpath} e \param{newpath} non fanno
+ riferimento ad un filesystem montato sullo stesso \textit{mount point}.
\item[\errcode{EPERM}] il filesystem che contiene \param{oldpath} e
\param{newpath} non supporta i link diretti o è una directory.
- \item[\errcode{EEXIST}] un file (o una directory) con quel nome esiste di
- già.
+ \item[\errcode{EEXIST}] un file (o una directory) di nome \param{newpath}
+ esiste già.
\item[\errcode{EMLINK}] ci sono troppi link al file \param{oldpath} (il
numero massimo è specificato dalla variabile \const{LINK\_MAX}, vedi
sez.~\ref{sec:sys_limits}).
\var{st\_nlink} della struttura \struct{stat}, vedi sez.~\ref{sec:file_stat})
aggiungendo il nuovo nome ai precedenti. Si noti che uno stesso file può
essere così chiamato con vari nomi in diverse directory.
-
+
Per quanto dicevamo in sez.~\ref{sec:file_filesystem} la creazione di un
collegamento diretto è possibile solo se entrambi i \itindex{pathname}
\textit{pathname} sono nello stesso filesystem; inoltre il filesystem deve
supportare i collegamenti diretti (il meccanismo non è disponibile ad esempio
-con il filesystem \acr{vfat} di Windows).
+con il filesystem \acr{vfat} di Windows). In realtà la funzione ha un
+ulteriore requisito, e cioè che non solo che i due file siano sullo stesso
+filesystem, ma anche che si faccia riferimento ad essi sullo stesso
+\textit{mount point}.\footnote{si tenga presente infatti (vedi
+ sez.~\ref{sec:sys_file_config}) che a partire dal kernel 2.4 uno stesso
+ filesystem può essere montato più volte su directory diverse.}
La funzione inoltre opera sia sui file ordinari che sugli altri oggetti del
filesystem, con l'eccezione delle directory. In alcune versioni di Unix solo
Data la pericolosità di questa operazione e la disponibilità dei link
simbolici che possono fornire la stessa funzionalità senza questi problemi,
-nei filesystem usati in Linux questa caratteristica è stata completamente
-disabilitata, e al tentativo di creare un link diretto ad una directory la
-funzione restituisce l'errore \errcode{EPERM}.
+nel caso di Linux questa capacità è stata completamente disabilitata, e al
+tentativo di creare un link diretto ad una directory la funzione \func{link}
+restituisce l'errore \errcode{EPERM}.
+
+Un ulteriore comportamento peculiare di Linux è quello in cui si crea un
+\textit{hard link} ad un link simbolico. In questo caso lo standard POSIX
+prevederebbe che quest'ultimo venga risolto e che il collegamento sia
+effettuato rispetto al file cui esso punta, e che venga riportato un errore
+qualora questo non esista o non sia un file. Questo era anche il comportamento
+iniziale di Linux ma a partire dai kernel della serie 2.0.x\footnote{per la
+ precisione il comportamento era quello previsto dallo standard POSIX fino al
+ kernel di sviluppo 1.3.56, ed è stato temporaneamente ripristinato anche
+ durante lo sviluppo della serie 2.1.x, per poi tornare al comportamento
+ attuale fino ad oggi (per riferimento si veda
+ \href{http://lwn.net/Articles/293902}
+ {\texttt{http://lwn.net/Articles/293902}}).} è stato adottato un
+comportamento che non segue più lo standard per cui l'\textit{hard link} viene
+creato rispetto al link simbolico, e non al file cui questo punta.
+
+La ragione di questa differenza rispetto allo standard, presente anche in
+altri sistemi unix-like, sono dovute al fatto che un link simbolico può fare
+riferimento anche ad un file non esistente o a una directory, per i quali
+l'\textit{hard link} non può essere creato, per cui la scelta di seguire il
+link simbolico è stata ritenuta una scelta scorretta nella progettazione
+dell'interfaccia. Infatti se non ci fosse il comportamento adottato da Linux
+sarebbe impossibile creare un \textit{hard link} ad un link simbolico, perché
+la funzione lo risolverebbe e l'\textit{hard link} verrebbe creato verso la
+destinazione. Invece evitando di seguire lo standard l'operazione diventa
+possibile, ed anche il comportamento della funzione risulta molto più
+comprensibile. Tanto più che se proprio se si vuole creare un \textit{hard
+ link} rispetto alla destinazione di un link simbolico è sempre possibile
+farlo direttamente.\footnote{ciò non toglie che questo comportamento fuori
+ standard possa causare problemi, come nell'esempio descritto nell'articolo
+ citato nella nota precedente, a programmi che non si aspettano questa
+ differenza rispetto allo standard POSIX.}
La rimozione di un file (o più precisamente della voce che lo referenzia
all'interno di una directory) si effettua con la funzione \funcd{unlink}; il
abbia privilegi sufficienti.}
La funzione cancella il nome specificato da \param{pathname} nella relativa
-directory e decrementa il numero di riferimenti nel relativo \index{inode}
-inode. Nel caso di link simbolico cancella il link simbolico; nel caso di
-socket, fifo o file di dispositivo \index{file!di~dispositivo} rimuove il
-nome, ma come per i file i processi che hanno aperto uno di questi oggetti
+directory e decrementa il numero di riferimenti nel relativo \itindex{inode}
+\textit{inode}. Nel caso di link simbolico cancella il link simbolico; nel
+caso di socket, fifo o file di dispositivo \index{file!di~dispositivo} rimuove
+il nome, ma come per i file i processi che hanno aperto uno di questi oggetti
possono continuare ad utilizzarlo.
Per cancellare una voce in una directory è necessario avere il permesso di
Una delle caratteristiche di queste funzioni è che la creazione/rimozione del
nome dalla directory e l'incremento/decremento del numero di riferimenti
-\index{inode} nell'inode devono essere effettuati in maniera atomica (si veda
-sez.~\ref{sec:proc_atom_oper}) senza possibili interruzioni fra le due
-operazioni. Per questo entrambe queste funzioni sono realizzate tramite una
-singola system call.
+\itindex{inode} nell'\textit{inode} devono essere effettuati in maniera
+atomica (si veda sez.~\ref{sec:proc_atom_oper}) senza possibili interruzioni
+fra le due operazioni. Per questo entrambe queste funzioni sono realizzate
+tramite una singola system call.
Si ricordi infine che un file non viene eliminato dal disco fintanto che tutti
i riferimenti ad esso sono stati cancellati: solo quando il \textit{link
- count} mantenuto \index{inode} nell'inode diventa zero lo spazio occupato su
-disco viene rimosso (si ricordi comunque che a questo si aggiunge sempre
-un'ulteriore condizione,\footnote{come vedremo in
+ count} mantenuto \itindex{inode} nell'\textit{inode} diventa zero lo spazio
+occupato su disco viene rimosso (si ricordi comunque che a questo si aggiunge
+sempre un'ulteriore condizione,\footnote{come vedremo in
cap.~\ref{cha:file_unix_interface} il kernel mantiene anche una tabella dei
file aperti nei vari processi, che a sua volta contiene i riferimenti agli
- \index{inode} 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'inode in questione.} e cioè che non ci siano processi che
-abbiano il suddetto file aperto).
+ \itindex{inode} \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.} e cioè che
+non ci siano processi che abbiano il suddetto file aperto).
Questa proprietà viene spesso usata per essere sicuri di non lasciare file
temporanei su disco in caso di crash dei programmi; la tecnica è quella di
\label{sec:file_symlink}
Come abbiamo visto in sez.~\ref{sec:file_link} la funzione \func{link} crea
-riferimenti agli \index{inode} inode, pertanto può funzionare soltanto per file
-che risiedono sullo stesso filesystem e solo per un filesystem di tipo Unix.
-Inoltre abbiamo visto che in Linux non è consentito eseguire un link diretto
-ad una directory.
+riferimenti agli \itindex{inode} \textit{inode}, pertanto può funzionare
+soltanto per file che risiedono sullo stesso filesystem e solo per un
+filesystem di tipo Unix. Inoltre abbiamo visto che in Linux non è consentito
+eseguire un link diretto ad una directory.
Per ovviare a queste limitazioni i sistemi Unix supportano un'altra forma di
link (i cosiddetti \textit{soft link} o \textit{symbolic link}), che sono,
Il sistema funziona in quanto i link simbolici sono riconosciuti come tali dal
kernel\footnote{è uno dei diversi tipi di file visti in
- tab.~\ref{tab:file_file_types}, contrassegnato come tale nell'inode, e
- riconoscibile dal valore del campo \var{st\_mode} della struttura
- \struct{stat} (vedi sez.~\ref{sec:file_stat}).} per cui alcune funzioni di
-libreria (come \func{open} o \func{stat}) quando ricevono come argomento un
-link simbolico vengono automaticamente applicate al file da esso specificato.
-La funzione che permette di creare un nuovo link simbolico è \funcd{symlink},
-ed il suo prototipo è:
+ tab.~\ref{tab:file_file_types}, contrassegnato come tale
+ nell'\textit{inode}, e riconoscibile dal valore del campo \var{st\_mode}
+ della struttura \struct{stat} (vedi sez.~\ref{sec:file_stat}).} per cui
+alcune funzioni di libreria (come \func{open} o \func{stat}) quando ricevono
+come argomento un link simbolico vengono automaticamente applicate al file da
+esso specificato. La funzione che permette di creare un nuovo link simbolico
+è \funcd{symlink}, ed il suo prototipo è:
\begin{prototype}{unistd.h}
{int symlink(const char *oldpath, const char *newpath)}
Crea un nuovo link simbolico di nome \param{newpath} il cui contenuto è
\func{chown} & -- & $\bullet$ \\
\func{creat} & $\bullet$ & -- \\
\func{exec} & $\bullet$ & -- \\
- \func{lchown} & $\bullet$ & $\bullet$ \\
- \func{link} & -- & -- \\
+ \func{lchown} & $\bullet$ & -- \\
+ \func{link}\footnotemark & -- & $\bullet$ \\
\func{lstat} & -- & $\bullet$ \\
\func{mkdir} & $\bullet$ & -- \\
\func{mkfifo} & $\bullet$ & -- \\
\label{tab:file_symb_effect}
\end{table}
+\footnotetext{a partire dalla serie 2.0, e contrariamente a quanto indicato
+ dallo standard POSIX, si veda quanto detto in sez.~\ref{sec:file_link}.}
+
Si noti che non si è specificato il comportamento delle funzioni che operano
con i file descriptor, in quanto la risoluzione del link simbolico viene in
genere effettuata dalla funzione che restituisce il file descriptor
\label{sec:file_dir_creat_rem}
Benché in sostanza le directory non siano altro che dei file contenenti
-elenchi di nomi ed \index{inode} inode, non è possibile trattarle come file
-ordinari e devono essere create direttamente dal kernel attraverso una
-opportuna system call.\footnote{questo è quello che permette anche, attraverso
- l'uso del VFS, l'utilizzo di diversi formati per la gestione dei suddetti
- elenchi.} La funzione usata per creare una directory è \funcd{mkdir}, ed il
-suo prototipo è:
+elenchi di nomi ed \itindex{inode} \textit{inode}, non è possibile trattarle
+come file ordinari e devono essere create direttamente dal kernel attraverso
+una opportuna system call.\footnote{questo è quello che permette anche,
+ attraverso l'uso del VFS, l'utilizzo di diversi formati per la gestione dei
+ suddetti elenchi.} La funzione usata per creare una directory è
+\funcd{mkdir}, ed il suo prototipo è:
\begin{functions}
\headdecl{sys/stat.h}
\headdecl{sys/types.h}
\textit{pathname} assoluto o relativo.
La modalità con cui avviene la cancellazione è analoga a quella di
-\func{unlink}: fintanto che il numero di link \index{inode} all'inode della
-directory non diventa nullo e nessun processo ha la directory aperta lo spazio
-occupato su disco non viene rilasciato. Se un processo ha la directory aperta
-la funzione rimuove il link \index{inode} all'inode e nel caso sia l'ultimo,
-pure le voci standard ``\file{.}'' e ``\file{..}'', a questo punto il kernel
-non consentirà di creare più nuovi file nella directory.
+\func{unlink}: fintanto che il numero di link \itindex{inode}
+all'\textit{inode} della directory non diventa nullo e nessun processo ha la
+directory aperta lo spazio occupato su disco non viene rilasciato. Se un
+processo ha la directory aperta la funzione rimuove il link \itindex{inode}
+all'\textit{inode} e nel caso sia l'ultimo, pure le voci standard ``\file{.}''
+e ``\file{..}'', a questo punto il kernel non consentirà di creare più nuovi
+file nella directory.
\subsection{La creazione di file speciali}
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}
\headdecl{unistd.h}
\funcdecl{int mknod(const char *pathname, mode\_t mode, dev\_t dev)}
- Crea un inode, si usa per creare i file speciali.
+ Crea un \textit{inode} del tipo specificato sul filesystem.
\bodydesc{La funzione restituisce zero in caso di successo e -1 per un
errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
- \item[\errcode{EPERM}] non si hanno privilegi sufficienti a creare l'inode, o
- il filesystem su cui si è cercato di creare \param{pathname} non supporta
- l'operazione.
+ \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.
\item[\errcode{EINVAL}] il valore di \param{mode} non indica un file, una
- fifo o un dispositivo.
+ fifo, un socket o un dispositivo.
\item[\errcode{EEXIST}] \param{pathname} esiste già o è un link simbolico.
\end{errlist}
ed inoltre anche \errval{EFAULT}, \errval{EACCES}, \errval{ENAMETOOLONG},
\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
-\var{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 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, il valore di
-\param{dev} viene usato per indicare a quale dispositivo si fa riferimento.
-
-Solo l'amministratore può creare un file di dispositivo o un file regolare
-usando questa funzione; 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 una fifo è consentito anche
+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 \index{inode} inode creati con \func{mknod} apparterranno al
-proprietario e al gruppo del processo che li ha creati, a meno che non si sia
-attivato 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 \index{inode} l'inode.
+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
+sia attivato 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
+\itindex{inode} l'\textit{inode}.
+
+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}
-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 è:
+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}
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 link
simbolico); al solito i permessi specificati da \param{mode} vengono
-modificati dal valore di \var{umask}.
+modificati dal valore di \itindex{umask} \textit{umask}.
\label{sec:file_dir_read}
Benché le directory alla fine non siano altro che dei file che contengono
-delle liste di nomi ed \index{inode} inode, per il ruolo che rivestono nella
-struttura del sistema, non possono essere trattate come dei normali file di
-dati. Ad esempio, onde evitare inconsistenze all'interno del filesystem, solo
-il kernel può scrivere il contenuto di una directory, e non può essere un
-processo a inserirvi direttamente delle voci con le usuali funzioni di
-scrittura.
+delle liste di nomi ed \itindex{inode} \textit{inode}, per il ruolo che
+rivestono nella struttura del sistema, non possono essere trattate come dei
+normali file di dati. Ad esempio, onde evitare inconsistenze all'interno del
+filesystem, solo il kernel può scrivere il contenuto di una directory, e non
+può essere un processo a inserirvi direttamente delle voci con le usuali
+funzioni di scrittura.
Ma se la scrittura e l'aggiornamento dei dati delle directory è compito del
kernel, sono molte le situazioni in cui i processi necessitano di poterne
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).
-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},
- che in Linux è definito come alias di quest'ultimo. Il campo \var{d\_name} è
- considerato dipendente dall'implementazione.} prevedono che siano sempre
-presenti il campo \var{d\_name}, che contiene il nome del file nella forma di
-una stringa terminata da uno zero,\footnote{lo standard POSIX non specifica
- una lunghezza, ma solo un limite \const{NAME\_MAX}; in SVr4 la lunghezza del
- campo è definita come \code{NAME\_MAX+1} che di norma porta al valore di 256
- byte usato anche in Linux.} ed il campo \var{d\_ino}, che contiene il numero
-di \index{inode} 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}
\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},
+ che in Linux è definito come alias di quest'ultimo. Il campo \var{d\_name} è
+ considerato dipendente dall'implementazione.} prevedono che siano sempre
+presenti il campo \var{d\_name}, che contiene il nome del file nella forma di
+una stringa terminata da uno zero,\footnote{lo standard POSIX non specifica
+ una lunghezza, ma solo un limite \const{NAME\_MAX}; in SVr4 la lunghezza del
+ campo è definita come \code{NAME\_MAX+1} che di norma porta al valore di 256
+ byte usato anche in Linux.} ed il campo \var{d\_ino}, che contiene il numero
+di \itindex{inode} \textit{inode} cui il file è associato (di solito
+corrisponde al campo \var{st\_ino} di \struct{stat}).
+
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 \index{inode}
-dell'inode della directory di lavoro, per ottenere il \textit{pathname}
-occorre usare una apposita funzione di libreria, \funcd{getcwd}, il cui
-prototipo è:
+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},\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
Come spiegato in sez.~\ref{sec:file_filesystem} tutte le informazioni generali
relative alle caratteristiche di ciascun file, a partire dalle informazioni
-relative al controllo di accesso, sono mantenute \index{inode} nell'inode.
+relative al controllo di accesso, sono mantenute \itindex{inode}
+nell'\textit{inode}.
Vedremo in questa sezione come sia possibile leggere tutte queste informazioni
usando la funzione \func{stat}, che permette l'accesso a tutti i dati
-memorizzati \index{inode} nell'inode; esamineremo poi le varie funzioni usate
-per manipolare tutte queste informazioni (eccetto quelle che riguardano la
-gestione del controllo di accesso, trattate in in
+memorizzati \itindex{inode} nell'\textit{inode}; esamineremo poi le varie
+funzioni usate per manipolare tutte queste informazioni (eccetto quelle che
+riguardano la gestione del controllo di accesso, trattate in in
sez.~\ref{sec:file_access_control}).
primitivi del sistema (di quelli definiti in
tab.~\ref{tab:intro_primitive_types}, e dichiarati in \file{sys/types.h}).
+% TODO: aggiornare con i cambiamenti ai tempi fatti con il 2.6
\subsection{I tipi di file}
\label{sec:file_types}
\textbf{Macro} & \textbf{Tipo del file} \\
\hline
\hline
- \macro{S\_ISREG(m)} & File normale.\\
- \macro{S\_ISDIR(m)} & Directory.\\
- \macro{S\_ISCHR(m)} & Dispositivo a caratteri.\\
- \macro{S\_ISBLK(m)} & Dispositivo a blocchi.\\
- \macro{S\_ISFIFO(m)} & Fifo.\\
- \macro{S\_ISLNK(m)} & Link simbolico.\\
- \macro{S\_ISSOCK(m)} & Socket.\\
+ \macro{S\_ISREG(m)} & file normale.\\
+ \macro{S\_ISDIR(m)} & directory.\\
+ \macro{S\_ISCHR(m)} & dispositivo a caratteri.\\
+ \macro{S\_ISBLK(m)} & dispositivo a blocchi.\\
+ \macro{S\_ISFIFO(m)} & fifo.\\
+ \macro{S\_ISLNK(m)} & link simbolico.\\
+ \macro{S\_ISSOCK(m)} & socket.\\
\hline
\end{tabular}
\caption{Macro per i tipi di file (definite in \texttt{sys/stat.h}).}
\label{sec:file_file_times}
Il sistema mantiene per ciascun file tre tempi. Questi sono registrati
-\index{inode} nell'inode insieme agli altri attributi del file e possono
-essere letti tramite la funzione \func{stat}, che li restituisce attraverso
-tre campi della struttura \struct{stat} di fig.~\ref{fig:file_stat_struct}. Il
-significato di detti tempi e dei relativi campi è riportato nello schema in
-tab.~\ref{tab:file_file_times}, dove è anche riportato un esempio delle
-funzioni che effettuano cambiamenti su di essi.
+\itindex{inode} nell'\textit{inode} insieme agli altri attributi del file e
+possono essere letti tramite la funzione \func{stat}, che li restituisce
+attraverso tre campi della struttura \struct{stat} di
+fig.~\ref{fig:file_stat_struct}. Il significato di detti tempi e dei relativi
+campi è riportato nello schema in tab.~\ref{tab:file_file_times}, dove è anche
+riportato un esempio delle funzioni che effettuano cambiamenti su di essi.
\begin{table}[htb]
\centering
\func{read}, \func{utime} & \cmd{-u}\\
\var{st\_mtime}& ultima modifica ai dati del file &
\func{write}, \func{utime} & default\\
- \var{st\_ctime}& ultima modifica ai dati dell'inode &
+ \var{st\_ctime}& ultima modifica ai dati dell'\textit{inode} &
\func{chmod}, \func{utime} & \cmd{-c}\\
\hline
\end{tabular}
modifica (il \textit{modification time} \var{st\_mtime}) e il tempo di
cambiamento di stato (il \textit{change time} \var{st\_ctime}). Il primo
infatti fa riferimento ad una modifica del contenuto di un file, mentre il
-secondo ad una modifica \index{inode} dell'inode; siccome esistono molte
-operazioni (come la funzione \func{link} e molte altre che vedremo in seguito)
-che modificano solo le informazioni contenute \index{inode} nell'inode senza
-toccare il contenuto del file, diventa necessario l'utilizzo di un altro
-tempo.
-
-Il sistema non tiene conto dell'ultimo accesso \index{inode} all'inode,
-pertanto funzioni come \func{access} o \func{stat} non hanno alcuna influenza
-sui tre tempi. Il tempo di ultimo accesso (ai dati) viene di solito usato per
-cancellare i file che non servono più dopo un certo lasso di tempo (ad esempio
-il programma \cmd{leafnode} cancella i vecchi articoli sulla base di questo
-tempo).
+secondo ad una modifica \itindex{inode} dell'\textit{inode}; siccome esistono
+molte operazioni (come la funzione \func{link} e molte altre che vedremo in
+seguito) che modificano solo le informazioni contenute \itindex{inode}
+nell'\textit{inode} senza toccare il contenuto del file, diventa necessario
+l'utilizzo di un altro tempo.
+
+Il sistema non tiene conto dell'ultimo accesso \itindex{inode}
+all'\textit{inode}, pertanto funzioni come \func{access} o \func{stat} non
+hanno alcuna influenza sui tre tempi. Il tempo di ultimo accesso (ai dati)
+viene di solito usato per cancellare i file che non servono più dopo un certo
+lasso di tempo (ad esempio il programma \cmd{leafnode} cancella i vecchi
+articoli sulla base di questo tempo).
\begin{table}[htb]
\centering
\begin{prototype}{utime.h}
{int utime(const char *filename, struct utimbuf *times)}
-Cambia i tempi di ultimo accesso e modifica \index{inode} dell'inode
-specificato da \param{filename} secondo i campi \var{actime} e \var{modtime}
-di \param{times}. Se questa è \val{NULL} allora viene usato il tempo corrente.
+Cambia i tempi di ultimo accesso e modifica \itindex{inode}
+dell'\textit{inode} specificato da \param{filename} secondo i campi
+\var{actime} e \var{modtime} di \param{times}. Se questa è \val{NULL} allora
+viene usato il tempo corrente.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
errore, nel qual caso \var{errno} assumerà uno dei valori:
Si tenga presente che non è comunque possibile specificare il tempo di
cambiamento di stato del file, che viene comunque cambiato dal kernel tutte le
-volte che si modifica \index{inode} l'inode (quindi anche alla chiamata di
-\func{utime}). Questo serve anche come misura di sicurezza per evitare che si
-possa modificare un file nascondendo completamente le proprie tracce. In
-realtà la cosa resta possibile, se si è in grado di accedere al file di
-dispositivo, scrivendo direttamente sul disco senza passare attraverso il
-filesystem, ma ovviamente in questo modo la cosa è molto più complicata da
+volte che si modifica \itindex{inode} l'\textit{inode} (quindi anche alla
+chiamata di \func{utime}). Questo serve anche come misura di sicurezza per
+evitare che si possa modificare un file nascondendo completamente le proprie
+tracce. In realtà la cosa resta possibile, se si è in grado di accedere al
+file di dispositivo, scrivendo direttamente sul disco senza passare attraverso
+il filesystem, ma ovviamente in questo modo la cosa è molto più complicata da
realizzare.
riportato in fig.~\ref{fig:file_perm_bit}.
Anche i permessi, come tutte le altre informazioni pertinenti al file, sono
-memorizzati \index{inode} nell'inode; in particolare essi sono contenuti in
-alcuni bit del campo \var{st\_mode} della struttura \struct{stat} (si veda di
-nuovo fig.~\ref{fig:file_stat_struct}).
+memorizzati \itindex{inode} nell'\textit{inode}; in particolare essi sono
+contenuti in alcuni bit 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
\cmd{u} (per \textit{user}), \cmd{g} (per \textit{group}) e \cmd{o} (per
consentito,
\item altrimenti l'accesso è negato
\end{itemize*}
-\item se il bit dei permessi d'accesso per tutti gli altri è impostato,
+\item Se il bit dei permessi d'accesso per tutti gli altri è impostato,
l'accesso è consentito, altrimenti l'accesso è negato.
\end{enumerate}
l'uso del \itindex{suid~bit} \textit{suid bit}) che vuole controllare se
l'utente originale ha i permessi per accedere ad un certo file.
+% TODO documentare euidaccess (e eaccess)
+
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:
gruppi, ed inoltre il problema si pone anche per l'interfaccia nativa quando i
permessi non vengono indicati esplicitamente.
-In tutti questi casi l'unico riferimento possibile è quello della modalità di
-apertura del nuovo file (lettura/scrittura o sola lettura), che però può
-fornire un valore che è lo stesso per tutti e tre i permessi di
-sez.~\ref{sec:file_perm_overview} (cioè $666$ nel primo caso e $222$ nel
-secondo). Per questo motivo il sistema associa ad ogni processo\footnote{è
- infatti contenuta nel campo \var{umask} della struttura \struct{fs\_struct},
- vedi fig.~\ref{fig:proc_task_struct}.} una maschera di bit, la cosiddetta
-\textit{umask}, che viene utilizzata per impedire che alcuni permessi possano
-essere assegnati ai nuovi file in sede di creazione. I bit indicati nella
-maschera vengono infatti cancellati dai permessi quando un nuovo file viene
-creato.
+\itindbeg{umask}
+
+Per le funzioni dell'interfaccia standard ANSI C l'unico riferimento possibile
+è quello della modalità di apertura del nuovo file (lettura/scrittura o sola
+lettura), che però può fornire un valore che è lo stesso per tutti e tre i
+permessi di sez.~\ref{sec:file_perm_overview} (cioè $666$ nel primo caso e
+$222$ nel secondo). Per questo motivo il sistema associa ad ogni
+processo\footnote{è infatti contenuta nel campo \var{umask} della struttura
+ \struct{fs\_struct}, vedi fig.~\ref{fig:proc_task_struct}.} una maschera di
+bit, la cosiddetta \textit{umask}, che viene utilizzata per impedire che
+alcuni permessi possano essere assegnati ai nuovi file in sede di creazione. I
+bit indicati nella maschera vengono infatti cancellati dai permessi quando un
+nuovo file viene creato.\footnote{l'operazione viene fatta sempre: anche
+ qualora si indichi esplicitamente un valore dei permessi nelle funzioni di
+ creazione che lo consentono, i permessi contenuti nella \textit{umask}
+ verranno tolti.}
La funzione che permette di impostare il valore di questa maschera di
controllo è \funcd{umask}, ed il suo prototipo è:
voluti. Di norma questo valore viene impostato una volta per tutte al login a
$022$, e gli utenti non hanno motivi per modificarlo.
+\itindend{umask}
\subsection{La gestione della titolarità dei file}
\itindbeg{Extended~Attributes}
Nelle sezioni precedenti abbiamo trattato in dettaglio le varie informazioni
-che il sistema mantiene negli inode, e le varie funzioni che permettono di
-modificarle. Si sarà notato come in realtà queste informazioni siano
-estremamente ridotte. Questo è dovuto al fatto che Unix origina negli anni
-'70, quando le risorse di calcolo e di spazio disco erano minime. Con il venir
-meno di queste restrizioni è incominciata ad emergere l'esigenza di poter
-associare ai file delle ulteriori informazioni astratte (quelli che vengono
-chiamati i \textsl{meta-dati}) che però non potevano trovar spazio nei dati
-classici mantenuti negli inode.
+che il sistema mantiene negli \itindex{inode} \textit{inode}, e le varie
+funzioni che permettono di modificarle. Si sarà notato come in realtà queste
+informazioni siano estremamente ridotte. Questo è dovuto al fatto che Unix
+origina negli anni '70, quando le risorse di calcolo e di spazio disco erano
+minime. Con il venir meno di queste restrizioni è incominciata ad emergere
+l'esigenza di poter associare ai file delle ulteriori informazioni astratte
+(quelli che vengono chiamati i \textsl{meta-dati}) che però non potevano
+trovare spazio nei dati classici mantenuti negli \itindex{inode}
+\textit{inode}.
Per risolvere questo problema alcuni sistemi unix-like (e fra questi anche
Linux) hanno introdotto un meccanismo generico che consenta di associare delle
richiedono una gran numero di accessi, come le ACL.} e di garantire
l'atomicità di tutte le operazioni.
-In Linux gli attributi estesi sono sempre associati al singolo inode e
-l'accesso viene sempre eseguito in forma atomica, in lettura il valore
-corrente viene scritto su un buffer in memoria, mentre la scrittura prevede
-che ogni valore precedente sia sovrascritto.
+In Linux gli attributi estesi sono sempre associati al singolo \itindex{inode}
+\textit{inode} e l'accesso viene sempre eseguito in forma atomica, in lettura
+il valore corrente viene scritto su un buffer in memoria, mentre la scrittura
+prevede che ogni valore precedente sia sovrascritto.
Si tenga presente che non tutti i filesystem supportano gli \textit{Extended
Attributes}, in particolare al momento della scrittura di queste dispense
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'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.
+ 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.
Come meccanismo per mantenere informazioni aggiuntive associate al singolo
file, gli \textit{Extended Attributes} possono avere usi anche molto diversi
\begin{table}[htb]
\centering
\footnotesize
- \begin{tabular}{|c|p{8cm}|}
+ \begin{tabular}{|c|p{10cm}|}
\hline
\textbf{Nome} & \textbf{Descrizione} \\
\hline
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
rispondere in maniera adeguata a situazioni che richiedono una gestione
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 soddisfacente.}
+ si può soddisfare in maniera semplice.}
Per questo motivo erano state progressivamente introdotte nelle varie versioni
di Unix dei meccanismi di gestione dei permessi dei file più flessibili, nella
\acr{glibc} e devono essere installate a parte;\footnote{la versione corrente
della libreria è \texttt{libacl1}, e nel caso si usi Debian la si può
installare con il pacchetto omonimo e con il collegato \texttt{libacl1-dev}
- per il file di sviluppo.}
-pertanto se un programma le utilizza si dovrà indicare esplicitamente l'uso
-della libreria \texttt{libacl} invocando il compilatore con l'opzione
-\texttt{-lacl}.
+ per i file di sviluppo.} pertanto se un programma le utilizza si dovrà
+indicare esplicitamente l'uso della libreria \texttt{libacl} invocando il
+compilatore con l'opzione \texttt{-lacl}. Si tenga presente inoltre che per
+poterle utilizzare 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} attiva. Dato che si tratta di una
+estensione è infatti opportuno utilizzarle soltanto laddove siano necessarie.
+
+Una ACL è composta da un insieme di voci, e ciascuna voce è a sua volta
+costituita da un \textsl{tipo}, da un eventuale
+\textsl{qualificatore},\footnote{deve essere presente soltanto per le voci di
+ tipo \const{ACL\_USER} e \const{ACL\_GROUP}.} e da un insieme di permessi.
+Ad ogni oggetto sul filesystem si può associare una ACL che ne governa i
+permessi di accesso, detta \textit{access ACL}. Inoltre per le directory si
+può impostare una ACL aggiuntiva, detta \textit{default ACL}, che serve ad
+indicare quale dovrà essere la ACL assegnata di default nella creazione di un
+file all'interno della directory stessa. Come avviene per i permessi le ACL
+possono essere impostate solo del proprietario del file, o da un processo con
+la capability \index{capabilities} \const{CAP\_FOWNER}.
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}{|l|p{8cm}|}
+ \hline
+ \textbf{Tipo} & \textbf{Descrizione} \\
+ \hline
+ \hline
+ \const{ACL\_USER\_OBJ} & voce che contiene i diritti di accesso del
+ proprietario del file.\\
+ \const{ACL\_USER} & voce che contiene i diritti di accesso per
+ l'utente indicato dal rispettivo
+ qualificatore.\\
+ \const{ACL\_GROUP\_OBJ}& voce che contiene i diritti di accesso del
+ gruppo proprietario del file.\\
+ \const{ACL\_GROUP} & voce che contiene i diritti di accesso per
+ il gruppo indicato dal rispettivo
+ qualificatore.\\
+ \const{ACL\_MASK} & voce che contiene la maschera dei massimi
+ permessi di accesso che possono essere garantiti
+ da voci del tipo \const{ACL\_USER},
+ \const{ACL\_GROUP} e \const{ACL\_GROUP\_OBJ}.\\
+ \const{ACL\_OTHER} & voce che contiene i diritti di accesso di chi
+ non corrisponde a nessuna altra voce dell'ACL.\\
+ \hline
+ \end{tabular}
+ \caption{Le costanti che identificano i tipi delle voci di una ACL.}
+ \label{tab:acl_tag_types}
+\end{table}
+L'elenco dei vari tipi di voci presenti in una ACL, con una breve descrizione
+del relativo significato, è riportato in tab.~\ref{tab:acl_tag_types}. Tre di
+questi tipi, \const{ACL\_USER\_OBJ}, \const{ACL\_GROUP\_OBJ} e
+\const{ACL\_OTHER}, corrispondono direttamente ai tre permessi ordinari dei
+file (proprietario, gruppo proprietario e tutti gli altri) e per questo una
+ACL valida deve sempre contenere una ed una sola voce per ciascuno di questi
+tipi.
+
+Una ACL può poi contenere un numero arbitrario di voci di tipo
+\const{ACL\_USER} e \const{ACL\_GROUP}, ciascuna delle quali indicherà i
+permessi assegnati all'utente e al gruppo indicato dal relativo qualificatore;
+ovviamente ciascuna di queste voci dovrà fare riferimento ad un utente o ad un
+gruppo diverso, e non corrispondenti a quelli proprietari del file. Inoltre se
+in una ACL esiste una voce di uno di questi due tipi è obbligatoria anche la
+presenza di una ed una sola voce di tipo \const{ACL\_MASK}, che negli altri
+casi è opzionale.
+
+Quest'ultimo tipo di voce contiene la maschera dei permessi che possono essere
+assegnati tramite voci di tipo \const{ACL\_USER}, \const{ACL\_GROUP} e
+\const{ACL\_GROUP\_OBJ}; se in una di queste voci si fosse specificato un
+permesso non presente in \const{ACL\_MASK} questo verrebbe ignorato. L'uso di
+una ACL di tipo \const{ACL\_MASK} è di particolare utilità quando essa
+associata ad una \textit{default ACL} su una directory, in quanto i permessi
+così specificati verranno ereditati da tutti i file creati nella stessa
+directory. Si ottiene così una sorta di \itindex{umask} \textit{umask}
+associata ad un oggetto sul filesystem piuttosto che a un processo.
+
+Dato che le ACL vengono a costituire una estensione dei permessi ordinari, uno
+dei problemi che si erano posti nella loro standardizzazione era appunto
+quello della corrispondenza fra questi e le ACL. Come accennato i permessi
+ordinari vengono mappati le tre voci di tipo \const{ACL\_USER\_OBJ},
+\const{ACL\_GROUP\_OBJ} e \const{ACL\_OTHER} che devono essere presenti in
+qualunque ACL; un cambiamento ad una di queste voci viene automaticamente
+riflesso sui permessi ordinari dei file\footnote{per permessi ordinari si
+ intende quelli mantenuti nell'\textit{inode}, che devono restare dato che un
+ filesystem può essere montato senza abilitare le ACL.} e viceversa. In
+realtà la mappatura è diretta solo per le voci \const{ACL\_USER\_OBJ} e
+\const{ACL\_OTHER}, nel caso di \const{ACL\_GROUP\_OBJ} questo vale soltanto
+se non è presente una voce di tipo \const{ACL\_MASK}, se invece questa è
+presente verranno tolti dai permessi di \const{ACL\_GROUP\_OBJ} tutti quelli
+non presenti in \const{ACL\_MASK}.\footnote{questo diverso comportamento a
+ seconda delle condizioni è stato introdotto dalla standardizzazione
+ \textit{POSIX 1003.1e Draft 17} per mantenere il comportamento invariato sui
+ sistemi dotati di ACL per tutte quelle applicazioni che sono conformi
+ soltanto all'ordinario standard \textit{POSIX 1003.1}.}
+
+Un secondo aspetto dell'incidenza delle ACL sul comportamento del sistema è
+quello relativo alla creazione di nuovi file,\footnote{o oggetti sul
+ filesystem, il comportamento discusso vale per le funzioni \func{open} e
+ \func{creat} (vedi sez.~\ref{sec:file_open}), \func{mkdir} (vedi
+ sez.~\ref{sec:file_dir_creat_rem}), \func{mknod} e \func{mkfifo} (vedi
+ sez.~\ref{sec:file_mknod}).} che come accennato può essere modificato dalla
+presenza di una \textit{default ACL} sulla directory che contiene quel file.
+Se questa non c'è valgono le regole usuali illustrate in
+sez.~\ref{sec:file_perm_management}, per cui essi sono determinati dalla
+\itindex{umask} \textit{umask} del processo, e la sola differenza è che i
+permessi ordinari da esse risultanti vengono automaticamente rimappati anche
+su una ACL di accesso assegnata automaticamente al nuovo file, che contiene
+soltanto le tre corrispondenti voci di tipo \const{ACL\_USER\_OBJ},
+\const{ACL\_GROUP\_OBJ} e \const{ACL\_OTHER}.
+
+Se invece è presente una ACL di default sulla directory che contiene il nuovo
+file questa diventerà automaticamente la sua ACL di accesso, a meno di non
+aver indicato, nelle funzioni di creazione che lo consentono, uno specifico
+valore per i permessi ordinari;\footnote{tutte le funzioni citate in
+ precedenza supportano un argomento \var{mode} che indichi un insieme di
+ permessi iniziale.} in tal caso saranno eliminati dalle voci corrispondenti
+nella ACL tutti quelli non presenti in tale indicazione.
+
+Dato che questa è la ragione che ha portato alla loro creazione, la principale
+modifica introdotta con la presenza della ACL è quella alle regole del
+controllo di accesso ai file illustrate in sez.~\ref{sec:file_perm_overview}.
+Come nel caso ordinario per il controllo vengono sempre utilizzati gli
+identificatori del gruppo \textit{effective} del processo, ma in presenza di
+ACL i passi attraverso i quali viene stabilito se esso ha diritto di accesso
+sono i seguenti:
+\begin{enumerate*}
+\item Se l'user-ID del processo è nullo l'accesso è sempre garantito senza
+ nessun controllo.
+\item Se l'user-ID del processo corrisponde al proprietario del file allora:
+ \begin{itemize*}
+ \item se la voce \const{ACL\_USER\_OBJ} contiene il permesso richiesto,
+ l'accesso è consentito;
+ \item altrimenti l'accesso è negato.
+ \end{itemize*}
+\item Se l'user-ID del processo corrisponde ad un qualunque qualificatore
+ presente in una voce \const{ACL\_USER} allora:
+ \begin{itemize*}
+ \item se la voce \const{ACL\_USER} corrispondente e la voce
+ \const{ACL\_MASK} contengono entrambe il permesso richiesto, l'accesso è
+ consentito;
+ \item altrimenti l'accesso è negato.
+ \end{itemize*}
+\item Se è il group-ID del processo o uno dei group-ID supplementari
+ corrisponde al gruppo proprietario del file allora:
+ \begin{itemize*}
+ \item se la voce \const{ACL\_GROUP\_OBJ} e una eventuale voce
+ \const{ACL\_MASK} (se non vi sono voci di tipo \const{ACL\_GROUP} questa
+ può non essere presente) contengono entrambe il permesso richiesto,
+ l'accesso è consentito;
+ \item altrimenti l'accesso è negato.
+ \end{itemize*}
+\item Se è il group-ID del processo o uno dei group-ID supplementari
+ corrisponde ad un qualunque qualificatore presente in una voce
+ \const{ACL\_GROUP} allora:
+ \begin{itemize*}
+ \item se la voce \const{ACL\_GROUP} corrispondente e la voce
+ \const{ACL\_MASK} contengono entrambe il permesso richiesto, l'accesso è
+ consentito;
+ \item altrimenti l'accesso è negato.
+ \end{itemize*}
+\item Se la voce \const{ACL\_USER\_OBJ} contiene il permesso richiesto,
+ l'accesso è consentito, altrimenti l'accesso è negato.
+\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
+identificatori del processo. Questo significa che i permessi presenti in una
+voce di tipo \const{ACL\_USER} hanno la precedenza sui permessi ordinari
+associati al gruppo proprietario del file (vale a dire su
+\const{ACL\_GROUP\_OBJ}).
+
+Per la gestione delle ACL lo standard \textit{POSIX 1003.1e Draft 17} ha
+previsto delle apposite funzioni ed tutta una serie di tipi di dati
+dedicati;\footnote{fino a definire un tipo di dato e delle costanti apposite
+ per identificare i permessi standard di lettura, scrittura ed esecuzione.}
+tutte le operazioni devono essere effettuate attraverso tramite questi tipi di
+dati, che incapsulano tutte le informazioni contenute nelle ACL. La prima di
+queste funzioni che prendiamo in esame è \funcd{acl\_init}, il cui prototipo
+è:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/acl.h}
+
+ \funcdecl{acl\_t acl\_init(int count)}
+ Inizializza un'area di lavoro per una ACL di \param{count} voci.
+
+ \bodydesc{La funzione restituisce un puntatore all'area di lavoro in caso di
+ successo e \const{NULL} in caso di errore, nel qual caso \var{errno}
+ assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] il valore di \param{count} è negativo.
+ \item[\errcode{ENOMEM}] non c'è sufficiente memoria disponibile.
+ \end{errlist}
+}
+\end{functions}
+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 \const{count}
+voci. La funzione ritorna un valore di tipo \type{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
+``\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 e si dovrà
+confrontare il valore di ritorno della funzione con ``\code{(acl\_t) NULL}''.
+
+Una volta che si siano completate le operazioni sui dati di una ACL la memoria
+allocata dovrà essere liberata esplicitamente attraverso una chiamata alla
+funzione \funcd{acl\_free}, il cui prototipo è:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/acl.h}
+
+ \funcdecl{int acl\_free(void * obj\_p)}
+
+ Disalloca la memoria riservata per i dati di una ACL.
+
+ \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ se
+ \param{obj\_p} non è un puntatore valido, nel qual caso \var{errno}
+ assumerà il valore \errcode{EINVAL}
+}
+\end{functions}
+
+Si noti come la funzione richieda come argomento un puntatore di tipo
+``\ctyp{void *}'', essa infatti può essere usata non solo per liberare la
+memoria allocata per i dati di una ACL, ma anche per quella usata per creare
+le stringhe di descrizione testuale delle ACL o per ottenere i valori dei
+qualificatori di una voce; pertanto a seconda dei casi occorrerà eseguire un
+\textit{cast} a ``\ctyp{void *}'' del tipo di dato di cui si vuole eseguire la
+disallocazione. Si tenga presente poi che oltre a \func{acl\_init} esistono
+molte altre funzioni che possono allocare memoria per i dati delle ACL, è
+pertanto opportuno tenere traccia di tutte queste funzioni perché alla fine
+delle operazioni tutta la memoria allocata dovrà essere liberata con
+\func{acl\_free}.
+
+Una volta che si abbiano a disposizione i dati di una ACL tramite il
+riferimento ad oggetto di tipo \type{acl\_t} questi potranno essere copiati
+con la funzione \funcd{acl\_dup}, il cui prototipo è:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/acl.h}
+
+ \funcdecl{acl\_t acl\_dup(acl\_t acl)}
+
+ Crea una copia della ACL \param{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}] l'argomento \param{acl} non è un puntatore valido
+ per una ACL.
+ \item[\errcode{ENOMEM}] non c'è sufficiente memoria disponibile per eseguire
+ la copia.
+ \end{errlist}
+}
+\end{functions}
+
+La funzione crea una copia dei dati della ACL indicata tramite l'argomento
+\param{acl}, allocando autonomamente tutto spazio necessario alla copia e
+restituendo un secondo oggetto di tipo \type{acl\_t} come riferimento a
+quest'ultima. Valgono per questo le stesse considerazioni fatte per il valore
+di ritorno di \func{acl\_init}, ed in particolare il fatto che occorrerà
+prevedere una ulteriore chiamata esplicita a \func{acl\_free} per liberare la
+memoria occupata dalla copia.
+
+Se si deve creare una ACL manualmente l'uso di \func{acl\_init} è scomodo,
+dato che la funzione restituisce una ACL vuota, una alternativa allora è usare
+\funcd{acl\_from\_mode} che consente di creare una ACL a partire da un valore
+di permessi ordinari, il prototipo della funzione è:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/acl.h}
+
+ \funcdecl{acl\_t acl\_from\_mode(mode\_t mode)}
+
+ Crea una ACL inizializzata con i permessi di \param{mode}.
+
+ \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à il valore \errval{ENOMEM}.
+
+}
+\end{functions}
+
+La funzione restituisce una ACL inizializzata con le tre voci obbligatorie
+\const{ACL\_USER\_OBJ}, \const{ACL\_GROUP\_OBJ} e \const{ACL\_OTHER} già
+impostate secondo la corrispondenza ai valori dei permessi ordinari indicati
+dalla maschera passata nell'argomento \param{mode}. Questa funzione è una
+estensione usata dalle ACL di Linux e non è portabile, ma consente di
+semplificare l'inizializzazione in maniera molto comoda.
+
+Altre due funzioni che consentono di creare una ACL già inizializzata sono
+\funcd{acl\_get\_fd} e \funcd{acl\_get\_file}, che però sono per lo più
+utilizzate per leggere la ACL corrente di un file; i rispettivi prototipi
+sono:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/acl.h}
+
+ \funcdecl{acl\_t acl\_get\_file(const char *path\_p, acl\_type\_t type)}
+ \funcdecl{acl\_t acl\_get\_fd(int fd)}
+
+ Ottiene i dati delle ACL di un file.
+
+ \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{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
+ \item[\errcode{ENOTSUP}] il filesystem cui fa riferimento il file non
+ supporta le ACL.
+ \end{errlist}
+ ed inoltre \errval{EBADF} per \func{acl\_get\_fd}, ed \errval{EINVAL} per
+ valori scorretti di \param{type} e tutti i possibili errori per l'accesso ad
+ un file per \func{acl\_get\_file}.
+
+}
+\end{functions}
+
+Le due funzioni ritornano, con un oggetto di tipo \type{acl\_t}, il valore
+della ACL correntemente associata ad un file, che può essere identificato
+tramite un file descriptor usando \func{acl\_get\_fd} o con un pathname usando
+\func{acl\_get\_file}. Nel caso di quest'ultima 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 tab.~\ref{tab:acl_type}.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}{|l|l|}
+ \hline
+ \textbf{Tipo} & \textbf{Descrizione} \\
+ \hline
+ \hline
+ \const{ACL\_TYPE\_ACCESS} & indica una ACL di accesso.\\
+ \const{ACL\_TYPE\_DEFAULT}& indica una ACL di default.\\
+ \hline
+ \end{tabular}
+ \caption{Le costanti che identificano il tipo di ACL.}
+ \label{tab:acl_type}
+\end{table}
+
+Si tenga presente che nel caso di \func{acl\_get\_file} occorrerà che il
+processo chiamante abbia privilegi di accesso sufficienti a poter leggere gli
+attributi estesi dei file (come illustrati in sez.~\ref{sec:file_xattr});
+inoltre una ACL di tipo \const{ACL\_TYPE\_DEFAULT} potrà essere richiesta
+soltanto per una directory, e verrà restituita solo se presente, altrimenti
+verrà restituita una ACL vuota.
+
+Infine si potrà creare una ACL direttamente dalla sua rappresentazione
+testuale con la funzione \funcd{acl\_from\_text}, il cui prototipo è:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/acl.h}
+
+ \funcdecl{acl\_t acl\_from\_text(const char *buf\_p)}
+
+ Crea una ACL a partire dalla sua rappresentazione testuale.
+
+ \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{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
+ \item[\errcode{EINVAL}] la rappresentazione testuale all'indirizzo
+ \param{buf\_p} non è valida.
+ \end{errlist}
+
+}
+\end{functions}
+
+La funzione prende come argomento il puntatore ad un buffer dove si è inserita
+la rappresentazione testuale della ACL che si vuole creare, la memoria
+necessaria viene automaticamente allocata ed in caso di successo viene
+restituito come valore di ritorno un oggetto di tipo \type{acl\_t} con il
+contenuto della stessa, che come per le precedenti funzioni, dovrà essere
+disallocato esplicitamente al termine del suo utilizzo.
+
+La rappresentazione testuale di una ACL è quella usata anche dai comandi
+ordinari per la gestione delle ACL (\texttt{getfacl} e \texttt{setfacl}), che
+prevede due diverse forme, estesa e breve, entrambe supportate da
+\func{acl\_from\_text}. La forma estesa prevede che sia specificata una voce
+per riga, nella forma:
+\begin{Verbatim}
+ tipo:qualificatore:permessi
+\end{Verbatim}
+dove il tipo può essere uno fra \texttt{user}, \texttt{group}, \texttt{other}
+e \texttt{mask}. Il qualificatore è presente solo per \texttt{user} e
+\texttt{group} e indica l'utente o il gruppo a cui la voce si riferisce; i
+permessi sono espressi con una tripletta di lettere analoga a quella usata per
+i permessi dei file.\footnote{vale a dire \texttt{r} per il permesso di
+ lettura, \texttt{w} per il permesso di scrittura, \texttt{x} per il permesso
+ di esecuzione (scritti in quest'ordine) e \texttt{-} per l'assenza del
+ permesso.}
+
+Va precisato che i due tipi \texttt{user} e \texttt{group} sono usati
+rispettivamente per indicare delle voci relative ad utenti e
+gruppi,\footnote{cioè per voci di tipo \const{ACL\_USER\_OBJ} e
+ \const{ACL\_USER} per \texttt{user} e \const{ACL\_GROUP\_OBJ} e
+ \const{ACL\_GROUP} per \texttt{group}.} applicate sia a quelli proprietari
+del file che a quelli generici; quelle dei proprietari si riconoscono per
+l'assenza di un qualificatore, ed in genere si scrivono per prima delle altre.
+Il significato delle voci di tipo \texttt{mask} e \texttt{mark} è evidente. In
+questa forma si possono anche inserire dei commenti precedendoli con il
+carattere ``\texttt{\#}''.
+
+La forma breve prevede invece la scrittura delle singole voci su una riga,
+separate da virgole; come specificatori del tipo di voce si possono usare le
+iniziali dei valori usati nella forma estesa (cioè ``\texttt{u}'',
+``\texttt{g}'', ``\texttt{o}'' e ``\texttt{m}''), mentre le altri parte della
+voce sono le stesse. In questo caso non sono consentiti permessi.
+
+Per la conversione inversa, che consente di ottenere la rappresentazione
+testuale di una ACL, sono invece disponibili due funzioni, la prima delle due,
+di uso più immediato, è \funcd{acl\_to\_text}, il cui prototipo è:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/acl.h}
+
+ \funcdecl{char * acl\_to\_text(acl\_t acl, ssize\_t *len\_p)}
+
+ Produce la rappresentazione testuale di una ACL.
+
+ \bodydesc{La funzione restituisce il puntatore ad una stringa con la
+ rappresentazione testuale della ACL 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{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
+ \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida.
+ \end{errlist}
+
+}
+\end{functions}
+
+La funzione restituisce il puntatore ad una stringa terminata da NUL
+contenente la rappresentazione in forma estesa della ACL passata come
+argomento, ed alloca automaticamente la memoria necessaria. Questa dovrà poi
+essere liberata, quando non più necessaria, con \func{acl\_free}. Se
+nell'argomento \param{len\_p} si passa un valore puntatore ad una variabile
+intera in questa verrà restituita la dimensione della stringa con la
+rappresentazione testuale (non comprendente il carattere nullo finale).
+
+La seconda funzione, \funcd{acl\_to\_any\_text}, permette di controllare con
+dovizia di dettagli la generazione della stringa contenente la
+rappresentazione testuale della ACL, il suo prototipo è:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/acl.h}
+
+ \funcdecl{char * acl\_to\_any\_text(acl\_t acl, const char *prefix, char
+ separator, int options)}
+
+ Produce la rappresentazione testuale di una ACL.
+
+ \bodydesc{La funzione restituisce il puntatore ad una stringa con la
+ rappresentazione testuale della ACL in caso di successo e \code{NULL} in
+ caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
+ \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida.
+ \end{errlist}
+
+}
+\end{functions}
+
+La funzione converte in formato testo la ACL indicata dall'argomento
+\param{acl}, usando il carattere \param{separator} come separatore delle
+singole voci; se l'argomento \param{prefix} non è nullo la stringa da esso
+indicata viene utilizzata come prefisso per le singole voci.
+
+L'ultimo argomento, \param{options}, consente di controllare la modalità con
+cui viene generata la rappresentazione testuale. Un valore nullo fa si che
+vengano usati gli identificatori standard \texttt{user}, \texttt{group},
+\texttt{other} e \texttt{mask} con i nomi di utenti e gruppi risolti rispetto
+ai loro valori numerici. Altrimenti si può specificare un valore in forma di
+maschera binaria, da ottenere con un OR aritmetico dei valori riportati in
+tab.~\ref{tab:acl_to_text_options}.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}{|l|p{8cm}|}
+ \hline
+ \textbf{Tipo} & \textbf{Descrizione} \\
+ \hline
+ \hline
+ \const{TEXT\_ABBREVIATE} & stampa le voci in forma abbreviata.\\
+ \const{TEXT\_NUMERIC\_IDS} & non effettua la risoluzione numerica di
+ user-ID e group-ID.\\
+ \const{TEXT\_SOME\_EFFECTIVE}& per ciascuna voce che contiene permessi che
+ vengono eliminati dalla \const{ACL\_MASK}
+ viene generato un commento con i permessi
+ effettivamente risultanti; il commento è
+ separato con un tabulatore.\\
+ \const{TEXT\_ALL\_EFFECTIVE} & viene generato un commento con i permessi
+ effettivi per ciascuna voce che contiene
+ permessi citati nella \const{ACL\_MASK},
+ anche quando questi non vengono modificati
+ da essa; il commento è separato con un
+ tabulatore.\\
+ \const{TEXT\_SMART\_INDENT} & da usare in combinazione con le precedenti
+ \const{TEXT\_SOME\_EFFECTIVE} e
+ \const{TEXT\_ALL\_EFFECTIVE} aumenta
+ automaticamente il numero di spaziatori
+ prima degli eventuali commenti in modo da
+ mantenerli allineati.\\
+ \hline
+ \end{tabular}
+ \caption{Possibili valori per l'argomento \param{options} di
+ \func{acl\_to\_any\_text}.}
+ \label{tab:acl_to_text_options}
+\end{table}
+
+Come per \func{acl\_to\_text} anche in questo caso il buffer contenente la
+rappresentazione testuale dell'ACL, di cui la funzione restituisce
+l'indirizzo, viene allocato automaticamente, e dovrà essere esplicitamente
+disallocato con una chiamata ad \func{acl\_free}. Si tenga presente infine che
+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}
-% TODO trattare le ACL, la documentazione di sistema è nei pacchetti
+% TODO trattare le ACL, la documentazione di sistema è nei pacchetti
% libacl1-dev e acl
% vedi anche http://www.suse.de/~agruen/acl/linux-acls/online/
\subsection{La funzione \func{chroot}}
\label{sec:file_chroot}
-% TODO intrudurre nuova sezione sulle funzionalità di sicurezza avanzate, con
+% TODO introdurre nuova sezione sulle funzionalità di sicurezza avanzate, con
% dentro chroot SELinux e AppArmor ???
Benché non abbia niente a che fare con permessi, utenti e gruppi, la funzione
\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: ELOOP ENOSPC EIO pathname nlink stat vfat fsck EISDIR ENOENT cap
-% LocalWords: POSIX socket fifo sticky root nell'inode system call count crash
-% LocalWords: all'inode descriptor remove rename rmdir stdio glibc libc NFS DT
+% LocalWords: POSIX socket fifo sticky root system call count crash nell' init
+% LocalWords: descriptor remove rename rmdir stdio glibc libc NFS DT obj dup
% LocalWords: ENOTEMPTY EBUSY mount point EINVAL soft symbolic tab symlink fig
% LocalWords: dangling access chdir chmod chown creat exec lchown lstat mkdir
% LocalWords: mkfifo mknod opendir pathconf readlink truncate path buff size
% LocalWords: grub bootloader grep linux MAXSYMLINKS cat VFS sys dirname fcntl
-% LocalWords: dev l'inode umask IFREG IFBLK IFCHR IFIFO SVr sgid BSD SVID NULL
+% LocalWords: dev umask IFREG IFBLK IFCHR IFIFO SVr sgid BSD SVID NULL from to
% LocalWords: stream dirent EMFILE ENFILE dirfd SOURCE fchdir readdir struct
% LocalWords: EBADF namlen HAVE thread entry result value argument fileno ino
% LocalWords: name TYPE OFF RECLEN UNKNOWN REG SOCK CHR BLK type IFTODT DTTOIF
% LocalWords: DTYPE off reclen seekdir telldir void rewinddir closedir select
% LocalWords: namelist compar malloc qsort alphasort versionsort strcoll myls
% LocalWords: strcmp DirScan direntry while current working home shell pwd get
-% LocalWords: dell'inode getcwd ERANGE getwd change fd race condition tmpnam
+% LocalWords: getcwd ERANGE getwd change fd race condition tmpnam getfacl mark
% LocalWords: string tmpdir TMP tempnam pfx TMPNAME suid tmp EXCL tmpfile pid
% LocalWords: EINTR mktemp mkstemp stlib template filename XXXXXX OpenBSD buf
% LocalWords: mkdtemp fstat filedes nell'header padding ISREG ISDIR ISCHR IFMT
% LocalWords: IRWXO ext reiser capability FSETID mask capabilities chroot jail
% LocalWords: FTP Di filter reiserfs Attributes Solaris Posix FreeBSD libacl
% LocalWords: XFS SELinux namespace attribute security trusted Draft Modules
-% LocalWords: attributes mime ADMIN FOWNER libattr lattr getxattr lgetxattr
+% LocalWords: attributes mime ADMIN FOWNER libattr lattr getxattr lgetxattr of
% LocalWords: fgetxattr attr ssize ENOATTR ENOTSUP NUL setxattr lsetxattr list
-% LocalWords: fsetxattr flags XATTR REPLACE listxattr llistxattr flistxattr
-% LocalWords: removexattr lremovexattr fremovexattr attributename lacl
+% 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
projects / gapil.git / blobdiff