%% filedir.tex
%%
-%% Copyright (C) 2000-2014 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2015 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",
% NOTE articolo interessante:
% http://www.ibm.com/developerworks/linux/library/l-virtual-filesystem-switch/index.html?ca=dgr-lnxw97Linux-VFSdth-LXdW&S_TACT=105AGX59&S_CMP=GRlnxw97
-\itindbeg{Virtual~File~System}
+\itindbeg{Virtual~File~System~(VFS)}
Come illustrato brevemente in sez.~\ref{sec:file_arch_overview} in Linux il
concetto di \textit{everything is a file} è stato implementato attraverso il
sez.~\ref{sec:file_dir_creat_rem}).\\
\textsl{\code{rmdir}} & Rimuove una directory (vedi
sez.~\ref{sec:file_dir_creat_rem}).\\
- \textsl{\code{mknod}} & Crea un \index{file!speciali} file speciale (vedi
+ \textsl{\code{mknod}} & Crea un file speciale (vedi
sez.~\ref{sec:file_mknod}).\\
\textsl{\code{rename}} & Cambia il nome di un file (vedi
sez.~\ref{sec:link_symlink_rename}).\\
possono esserci negli oggetti a cui si applicano.
-\itindend{Virtual~File~System}
+\itindend{Virtual~File~System~(VFS)}
% NOTE: documentazione interessante:
% * sorgenti del kernel: Documentation/filesystems/vfs.txt
indicati con la stringa contenente il loro \textit{pathname}.
Normalmente un filesystem è contenuto su un disco o una partizione, ma come
-illustrato in sez.~\ref{sec:file_vfs_work} la struttura del
-\itindex{Virtual~File~System} \textit{Virtual File System} è estremamente
-flessibile e può essere usata anche per oggetti diversi da un disco. Ad
-esempio usando il \textit{loop device} si può montare un file qualunque (come
-l'immagine di un CD-ROM o di un floppy) che contiene l'immagine di un
-filesystem, inoltre alcuni tipi di filesystem, come \texttt{proc} o
-\texttt{sysfs} sono virtuali e non hanno un supporto che ne contenga i dati,
-che invece sono generati al volo ad ogni lettura, e passati indietro al kernel
-ad ogni scrittura.\footnote{costituiscono quindi un meccanismo di
- comunicazione, attraverso l'ordinaria interfaccia dei file, con il kernel.}
+illustrato in sez.~\ref{sec:file_vfs_work} la struttura del \textit{Virtual
+ File System} è estremamente flessibile e può essere usata anche per oggetti
+diversi da un disco. Ad esempio usando il \textit{loop device} si può montare
+un file qualunque (come l'immagine di un CD-ROM o di un floppy) che contiene
+l'immagine di un filesystem, inoltre alcuni tipi di filesystem, come
+\texttt{proc} o \texttt{sysfs} sono virtuali e non hanno un supporto che ne
+contenga i dati, che invece sono generati al volo ad ogni lettura, e passati
+indietro al kernel ad ogni scrittura.\footnote{costituiscono quindi un
+ meccanismo di comunicazione, attraverso l'ordinaria interfaccia dei file,
+ con il kernel.}
Il tipo di filesystem che si vuole montare è specificato
dall'argomento \param{filesystemtype}, che deve essere una delle stringhe
In Linux \param{mountflags} deve essere un intero a 32 bit; fino ai kernel
della serie 2.2.x i 16 più significativi avevano un valore riservato che
doveva essere specificato obbligatoriamente,\footnote{il valore era il
- \itindex{magic~number} \textit{magic number} \code{0xC0ED}, si può usare la
- costante \const{MS\_MGC\_MSK} per ottenere la parte di \param{mountflags}
- riservata al \textit{magic number}, mentre per specificarlo si può dare un
- OR aritmetico con la costante \const{MS\_MGC\_VAL}.} e si potevano usare
-solo i 16 meno significativi. Oggi invece, con un numero di opzioni superiore,
-sono utilizzati tutti e 32 i bit, ma qualora nei 16 più significativi sia
-presente detto valore, che non esprime una combinazione valida, esso viene
-ignorato. Il valore dell'argomento deve essere espresso come maschera binaria
-e i vari bit che lo compongono, detti anche \textit{mount flags}, devono
-essere impostati con un OR aritmetico dei valori dalle costanti riportate
-nell'elenco seguente:
+ \textit{magic number} \code{0xC0ED}, si può usare la costante
+ \const{MS\_MGC\_MSK} per ottenere la parte di \param{mountflags} riservata
+ al \textit{magic number}, mentre per specificarlo si può dare un OR
+ aritmetico con la costante \const{MS\_MGC\_VAL}.} e si potevano usare solo i
+16 meno significativi. Oggi invece, con un numero di opzioni superiore, sono
+utilizzati tutti e 32 i bit, ma qualora nei 16 più significativi sia presente
+detto valore, che non esprime una combinazione valida, esso viene ignorato. Il
+valore dell'argomento deve essere espresso come maschera binaria e i vari bit
+che lo compongono, detti anche \textit{mount flags}, devono essere impostati
+con un OR aritmetico dei valori dalle costanti riportate nell'elenco seguente:
\begin{basedescript}{\desclabelwidth{2.cm}\desclabelstyle{\nextlinelabel}}
\itindbeg{bind~mount}
nell'altro, visto che entrambi faranno riferimento agli stessi
\textit{inode}.
- Dal punto di vista del \itindex{Virtual~File~System} VFS l'operazione è
- analoga al montaggio di un filesystem proprio nel fatto che anche in questo
- caso si inserisce in corrispondenza della \textit{dentry} di \texttt{target}
- un diverso \itindex{inode} \textit{inode}, che stavolta, invece di essere
- quello della radice del filesystem indicato da un file di dispositivo, è
- quello di una directory già montata.
+ Dal punto di vista del VFS l'operazione è analoga al montaggio di un
+ filesystem proprio nel fatto che anche in questo caso si inserisce in
+ corrispondenza della \textit{dentry} di \texttt{target} un diverso
+ \itindex{inode} \textit{inode}, che stavolta, invece di essere quello della
+ radice del filesystem indicato da un file di dispositivo, è quello di una
+ directory già montata.
Si tenga presente che proprio per questo sotto \param{target} comparirà il
contenuto che è presente sotto \param{source} all'interno del filesystem in
una fra \const{MS\_PRIVATE}, \const{MS\_SHARED}, \const{MS\_SLAVE} e
\const{MS\_UNBINDABLE}.
+ % TODO trattare l'opzione \texttt{lazytime} introdotta con il kernel 4.0,
+ % vedi http://lwn.net/Articles/621046/
+
\item[\const{MS\_RELATIME}] Indica di effettuare l'aggiornamento degli
\textit{access time} sul filesystem soltanto quando questo risulti
antecedente il valore corrente del \textit{modification time} o del
\errval{ENOENT}, \errval{ENOMEM} nel loro significato generico. }
\end{funcproto}
-\footnotetext{più precisamente la \itindex{capabilities} capacità
- \const{CAP\_SYS\_ADMIN}, vedi sez.~\ref{sec:proc_capabilities}.}
+\footnotetext{più precisamente la capacità \const{CAP\_SYS\_ADMIN}, vedi
+ sez.~\ref{sec:proc_capabilities}.}
La funzione prende il nome della directory su cui il filesystem è montato e
non il file o il dispositivo che è stato montato,\footnote{questo è vero a
sullo stesso \itindex{mount~point} \textit{mount point} viene smontato quello
che è stato montato per ultimo. Si tenga presente che la funzione fallisce se
il filesystem è ``\textsl{occupato}'', cioè quando ci sono ancora dei file
-aperti sul filesystem, se questo contiene la \index{directory~di~lavoro}
-directory di lavoro di un qualunque processo o il \itindex{mount~point}
-\textit{mount point} di un altro filesystem.
+aperti sul filesystem, se questo contiene la directory di lavoro (vedi
+sez.~\ref{sec:file_work_dir}) di un qualunque processo o il
+\itindex{mount~point} \textit{mount point} di un altro filesystem.
Linux provvede inoltre una seconda funzione di sistema, \funcd{umount2}, che
consente un maggior controllo delle operazioni, come forzare lo smontaggio di
\begin{errlist}
\item[\errcode{EAGAIN}] si è chiamata la funzione con \const{MNT\_EXPIRE}
ed il filesystem non era occupato.
- \item[\errcode{EBUSY}] \param{target} è la \index{directory~di~lavoro}
- directory di lavoro di qualche processo, o contiene dei file aperti, o un
- altro mount point.
- \item[\errcode{EINVAL}] \param{target} non è un \itindex{mount~point}
- \textit{mount point} o si è usato \const{MNT\_EXPIRE} con
- \const{MNT\_FORCE} o \const{MNT\_DETACH} o si è specificato un flag non
- esistente.
+ \item[\errcode{EBUSY}] \param{target} è la directory di lavoro di qualche
+ processo, o contiene dei file aperti, o un altro \textit{mount point}.
+ \item[\errcode{EINVAL}] \param{target} non è un \textit{mount point} o si
+ è usato \const{MNT\_EXPIRE} con \const{MNT\_FORCE} o
+ \const{MNT\_DETACH} o si è specificato un flag non esistente.
\end{errlist}
e tutti gli altri valori visti per \func{umount} con lo stesso significato.}
\end{funcproto}
introdotta per evitare, per quei filesystem per il quale è prevista una
gestione diretta da parte degli utenti, come quelli basati su
FUSE,\footnote{il \textit{Filesystem in USEr space} (FUSE) è una delle più
- interessanti applicazioni del \itindex{Virtual~File~System} VFS che
- consente, tramite un opportuno modulo, di implementarne le funzioni in
- \textit{user space}, così da rendere possibile l'implementazione di un
- qualunque filesystem (con applicazioni di grande interesse come il
- filesystem cifrato \textit{encfs} o il filesystem di rete \textit{sshfs})
- che possa essere usato direttamente per conto degli utenti.} che si possano
-passare ai programmi che effettuano lo smontaggio dei filesystem, che in
-genere sono privilegiati ma consentono di agire solo sui propri \textit{mount
- point}, dei collegamenti simbolici che puntano ad altri \textit{mount
- point}, ottenendo così la possibilità di smontare qualunque filesystem.
+ interessanti applicazioni del VFS che consente, tramite un opportuno modulo,
+ di implementarne le funzioni in \textit{user space}, così da rendere
+ possibile l'implementazione di un qualunque filesystem (con applicazioni di
+ grande interesse come il filesystem cifrato \textit{encfs} o il filesystem
+ di rete \textit{sshfs}) che possa essere usato direttamente per conto degli
+ utenti.} che si possano passare ai programmi che effettuano lo smontaggio
+dei filesystem, che in genere sono privilegiati ma consentono di agire solo
+sui propri \textit{mount point}, dei collegamenti simbolici che puntano ad
+altri \textit{mount point}, ottenendo così la possibilità di smontare
+qualunque filesystem.
Altre due funzioni di sistema specifiche di Linux,\footnote{esse si trovano
non si potrebbe più rimuoverla.}
Data la pericolosità di questa operazione e la disponibilità dei collegamenti
-simbolici (che vedremo a breve) e dei \itindex{bind~mount} \textit{bind mount}
+simbolici (che vedremo a breve) e dei \textit{bind mount}
(già visti in sez.~\ref{sec:filesystem_mounting}) che possono fornire la
stessa funzionalità senza questi problemi, nel caso di Linux questa capacità è
stata completamente disabilitata, e al tentativo di creare un collegamento
directory che lo contiene e decrementa il numero di riferimenti nel relativo
\itindex{inode} \textit{inode}.\footnote{come per \func{link} queste due
operazioni sono effettuate all'interno della \textit{system call} in maniera
- atomica.} Nel caso di socket, fifo o file di dispositivo
-\index{file!di~dispositivo} rimuove il nome, ma come per i file normali i
-processi che hanno aperto uno di questi oggetti possono continuare ad
-utilizzarli. Nel caso di cancellazione di un collegamento simbolico, che
-consiste solo nel rimando ad un altro file, questo viene immediatamente
-eliminato.
+ atomica.} Nel caso di socket, fifo o file di dispositivo rimuove il nome, ma
+come per i file normali i processi che hanno aperto uno di questi oggetti
+possono continuare ad utilizzarli. Nel caso di cancellazione di un
+collegamento simbolico, che consiste solo nel rimando ad un altro file, questo
+viene immediatamente eliminato.
Per cancellare una voce in una directory è necessario avere il permesso di
scrittura su di essa, dato che si va a rimuovere una voce dal suo contenuto, e
quelle dei loro \textit{pathname} o di scrivere su \param{newpath}
se questa è una directory.
\item[\errcode{EBUSY}] o \param{oldpath} o \param{newpath} sono in uso da
- parte di qualche processo (come \index{directory~di~lavoro} directory di
- lavoro o come radice) o del sistema (come \itindex{mount~point}
- \textit{mount point}) ed il sistema non riesce a risolvere la situazione.
+ parte di qualche processo (come directory di lavoro o come radice) o del
+ sistema (come \textit{mount point}) ed il sistema non riesce a risolvere
+ la situazione.
\item[\errcode{EEXIST}] \param{newpath} è una directory già esistente e
non è vuota (anche \errcode{ENOTEMPTY}).
\item[\errcode{EINVAL}] \param{newpath} contiene un prefisso di
non è possibile trattarle come file ordinari e devono essere create
direttamente dal kernel attraverso una opportuna \textit{system
call}.\footnote{questo è quello che permette anche, attraverso l'uso del
- \itindex{Virtual~File~System} VFS, l'utilizzo di diversi formati per la
- gestione dei suddetti elenchi, dalle semplici liste a strutture complesse
- come alberi binari, hash, ecc. che consentono una ricerca veloce quando il
- numero di file è molto grande.} La funzione di sistema usata per creare una
-directory è \funcd{mkdir}, ed il suo prototipo è:
+ VFS, l'utilizzo di diversi formati per la gestione dei suddetti elenchi,
+ dalle semplici liste a strutture complesse come alberi binari, hash,
+ ecc. che consentono una ricerca veloce quando il numero di file è molto
+ grande.} La funzione di sistema usata per creare una directory è
+\funcd{mkdir}, ed il suo prototipo è:
\begin{funcproto}{
\fhead{sys/stat.h}
che contiene la directory che si vuole cancellare, o non c'è il permesso
di attraversare (esecuzione) una delle directory specificate in
\param{dirname}.
- \item[\errcode{EBUSY}] la directory specificata è la
- \index{directory~di~lavoro} directory di lavoro o la radice di qualche
- processo o un \itindex{mount~point} \textit{mount point}.
+ \item[\errcode{EBUSY}] la directory specificata è la directory di lavoro o
+ la radice di qualche processo o un \textit{mount point}.
\item[\errcode{EINVAL}] si è usato ``\texttt{.}'' come ultimo componente
di \param{dirname}.
\item[\errcode{EPERM}] il filesystem non supporta la cancellazione di
in sez.~\ref{sec:file_open_close} che è possibile aprire una directory come se
fosse un file, anche se solo in sola lettura) in generale il formato con cui
esse sono scritte può dipendere dal tipo di filesystem, tanto che, come
-riportato in tab.~\ref{tab:file_file_operations}, il
-\itindex{Virtual~File~System} VFS prevede una apposita funzione per la lettura
-delle directory.
+riportato in tab.~\ref{tab:file_file_operations}, il VFS prevede una apposita
+funzione per la lettura delle directory.
\itindbeg{directory~stream}
Si tenga presente che comunque la funzione opera associando il
\textit{directory stream} ad un opportuno file descriptor sottostante, sul
quale vengono compiute le operazioni. Questo viene sempre aperto impostando il
-flag di \itindex{close-on-exec} \textit{close-on-exec} (si ricordi quanto
-detto in sez.~\ref{sec:proc_exec}), così da evitare che resti aperto in caso
-di esecuzione di un altro programma.
+flag di \textit{close-on-exec} (si ricordi quanto detto in
+sez.~\ref{sec:proc_exec}), così da evitare che resti aperto in caso di
+esecuzione di un altro programma.
Nel caso in cui sia necessario conoscere il \textit{file descriptor} associato
ad un \textit{directory stream} si può usare la funzione
stream} \param{dir}. Di solito si utilizza questa funzione in abbinamento a
funzioni che operano sui file descriptor, ad esempio si potrà usare
\func{fstat} per ottenere le proprietà della directory, o \func{fchdir} per
-spostare su di essa la \index{directory~di~lavoro} directory di lavoro (vedi
+spostare su di essa la directory di lavoro (vedi
sez.~\ref{sec:file_work_dir}).
Viceversa se si è aperto un file descriptor corrispondente ad una directory è
utilizzato all'interno del proprio programma. In particolare dovrà essere
chiuso attraverso il \textit{directory stream} con \func{closedir} e non
direttamente. Si tenga presente inoltre che \func{fdopendir} non modifica lo
-stato di un eventuale flag di \itindex{close-on-exec} \textit{close-on-exec},
-che pertanto dovrà essere impostato esplicitamente in fase di apertura del
-file descriptor.
+stato di un eventuale flag di \textit{close-on-exec}, che pertanto dovrà
+essere impostato esplicitamente in fase di apertura del file descriptor.
Una volta che si sia aperto un \textit{directory stream} la lettura del
contenuto della directory viene effettuata attraverso la funzione
una struttura allocata staticamente, che 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, \funcd{readdir\_r},\footnote{per usarla è necessario definire una
- qualunque delle macro \texttt{\macro{\_POSIX\_C\_SOURCE} >= 1},
+Di questa funzione esiste anche una versione rientrante,
+\funcd{readdir\_r},\footnote{per usarla è necessario definire una qualunque
+ delle macro \texttt{\macro{\_POSIX\_C\_SOURCE} >= 1},
\macro{\_XOPEN\_SOURCE}, \macro{\_BSD\_SOURCE}, \macro{\_SVID\_SOURCE},
\macro{\_POSIX\_SOURCE}.} che non usa una struttura allocata staticamente, e
può essere utilizzata anche con i \itindex{thread} \textit{thread}, il suo
18-22}) uno \textit{stream} sulla directory passata come primo argomento,
stampando un messaggio in caso di errore.
-Il passo successivo (\texttt{\small 23-24}) è cambiare
-\index{directory~di~lavoro} directory di lavoro (vedi
-sez.~\ref{sec:file_work_dir}), usando in sequenza le funzioni \func{dirfd} e
-\func{fchdir} (in realtà si sarebbe potuto usare direttamente \func{chdir} su
-\var{dirname}), in modo che durante il successivo ciclo (\texttt{\small
- 26-30}) sulle singole voci dello \textit{stream} ci si trovi all'interno
-della directory.\footnote{questo è essenziale al funzionamento della funzione
- \code{do\_ls}, e ad ogni funzione che debba usare il campo \var{d\_name}, in
- quanto i nomi dei file memorizzati all'interno di una struttura
- \struct{dirent} sono sempre relativi alla directory in questione, e senza
- questo posizionamento non si sarebbe potuto usare \func{stat} per ottenere
- le dimensioni.}
+Il passo successivo (\texttt{\small 23-24}) è cambiare directory di lavoro
+(vedi sez.~\ref{sec:file_work_dir}), usando in sequenza le funzioni
+\func{dirfd} e \func{fchdir} (in realtà si sarebbe potuto usare direttamente
+\func{chdir} su \var{dirname}), in modo che durante il successivo ciclo
+(\texttt{\small 26-30}) sulle singole voci dello \textit{stream} ci si trovi
+all'interno della directory.\footnote{questo è essenziale al funzionamento
+ della funzione \code{do\_ls}, e ad ogni funzione che debba usare il campo
+ \var{d\_name}, in quanto i nomi dei file memorizzati all'interno di una
+ struttura \struct{dirent} sono sempre relativi alla directory in questione,
+ e senza questo posizionamento non si sarebbe potuto usare \func{stat} per
+ ottenere le dimensioni.}
Avendo usato lo stratagemma di fare eseguire tutte le manipolazioni necessarie
alla funzione passata come secondo argomento, il ciclo di scansione della
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
-\itindex{capabilities} \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.
+dispositivo usando questa funzione (il processo deve avere la capacità
+\const{CAP\_MKNOD}), ma in Linux\footnote{questo è un comportamento specifico
+ di Linux, la funzione non è prevista dallo standard POSIX.1 originale,
+ mentre è presente in SVr4 e 4.4BSD, ma esistono differenze nei comportamenti
+ e nei codici di errore, tanto che questa è stata introdotta in POSIX.1-2001
+ con una nota che la definisce portabile solo quando viene usata per creare
+ delle fifo, ma comunque deprecata essendo utilizzabile a tale scopo la
+ specifica \func{mkfifo}.} l'uso per la creazione di un file ordinario, di
+una fifo o di un socket è consentito anche agli utenti normali.
I nuovi \itindex{inode} \textit{inode} creati con \func{mknod} apparterranno
al proprietario e al gruppo del processo (usando \ids{UID} e \ids{GID} del
\const{L\_tmpnam}, \const{P\_tmpdir} e \const{TMP\_MAX} sono definite in
\headfile{stdio.h}.}
-Di questa funzione esiste una versione \index{funzioni!rientranti} rientrante,
+Di questa funzione esiste una versione \ rientrante,
\funcm{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 è:
\end{funcproto}
La funzione alloca con \code{malloc} la stringa in cui restituisce il nome,
-per cui è sempre \index{funzioni!rientranti} rientrante, occorre però
+per cui è sempre \ 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,
che viene automaticamente cancellato alla sua chiusura o all'uscita dal
programma. Lo standard non specifica in quale directory verrà aperto il file,
ma la \acr{glibc} prima tenta con \const{P\_tmpdir} e poi con
-\file{/tmp}. Questa funzione è \index{funzioni!rientranti} rientrante e non
-soffre di problemi di \itindex{race~condition} \textit{race condition}.
+\file{/tmp}. Questa funzione è 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
\var{st\_size} non è detto che corrisponda all'occupazione dello spazio su
disco, e non solo perché la parte finale del file potrebbe riempire
parzialmente un blocco. In un sistema unix-like infatti è possibile
-l'esistenza dei cosiddetti \itindex{sparse~file} \textit{sparse file}, cioè
-file in cui sono presenti dei ``\textsl{buchi}'' \index{file!\textit{hole}}
-(\textit{holes} nella nomenclatura inglese) che si formano tutte le volte che
-si va a scrivere su un file dopo aver eseguito uno spostamento oltre la sua
-fine (tratteremo in dettaglio l'argomento in sez.~\ref{sec:file_lseek}).
+l'esistenza dei cosiddetti \textit{sparse file}, cioè file in cui sono
+presenti dei ``\textsl{buchi}'' (\textit{holes} nella nomenclatura inglese)
+che si formano tutte le volte che si va a scrivere su un file dopo aver
+eseguito uno spostamento oltre la sua fine (tratteremo in dettaglio
+l'argomento in sez.~\ref{sec:file_lseek}).
In questo caso si avranno risultati differenti a seconda del modo in cui si
calcola la lunghezza del file, ad esempio il comando \cmd{du}, (che riporta il
numero di blocchi occupati) potrà dare una dimensione inferiore, mentre se si
legge dal file (ad esempio usando il comando \cmd{wc -c}), dato che in tal
-caso per i ``\textsl{buchi}'' \index{file!\textit{hole}} vengono restituiti
-degli zeri, si avrà lo stesso risultato di \cmd{ls}.
+caso per i ``\textsl{buchi}'' vengono restituiti degli zeri, si avrà lo stesso
+risultato di \cmd{ls}.
Se è sempre possibile allargare un file, scrivendoci sopra o usando la
funzione \func{lseek} (vedi sez.~\ref{sec:file_lseek}) per spostarsi oltre la
Il comportamento in caso di lunghezza del file inferiore a \param{length} non
è specificato e dipende dall'implementazione: il file può essere lasciato
invariato o esteso fino alla lunghezza scelta. Nel caso di Linux viene esteso
-con la creazione di un \index{file!\textit{hole}} \textsl{buco} nel
-\itindex{sparse~file} file e ad una lettura si otterranno degli zeri, si tenga
-presente però che questo comportamento è supportato solo per filesystem
-nativi, ad esempio su un filesystem non nativo come il VFAT di Windows questo
-non è possibile.
+con la creazione di un \textsl{buco} nel file e ad una lettura si otterranno
+degli zeri, si tenga presente però che questo comportamento è supportato solo
+per filesystem nativi, ad esempio su un filesystem non nativo come il VFAT di
+Windows questo non è possibile.
\subsection{I tempi dei file}
campi della struttura \struct{stat} è illustrato nello schema di
tab.~\ref{tab:file_file_times}, dove è anche riportato un esempio delle
funzioni che effettuano cambiamenti su di essi. Il valore del tempo è espresso
-nel cosiddetto \itindex{calendar~time} \textit{calendar time}, su cui
-torneremo in dettaglio in sez.~\ref{sec:sys_time}.
+nel cosiddetto \textit{calendar time}, su cui torneremo in dettaglio in
+sez.~\ref{sec:sys_time}.
\begin{table}[htb]
\centering
proprietari del file o avere i privilegi di amministratore. Se invece si è
specificato un valore diverso la funzione avrà successo solo se si è
proprietari del file o se si hanno i privilegi di amministratore.\footnote{per
- essere precisi la \itindex{capabilities} capacità \const{CAP\_FOWNER}, vedi
+ essere precisi la capacità \const{CAP\_FOWNER}, vedi
sez.~\ref{sec:proc_capabilities}.} In entrambi i casi per verificare la
proprietà del file viene utilizzato l'\ids{UID} effettivo del processo.
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 \index{file!di~dispositivo} file di dispositivo,
-scrivendo direttamente sul disco senza passare attraverso il filesystem, ma
-ovviamente in questo modo la cosa è più complicata da
-realizzare.\footnote{esistono comunque molti programmi che consentono di farlo
- con relativa semplicità per cui non si dia per scontato che il valore sia
- credibile in caso di macchina compromessa.}
+grado di accedere al file di dispositivo, scrivendo direttamente sul disco
+senza passare attraverso il filesystem, ma ovviamente in questo modo la cosa è
+più complicata da realizzare.\footnote{esistono comunque molti programmi che
+ consentono di farlo con relativa semplicità per cui non si dia per scontato
+ che il valore sia credibile in caso di macchina compromessa.}
A partire dal kernel 2.6 la risoluzione dei tempi dei file, che nei campi di
tab.~\ref{tab:file_file_times} è espressa in secondi, è stata portata ai
Torneremo su questa sintassi e sulla sua motivazione in
sez.~\ref{sec:file_openat}, quando tratteremo tutte le altre funzioni (le
-cosiddette \itindex{at-functions} \textit{at-functions}) che la utilizzano;
-essa prevede comunque anche la presenza dell'argomento \param{flags} con cui
-attivare flag di controllo che modificano il comportamento della funzione, nel
-caso specifico l'unico valore consentito è \const{AT\_SYMLINK\_NOFOLLOW} che
-indica alla funzione di non dereferenziare i collegamenti simbolici, cosa che
-le permette di riprodurre le funzionalità di \func{lutimes}.
+cosiddette \textit{at-functions}) che la utilizzano; essa prevede comunque
+anche la presenza dell'argomento \param{flags} con cui attivare flag di
+controllo che modificano il comportamento della funzione, nel caso specifico
+l'unico valore consentito è \const{AT\_SYMLINK\_NOFOLLOW} che indica alla
+funzione di non dereferenziare i collegamenti simbolici, cosa che le permette
+di riprodurre le funzionalità di \func{lutimes}.
Il controllo di accesso ai file segue un modello abbastanza semplice che
prevede tre permessi fondamentali strutturati su tre livelli di accesso.
-Esistono varie estensioni a questo modello,\footnote{come le
- \itindex{Access~Control~List~(ACL)} \textit{Access Control List} che sono
- state aggiunte ai filesystem standard con opportune estensioni (vedi
- sez.~\ref{sec:file_ACL}) per arrivare a meccanismi di controllo ancora più
- sofisticati come il \itindex{Mandatory~Access~Control~(MAC)}
- \textit{mandatory access control} di SE-Linux e delle altre estensioni come
- \textit{Smack} o \textit{AppArmor}.} ma nella maggior parte dei casi il
-meccanismo standard è più che sufficiente a soddisfare tutte le necessità più
-comuni. I tre permessi di base associati ad ogni file sono:
+Esistono varie estensioni a questo modello,\footnote{come le \textit{Access
+ Control List} che sono state aggiunte ai filesystem standard con opportune
+ estensioni (vedi sez.~\ref{sec:file_ACL}) per arrivare a meccanismi di
+ controllo ancora più sofisticati come il \textit{Mandatory Access Control}
+ di \textit{SELinux} e delle altre estensioni come \textit{Smack} o
+ \textit{AppArmor}.} ma nella maggior parte dei casi il meccanismo standard è
+più che sufficiente a soddisfare tutte le necessità più comuni. I tre
+permessi di base associati ad ogni file sono:
\begin{itemize*}
\item il permesso di lettura (indicato con la lettera \texttt{r}, dall'inglese
\textit{read}).
per cui a differenza dei permessi ordinari esse varranno per qualunque utente
compreso l'amministratore. L'amministratore è l'unico che può attivare o
disattivare questi attributi,\footnote{più precisamente un processo con la
- \itindex{capabilities} capacità \const{CAP\_LINUX\_IMMUTABLE}, vedi
+ capacità \const{CAP\_LINUX\_IMMUTABLE}, vedi
sez.~\ref{sec:proc_capabilities}.} e potendo rimuoverli è comunque capace di
tornare in grado di eseguire qualunque operazione su un file immutabile o
\textit{append-only}.
\itindex{race~condition} \textit{race condition} che apre ad un possibile
\itindex{symlink~attack} \textit{symlink attack} fra il controllo e l'apertura
del file. In questo caso è sempre opportuno usare invece la funzione
-\func{faccessat} che tratteremo insieme alle altre \itindex{at-functions}
-\textit{at-functions} in sez.~\ref{sec:file_openat}.
+\func{faccessat} che tratteremo insieme alle altre \textit{at-functions} in
+sez.~\ref{sec:file_openat}.
Del tutto analoghe a \func{access} sono le due funzioni \funcm{euidaccess} e
\funcm{eaccess} che ripetono lo stesso controllo usando però gli
\acr{suid} e \acr{sgid}; essa consiste nel cancellare automaticamente questi
bit dai permessi di un file qualora un processo che non appartenga
all'amministratore\footnote{per la precisione un processo che non dispone
- della \itindex{capabilities} capacità \const{CAP\_FSETID}, vedi
- sez.~\ref{sec:proc_capabilities}.} effettui una scrittura. In questo modo
-anche se un utente malizioso scopre un file \acr{suid} su cui può scrivere,
-un'eventuale modifica comporterà la perdita di questo privilegio.
+ della capacità \const{CAP\_FSETID}, vedi sez.~\ref{sec:proc_capabilities}.}
+effettui una scrittura. In questo modo anche se un utente malizioso scopre un
+file \acr{suid} su cui può scrivere, un'eventuale modifica comporterà la
+perdita di questo privilegio.
Le funzioni \func{chmod} e \func{fchmod} ci permettono di modificare i
permessi di un file, resta però il problema di quali sono i permessi assegnati
Le funzioni cambiano utente e gruppo di appartenenza di un file ai valori
specificati dalle variabili \param{owner} e \param{group}. Con Linux solo
-l'amministratore\footnote{o in generale un processo con la
- \itindex{capabilities} capacità \const{CAP\_CHOWN}, vedi
- sez.~\ref{sec:proc_capabilities}.} può cambiare il proprietario di un file;
-in questo viene seguita la semantica usata da BSD che non consente agli utenti
-di assegnare i loro file ad altri utenti evitando eventuali aggiramenti delle
-quote. L'amministratore può cambiare sempre il gruppo di un file, il
-proprietario può cambiare il gruppo solo dei file che gli appartengono e solo
-se il nuovo gruppo è il suo gruppo primario o uno dei gruppi di cui fa parte.
+l'amministratore\footnote{o in generale un processo con la capacità
+ \const{CAP\_CHOWN}, vedi sez.~\ref{sec:proc_capabilities}.} può cambiare il
+proprietario di un file; in questo viene seguita la semantica usata da BSD che
+non consente agli utenti di assegnare i loro file ad altri utenti evitando
+eventuali aggiramenti delle quote. L'amministratore può cambiare sempre il
+gruppo di un file, il proprietario può cambiare il gruppo solo dei file che
+gli appartengono e solo se il nuovo gruppo è il suo gruppo primario o uno dei
+gruppi di cui fa parte.
La funzione \func{chown} segue i collegamenti simbolici, per operare
direttamente su un collegamento simbolico si deve usare la funzione
notazione illustrata in fig.~\ref{fig:file_perm_bit}.
Si ricordi infine che i permessi non hanno alcun significato per i
-collegamenti simbolici, mentre per i \index{file!di~dispositivo} file di
-dispositivo hanno senso soltanto i permessi di lettura e scrittura, che si
-riflettono sulla possibilità di compiere dette operazioni sul dispositivo
-stesso.
+collegamenti simbolici, mentre per i file di dispositivo hanno senso soltanto
+i permessi di lettura e scrittura, che si riflettono sulla possibilità di
+compiere dette operazioni sul dispositivo stesso.
Nella tabella si è indicato con il carattere ``-'' il fatto che il valore del
bit in questione non è influente rispetto a quanto indicato nella riga della
Linux) hanno introdotto un meccanismo generico, detto \textit{Extended
Attributes} che consente di associare delle informazioni ulteriori ai
singoli file.\footnote{essi ad esempio vengono usati per le ACL, che
- tratteremo in sez.~\ref{sec:file_ACL} e le \itindex{file~capabilities}
- \textit{file capabilities}, che vedremo in
- sez.~\ref{sec:proc_capabilities}.} Gli \textsl{attributi estesi} non sono
-altro che delle coppie nome/valore che sono associate permanentemente ad un
-oggetto sul filesystem, analoghi di quello che sono le variabili di ambiente
-(vedi sez.~\ref{sec:proc_environ}) per un processo.
+ tratteremo in sez.~\ref{sec:file_ACL} e le \textit{file capabilities}, che
+ vedremo in sez.~\ref{sec:proc_capabilities}.} Gli \textsl{attributi estesi}
+non sono altro che delle coppie nome/valore che sono associate permanentemente
+ad un oggetto sul filesystem, analoghi di quello che sono le variabili di
+ambiente (vedi sez.~\ref{sec:proc_environ}) per un processo.
Altri sistemi (come Solaris, MacOS e Windows) hanno adottato un meccanismo
diverso in cui ad un file sono associati diversi flussi di dati, su cui
\hline
\texttt{security}&Gli \textit{extended security attributes}: vengono
utilizzati dalle estensioni di sicurezza del kernel (i
- \itindex{Linux~Security~Modules} \textit{Linux
- Security Modules}), per le realizzazione di meccanismi
- evoluti di controllo di accesso come \index{SELinux}
- SELinux o le \textit{capabilities} dei file di
- sez.~\ref{sec:proc_capabilities}.\\
+ \textit{Linux Security Modules}), per le realizzazione
+ di meccanismi evoluti di controllo di accesso come
+ \textit{SELinux} o le \textit{capabilities} dei
+ file di sez.~\ref{sec:proc_capabilities}.\\
\texttt{system} & Gli \textit{extended security attributes}: sono usati
dal kernel per memorizzare dati di sistema associati ai
- file come le \itindex{Access~Control~List~(ACL)} ACL (vedi
- sez.~\ref{sec:file_ACL}) o le \itindex{capabilities}
+ file come le ACL (vedi sez.~\ref{sec:file_ACL}) o le
\textit{capabilities} (vedi
sez.~\ref{sec:proc_capabilities}).\\
\texttt{trusted}& I \textit{trusted extended attributes}: vengono
Dato che uno degli usi degli \textit{Extended Attributes} è di impiegarli per
-realizzare delle estensioni (come le \itindex{Access~Control~List~(ACL)} 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 che 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:
+realizzare delle estensioni (come le ACL, \textit{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 che
+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{1.7cm}\desclabelstyle{\nextlinelabel}}
\item[\texttt{security}] L'accesso agli \textit{extended security attributes}
dipende dalle politiche di sicurezza stabilite da loro stessi tramite
- l'utilizzo di un sistema di controllo basato sui
- \itindex{Linux~Security~Modules} \textit{Linux Security Modules} (ad esempio
- \index{SELinux} SELinux). Pertanto l'accesso in lettura o scrittura dipende
- dalle politiche di sicurezza implementate all'interno dal modulo di
- sicurezza che si sta utilizzando al momento (ciascuno avrà le sue). Se non è
- stato caricato nessun modulo di sicurezza l'accesso in lettura sarà
- consentito a tutti i processi, mentre quello in scrittura solo ai processi
- con privilegi amministrativi dotati della \itindex{capabilities}
- \textit{capability} \const{CAP\_SYS\_ADMIN}.
+ l'utilizzo di un sistema di controllo basato sui \textit{Linux Security
+ Modules} (ad esempio \textit{SELinux}). Pertanto l'accesso in lettura o
+ scrittura dipende dalle politiche di sicurezza implementate all'interno dal
+ modulo di sicurezza che si sta utilizzando al momento (ciascuno avrà le
+ sue). Se non è stato caricato nessun modulo di sicurezza l'accesso in
+ lettura sarà consentito a tutti i processi, mentre quello in scrittura solo
+ ai processi con privilegi amministrativi dotati della capacità
+ \const{CAP\_SYS\_ADMIN}.
\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 \itindex{Access~Control~List~(ACL)} 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} \itindex{capabilities}
+ delle ACL (vedi sez.~\ref{sec:file_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 capacità
\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
- privilegi amministrativi dotati della \itindex{capabilities}
- \textit{capability} \const{CAP\_SYS\_ADMIN}. In questo modo si possono
- utilizzare questi attributi per realizzare in user space dei meccanismi di
- controllo che accedono ad informazioni non disponibili ai processi ordinari.
+ privilegi amministrativi dotati della capacità \const{CAP\_SYS\_ADMIN}. In
+ questo modo si possono utilizzare questi attributi per realizzare in user
+ space dei meccanismi di controllo che accedono ad informazioni non
+ disponibili ai processi ordinari.
\item[\texttt{user}] L'accesso agli \textit{extended user attributes} è
regolato dai normali permessi dei file: occorre avere il permesso di lettura
directory ordinarie, se valesse in generale infatti si avrebbe un serio
problema di sicurezza dato che esistono diversi oggetti sul filesystem per i
quali è normale avere avere il permesso di scrittura consentito a tutti gli
- utenti, come i collegamenti simbolici, o alcuni \index{file!di~dispositivo}
- file di dispositivo come \texttt{/dev/null}. Se fosse possibile usare su di
- essi gli \textit{extended user attributes} un utente qualunque potrebbe
- inserirvi dati a piacere.\footnote{la cosa è stata notata su XFS, dove
- questo comportamento permetteva, non essendovi limiti sullo spazio
- occupabile dagli \textit{Extended Attributes}, di bloccare il sistema
- riempiendo il disco.}
+ utenti, come i collegamenti simbolici, o alcuni file di dispositivo come
+ \texttt{/dev/null}. Se fosse possibile usare su di essi gli \textit{extended
+ user attributes} un utente qualunque potrebbe inserirvi dati a
+ piacere.\footnote{la cosa è stata notata su XFS, dove questo comportamento
+ permetteva, non essendovi limiti sullo spazio occupabile dagli
+ \textit{Extended Attributes}, di bloccare il sistema riempiendo il disco.}
La semantica del controllo di accesso indicata inoltre non avrebbe alcun
senso al di fuori di file e directory: i permessi di lettura e scrittura per
- un \index{file!di~dispositivo} file di dispositivo attengono alle capacità
- di accesso al dispositivo sottostante,\footnote{motivo per cui si può
- formattare un disco anche se \texttt{/dev} è su un filesystem in sola
- lettura.} mentre per i collegamenti simbolici questi vengono semplicemente
- ignorati: in nessuno dei due casi hanno a che fare con il contenuto del
- file, e nella discussione relativa all'uso degli \textit{extended user
- attributes} nessuno è mai stato capace di indicare una qualche forma
- sensata di utilizzo degli stessi per collegamenti simbolici o
- \index{file!di~dispositivo} file di dispositivo, e neanche per le fifo o i
+ un file di dispositivo attengono alle capacità di accesso al dispositivo
+ sottostante,\footnote{motivo per cui si può formattare un disco anche se
+ \texttt{/dev} è su un filesystem in sola lettura.} mentre per i
+ collegamenti simbolici questi vengono semplicemente ignorati: in nessuno dei
+ due casi hanno a che fare con il contenuto del file, e nella discussione
+ relativa all'uso degli \textit{extended user attributes} nessuno è mai stato
+ capace di indicare una qualche forma sensata di utilizzo degli stessi per
+ collegamenti simbolici o file di dispositivo, e neanche per le fifo o i
socket. Per questo motivo essi sono stati completamente disabilitati per
tutto ciò che non sia un file regolare o una directory.\footnote{si può
verificare la semantica adottata consultando il file \texttt{fs/xattr.c}
per evitare eventuali abusi, se una directory ha lo \itindex{sticky~bit}
\textit{sticky bit} attivo sarà consentito scrivere i suoi \textit{extended
user attributes} soltanto se si è proprietari della stessa, o si hanno i
- privilegi amministrativi della capacità \itindex{capabilities}
- \const{CAP\_FOWNER}.
+ privilegi amministrativi della capacità \const{CAP\_FOWNER}.
\end{basedescript}
Le funzioni per la gestione degli attributi estesi, come altre funzioni di
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 capacità \itindex{capabilities} \const{CAP\_FOWNER}.
+la capacità \const{CAP\_FOWNER}.
\begin{table}[htb]
\centering
\begin{enumerate}
\item Se l'\ids{UID} del processo è nullo (se cioè si è l'amministratore)
l'accesso è sempre garantito senza nessun controllo.\footnote{più
- precisamente se si devono avere le \itindex{capabilities} capacità
- \const{CAP\_DAC\_OVERRIDE} per i file e \const{CAP\_DAC\_READ\_SEARCH} per
- le directory, vedi sez.~\ref{sec:proc_capabilities}.}
+ precisamente se si devono avere le capacità \const{CAP\_DAC\_OVERRIDE} per
+ i file e \const{CAP\_DAC\_READ\_SEARCH} per le directory, vedi
+ sez.~\ref{sec:proc_capabilities}.}
\item Se l'\ids{UID} del processo corrisponde al proprietario del file allora:
\begin{itemize*}
\item se la voce \const{ACL\_USER\_OBJ} contiene il permesso richiesto,
operazioni di attivazione, disattivazione e di modifica dei limiti delle quote
sono riservate e richiedono i privilegi di amministratore.\footnote{per essere
precisi tutte le operazioni indicate come privilegiate in
- tab.~\ref{tab:quotactl_commands} richiedono la \textit{capability}
+ tab.~\ref{tab:quotactl_commands} richiedono la capacità
\const{CAP\_SYS\_ADMIN}.} Inoltre gli utenti possono soltanto richiedere i
dati relativi alle proprie quote, solo l'amministratore può ottenere i dati di
tutti.
gestione dei privilegi in un sistema unix-like ha il sostanziale problema di
fornire all'amministratore dei poteri troppo ampi. Questo comporta che anche
quando si siano predisposte delle misure di protezione per in essere in grado
-di difendersi dagli effetti di una eventuale compromissione del
-sistema,\footnote{come montare un filesystem in sola lettura per impedirne
- modifiche, o marcare un file come immutabile.} una volta che questa sia
-stata effettuata e si siano ottenuti i privilegi di amministratore, queste
-misure potranno essere comunque rimosse.\footnote{nei casi elencati nella
- precedente nota si potrà sempre rimontare il sistema in lettura-scrittura, o
- togliere l'attributo di immutabilità.}
+di difendersi dagli effetti di una eventuale compromissione del sistema (come
+montare un filesystem in sola lettura per impedirne modifiche, o marcare un
+file come immutabile) una volta che questa sia stata effettuata e si siano
+ottenuti i privilegi di amministratore, queste misure potranno essere comunque
+rimosse (nei casi elencati nella precedente nota si potrà sempre rimontare il
+sistema in lettura-scrittura, o togliere l'attributo di immutabilità).
Il problema consiste nel fatto che nell'architettura tradizionale di un
sistema unix-like i controlli di accesso sono basati su un solo livello di
processi con i privilegi di amministratore essi non vengono neppure eseguiti.
Per questo motivo non era previsto alcun modo per evitare che un processo con
diritti di amministratore non potesse eseguire certe operazioni, o per cedere
-definitivamente alcuni privilegi da un certo momento in poi.
-
-Per ovviare a tutto ciò, a partire dai kernel della serie 2.2, è stato
+definitivamente alcuni privilegi da un certo momento in poi.
+
+Per risolvere questo problema sono possibili varie soluzioni ed ad esempio dai
+kernel 2.5 è stata introdotta la struttura dei
+\itindex{Linux~Security~Modules} \textit{Linux Security Modules} che han
+permesso di aggiungere varie forme di \itindex{Mandatory~Access~Control~(DAC)}
+\textit{Mandatory Access Control} (MAC), in cui si potessero parcellizzare e
+controllare nei minimi dettagli tutti i privilegi e le modalità in cui questi
+possono essere usati dai programmi e trasferiti agli utenti, con la creazione
+di varie estensioni (come \textit{SELinux}, \textit{Smack}, \textit{Tomoyo},
+\textit{AppArmor}) che consentono di superare l'architettura tradizionale dei
+permessi basati sul modello classico del controllo di accesso chiamato
+\itindex{Discrectionary~Access~Control~(DAC)} \textit{Discrectionary Access
+ Control} (DAC).
+
+Ma già in precedenza, a partire dai kernel della serie 2.2, era stato
introdotto un meccanismo, detto \textit{capabilities}, che consentisse di
suddividere i vari privilegi tradizionalmente associati all'amministratore in
un insieme di \textsl{capacità} distinte. L'idea era che queste capacità
\itindbeg{file~capabilities}
-Il meccanismo completo delle \textit{capabilities}\footnote{l'implementazione
- si rifà ad una bozza di quello che doveva diventare lo standard POSIX.1e,
- poi abbandonato.} prevede inoltre la possibilità di associare le stesse ai
-singoli file eseguibili, in modo da poter stabilire quali capacità possono
-essere utilizzate quando viene messo in esecuzione uno specifico programma; ma
-il supporto per questa funzionalità, chiamata \textit{file capabilities}, è
-stato introdotto soltanto a partire dal kernel 2.6.24. Fino ad allora doveva
-essere il programma stesso ad eseguire una riduzione esplicita delle sue
-capacità, cosa che ha reso l'uso di questa funzionalità poco diffuso, vista la
-presenza di meccanismi alternativi per ottenere limitazioni delle capacità
-dell'amministratore a livello di sistema operativo, come \index{SELinux}
-SELinux.
+Il meccanismo completo delle \textit{capabilities} (l'implementazione si rifà
+ad una bozza di quello che doveva diventare lo standard POSIX.1e, poi
+abbandonato) prevede inoltre la possibilità di associare le stesse ai singoli
+file eseguibili, in modo da poter stabilire quali capacità possono essere
+utilizzate quando viene messo in esecuzione uno specifico programma; ma il
+supporto per questa funzionalità, chiamata \textit{file capabilities}, è stato
+introdotto soltanto a partire dal kernel 2.6.24. Fino ad allora doveva essere
+il programma stesso ad eseguire una riduzione esplicita delle sue capacità,
+cosa che ha reso l'uso di questa funzionalità poco diffuso, vista la presenza
+di meccanismi alternativi per ottenere limitazioni delle capacità
+dell'amministratore a livello di sistema operativo, come \textit{SELinux}.
Con questo supporto e con le ulteriori modifiche introdotte con il kernel
2.6.25 il meccanismo delle \textit{capabilities} è stato totalmente
rivoluzionato, rendendolo più aderente alle intenzioni originali dello
standard POSIX, rimuovendo il significato che fino ad allora aveva avuto la
capacità \const{CAP\_SETPCAP} e cambiando le modalità di funzionamento del
-cosiddetto \itindex{capabilities~bounding~set} \textit{capabilities bounding
- set}. Ulteriori modifiche sono state apportate con il kernel 2.6.26 per
-consentire la rimozione non ripristinabile dei privilegi di
-amministratore. Questo fa sì che il significato ed il comportamento del kernel
-finisca per dipendere dalla versione dello stesso e dal fatto che le nuove
-\textit{file capabilities} siano abilitate o meno. Per capire meglio la
-situazione e cosa è cambiato conviene allora spiegare con maggiori dettagli
-come funziona il meccanismo delle \textit{capabilities}.
+cosiddetto \textit{capabilities bounding set}. Ulteriori modifiche sono state
+apportate con il kernel 2.6.26 per consentire la rimozione non ripristinabile
+dei privilegi di amministratore. Questo fa sì che il significato ed il
+comportamento del kernel finisca per dipendere dalla versione dello stesso e
+dal fatto che le nuove \textit{file capabilities} siano abilitate o meno. Per
+capire meglio la situazione e cosa è cambiato conviene allora spiegare con
+maggiori dettagli come funziona il meccanismo delle \textit{capabilities}.
Il primo passo per frazionare i privilegi garantiti all'amministratore,
supportato fin dalla introduzione iniziale del kernel 2.2, è stato quello in
\const{CAP\_AUDIT\_WRITE}&Scrivere dati nel giornale di
auditing del kernel (dal kernel 2.6.11).\\
% TODO verificare questa roba dell'auditing
+ \const{CAP\_BLOCK\_SUSPEND}&Utilizzare funzionalità che possono bloccare
+ la sospensione del sistema (dal kernel 3.5).\\
\const{CAP\_CHOWN} & Cambiare proprietario e gruppo
proprietario di un file (vedi
sez.~\ref{sec:file_ownership_management}).\\
sez.~\ref{sec:file_perm_management}).\\
\const{CAP\_KILL} & Mandare segnali a qualunque
processo (vedi sez.~\ref{sec:sig_kill_raise}).\\
- \const{CAP\_SETFCAP} & Impostare le
- \textit{capabilities} di un file (dal kernel
- 2.6.24).\\
+ \const{CAP\_SETFCAP} & Impostare le \textit{capabilities} di un file (dal kernel
+ 2.6.24).\\
\const{CAP\_SETGID} & Manipolare i group ID dei
processi, sia il principale che i supplementari,
(vedi sez.~\ref{sec:proc_setgroups}) che quelli
pur non essendo proprietari del file (dal kernel
2.4).\\
\const{CAP\_LINUX\_IMMUTABLE}& Impostare sui file gli attributi
- \textit{immutable} e \itindex{append~mode}
- \textit{append-only} (vedi
+ \textit{immutable} e \textit{append-only} (vedi
sez.~\ref{sec:file_perm_overview}) se
supportati.\\
- \const{CAP\_MKNOD} & Creare \index{file!di~dispositivo} file di
- dispositivo con \func{mknod} (vedi
+ \const{CAP\_MKNOD} & Creare file di dispositivo con \func{mknod} (vedi
sez.~\ref{sec:file_mknod}) (dal kernel 2.4).\\
\const{CAP\_NET\_ADMIN} & Eseguire alcune operazioni
privilegiate sulla rete.\\
\const{CAP\_SYS\_CHROOT}& Eseguire la funzione \func{chroot} (vedi
sez.~\ref{sec:file_chroot}).\\
\const{CAP\_MAC\_ADMIN} & Amministrare il \textit{Mandatory
- Access Control} di Smack (dal kernel 2.6.25).\\
- \const{CAP\_MAC\_OVERRIDE}& Evitare il \textit{Mandatory
- Access Control} di Smack (dal kernel 2.6.25).\\
+ Access Control} di \textit{Smack} (dal kernel
+ 2.6.25).\\
+ \const{CAP\_MAC\_OVERRIDE}& Evitare il \textit{Mandatory
+ Access Control} di \textit{Smack} (dal kernel
+ 2.6.25).\\
\const{CAP\_SYS\_MODULE}& Caricare e rimuovere moduli del kernel.\\
\const{CAP\_SYS\_NICE} & Modificare le varie priorità dei processi (vedi
sez.~\ref{sec:proc_priority}).\\
\label{tab:proc_capabilities}
\end{table}
-% \footnotetext{vale a dire i permessi caratteristici del modello classico del
-% controllo di accesso chiamato \itindex{Discrectionary~Access~Control~(DAC)}
-% \textit{Discrectionary Access Control} (da cui il nome DAC).}
-
Prima di dettagliare il significato della capacità più generiche, conviene
però dedicare un discorso a parte a \const{CAP\_SETPCAP}, il cui significato è
kernel) nel \textit{capabilities bounding set} usato di default, essa non è
neanche mai stata realmente disponibile.
-Con l'introduzione \itindex{file~capabilities} \textit{file capabilities} e
-il cambiamento del significato del \textit{capabilities bounding set} la
-possibilità di modificare le capacità di altri processi è stata completamente
-rimossa, e \const{CAP\_SETPCAP} ha acquisito quello che avrebbe dovuto essere
-il suo significato originario, e cioè la capacità del processo di poter
-inserire nel suo \textit{inheritable set} qualunque capacità presente nel
-\textit{bounding set}. Oltre a questo la disponibilità di \const{CAP\_SETPCAP}
-consente ad un processo di eliminare una capacità dal proprio \textit{bounding
- set} (con la conseguente impossibilità successiva di eseguire programmi con
-quella capacità), o di impostare i \textit{securebits} delle
-\textit{capabilities}.
+Con l'introduzione \textit{file capabilities} e il cambiamento del significato
+del \textit{capabilities bounding set} la possibilità di modificare le
+capacità di altri processi è stata completamente rimossa, e
+\const{CAP\_SETPCAP} ha acquisito quello che avrebbe dovuto essere il suo
+significato originario, e cioè la capacità del processo di poter inserire nel
+suo \textit{inheritable set} qualunque capacità presente nel \textit{bounding
+ set}. Oltre a questo la disponibilità di \const{CAP\_SETPCAP} consente ad un
+processo di eliminare una capacità dal proprio \textit{bounding set} (con la
+conseguente impossibilità successiva di eseguire programmi con quella
+capacità), o di impostare i \textit{securebits} delle \textit{capabilities}.
La prima fra le capacità ``\textsl{ampie}'' che occorre dettagliare
maggiormente è \const{CAP\_FOWNER}, che rimuove le restrizioni poste ad un
La struttura a cui deve puntare l'argomento \param{hdrp} serve ad indicare,
tramite il campo \var{pid}, il \ids{PID} del processo del quale si vogliono
leggere o modificare le \textit{capabilities}. Con \func{capset} questo, se si
-usano le \itindex{file~capabilities} \textit{file capabilities}, può essere
-solo 0 o il \ids{PID} del processo chiamante, che sono equivalenti. Non
-tratteremo, essendo comunque di uso irrilevante, il caso in cui, in mancanza
-di tale supporto, la funzione può essere usata per modificare le
-\textit{capabilities} di altri processi, per il quale si rimanda, se
-interessati, alla lettura della pagina di manuale.
+usano le \textit{file capabilities}, può essere solo 0 o il \ids{PID} del
+processo chiamante, che sono equivalenti. Non tratteremo, essendo comunque di
+uso irrilevante, il caso in cui, in mancanza di tale supporto, la funzione può
+essere usata per modificare le \textit{capabilities} di altri processi, per il
+quale si rimanda, se interessati, alla lettura della pagina di manuale.
Il campo \var{version} deve essere impostato al valore della versione delle
stesse usata dal kernel (quello indicato da una delle costanti
% informazioni su setns qui: http://lwn.net/Articles/532748/
% http://lwn.net/Articles/531498/
-
% TODO: spostare chroot e le funzioni affini relative ai container da qualche
% parte diversa se è il caso.
+% TODO Inheriting capabilities vedi http://lwn.net/Articles/632520/ eambient
+% capabilities introdotte con il kernel 4.3, vedi
+% http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=58319057b7847667f0c9585b9de0e8932b0fdb08
Benché non abbia niente a che fare con permessi, utenti e gruppi, la funzione
\func{chroot} viene usata spesso per restringere le capacità di accesso di un
questa sezione.
Come accennato in sez.~\ref{sec:proc_fork} ogni processo oltre ad una
-\index{directory~di~lavoro} directory di lavoro, ha anche una directory
-\textsl{radice}\footnote{entrambe sono contenute in due campi (rispettivamente
- \var{pwd} e \var{root}) di \kstruct{fs\_struct}; vedi
- fig.~\ref{fig:proc_task_struct}.} che, pur essendo di norma corrispondente
-alla radice dell'albero dei file dell'intero sistema, ha per il processo il
-significato specifico di directory rispetto alla quale vengono risolti i
-\itindsub{pathname}{assoluto}\textit{pathname} assoluti.\footnote{cioè quando
- un processo chiede la risoluzione di un \textit{pathname}, il kernel usa
- sempre questa directory come punto di partenza.} Il fatto che questo valore
-sia specificato per ogni processo apre allora la possibilità di modificare le
-modalità di risoluzione dei \itindsub{pathname}{assoluto} \textit{pathname}
-assoluti da parte di un processo cambiando questa directory, così come si fa
-coi \itindsub{pathname}{relativo} \textit{pathname} relativi cambiando la
-\index{directory~di~lavoro} directory di lavoro.
+directory di lavoro, ha anche una directory \textsl{radice}\footnote{entrambe
+ sono contenute in due campi (rispettivamente \var{pwd} e \var{root}) di
+ \kstruct{fs\_struct}; vedi fig.~\ref{fig:proc_task_struct}.} che, pur
+essendo di norma corrispondente alla radice dell'albero dei file dell'intero
+sistema, ha per il processo il significato specifico di directory rispetto
+alla quale vengono risolti i \itindsub{pathname}{assoluto}\textit{pathname}
+assoluti.\footnote{cioè quando un processo chiede la risoluzione di un
+ \textit{pathname}, il kernel usa sempre questa directory come punto di
+ partenza.} Il fatto che questo valore sia specificato per ogni processo apre
+allora la possibilità di modificare le modalità di risoluzione dei
+\itindsub{pathname}{assoluto} \textit{pathname} assoluti da parte di un
+processo cambiando questa directory, così come si fa coi
+\itindsub{pathname}{relativo} \textit{pathname} relativi cambiando la
+directory di lavoro.
Normalmente la directory radice di un processo coincide con la radice generica
dell'albero dei file, che è la directory che viene montata direttamente dal
\textsl{imprigionato}.
Solo un processo con i privilegi di amministratore può usare questa
-funzione,\footnote{più precisamente se possiede la \itindex{capabilities}
- capacità \const{CAP\_SYS\_CHROOT}.} e la nuova radice, per quanto detto in
+funzione,\footnote{più precisamente se possiede la capacità
+ \const{CAP\_SYS\_CHROOT}.} e la nuova radice, per quanto detto in
sez.~\ref{sec:proc_fork}, sarà ereditata da tutti i suoi processi figli. Si
tenga presente però che la funzione non cambia la directory di lavoro del
processo, che potrebbe restare fuori dalla \textit{chroot jail}.
Questo è il motivo per cui la funzione è efficace nel restringere un processo
ad un ramo di albero solo se dopo averla eseguita si cedono i privilegi di
amministratore. Infatti se per un qualunque motivo il processo resta con la
-sua \index{directory~di~lavoro} directory di lavoro al di fuori dalla
-\textit{chroot jail}, potrà accedere a tutto il resto del filesystem usando
-\itindsub{pathname}{relativo} dei \textit{pathname} relativi, dato che in tal
-caso è possibile, grazie all'uso di ``\texttt{..}'', risalire all'indietro
-fino alla radice effettiva dell'albero dei file.
+sua directory di lavoro al di fuori dalla \textit{chroot jail}, potrà accedere
+a tutto il resto del filesystem usando \itindsub{pathname}{relativo} dei
+\textit{pathname} relativi, dato che in tal caso è possibile, grazie all'uso
+di ``\texttt{..}'', risalire all'indietro fino alla radice effettiva
+dell'albero dei file.
Potrebbe sembrare che per risolvere il problema sia sufficiente ricordarsi di
eseguire preventivamente anche una \func{chdir} sulla directory su cui si
andrà ad eseguire \func{chroot}, così da assicurarsi che le directory di
lavoro sia all'interno della \textit{chroot jail}. Ma se ad un processo
restano i privilegi di amministratore esso potrà comunque portare la sua
-\index{directory~di~lavoro} directory di lavoro fuori dalla \textit{chroot
- jail} in cui si trova. Basterà infatti eseguire di nuovo \func{chroot} su
-una qualunque directory contenuta nell'attuale directory di lavoro perché
-quest'ultima risulti al di fuori della nuova \textit{chroot jail}. Per questo
-motivo l'uso di questa funzione non ha molto senso quando un processo di cui
-si vuole limitare l'accesso necessita comunque dei privilegi di amministratore
-per le sue normali operazioni.
+directory di lavoro fuori dalla \textit{chroot jail} in cui si trova. Basterà
+infatti eseguire di nuovo \func{chroot} su una qualunque directory contenuta
+nell'attuale directory di lavoro perché quest'ultima risulti al di fuori della
+nuova \textit{chroot jail}. Per questo motivo l'uso di questa funzione non ha
+molto senso quando un processo di cui si vuole limitare l'accesso necessita
+comunque dei privilegi di amministratore per le sue normali operazioni.
Nonostante queste limitazioni la funzione risulta utile qualora la si possa
applicare correttamente cedendo completamente i privilegi di amministratore
projects / gapil.git / blobdiff