%% filedir.tex
%%
-%% Copyright (C) 2000-2014 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2016 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
entry}. Le \textit{dentry} sono gli oggetti che il kernel usa per eseguire
la \textit{pathname resolution}, ciascuna di esse corrisponde ad un
\textit{pathname} e contiene il riferimento ad un \textit{inode}, che come
-vedremo a breve è l'oggetto usato dal kernel per identificare un un
+vedremo a breve è l'oggetto usato dal kernel per identificare un
file.\footnote{in questo caso si parla di file come di un qualunque oggetto
generico che sta sul filesystem e non dell'oggetto file del VFS cui
accennavamo prima.} La \textit{dentry} ottenuta dalla chiamata alla funzione
questo punto verrà inserita nella cache.
Dato che tutte le volte che si monta un filesystem la funzione \texttt{mount}
-della corrispondente \kstruct{file\_system\_type} inserisce la \textit{dentry}
-iniziale nel \itindex{mount~point} \textit{mount point} dello stesso, si avrà
-comunque un punto di partenza. Inoltre essendo questa \textit{dentry} relativa
-a quel tipo di filesystem essa farà riferimento ad un \textit{inode} di quel
-filesystem, e come vedremo questo farà sì che venga eseguita una
-\texttt{lookup} adatta per effettuare la risoluzione dei nomi per quel
-filesystem.
+(vedi sez.~\ref{sec:filesystem_mounting}) della corrispondente
+\kstruct{file\_system\_type} inserisce la \textit{dentry} iniziale nel
+\textit{mount point} dello stesso, si avrà comunque un punto di
+partenza. Inoltre essendo questa \textit{dentry} relativa a quel tipo di
+filesystem essa farà riferimento ad un \textit{inode} di quel filesystem, e
+come vedremo questo farà sì che venga eseguita una \texttt{lookup} adatta per
+effettuare la risoluzione dei nomi per quel filesystem.
\itindend{pathname}
\itindend{pathname~resolution}
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}).\\
\hline
\end{tabular}
\caption{Le principali operazioni sugli \textit{inode} definite tramite
- \kstruct{inode\_operation}.}
+ \kstructd{inode\_operation}.}
\label{tab:file_inode_operations}
\end{table}
dei file descriptor. Ogni processo infatti mantiene il riferimento ad una
struttura \kstruct{file} per ogni file che ha aperto, ed è tramite essa che
esegue le operazioni di I/O. Inoltre il kernel mantiene un elenco di tutti i
-file aperti nella \itindex{file~table} \textit{file table}.
+file aperti nella \textit{file table} (torneremo su questo in
+sez.~\ref{sec:file_fd}).
Inoltre se le operazioni relative agli \textit{inode} fanno riferimento ad
oggetti posti all'interno di un filesystem e vi si applicano quindi le
sez.~\ref{sec:file_asyncronous_io}) sul file.\\
\hline
\end{tabular}
- \caption{Operazioni sui file definite tramite \kstruct{file\_operation}.}
+ \caption{Operazioni sui file definite tramite \kstructd{file\_operation}.}
\label{tab:file_file_operations}
\end{table}
alle funzioni presenti nelle due strutture \kstruct{inode\_operation} e
\kstruct{file\_operation}. Ovviamente non è detto che tutte le operazioni
possibili siano poi disponibili in tutti i casi, ad esempio \code{llseek} non
-sarà presente per un dispositivo come la porta seriale o per una fifo, mentre
-sui file del filesystem \texttt{vfat} non saranno disponibili i permessi, ma
-resta il fatto che grazie al VFS le \textit{system call} per le operazioni sui
-file possono restare sempre le stesse nonostante le enormi differenze che
-possono esserci negli oggetti a cui si applicano.
+sarà presente per un dispositivo come la porta seriale o per una
+\textit{fifo}, mentre sui file del filesystem \texttt{vfat} non saranno
+disponibili i permessi, ma resta il fatto che grazie al VFS le \textit{system
+ call} per le operazioni sui file possono restare sempre le stesse nonostante
+le enormi differenze che possono esserci negli oggetti a cui si applicano.
-\itindend{Virtual~File~System}
+\itindend{Virtual~File~System~(VFS)}
% NOTE: documentazione interessante:
% * sorgenti del kernel: Documentation/filesystems/vfs.txt
daremo una descrizione a grandi linee che si adatta alle caratteristiche
comuni di qualunque filesystem di un sistema unix-like.
+\itindbeg{superblock}
+
Una possibile strutturazione dell'informazione su un disco è riportata in
fig.~\ref{fig:file_disk_filesys}, dove si hanno tre filesystem su tre
partizioni. In essa per semplicità si è fatto riferimento alla struttura del
filesystem \acr{ext2}, che prevede una suddivisione dei dati in \textit{block
group}. All'interno di ciascun \textit{block group} viene anzitutto
-replicato il cosiddetto \itindex{superblock} \textit{superblock}, (la
-struttura che contiene l'indice iniziale del filesystem e che consente di
-accedere a tutti i dati sottostanti) e creata una opportuna suddivisione dei
-dati e delle informazioni per accedere agli stessi. Sulle caratteristiche di
-\acr{ext2} e derivati torneremo in sez.~\ref{sec:file_ext2}.
+replicato il cosiddetto \textit{superblock}, (la struttura che contiene
+l'indice iniziale del filesystem e che consente di accedere a tutti i dati
+sottostanti) e creata una opportuna suddivisione dei dati e delle informazioni
+per accedere agli stessi. Sulle caratteristiche di \acr{ext2} e derivati
+torneremo in sez.~\ref{sec:file_ext2}.
+\itindend{superblock}
\itindbeg{inode}
È comunque caratteristica comune di tutti i filesystem per Unix,
\begin{figure}[!htb]
\centering
- \includegraphics[width=12cm]{img/disk_struct}
+ \includegraphics[width=11cm]{img/disk_struct}
\caption{Organizzazione dello spazio su un disco in partizioni e
filesystem.}
\label{fig:file_disk_filesys}
Se si va ad esaminare con maggiore dettaglio la strutturazione
dell'informazione all'interno del filesystem \textsl{ext2}, tralasciando i
dettagli relativi al funzionamento del filesystem stesso come la
-strutturazione in gruppi dei blocchi, il \itindex{superblock}
-\textit{superblock} e tutti i dati di gestione possiamo esemplificare la
-situazione con uno schema come quello esposto in
-fig.~\ref{fig:file_filesys_detail}.
+strutturazione in gruppi dei blocchi, il \textit{superblock} e tutti i dati di
+gestione possiamo esemplificare la situazione con uno schema come quello
+esposto in fig.~\ref{fig:file_filesys_detail}.
\begin{figure}[!htb]
\centering
- \includegraphics[width=12cm]{img/filesys_struct}
+ \includegraphics[width=11cm]{img/filesys_struct}
\caption{Strutturazione dei dati all'interno di un filesystem.}
\label{fig:file_filesys_detail}
\end{figure}
\subsection{Alcuni dettagli sul filesystem \textsl{ext2} e successori}
\label{sec:file_ext2}
-
Benché non esista ``il'' filesystem di Linux, dato che esiste un supporto
nativo di diversi filesystem che sono in uso da anni, quello che gli avvicina
di più è la famiglia di filesystem evolutasi a partire dal \textit{second
in fase di creazione, a seconda delle sue esigenze: blocchi più grandi
permettono un accesso più veloce, ma sprecano più spazio disco.
\item il filesystem implementa collegamenti simbolici veloci, in cui il nome
- del file non è salvato su un blocco, ma tenuto all'interno \itindex{inode}
+ del file non è salvato su un blocco, ma tenuto all'interno
dell'\textit{inode} (evitando letture multiple e spreco di spazio), non
tutti i nomi però possono essere gestiti così per limiti di spazio (il
limite è 60 caratteri).
-\item vengono supportati \itindex{file~attributes} i cosiddetti \textit{file
- attributes} che attivano comportamenti specifici per i file su cui vengono
- attivati come marcarli come immutabili (che possono cioè essere soltanto
- letti) per la protezione di file di configurazione sensibili, o come
- \textit{append-only} (che possono essere aperti in scrittura solo per
- aggiungere dati) per la protezione dei file di log.
+\item vengono supportati i cosiddetti \textit{file attributes} (vedi
+ sez.~\ref{sec:file_perm_overview}) che attivano comportamenti specifici per
+ i file su cui vengono attivati come marcarli come immutabili (che possono
+ cioè essere soltanto letti) per la protezione di file di configurazione
+ sensibili, o come \textit{append-only} (che possono essere aperti in
+ scrittura solo per aggiungere dati) per la protezione dei file di log.
\end{itemize}
La struttura di \acr{ext2} è stata ispirata a quella del filesystem di BSD: un
in gruppi di blocchi.
Ciascun gruppo di blocchi contiene una copia delle informazioni essenziali del
-filesystem (i \itindex{superblock} \textit{superblock} sono quindi ridondati)
-per una maggiore affidabilità e possibilità di recupero in caso di corruzione
-del \itindex{superblock} \textit{superblock} principale. L'utilizzo di
-raggruppamenti di blocchi ha inoltre degli effetti positivi nelle prestazioni
-dato che viene ridotta la distanza fra i dati e la tabella degli
-\itindex{inode} \textit{inode}.
+filesystem (i \textit{superblock} sono quindi ridondati) per una maggiore
+affidabilità e possibilità di recupero in caso di corruzione del
+\textit{superblock} principale. L'utilizzo di raggruppamenti di blocchi ha
+inoltre degli effetti positivi nelle prestazioni dato che viene ridotta la
+distanza fra i dati e la tabella degli \textit{inode}.
\begin{figure}[!htb]
\centering
\label{fig:file_ext2_dirs}
\end{figure}
-Le directory sono implementate come una \itindex{linked~list} \textit{linked
- list} con voci di dimensione variabile. Ciascuna voce della lista contiene
-il numero di \itindex{inode} \textit{inode}, la sua lunghezza, il nome del
-file e la sua lunghezza, secondo lo schema in fig.~\ref{fig:file_ext2_dirs};
-in questo modo è possibile implementare nomi per i file anche molto lunghi
-(fino a 1024 caratteri) senza sprecare spazio disco.
+
+Le directory sono implementate come una \textit{linked list} con voci di
+dimensione variabile. Ciascuna voce della lista contiene il numero di
+\textit{inode}, la sua lunghezza, il nome del file e la sua lunghezza, secondo
+lo schema in fig.~\ref{fig:file_ext2_dirs}; in questo modo è possibile
+implementare nomi per i file anche molto lunghi (fino a 1024 caratteri) senza
+sprecare spazio disco.
Con l'introduzione del filesystem \textit{ext3} sono state introdotte diverse
modifiche strutturali, la principale di queste è quella che \textit{ext3} è un
Oltre a questo \textit{ext3} introduce ulteriori modifiche volte a migliorare
sia le prestazioni che la semplicità di gestione del filesystem, in
particolare per le directory si è passato all'uso di alberi binari con
-indicizzazione tramite hash al posto delle \textit{linked list} che abbiamo
-illustrato, ottenendo un forte guadagno di prestazioni in caso di directory
-contenenti un gran numero di file.
+indicizzazione tramite \textit{hash} al posto delle \textit{linked list} che
+abbiamo illustrato, ottenendo un forte guadagno di prestazioni in caso di
+directory contenenti un gran numero di file.
% TODO (bassa priorità) portare a ext3, ext4 e btrfs ed illustrare le
% problematiche che si possono incontrare (in particolare quelle relative alla
o non può essere montato su \param{target} perché la directory è ancora in
uso.
\item[\errcode{EINVAL}] il dispositivo \param{source} presenta un
- \itindex{superblock} \textit{superblock} non valido, o si è cercato di
- rimontare un filesystem non ancora montato, o di montarlo senza
- che \param{target} sia un \itindex{mount~point} \textit{mount point} o di
- spostarlo quando \param{target} non è un \itindex{mount~point}
+ \textit{superblock} non valido, o si è cercato di rimontare un filesystem
+ non ancora montato, o di montarlo senza che \param{target} sia un
+ \textit{mount point} o di spostarlo quando \param{target} non è un
\textit{mount point} o è la radice.
- \item[\errcode{ELOOP}] si è cercato di spostare un \itindex{mount~point}
- \textit{mount point} su una sottodirectory di \param{source} o si sono
- incontrati troppi collegamenti simbolici nella risoluzione di un nome.
+ \item[\errcode{ELOOP}] si è cercato di spostare un \textit{mount point} su
+ una sottodirectory di \param{source} o si sono incontrati troppi
+ collegamenti simbolici nella risoluzione di un nome.
\item[\errcode{EMFILE}] in caso di filesystem virtuale, la tabella dei
dispositivi fittizi (chiamati \textit{dummy} nella documentazione inglese)
è piena.
configurato nel kernel.
\item[\errcode{ENOTBLK}] non si è usato un \textit{block device} per
\param{source} quando era richiesto.
- \item[\errcode{ENXIO}] il \itindex{major~number} \textit{major number} del
+ \item[\errcode{ENXIO}] il \textit{major number} del
dispositivo \param{source} è sbagliato.
\item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
\end{errlist}
\errval{ENOENT}, \errval{ENOTDIR} nel loro significato generico.}
\end{funcproto}
+\itindbeg{mount~point}
+
La funzione monta sulla directory indicata da \param{target}, detta
-\itindex{mount~point} \textit{mount point}, il filesystem contenuto nel file
-di dispositivo indicato da \param{source}. In entrambi i casi, come daremo per
-assunto da qui in avanti tutte le volte che si parla di directory o file nel
-passaggio di un argomento di una funzione, si intende che questi devono essere
-indicati con la stringa contenente il loro \textit{pathname}.
+\textit{mount point}, il filesystem contenuto nel file di dispositivo indicato
+da \param{source}. In entrambi i casi, come daremo per assunto da qui in
+avanti tutte le volte che si parla di directory o file nel passaggio di un
+argomento di una funzione, si intende che questi devono essere 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
-riportate nel file \procfile{/proc/filesystems} che, come accennato in
+riportate nel file \procfilem{/proc/filesystems} che, come accennato in
sez.~\ref{sec:file_vfs_work}, contiene l'elenco dei filesystem supportati dal
kernel. Nel caso si sia indicato un filesystem virtuale, che non è associato a
nessun file di dispositivo, il contenuto di \param{source} viene ignorato.
pagina di manuale di questo comando e dei singoli filesystem.
Dopo l'esecuzione della funzione il contenuto del filesystem viene resto
-disponibile nella directory specificata come \itindex{mount~point}
-\textit{mount point}, il precedente contenuto di detta directory viene
-mascherato dal contenuto della directory radice del filesystem montato. Fino
-ai kernel della serie 2.2.x non era possibile montare un filesystem se un
-\textit{mount point} era già in uso.
+disponibile nella directory specificata come \textit{mount point}, il
+precedente contenuto di detta directory viene mascherato dal contenuto della
+directory radice del filesystem montato. Fino ai kernel della serie 2.2.x non
+era possibile montare un filesystem se un \textit{mount point} era già in uso.
A partire dal kernel 2.4.x inoltre è divenuto possibile sia spostare
-atomicamente un \itindex{mount~point} \textit{mount point} da una directory ad
-un'altra, sia montare lo stesso filesystem in diversi \itindex{mount~point}
-\textit{mount point}, sia montare più filesystem sullo stesso
-\itindex{mount~point} \textit{mount point} impilandoli l'uno sull'altro, nel
+atomicamente un \textit{mount point} da una directory ad un'altra, sia montare
+lo stesso filesystem in diversi \textit{mount point}, sia montare più
+filesystem sullo stesso \textit{mount point} impilandoli l'uno sull'altro, nel
qual caso vale comunque quanto detto in precedenza, e cioè che solo il
contenuto dell'ultimo filesystem montato sarà visibile.
+\itindend{mount~point}
+
Oltre alle opzioni specifiche di ciascun filesystem, che si passano nella
forma della lista di parole chiave indicata con l'argomento \param{data},
esistono pure alcune opzioni che si possono applicare in generale, anche se
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
+ \constd{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 \constd{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}
-\item[\const{MS\_BIND}] Effettua un cosiddetto \textit{bind mount}, in cui è
+\item[\constd{MS\_BIND}] Effettua un cosiddetto \textit{bind mount}, in cui è
possibile montare una directory di un filesystem in un'altra directory,
l'opzione è disponibile a partire dai kernel della serie 2.4. In questo caso
verranno presi in considerazione solo gli argomenti \param{source}, che
e \param{data} vengono ignorati.
In sostanza quello che avviene è che in corrispondenza del \textit{pathname}
- indicato da \param{target} viene montato \itindex{inode} l'\textit{inode}
- di \param{source}, così che la porzione di albero dei file presente sotto
- \param{source} diventi visibile allo stesso modo sotto
- \param{target}. Trattandosi esattamente dei dati dello stesso filesystem,
- ogni modifica fatta in uno qualunque dei due rami di albero sarà visibile
- 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.
+ indicato da \param{target} viene montato l'\textit{inode} di \param{source},
+ così che la porzione di albero dei file presente sotto \param{source}
+ diventi visibile allo stesso modo sotto \param{target}. Trattandosi
+ esattamente dei dati dello stesso filesystem, ogni modifica fatta in uno
+ qualunque dei due rami di albero sarà visibile nell'altro, visto che
+ entrambi faranno riferimento agli stessi \textit{inode}.
+
+ 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
+ \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
all'uso dei collegamenti simbolici (di cui parleremo in
sez.~\ref{sec:link_symlink_rename}) che funziona correttamente anche
all'intero di un \textit{chroot} (argomento su cui torneremo in
- sez.~\ref{sec:file_chroot}). \itindend{bind~mount}
+ sez.~\ref{sec:file_chroot}).
+
+\itindend{bind~mount}
-\item[\const{MS\_DIRSYNC}] Richiede che ogni modifica al contenuto di una
+\item[\constd{MS\_DIRSYNC}] Richiede che ogni modifica al contenuto di una
directory venga immediatamente registrata su disco in maniera sincrona
(introdotta a partire dai kernel della serie 2.6). L'opzione si applica a
tutte le directory del filesystem, ma su alcuni filesystem è possibile
operazioni sulle directory non saranno più bufferizzate e si bloccheranno
fino all'arrivo dei dati sul disco prima che un programma possa proseguire.
-\item[\const{MS\_MANDLOCK}] Consente l'uso del \textit{mandatory locking}
- \itindex{mandatory~locking} (vedi sez.~\ref{sec:file_mand_locking}) sui file
- del filesystem. Per poterlo utilizzare effettivamente però esso dovrà essere
- comunque attivato esplicitamente per i singoli file impostando i permessi
- come illustrato in sez.~\ref{sec:file_mand_locking}.
+\item[\constd{MS\_MANDLOCK}] Consente l'uso del \textit{mandatory locking}
+ (vedi sez.~\ref{sec:file_mand_locking}) sui file del filesystem. Per poterlo
+ utilizzare effettivamente però esso dovrà essere comunque attivato
+ esplicitamente per i singoli file impostando i permessi come illustrato in
+ sez.~\ref{sec:file_mand_locking}.
-\item[\const{MS\_MOVE}] Effettua uno del spostamento del \itindex{mount~point}
- \textit{mount point} di un filesystem. La directory del
- \itindex{mount~point} \textit{mount point} originale deve essere indicata
- nell'argomento \param{source}, e la sua nuova posizione
+\item[\constd{MS\_MOVE}] Effettua uno del spostamento del \textit{mount point}
+ di un filesystem. La directory del \textit{mount point} originale deve
+ essere indicata nell'argomento \param{source}, e la sua nuova posizione
nell'argomento \param{target}. Tutti gli altri argomenti della funzione
vengono ignorati.
sotto \param{source} sarà immediatamente visibile sotto \param{target}. Non
esiste cioè nessun momento in cui il filesystem non risulti montato in una o
nell'altra directory e pertanto è garantito che la risoluzione di
- \itindsub{pathname}{relativo} \textit{pathname} relativi all'interno del
- filesystem non possa fallire.
+ \textit{pathname} relativi all'interno del filesystem non possa fallire.
-\item[\const{MS\_NOATIME}] Viene disabilitato sul filesystem l'aggiornamento
+\item[\constd{MS\_NOATIME}] Viene disabilitato sul filesystem l'aggiornamento
degli \textit{access time} (vedi sez.~\ref{sec:file_file_times}) per
qualunque tipo di file. Dato che l'aggiornamento degli \textit{access time}
è una funzionalità la cui utilità è spesso irrilevante ma comporta un costo
sviluppo del kernel sono state introdotte altre opzioni che forniscono
soluzioni più appropriate e meno radicali.
-\item[\const{MS\_NODEV}] Viene disabilitato sul filesystem l'accesso ai file
+\item[\constd{MS\_NODEV}] Viene disabilitato sul filesystem l'accesso ai file
di dispositivo eventualmente presenti su di esso. L'opzione viene usata come
misura di precauzione per rendere inutile la presenza di eventuali file di
dispositivo su filesystem che non dovrebbero contenerne.\footnote{si ricordi
- che le convenzioni del \itindex{Filesystem~Hierarchy~Standard~(FHS)}
- \textit{Linux Filesystem Hierarchy Standard} richiedono che questi siano
- mantenuti esclusivamente sotto \texttt{/dev}.}
+ che le convenzioni del \textit{Linux Filesystem Hierarchy Standard}
+ richiedono che questi siano mantenuti esclusivamente sotto \texttt{/dev}.}
Viene utilizzata, assieme a \const{MS\_NOEXEC} e \const{MS\_NOSUID}, per
fornire un accesso più controllato a quei filesystem di cui gli utenti hanno
dispositivo con permessi ``opportunamente'' ampliati che gli consentirebbero
di accedere anche a risorse cui non dovrebbe.
-\item[\const{MS\_NODIRATIME}] Viene disabilitato sul filesystem
+\item[\constd{MS\_NODIRATIME}] Viene disabilitato sul filesystem
l'aggiornamento degli \textit{access time} (vedi
sez.~\ref{sec:file_file_times}), ma soltanto per le directory. Costituisce
una alternativa per \const{MS\_NOATIME}, che elimina l'informazione per le
directory, che in pratica che non viene mai utilizzata, mantenendola per i
file in cui invece ha un impiego, sia pur limitato.
-\item[\const{MS\_NOEXEC}] Viene disabilitata sul filesystem l'esecuzione di un
+\item[\constd{MS\_NOEXEC}] Viene disabilitata sul filesystem l'esecuzione di un
qualunque file eseguibile eventualmente presente su di esso. L'opzione viene
usata come misura di precauzione per rendere impossibile l'uso di programmi
posti su filesystem che non dovrebbero contenerne.
vuole che gli utenti eseguano solo i programmi forniti
dall'amministratore.}
-\item[\const{MS\_NOSUID}] Viene disabilitato sul filesystem l'effetto dei bit
- dei permessi \itindex{suid~bit} \acr{suid} e \itindex{sgid~bit} \acr{sgid}
- (vedi sez.~\ref{sec:file_special_perm}) eventualmente presenti sui file in
- esso contenuti. L'opzione viene usata come misura di precauzione per rendere
- inefficace l'effetto di questi bit per filesystem in cui non ci dovrebbero
- essere file dotati di questi permessi.
+\item[\constd{MS\_NOSUID}] Viene disabilitato sul filesystem l'effetto dei bit
+ dei permessi \acr{suid} e \acr{sgid} (vedi sez.~\ref{sec:file_special_perm})
+ eventualmente presenti sui file in esso contenuti. L'opzione viene usata
+ come misura di precauzione per rendere inefficace l'effetto di questi bit
+ per filesystem in cui non ci dovrebbero essere file dotati di questi
+ permessi.
Di nuovo viene utilizzata, analogamente a \const{MS\_NOEXEC} e
\const{MS\_NODEV}, per fornire un accesso più controllato a quei filesystem
di cui gli utenti hanno il controllo dei contenuti. In questo caso si evita
che un utente malizioso possa inserire su uno di questi filesystem un
- eseguibile con il bit \itindex{suid~bit} \acr{suid} attivo e di proprietà
- dell'amministratore o di un altro utente, che gli consentirebbe di eseguirlo
- per conto di quest'ultimo.
-
-\item[\const{MS\_PRIVATE}] Marca un \itindex{mount~point} \textit{mount point}
- come privato. Si tratta di una delle nuove opzioni (insieme a
- \const{MS\_SHARED}, \const{MS\_SLAVE} e \const{MS\_UNBINDABLE}) facenti
- parte dell'infrastruttura degli \itindex{shared~subtree} \textit{shared
- subtree} introdotta a partire dal kernel 2.6.15, che estendono le
- funzionalità dei \itindex{bind~mount} \textit{bind mount}. In questo caso
- \param{target} dovrà fare riferimento al \textit{mount point} che si intende
- marcare, e tutti gli altri argomenti verranno ignorati.
+ eseguibile con il bit \acr{suid} attivo e di proprietà dell'amministratore o
+ di un altro utente, che gli consentirebbe di eseguirlo per conto di
+ quest'ultimo.
+
+\item[\constd{MS\_PRIVATE}] Marca un \textit{mount point} come privato. Si
+ tratta di una delle nuove opzioni (insieme a \const{MS\_SHARED},
+ \const{MS\_SLAVE} e \const{MS\_UNBINDABLE}) facenti parte
+ dell'infrastruttura degli \textit{shared subtree} introdotta a partire dal
+ kernel 2.6.15, che estendono le funzionalità dei \textit{bind mount}. In
+ questo caso \param{target} dovrà fare riferimento al \textit{mount point}
+ che si intende marcare, e tutti gli altri argomenti verranno ignorati.
Di default, finché non lo si marca altrimenti con una delle altre opzioni
- dell'interfaccia \itindex{shared~subtree} \textit{shared subtree}, ogni
- \textit{mount point} è privato. Ogni \textit{bind mount} ottenuto da un
- \itindex{mount~point} \textit{mount point} di tipo \textit{private} si
- comporta come descritto nella trattazione di \const{MS\_BIND}. Si usa questo
- flag principalmente per revocare gli effetti delle altre opzioni e riportare
- il comportamento a quello ordinario.
-
-\item[\const{MS\_RDONLY}] Esegue il montaggio del filesystem in sola lettura,
+ dell'interfaccia come \textit{shared subtree}, ogni \textit{mount point} è
+ privato. Ogni \textit{bind mount} ottenuto da un \textit{mount point} di
+ tipo \textit{private} si comporta come descritto nella trattazione di
+ \const{MS\_BIND}. Si usa questo flag principalmente per revocare gli effetti
+ delle altre opzioni e riportare il comportamento a quello ordinario.
+
+\item[\constd{MS\_RDONLY}] Esegue il montaggio del filesystem in sola lettura,
non sarà possibile nessuna modifica ai suoi contenuti. Viene usato tutte le
volte che si deve accedere ai contenuti di un filesystem con la certezza che
questo non venga modificato (ad esempio per ispezionare un filesystem
corrotto). All'avvio di default il kernel monta la radice in questa
modalità.
-\item[\const{MS\_REC}] Applica ricorsivamente a tutti i \itindex{mount~point}
- \textit{mount point} presenti al di sotto del \textit{mount point} indicato
- gli effetti della opzione degli \itindex{shared~subtree} \textit{shared
- subtree} associata. Anche questo caso l'argomento \param{target} deve fare
- riferimento ad un \itindex{mount~point} \textit{mount point} e tutti gli
- altri argomenti sono ignorati, ed il flag deve essere indicato assieme ad
- una fra \const{MS\_PRIVATE}, \const{MS\_SHARED}, \const{MS\_SLAVE} e
- \const{MS\_UNBINDABLE}.
+\item[\constd{MS\_REC}] Applica ricorsivamente a tutti i \textit{mount point}
+ presenti al di sotto del \textit{mount point} indicato gli effetti della
+ opzione degli \textit{shared subtree} associata. Anche questo caso
+ l'argomento \param{target} deve fare riferimento ad un \textit{mount point}
+ e tutti gli altri argomenti sono ignorati, ed il flag deve essere indicato
+ assieme ad 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
+\item[\constd{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
\textit{change time} (per i tempi dei file si veda
l'introduzione di questo comportamento l'uso delle alternative
\const{MS\_NOATIME} e \const{MS\_NODIRATIME} è sostanzialmente inutile.
-\item[\const{MS\_REMOUNT}] Consente di rimontare un filesystem già montato
+\item[\constd{MS\_REMOUNT}] Consente di rimontare un filesystem già montato
cambiandone le opzioni di montaggio in maniera atomica. In questo modo si
possono modificare le opzioni del filesystem anche se questo è in uso. Gli
argomenti \param{source} e \param{target} devono essere gli stessi usati per
\const{MS\_NOATIME} e \const{MS\_NODIRATIME}, ed infine prima del kernel
2.4.10 anche \const{MS\_NODEV}, \const{MS\_NOEXEC} e \const{MS\_NOSUID}.
-\item[\const{MS\_SHARED}] Marca un \itindex{mount~point} \textit{mount point}
- come \textit{shared mount}. Si tratta di una delle nuove opzioni (insieme a
+\itindbeg{shared~subtree}
+
+\item[\constd{MS\_SHARED}] Marca un \textit{mount point} come \textit{shared
+ mount}. Si tratta di una delle nuove opzioni (insieme a
\const{MS\_PRIVATE}, \const{MS\_SLAVE} e \const{MS\_UNBINDABLE}) facenti
- parte dell'infrastruttura degli \itindex{shared~subtree} \textit{shared
- subtree} introdotta a partire dal kernel 2.6.15, che estendono le
- funzionalità dei \itindex{bind~mount} \textit{bind mount}. In questo caso
- \param{target} dovrà fare riferimento al \itindex{mount~point} \textit{mount
- point} che si intende marcare, e tutti gli altri argomenti verranno
- ignorati.
-
- Lo scopo dell'opzione è ottenere che tutti i successivi \itindex{bind~mount}
- \textit{bind mount} effettuati da un \textit{mount point} marcato da essa
- siano di tipo \textit{shared}, cioè ``\textsl{condividano}'' con l'originale
- e fra di loro ogni ulteriore operazione di montaggio o smontaggio che
- avviene su una directory al di sotto di uno qualunque di essi. Le operazioni
- di montaggio e smontaggio effettuate al di sotto di un qualunque
- \textit{mount point} così marcato verranno ``\textsl{propagate}'' a tutti i
- \itindex{mount~point} \textit{mount point} della stessa condivisione, e la
- sezione di albero di file vista al di sotto di ciascuno di essi sarà sempre
- identica.
-
-\item[\const{MS\_SILENT}] Richiede la soppressione di alcuni messaggi di
+ parte dell'infrastruttura dei cosiddetti \textit{shared subtree} introdotta
+ a partire dal kernel 2.6.15, che estendono le funzionalità dei \textit{bind
+ mount}. In questo caso \param{target} dovrà fare riferimento al
+ \textit{mount point} che si intende marcare, e tutti gli altri argomenti
+ verranno ignorati.
+
+ Lo scopo dell'opzione è ottenere che tutti i successivi \textit{bind mount}
+ effettuati da un \textit{mount point} marcato da essa siano di tipo
+ \textit{shared}, cioè ``\textsl{condividano}'' con l'originale e fra di loro
+ ogni ulteriore operazione di montaggio o smontaggio che avviene su una
+ directory al di sotto di uno qualunque di essi. Le operazioni di montaggio e
+ smontaggio effettuate al di sotto di un qualunque \textit{mount point} così
+ marcato verranno ``\textsl{propagate}'' a tutti i \textit{mount point} della
+ stessa condivisione, e la sezione di albero di file vista al di sotto di
+ ciascuno di essi sarà sempre identica.
+
+\itindend{shared~subtree}
+
+\item[\constd{MS\_SILENT}] Richiede la soppressione di alcuni messaggi di
avvertimento nei log del kernel (vedi sez.~\ref{sec:sess_daemon}). L'opzione
è presente a partire dal kernel 2.6.17 e sostituisce, utilizzando un nome
non fuorviante, la precedente \const{MS\_VERBOSE}, introdotta nel kernel
2.6.12, che aveva lo stesso effetto.
-\item[\const{MS\_SLAVE}] Marca un \itindex{mount~point} \textit{mount point}
- come \textit{slave mount}. Si tratta di una delle nuove opzioni (insieme a
+\item[\constd{MS\_SLAVE}] Marca un \textit{mount point} come \textit{slave
+ mount}. Si tratta di una delle nuove opzioni (insieme a
\const{MS\_PRIVATE}, \const{MS\_SHARED} e \const{MS\_UNBINDABLE}) facenti
- parte dell'infrastruttura degli \itindex{shared~subtree} \textit{shared
- subtree} introdotta a partire dal kernel 2.6.15, che estendono le
- funzionalità dei \itindex{bind~mount} \textit{bind mount}. In questo caso
- \param{target} dovrà fare riferimento al \textit{mount point} che si intende
- marcare, e tutti gli altri argomenti verranno ignorati.
+ parte dell'infrastruttura degli \textit{shared subtree} introdotta a partire
+ dal kernel 2.6.15, che estendono le funzionalità dei \textit{bind mount}.
+ In questo caso \param{target} dovrà fare riferimento al \textit{mount point}
+ che si intende marcare, e tutti gli altri argomenti verranno ignorati.
Lo scopo dell'opzione è ottenere che tutti i successivi \textit{bind mount}
effettuati da un \textit{mount point} marcato da essa siano di tipo
questo caso vengono ``\textsl{propagate}'' soltanto dal \textit{mount point}
originale (detto anche \textit{master}) verso gli \textit{slave}, mentre
essi potranno eseguire al loro interno ulteriori montaggi che non saranno
- propagati né negli altri né nel \itindex{mount~point} \textit{mount point}
- originale.
+ propagati né negli altri né nel \textit{mount point} originale.
-\item[\const{MS\_STRICTATIME}] Ripristina il comportamento tradizionale per
+\item[\constd{MS\_STRICTATIME}] Ripristina il comportamento tradizionale per
cui l'\textit{access time} viene aggiornato ad ogni accesso al
file. L'opzione è disponibile solo a partire dal kernel 2.6.30 quando il
comportamento di default del kernel è diventato quello fornito da
\const{MS\_RELATIME}.
-\item[\const{MS\_SYNCHRONOUS}] Abilita la scrittura sincrona richiedendo che
+\item[\constd{MS\_SYNCHRONOUS}] Abilita la scrittura sincrona richiedendo che
ogni modifica al contenuto del filesystem venga immediatamente registrata su
disco. Lo stesso comportamento può essere ottenuto con il flag
\const{O\_SYNC} di \func{open} (vedi sez.~\ref{sec:file_open_close}).
compromesso in cui questo comportamento avviene solo per le directory, ed ha
quindi una incidenza nettamente minore, si può usare \const{MS\_DIRSYNC}.
-\item[\const{MS\_UNBINDABLE}] Marca un \itindex{mount~point} \textit{mount
- point} come \textit{unbindable mount}. Si tratta di una delle nuove
- opzioni (insieme a \const{MS\_PRIVATE}, \const{MS\_SHARED} e
- \const{MS\_SLAVE}) facenti parte dell'infrastruttura degli
- \itindex{shared~subtree} \textit{shared subtree} introdotta a partire dal
- kernel 2.6.15, che estendono le funzionalità dei \itindex{bind~mount}
- \textit{bind mount}. In questo caso
- \param{target} dovrà fare riferimento al \textit{mount point} che si intende
- marcare, e tutti gli altri argomenti verranno ignorati.
+\item[\constd{MS\_UNBINDABLE}] Marca un \textit{mount point} come
+ \textit{unbindable mount}. Si tratta di una delle nuove opzioni (insieme a
+ \const{MS\_PRIVATE}, \const{MS\_SHARED} e \const{MS\_SLAVE}) facenti parte
+ dell'infrastruttura degli \textit{shared subtree} introdotta a partire dal
+ kernel 2.6.15, che estendono le funzionalità dei \textit{bind mount}. In
+ questo caso \param{target} dovrà fare riferimento al \textit{mount point}
+ che si intende marcare, e tutti gli altri argomenti verranno ignorati.
Un \textit{mount point} marcato in questo modo disabilita la capacità di
- eseguire dei \itindex{bind~mount} \textit{bind mount} del suo contenuto. Si
- comporta cioè come allo stesso modo di un \itindex{mount~point}
- \textit{mount point} ordinario di tipo \textit{private} con in più la
- restrizione che nessuna sua sottodirectory (anche se relativa ad un
- ulteriore montaggio) possa essere utilizzata per un come sorgente di un
- \itindex{bind~mount} \textit{bind mount}.
+ eseguire dei \textit{bind mount} del suo contenuto. Si comporta cioè come
+ allo stesso modo di un \textit{mount point} ordinario di tipo
+ \textit{private} con in più la restrizione che nessuna sua sottodirectory
+ (anche se relativa ad un ulteriore montaggio) possa essere utilizzata per un
+ come sorgente di un \textit{bind mount}.
\end{basedescript}
\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
funzione poteva essere usata anche specificando il file di dispositivo.} in
quanto a partire dai kernel della serie 2.4.x è possibile montare lo stesso
dispositivo in più punti. Nel caso più di un filesystem sia stato montato
-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.
+sullo stesso \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 directory di lavoro (vedi
+sez.~\ref{sec:file_work_dir}) di un qualunque processo o il \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}
Il valore di \param{flags} è una maschera binaria dei flag che controllano le
modalità di smontaggio, che deve essere specificato con un OR aritmetico delle
costanti illustrate in tab.~\ref{tab:umount2_flags}. Specificando
-\const{MNT\_FORCE} la funzione cercherà di liberare il filesystem anche se è
+\constd{MNT\_FORCE} la funzione cercherà di liberare il filesystem anche se è
occupato per via di una delle condizioni descritte in precedenza. A seconda
del tipo di filesystem alcune (o tutte) possono essere superate, evitando
l'errore di \errcode{EBUSY}. In tutti i casi prima dello smontaggio viene
\hline
\hline
\const{MNT\_FORCE} & Forza lo smontaggio del filesystem anche se questo è
- occupato (presente dai kernel della serie 2.2).\\
+ occupato (presente dai kernel della serie 2.2).\\
\const{MNT\_DETACH} & Esegue uno smontaggio ``\textsl{pigro}'', in cui si
- blocca l'accesso ma si aspetta che il filesystem si
- liberi (presente dal kernel 2.4.11 e dalla
- \acr{glibc} 2.11).\\
- \const{MNT\_EXPIRE} & Se non occupato marca un \itindex{mount~point}
- \textit{mount point} come ``\textsl{in scadenza}'' in
- modo che ad una successiva chiamata senza utilizzo
- del filesystem questo venga smontato (presente dal
- kernel 2.6.8 e dalla \acr{glibc} 2.11).\\
+ blocca l'accesso ma si aspetta che il filesystem si
+ liberi (presente dal kernel 2.4.11 e dalla
+ \acr{glibc} 2.11).\\
+ \const{MNT\_EXPIRE} & Se non occupato marca un \textit{mount point} come
+ ``\textsl{in scadenza}'' in modo che ad una
+ successiva chiamata senza utilizzo del filesystem
+ questo venga smontato (presente dal
+ kernel 2.6.8 e dalla \acr{glibc} 2.11).\\
\const{UMOUNT\_NOFOLLOW}& Non dereferenzia \param{target} se questo è un
- collegamento simbolico (vedi
- sez.~\ref{sec:link_symlink_rename}) evitando
- problemi di sicurezza (presente dal kernel 2.6.34).\\
+ collegamento simbolico (vedi
+ sez.~\ref{sec:link_symlink_rename}) evitando
+ problemi di sicurezza (presente dal kernel
+ 2.6.34).\\
\hline
\end{tabular}
\caption{Costanti che identificano i bit dell'argomento \param{flags}
\label{tab:umount2_flags}
\end{table}
-Con l'opzione \const{MNT\_DETACH} si richiede invece uno smontaggio
+Con l'opzione \constd{MNT\_DETACH} si richiede invece uno smontaggio
``\textsl{pigro}'' (o \textit{lazy umount}) in cui il filesystem diventa
inaccessibile per i nuovi processi subito dopo la chiamata della funzione, ma
resta accessibile per quelli che lo hanno ancora in uso e non viene smontato
fintanto che resta occupato.
-Con \const{MNT\_EXPIRE}, che non può essere specificato insieme agli altri
-due, si marca il \itindex{mount~point} \textit{mount point} di un filesystem
-non occupato come ``\textsl{in scadenza}'', in tal caso \func{umount2} ritorna
-con un errore di \errcode{EAGAIN}, mentre in caso di filesystem occupato si
-sarebbe ricevuto \errcode{EBUSY}. Una volta marcato, se nel frattempo non
-viene fatto nessun uso del filesystem, ad una successiva chiamata con
-\const{MNT\_EXPIRE} questo verrà smontato. Questo flag consente di realizzare
-un meccanismo che smonti automaticamente i filesystem che restano inutilizzati
-per un certo periodo di tempo.
-
-Infine il flag \const{UMOUNT\_NOFOLLOW} non dereferenzia \param{target} se
+Con \constd{MNT\_EXPIRE}, che non può essere specificato insieme agli altri
+due, si marca il \textit{mount point} di un filesystem non occupato come
+``\textsl{in scadenza}'', in tal caso \func{umount2} ritorna con un errore di
+\errcode{EAGAIN}, mentre in caso di filesystem occupato si sarebbe ricevuto
+\errcode{EBUSY}. Una volta marcato, se nel frattempo non viene fatto nessun
+uso del filesystem, ad una successiva chiamata con \const{MNT\_EXPIRE} questo
+verrà smontato. Questo flag consente di realizzare un meccanismo che smonti
+automaticamente i filesystem che restano inutilizzati per un certo periodo di
+tempo.
+
+Infine il flag \constd{UMOUNT\_NOFOLLOW} non dereferenzia \param{target} se
questo è un collegamento simbolico (vedi
sez.~\ref{sec:link_symlink_rename}). Questa è una misura di sicurezza
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
\label{fig:sys_statfs}
\end{figure}
+\conffilebeg{/etc/mtab}
+
La \acr{glibc} provvede infine una serie di funzioni per la gestione dei due
-file \conffile{/etc/fstab}\footnote{più precisamente \funcm{setfsent},
+file \conffiled{/etc/fstab}\footnote{più precisamente \funcm{setfsent},
\funcm{getfsent}, \funcm{getfsfile}, \funcm{getfsspec}, \funcm{endfsent}.}
ed \conffile{/etc/mtab}\footnote{più precisamente \funcm{setmntent},
\funcm{getmntent},\funcm{getmntent\_r}, \funcm{addmntent},\funcm{endmntent},
\funcm{hasmntopt}.} che convenzionalmente sono usati in quasi tutti i
sistemi unix-like per mantenere rispettivamente le informazioni riguardo ai
filesystem da montare e a quelli correntemente montati. Le funzioni servono a
-leggere il contenuto di questi file in opportune strutture \struct{fstab} e
-\struct{mntent}, e, nel caso di \conffile{/etc/mtab}, per inserire e rimuovere
-le voci presenti nel file.
+leggere il contenuto di questi file in opportune strutture \structd{fstab} e
+\structd{mntent}, e, nel caso di \conffile{/etc/mtab}, per inserire e
+rimuovere le voci presenti nel file.
In generale si dovrebbero usare queste funzioni, in particolare quelle
relative a \conffile{/etc/mtab}, quando si debba scrivere un programma che
trattazione, di queste funzioni, rimandando al manuale della \acr{glibc}
\cite{GlibcMan} per la documentazione completa.
+\conffileend{/etc/mtab}
+
% TODO (bassa priorità) scrivere delle funzioni (getfsent e getmntent &C)
% TODO (bassa priorità) documentare ? swapon e swapoff (man 2 ...)
+
\section{La gestione di file e directory}
\label{sec:file_dir}
temporanei.
-
\subsection{La gestione dei nomi dei file}
\label{sec:link_symlink_rename}
chiamare un file con nomi diversi sia connaturata con l'architettura di un
filesystem per un sistema Unix, in quanto il nome del file che si trova in una
directory è solo un'etichetta associata ad un puntatore che permette di
-ottenere il riferimento ad un \itindex{inode} \textit{inode}, e che è
-quest'ultimo che viene usato dal kernel per identificare univocamente gli
-oggetti sul filesystem.
+ottenere il riferimento ad un \textit{inode}, e che è quest'ultimo che viene
+usato dal kernel per identificare univocamente gli oggetti sul filesystem.
Questo significa che fintanto che si resta sullo stesso filesystem la
realizzazione di un \textit{link} è immediata: uno stesso file può avere tanti
nomi diversi, dati da altrettante associazioni diverse allo stesso
-\itindex{inode} \textit{inode} effettuate tramite ``etichette'' diverse in
-directory diverse. Si noti anche come nessuno di questi nomi possa assumere
-una particolare preferenza o originalità rispetto agli altri, in quanto tutti
-fanno comunque riferimento allo stesso \itindex{inode} \textit{inode} e quindi
-tutti otterranno lo stesso file.
+\textit{inode} effettuate tramite ``etichette'' diverse in directory
+diverse. Si noti anche come nessuno di questi nomi possa assumere una
+particolare preferenza o originalità rispetto agli altri, in quanto tutti
+fanno comunque riferimento allo stesso \textit{inode} e quindi tutti
+otterranno lo stesso file.
Quando si vuole aggiungere ad una directory una voce che faccia riferimento ad
un file già esistente nella modalità appena descritta, per ottenere quello che
\item[\errcode{EPERM}] il filesystem che contiene \param{oldpath} e
\param{newpath} non supporta i collegamenti diretti o è una directory.
\item[\errcode{EXDEV}] i file \param{oldpath} e \param{newpath} non fanno
- riferimento ad un filesystem montato sullo stesso \itindex{mount~point}
+ riferimento ad un filesystem montato sullo stesso
\textit{mount point}.
\end{errlist} ed inoltre \errval{EACCES}, \errval{EFAULT}, \errval{EIO},
\errval{ELOOP}, \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM},
(il meccanismo non è disponibile ad esempio 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 all'interno dello stesso \itindex{mount~point}
-\textit{mount point}.\footnote{si tenga presente infatti, come detto in
- sez.~\ref{sec:filesystem_mounting}, che a partire dal kernel 2.4 uno stesso
- filesystem può essere montato più volte su directory diverse.}
+riferimento ad essi all'interno dello stesso \textit{mount point}.\footnote{si
+ tenga presente infatti, come detto in sez.~\ref{sec:filesystem_mounting},
+ 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
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
successiva dello standard.
\itindbeg{symbolic~link}
-
\index{collegamento!simbolico|(}
La ragione di questa differenza rispetto al vecchio standard, presente anche
questa differenza rispetto allo standard POSIX.}
Dato che \func{link} crea semplicemente dei nomi che fanno riferimenti agli
-\itindex{inode} \textit{inode}, essa 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 collegamento
-diretto ad una directory.
+\textit{inode}, essa 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 collegamento diretto ad una
+directory.
Per ovviare a queste limitazioni, come accennato all'inizio, i sistemi
unix-like supportano un'altra forma di collegamento, detta
Il meccanismo funziona in quanto i \textit{symbolic link} sono riconosciuti
come tali dal kernel\footnote{è uno dei diversi tipi di file visti in
- tab.~\ref{tab:file_file_types}, contrassegnato come tale \itindex{inode}
- nell'\textit{inode} e riconoscibile dal valore del campo \var{st\_mode}
- della struttura \struct{stat} (vedi sez.~\ref{sec:file_stat}).} e tutta una
-serie di funzioni di sistema (come \func{open} o \func{stat}) quando ricevono
-come argomento il \textit{pathname} di un collegamento simbolico vanno
+ 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}).} e tutta una serie di
+funzioni di sistema (come \func{open} o \func{stat}) quando ricevono come
+argomento il \textit{pathname} di un collegamento simbolico vanno
automaticamente ad operare sul file da esso specificato. La funzione di
sistema che permette di creare un nuovo collegamento simbolico è
\funcd{symlink}, ed il suo prototipo è:
Per questo motivo il kernel e le librerie prevedono che nella risoluzione di
un \textit{pathname} possano essere seguiti fino ad un certo numero massimo di
collegamenti simbolici, il cui valore limite è specificato dalla costante
-\const{MAXSYMLINKS}. Qualora questo limite venga superato viene generato un
+\constd{MAXSYMLINKS}. Qualora questo limite venga superato viene generato un
errore ed \var{errno} viene impostata al valore \errcode{ELOOP}, che nella
quasi totalità dei casi indica appunto che si è creato un collegamento
simbolico che fa riferimento ad una directory del suo stesso
\itindend{symbolic~link}
\index{collegamento!simbolico|)}
-
Un'altra funzione relativa alla gestione dei nomi dei file, anche se a prima
vista parrebbe riguardare un argomento completamente diverso, è quella che per
la cancellazione di un file. In realtà una \textit{system call} che serva
proprio a cancellare un file non esiste neanche perché, come accennato in
sez.~\ref{sec:file_filesystem}, quando in un sistema unix-like si richiede la
rimozione di un file quella che si va a cancellare è soltanto la voce che
-referenzia il suo \itindex{inode} \textit{inode} all'interno di una directory.
+referenzia il suo \textit{inode} all'interno di una directory.
La funzione di sistema che consente di effettuare questa operazione, il cui
nome come si può notare ha poco a che fare con il concetto di rimozione, è
\item[\errcode{EISDIR}] \param{pathname} si riferisce ad una
directory.
\item[\errcode{EPERM}] il filesystem non consente l'operazione, o la
- directory che contiene \param{pathname} ha lo \itindex{sticky~bit}
- \textit{sticky bit} e non si è il proprietario o non si hanno privilegi
- amministrativi.
+ directory che contiene \param{pathname} ha lo \textit{sticky bit} e non si
+ è il proprietario o non si hanno privilegi amministrativi.
\end{errlist} ed inoltre \errval{EFAULT}, \errval{EIO}, \errval{ELOOP},
\errval{ENOENT}, \errval{ENOMEM}, \errval{ENOTDIR}, \errval{EROFS} nel loro
significato generico.}
La funzione elimina il nome specificato dall'argomento \param{pathname} nella
directory che lo contiene e decrementa il numero di riferimenti nel relativo
-\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.
+\textit{inode}.\footnote{come per \func{link} queste due operazioni sono
+ effettuate all'interno della \textit{system call} in maniera atomica.} Nel
+caso di socket, \textit{fifo} o file di dispositivo rimuove il nome, ma come
+per i file normali i processi che hanno aperto uno di questi oggetti possono
+continuare ad utilizzarli. Nel caso di cancellazione di un collegamento
+simbolico, che consiste solo nel rimando ad un altro file, questo viene
+immediatamente eliminato.
Per cancellare una voce in una directory è necessario avere il permesso di
scrittura su di essa, dato che si va a rimuovere una voce dal suo contenuto, e
il diritto di esecuzione/attraversamento sulla directory che la contiene
(affronteremo in dettaglio l'argomento dei permessi di file e directory in
-sez.~\ref{sec:file_access_control}). Se inoltre lo \itindex{sticky~bit}
-\textit{sticky bit} (vedi sez.~\ref{sec:file_special_perm}) è impostato
-occorrerà anche essere proprietari del file o proprietari della directory o
-avere i privilegi di amministratore.
+sez.~\ref{sec:file_access_control}). Se inoltre lo \textit{sticky bit} (vedi
+sez.~\ref{sec:file_special_perm}) è impostato occorrerà anche essere
+proprietari del file o proprietari della directory o avere i privilegi di
+amministratore.
Si ricordi inoltre che anche se se ne è rimosso il nome da una directory, un
file non viene eliminato dal disco fintanto che tutti i riferimenti ad esso
sono stati cancellati: solo quando il numero di collegamenti mantenuto
-\itindex{inode} nell'\textit{inode} diventa nullo, questo viene disallocato e
-lo spazio occupato su disco viene liberato. Si tenga presente comunque che a
-questo si aggiunge sempre un'ulteriore condizione e cioè che non ci siano
-processi che abbiano il suddetto file aperto.\footnote{come vedremo in
+nell'\textit{inode} diventa nullo, questo viene disallocato e lo spazio
+occupato su disco viene liberato. Si tenga presente comunque che a questo si
+aggiunge sempre un'ulteriore condizione e cioè che non ci siano processi che
+abbiano il suddetto file aperto.\footnote{come vedremo in
sez.~\ref{sec:file_unix_interface} il kernel mantiene anche una tabella dei
file aperti nei vari processi, che a sua volta contiene i riferimenti agli
- \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.}
+ \textit{inode} ad essi relativi; prima di procedere alla cancellazione dello
+ spazio occupato su disco dal contenuto di un file il kernel controlla anche
+ questa tabella, per verificare che anche in essa non ci sia più nessun
+ riferimento all'\textit{inode} in questione.}
Questa caratteristica del sistema può essere usata per essere sicuri di non
lasciare file temporanei su disco in caso di crash di un programma. La tecnica
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
directory o \param{oldpath} è una directory e
\param{newpath} esiste e non è una directory.
\item[\errval{EPERM}] la directory contenente \param{oldpath} o quella
- contenente un \param{newpath} esistente hanno lo
- \itindex{sticky~bit} \textit{sticky bit} e non si è i proprietari dei
- rispettivi file (o non si hanno privilegi amministrativi) oppure il
- filesystem non supporta l'operazione.
+ contenente un \param{newpath} esistente hanno lo \textit{sticky bit} e non
+ si è i proprietari dei rispettivi file (o non si hanno privilegi
+ amministrativi) oppure il filesystem non supporta l'operazione.
\item[\errcode{EXDEV}] \param{oldpath} e \param{newpath} non sono sullo
- stesso filesystem e sotto lo stesso \itindex{mount~point} \textit{mount
- point}.
+ stesso filesystem e sotto lo stesso \textit{mount point}.
\end{errlist} ed inoltre \errval{EFAULT}, \errval{ELOOP}, \errval{EMLINK},
\errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM}, \errval{ENOSPC} e
\errval{EROFS} nel loro significato generico.}
La funzione rinomina in \param{newpath} il file o la directory indicati
dall'argomento \param{oldpath}. Il nome viene eliminato nella directory
originale e ricreato nella directory di destinazione mantenendo il riferimento
-allo stesso \itindex{inode} \textit{inode}. Non viene spostato nessun dato e
-\itindex{inode} l'\textit{inode} del file non subisce nessuna modifica in
-quanto le modifiche sono eseguite sulle directory che
-contengono \param{newpath} ed \param{oldpath}.
+allo stesso \textit{inode}. Non viene spostato nessun dato e l'\textit{inode}
+del file non subisce nessuna modifica in quanto le modifiche sono eseguite
+sulle directory che contengono \param{newpath} ed \param{oldpath}.
Il vantaggio nell'uso di questa funzione al posto della chiamata successiva di
\func{link} e \func{unlink} è che l'operazione è eseguita atomicamente, non
Dato che opera in maniera analoga la funzione è soggetta alle stesse
restrizioni di \func{link}, quindi è necessario che \param{oldpath}
e \param{newpath} siano nello stesso filesystem e facciano riferimento allo
-stesso \itindex{mount~point} \textit{mount point}, e che il filesystem
-supporti questo tipo di operazione. Qualora questo non avvenga si dovrà
-effettuare l'operazione in maniera non atomica copiando il file a destinazione
-e poi cancellando l'originale.
+stesso \textit{mount point}, e che il filesystem supporti questo tipo di
+operazione. Qualora questo non avvenga si dovrà effettuare l'operazione in
+maniera non atomica copiando il file a destinazione e poi cancellando
+l'originale.
Il comportamento della funzione è diverso a seconda che si voglia rinominare
un file o una directory. Se ci riferisce ad un file allora \param{newpath}, se
contenenti \param{oldpath} e \param{newpath}, e nel caso \param{newpath} sia
una directory vuota già esistente anche su di essa (perché dovrà essere
aggiornata la voce ``\texttt{..}''). Se poi le directory
-contenenti \param{oldpath} o \param{newpath} hanno lo \itindex{sticky~bit}
-\textit{sticky bit} attivo (vedi sez.~\ref{sec:file_special_perm}) si dovrà
-essere i proprietari dei file (o delle directory) che si vogliono rinominare,
-o avere i permessi di amministratore.
+contenenti \param{oldpath} o \param{newpath} hanno lo \textit{sticky bit}
+attivo (vedi sez.~\ref{sec:file_special_perm}) si dovrà essere i proprietari
+dei file (o delle directory) che si vogliono rinominare, o avere i permessi di
+amministratore.
\subsection{La creazione e la cancellazione delle directory}
\label{sec:file_dir_creat_rem}
Benché in sostanza le directory non siano altro che dei file contenenti
-elenchi di nomi con riferimenti ai rispettivi \itindex{inode} \textit{inode},
-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
+elenchi di nomi con riferimenti ai rispettivi \textit{inode}, 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 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 è:
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
directory, oppure la directory che contiene \param{dirname} ha lo
- \itindex{sticky~bit} \textit{sticky bit} impostato e non si è i
- proprietari della directory o non si hanno privilegi amministrativi.
+ \textit{sticky bit} impostato e non si è i proprietari della directory o
+ non si hanno privilegi amministrativi.
\end{errlist}
ed inoltre \errval{EFAULT}, \errval{ELOOP}, \errval{ENAMETOOLONG},
\errval{ENOENT}, \errval{ENOMEM}, \errval{ENOTDIR}, \errcode{ENOTEMPTY} e
\label{sec:file_dir_read}
Benché le directory alla fine non siano altro che dei file che contengono
-delle liste di nomi associati ai relativi \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.
+delle liste di nomi associati ai relativi \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
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}
\end{funcproto}
La funzione apre un \textit{directory stream} per la directory
-\param{dirname}, ritornando il puntatore ad un oggetto di tipo \type{DIR} (che
-è il \index{tipo!opaco} tipo opaco usato dalle librerie per gestire i
-\textit{directory stream}) da usare per tutte le operazioni successive, la
-funzione inoltre posiziona lo \textit{stream} sulla prima voce contenuta nella
-directory.
+\param{dirname}, ritornando il puntatore ad un oggetto di tipo \typed{DIR} (che
+è il tipo opaco usato dalle librerie per gestire i \textit{directory stream})
+da usare per tutte le operazioni successive, la funzione inoltre posiziona lo
+\textit{stream} sulla prima voce contenuta nella directory.
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
-sez.~\ref{sec:file_work_dir}).
+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 è
possibile associarvi un \textit{directory stream} con la funzione
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
-prototipo è:
+può essere utilizzata anche con i \textit{thread}, il suo prototipo è:
\begin{funcproto}{
\fhead{sys/types.h}
\func{readdir}.}
\end{funcproto}
-La funzione restituisce in \param{result} come \itindex{value~result~argument}
-\textit{value result argument} l'indirizzo della struttura \struct{dirent}
-dove sono stati salvati i dati, che deve essere allocata dal chiamante, ed il
-cui indirizzo deve essere indicato con l'argomento \param{entry}. Se si è
-raggiunta la fine del \textit{directory stream} invece in \param{result} viene
-restituito il valore \val{NULL}.
+La funzione restituisce in \param{result} come \textit{value result argument}
+l'indirizzo della struttura \struct{dirent} dove sono stati salvati i dati,
+che deve essere allocata dal chiamante, ed il cui indirizzo deve essere
+indicato con l'argomento \param{entry}. Se si è raggiunta la fine del
+\textit{directory stream} invece in \param{result} viene restituito il valore
+\val{NULL}.
\begin{figure}[!htb]
\footnotesize \centering
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, ed il campo \var{d\_ino}, che contiene il numero di
-\itindex{inode} \textit{inode} cui il file è associato e corrisponde al campo
-\var{st\_ino} di \struct{stat}. La presenza di ulteriori campi opzionali
-oltre i due citati è segnalata dalla definizione di altrettante macro nella
-forma \code{\_DIRENT\_HAVE\_D\_XXX} dove \code{XXX} è il nome del relativo
+\textit{inode} cui il file è associato e corrisponde al campo \var{st\_ino} di
+\struct{stat}. La presenza di ulteriori campi opzionali oltre i due citati è
+segnalata dalla definizione di altrettante macro nella forma
+\code{\_DIRENT\_HAVE\_D\_XXX} dove \code{XXX} è il nome del relativo
campo. Come si può evincere da fig.~\ref{fig:file_dirent_struct} nel caso di
-Linux sono pertanto definite le macro \macro{\_DIRENT\_HAVE\_D\_TYPE},
-\macro{\_DIRENT\_HAVE\_D\_OFF} e \macro{\_DIRENT\_HAVE\_D\_RECLEN}, mentre non
-è definita la macro \macro{\_DIRENT\_HAVE\_D\_NAMLEN}.
+Linux sono pertanto definite le macro \macrod{\_DIRENT\_HAVE\_D\_TYPE},
+\macrod{\_DIRENT\_HAVE\_D\_OFF} e \macrod{\_DIRENT\_HAVE\_D\_RECLEN}, mentre non
+è definita la macro \macrod{\_DIRENT\_HAVE\_D\_NAMLEN}.
Dato che possono essere presenti campi opzionali e che lo standard
POSIX.1-2001 non specifica una dimensione definita per il nome dei file (che
\vspace{3pt}
\begin{funcbox}{
\fhead{stddef.h}
-\fdecl{size\_t \macro{offsetof}(type, member)}
+\fdecl{size\_t \macrod{offsetof}(type, member)}
\fdesc{Restituisce la posizione del campo \param{member} nella
struttura \param{type}.}
}
della stringa.
Per quanto riguarda il significato dei campi opzionali, il campo \var{d\_type}
-indica il tipo di file (se fifo, directory, collegamento simbolico, ecc.), e
-consente di evitare una successiva chiamata a \func{lstat} (vedi
+indica il tipo di file (se \textit{fifo}, directory, collegamento simbolico,
+ecc.), e consente di evitare una successiva chiamata a \func{lstat} (vedi
sez.~\ref{sec:file_stat}) per determinarlo. I suoi possibili valori sono
riportati in tab.~\ref{tab:file_dtype_macro}. Si tenga presente che questo
valore è disponibile solo per i filesystem che ne supportano la restituzione
\textbf{Valore} & \textbf{Tipo di file} \\
\hline
\hline
- \const{DT\_UNKNOWN} & Tipo sconosciuto.\\
- \const{DT\_REG} & File normale.\\
- \const{DT\_DIR} & Directory.\\
- \const{DT\_LNK} & Collegamento simbolico.\\
- \const{DT\_FIFO} & Fifo.\\
- \const{DT\_SOCK} & Socket.\\
- \const{DT\_CHR} & Dispositivo a caratteri.\\
- \const{DT\_BLK} & Dispositivo a blocchi.\\
+ \constd{DT\_UNKNOWN} & Tipo sconosciuto.\\
+ \constd{DT\_REG} & File normale.\\
+ \constd{DT\_DIR} & Directory.\\
+ \constd{DT\_LNK} & Collegamento simbolico.\\
+ \constd{DT\_FIFO} & \textit{Fifo}.\\
+ \constd{DT\_SOCK} & Socket.\\
+ \constd{DT\_CHR} & Dispositivo a caratteri.\\
+ \constd{DT\_BLK} & Dispositivo a blocchi.\\
\hline
\end{tabular}
\caption{Costanti che indicano i vari tipi di file nel campo \var{d\_type}
\vspace{3pt}
\begin{funcbox}{
\fhead{dirent.h}
-\fdecl{int \macro{IFTODT}(mode\_t MODE)}
+\fdecl{int \macrod{IFTODT}(mode\_t MODE)}
\fdesc{Converte il tipo di file dal formato di \var{st\_mode} a quello di
\var{d\_type}.}
-\fdecl{mode\_t \macro{DTTOIF}(int DTYPE)}
+\fdecl{mode\_t \macrod{DTTOIF}(int DTYPE)}
\fdesc{Converte il tipo di file dal formato di \var{d\_type} a quello di
\var{st\_mode}.}
}
alla fine l'indirizzo della lista ordinata dei puntatori alle strutture
\struct{dirent} viene restituito nell'argomento
\param{namelist}.\footnote{la funzione alloca automaticamente la lista, e
- restituisce, come \itindex{value~result~argument} \textit{value result
- argument}, l'indirizzo della stessa; questo significa che \param{namelist}
- deve essere dichiarato come \code{struct dirent **namelist} ed alla funzione
- si deve passare il suo indirizzo.}
+ restituisce, come \textit{value result argument}, l'indirizzo della stessa;
+ questo significa che \param{namelist} deve essere dichiarato come
+ \code{struct dirent **namelist} ed alla funzione si deve passare il suo
+ indirizzo.}
\itindend{directory~stream}
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
precisamente nel campo \texttt{pwd} della sotto-struttura
\kstruct{fs\_struct}.} che è chiamata \textsl{directory corrente} o
\textsl{directory di lavoro} (in inglese \textit{current working directory}).
-La directory di lavoro è quella da cui si parte quando un
-\itindsub{pathname}{relativo} \textit{pathname} è espresso in forma relativa,
-dove il ``\textsl{relativa}'' fa riferimento appunto a questa directory.
+La directory di lavoro è quella da cui si parte quando un \textit{pathname} è
+espresso in forma relativa, dove il ``\textsl{relativa}'' fa riferimento
+appunto a questa directory.
Quando un utente effettua il login, questa directory viene impostata alla
\textit{home directory} del suo account. Il comando \cmd{cd} della shell
sez.~\ref{sec:proc_fork}), la directory di lavoro della shell diventa anche la
directory di lavoro di qualunque comando da essa lanciato.
-Dato che è il kernel che tiene traccia per ciascun processo \itindex{inode}
+Dato che è il kernel che tiene traccia per ciascun processo
dell'\textit{inode} della directory di lavoro, per ottenerne il
\textit{pathname} occorre usare una apposita funzione,
\funcd{getcwd},\footnote{con Linux \func{getcwd} è una \textit{system call}
Finora abbiamo parlato esclusivamente di file, directory e collegamenti
simbolici, ma in sez.~\ref{sec:file_file_types} abbiamo visto che il sistema
prevede anche degli altri tipi di file, che in genere vanno sotto il nome
-generico di \textsl{file speciali}, come i file di dispositivo, le fifo ed i
+generico di \textsl{file speciali}, come i file di dispositivo, le \textit{fifo} ed i
socket.
La manipolazione delle caratteristiche di questi file speciali, il cambiamento
\item[\errcode{EEXIST}] \param{pathname} esiste già o è un collegamento
simbolico.
\item[\errcode{EINVAL}] il valore di \param{mode} non indica un file, una
- fifo, un socket o un dispositivo.
+ \textit{fifo}, un socket o un dispositivo.
\item[\errcode{EPERM}] non si hanno privilegi sufficienti a creare
- \itindex{inode} l'\texttt{inode}, o il filesystem su cui si è cercato di
+ l'\texttt{inode}, o il filesystem su cui si è cercato di
creare \param{pathname} non supporta l'operazione.
\end{errlist}
ed inoltre \errval{EACCES}, \errval{EFAULT}, \errval{ELOOP},
\errval{ENOTDIR} e \errval{EROFS} nel loro significato generico.}
\end{funcproto}
-La funzione permette di creare un \itindex{inode} \textit{inode} di tipo
-generico sul filesystem, e viene in genere utilizzata per creare i file di
-dispositivo, ma si può usare anche per creare qualunque tipo di file speciale
-ed anche 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
+La funzione permette di creare un \textit{inode} di tipo generico sul
+filesystem, e viene in genere utilizzata per creare i file di dispositivo, ma
+si può usare anche per creare qualunque tipo di file speciale ed anche 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 aritmetico. I
permessi sono comunque modificati nella maniera usuale dal valore di
-\itindex{umask} \textit{umask} (si veda sez.~\ref{sec:file_perm_management}).
+\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 collegamenti simbolici, si dovranno usare le funzioni
+per una \textit{fifo};\footnote{con Linux la funzione non può essere usata per
+ creare directory o collegamenti simbolici, si dovranno usare le funzioni
\func{mkdir} e \func{symlink} a questo dedicate.} un valore diverso
comporterà l'errore \errcode{EINVAL}. Inoltre \param{pathname} non deve
esistere, neanche come collegamento simbolico.
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.
-
-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
-gruppo effettivo) che li ha creati a meno non sia presente il bit \acr{sgid}
-per la directory o sia stata attivata la semantica BSD per il filesystem (si
-veda sez.~\ref{sec:file_ownership_management}) in cui si va a creare
-\itindex{inode} l'\textit{inode}, nel qual caso per il gruppo verrà usato il
-\ids{GID} del proprietario della directory.
+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 \textit{fifo}, ma comunque deprecata essendo utilizzabile a tale scopo
+ la specifica \func{mkfifo}.} l'uso per la creazione di un file ordinario, di
+una \textit{fifo} o di un socket è consentito anche agli utenti normali.
+
+I nuovi \textit{inode} creati con \func{mknod} apparterranno al proprietario e
+al gruppo del processo (usando \ids{UID} e \ids{GID} del gruppo effettivo) che
+li ha creati a meno non sia presente il bit \acr{sgid} per la directory o sia
+stata attivata la semantica BSD per il filesystem (si veda
+sez.~\ref{sec:file_ownership_management}) in cui si va a creare
+l'\textit{inode}, nel qual caso per il gruppo verrà usato il \ids{GID} del
+proprietario della directory.
+
+\itindbeg{major~number}
+\itindbeg{minor~number}
Nella creazione di un file di dispositivo occorre poi specificare
correttamente il valore di \param{dev}; questo infatti è di tipo
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 uno dei dischi presenti) 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.
+bit diviso in due parti di 8 bit chiamate rispettivamente \textit{major
+ number} e \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 \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 uno dei dischi presenti) si usa invece il \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
-comportato il fatto che \type{dev\_t} è diventato un \index{tipo!opaco} 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 \headfile{sys/sysmacros.h},\footnote{se si usa
- la \acr{glibc} dalla versione 2.3.3 queste macro sono degli alias alle
- versioni specifiche di questa libreria, \macro{gnu\_dev\_major},
- \macro{gnu\_dev\_minor} e \macro{gnu\_dev\_makedev} che si possono usare
- direttamente, al costo di una minore portabilità.} che viene
-automaticamente incluso quando si include \headfile{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}:
+\type{dev\_t}, con delle dimensioni passate a 12 bit per il \textit{major
+ number} e 20 bit per il \textit{minor number}. La transizione però ha
+comportato il fatto che \type{dev\_t} è diventato un 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 \headfiled{sys/sysmacros.h},\footnote{se si
+ usa la \acr{glibc} dalla versione 2.3.3 queste macro sono degli alias alle
+ versioni specifiche di questa libreria, \macrod{gnu\_dev\_major},
+ \macrod{gnu\_dev\_minor} e \macrod{gnu\_dev\_makedev} che si possono usare
+ direttamente, al costo di una minore portabilità.} che viene automaticamente
+incluso quando si include \headfile{sys/types.h}. Si possono pertanto ottenere
+i valori del \textit{major number} e \textit{minor number} di un dispositivo
+rispettivamente con le macro \macro{major} e \macro{minor}:
{\centering
\vspace{3pt}
\begin{funcbox}{
\fhead{sys/types.h}
-\fdecl{int \macro{major}(dev\_t dev)}
-\fdesc{Restituisce il \itindex{major~number} \textit{major number} del
- dispositivo \param{dev}.}
-\fdecl{int \macro{minor}(dev\_t dev)}
-\fdesc{Restituisce il \itindex{minor~number} \textit{minor number} del
- dispositivo \param{dev}.}
+\fdecl{int \macrod{major}(dev\_t dev)}
+\fdesc{Restituisce il \textit{major number} del dispositivo \param{dev}.}
+\fdecl{int \macrod{minor}(dev\_t dev)}
+\fdesc{Restituisce il \textit{minor number} del dispositivo \param{dev}.}
}
\end{funcbox}
}
-\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}:
+\noindent mentre una volta che siano noti \textit{major number} e
+\textit{minor number} si potrà costruire il relativo identificativo con la
+macro \macro{makedev}:
{\centering
\vspace{3pt}
\begin{funcbox}{
\fhead{sys/types.h}
-\fdecl{dev\_t \macro{makedev}(int major, int minor)}
-\fdesc{Dati \itindex{major~number} \textit{major number} e
- \itindex{minor~number} \textit{minor number} restituisce l'identificativo di
- un dispositivo.}
+\fdecl{dev\_t \macrod{makedev}(int major, int minor)}
+\fdesc{Dati \textit{major number} e \textit{minor number} restituisce
+ l'identificativo di un dispositivo.}
}
\end{funcbox}
}
+
+\itindend{major~number}
+\itindend{minor~number}
\index{file!di~dispositivo|)}
Dato che la funzione di sistema \func{mknod} presenta diverse varianti nei
vari sistemi unix-like, lo standard POSIX.1-2001 la dichiara portabile solo in
-caso di creazione delle fifo, ma anche in questo caso alcune combinazioni
-degli argomenti restano non specificate, per cui nello stesso standard è stata
-introdotta una funzione specifica per creare una fifo deprecando l'uso di
-\func{mknod} a tale riguardo. La funzione è \funcd{mkfifo} ed il suo
-prototipo è:
+caso di creazione delle \textit{fifo}, ma anche in questo caso alcune
+combinazioni degli argomenti restano non specificate, per cui nello stesso
+standard è stata introdotta una funzione specifica per creare una
+\textit{fifo} deprecando l'uso di \func{mknod} a tale riguardo. La funzione è
+\funcd{mkfifo} ed il suo prototipo è:
\begin{funcproto}{
\fhead{sys/types.h}
\fhead{sys/stat.h}
\fdecl{int mkfifo(const char *pathname, mode\_t mode)}
-\fdesc{Crea una fifo.}
+\fdesc{Crea una \textit{fifo}.}
}
{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
caso \var{errno} assumerà \errval{EACCES}, \errval{EEXIST},
\errval{EROFS} nel loro significato generico.}
\end{funcproto}
-La funzione crea la fifo \param{pathname} con i permessi \param{mode}. Come
-per \func{mknod} il file \param{pathname} non deve esistere (neanche come
-collegamento simbolico); al solito i permessi specificati da \param{mode}
-vengono modificati dal valore di \itindex{umask} \textit{umask}.
+La funzione crea la \textit{fifo} \param{pathname} con i
+permessi \param{mode}. Come per \func{mknod} il file \param{pathname} non deve
+esistere (neanche come collegamento simbolico); al solito i permessi
+specificati da \param{mode} vengono modificati dal valore di \textit{umask}
+(vedi sez.~\ref{sec:file_perm_management}).
\index{file!speciali|)}
sembri semplice, in realtà il problema è più sottile di quanto non appaia a
prima vista. Infatti anche se sembrerebbe banale generare un nome a caso e
creare il file dopo aver controllato che questo non esista, nel momento fra il
-controllo e la creazione si ha giusto lo spazio per una possibile
-\itindex{race~condition} \textit{race condition} (si ricordi quanto visto in
-sez.~\ref{sec:proc_race_cond}).
+controllo e la creazione si ha giusto lo spazio per una possibile \textit{race
+ condition} (si ricordi quanto visto in sez.~\ref{sec:proc_race_cond}).
+
+\itindbeg{symlink~attack}
Molti problemi di sicurezza derivano proprio da una creazione non accorta di
-file temporanei che lascia aperta questa \itindex{race~condition} \textit{race
- condition}. Un attaccante allora potrà sfruttarla con quello che viene
-chiamato \itindex{symlink~attack} ``\textit{symlink attack}'' dove
-nell'intervallo fra la generazione di un nome e l'accesso allo stesso, viene
-creato un collegamento simbolico con quel nome verso un file diverso,
-ottenendo, se il programma sotto attacco ne ha la capacità, un accesso
-privilegiato.
+file temporanei che lascia aperta questa \textit{race condition}. Un
+attaccante allora potrà sfruttarla con quello che viene chiamato
+``\textit{symlink attack}'' dove nell'intervallo fra la generazione di un nome
+e l'accesso allo stesso, viene creato un collegamento simbolico con quel nome
+verso un file diverso, ottenendo, se il programma sotto attacco ne ha la
+capacità, un accesso privilegiato.
+
+\itindend{symlink~attack}
La \acr{glibc} provvede varie funzioni per generare nomi di file temporanei,
di cui si abbia certezza di unicità al momento della generazione; storicamente
La funzione restituisce il puntatore ad una stringa contente un nome di file
valido e non esistente al momento dell'invocazione. Se si è passato come
argomento \param{string} un puntatore non nullo ad un buffer di caratteri
-questo deve essere di dimensione \const{L\_tmpnam} ed il nome generato vi
+questo deve essere di dimensione \constd{L\_tmpnam} ed il nome generato vi
verrà copiato automaticamente, altrimenti il nome sarà generato in un buffer
statico interno che verrà sovrascritto ad una chiamata successiva. Successive
invocazioni della funzione continueranno a restituire nomi unici fino ad un
-massimo di \const{TMP\_MAX} volte, limite oltre il quale il comportamento è
+massimo di \constd{TMP\_MAX} volte, limite oltre il quale il comportamento è
indefinito. Al nome viene automaticamente aggiunto come prefisso la directory
-specificata dalla costante \const{P\_tmpdir}.\footnote{le costanti
+specificata dalla costante \constd{P\_tmpdir}.\footnote{le costanti
\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,
-\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 è:
+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 è:
\begin{funcproto}{
\fhead{stdio.h}
\end{funcproto}
La funzione alloca con \code{malloc} la stringa in cui restituisce il nome,
-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 accessibile, la prima valida fra le seguenti:
+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, verificando che esista e sia
+accessibile, la prima valida fra le seguenti:
\begin{itemize*}
\item la variabile di ambiente \envvar{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}),
+ definita o se il programma chiamante è \acr{suid} o \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}.
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
+\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
La funzione genera un nome univoco sostituendo le \code{XXXXXX} finali di
\param{template}; dato che \param{template} deve poter essere modificata dalla
funzione non si può usare una stringa costante. Tutte le avvertenze riguardo
-alle possibili \itindex{race~condition} \textit{race condition} date per
-\func{tmpnam} continuano a valere; inoltre in alcune vecchie implementazioni
-il valore usato per sostituire le \code{XXXXXX} viene formato con il \ids{PID}
-del processo più una lettera, il che mette a disposizione solo 26 possibilità
-diverse per il nome del file, e rende il nome temporaneo facile da indovinare.
-Per tutti questi motivi la funzione è deprecata e non dovrebbe mai essere
-usata.
+alle possibili \textit{race condition} date per \func{tmpnam} continuano a
+valere; inoltre in alcune vecchie implementazioni il valore usato per
+sostituire le \code{XXXXXX} viene formato con il \ids{PID} del processo più
+una lettera, il che mette a disposizione solo 26 possibilità diverse per il
+nome del file, e rende il nome temporaneo facile da indovinare. Per tutti
+questi motivi la funzione è deprecata e non dovrebbe mai essere usata.
La seconda funzione, \funcd{mkstemp} è sostanzialmente equivalente a
\func{tmpfile}, ma restituisce un file descriptor invece di un nome; il suo
La funzione crea una directory temporanea il cui nome è ottenuto sostituendo
le \code{XXXXXX} finali di \param{template} con permessi \code{0700} (si veda
sez.~\ref{sec:file_perm_overview} per i dettagli). Dato che la creazione della
-directory è sempre esclusiva i precedenti problemi di \itindex{race~condition}
-\textit{race condition} non si pongono.
+directory è sempre esclusiva i precedenti problemi di \textit{race condition}
+non si pongono.
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 \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 \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}.
+relative al controllo di accesso, sono mantenute 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
+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}.
\subsection{La lettura delle caratteristiche dei file}
tramite il suo file descriptor \param{filedes}.
La struttura \struct{stat} usata da queste funzioni è definita nell'header
-\headfile{sys/stat.h} e in generale dipende dall'implementazione; la versione
+\headfiled{sys/stat.h} e in generale dipende dall'implementazione; la versione
usata da Linux è mostrata in fig.~\ref{fig:file_stat_struct}, così come
riportata dalla pagina di manuale di \func{stat}. In realtà la definizione
effettivamente usata nel kernel dipende dall'architettura e ha altri campi
Si noti come i vari membri della struttura siano specificati come tipi
primitivi del sistema, di quelli definiti in
tab.~\ref{tab:intro_primitive_types}, e dichiarati in \headfile{sys/types.h},
-con l'eccezione di \type{blksize\_t} e \type{blkcnt\_t} che sono nuovi tipi
+con l'eccezione di \typed{blksize\_t} e \typed{blkcnt\_t} che sono nuovi tipi
introdotti per rendersi indipendenti dalla piattaforma.
Benché la descrizione dei commenti di fig.~\ref{fig:file_stat_struct} sia
fanno riferimento al file (il cosiddetto \textit{link count}) di cui abbiamo
già parlato in numerose occasioni.
-\item Il campo \var{st\_ino} contiene il numero di \itindex{inode}
- \textit{inode} del file, quello viene usato all'interno del filesystem per
- identificarlo e che può essere usato da un programma per determinare se due
- \textit{pathname} fanno riferimento allo stesso file.
+\item Il campo \var{st\_ino} contiene il numero di \textit{inode} del file,
+ quello viene usato all'interno del filesystem per identificarlo e che può
+ essere usato da un programma per determinare se due \textit{pathname} fanno
+ riferimento allo stesso file.
\item Il campo \var{st\_dev} contiene il numero del dispositivo su cui risiede
il file (o meglio il suo filesystem). Si tratta dello stesso numero che si
- usa con \func{mknod} e che può essere decomposto in \itindex{major~number}
- \textit{major number} e \itindex{minor~number} \textit{minor number} con le
- macro \macro{major} e \macro{minor} viste in sez.~\ref{sec:file_mknod}.
+ usa con \func{mknod} e che può essere decomposto in \textit{major number} e
+ \textit{minor number} con le macro \macro{major} e \macro{minor} viste in
+ sez.~\ref{sec:file_mknod}.
\item Il campo \var{st\_rdev} contiene il numero di dispositivo associato al
file stesso ed ovviamente ha un valore significativo soltanto quando il file
\textbf{Macro} & \textbf{Tipo del file} \\
\hline
\hline
- \macro{S\_ISREG}\texttt{(m)} & File normale.\\
- \macro{S\_ISDIR}\texttt{(m)} & Directory.\\
- \macro{S\_ISCHR}\texttt{(m)} & Dispositivo a caratteri.\\
- \macro{S\_ISBLK}\texttt{(m)} & Dispositivo a blocchi.\\
- \macro{S\_ISFIFO}\texttt{(m)} & Fifo.\\
- \macro{S\_ISLNK}\texttt{(m)} & Collegamento simbolico.\\
- \macro{S\_ISSOCK}\texttt{(m)} & Socket.\\
+ \macrod{S\_ISREG}\texttt{(m)} & File normale.\\
+ \macrod{S\_ISDIR}\texttt{(m)} & Directory.\\
+ \macrod{S\_ISCHR}\texttt{(m)} & Dispositivo a caratteri.\\
+ \macrod{S\_ISBLK}\texttt{(m)} & Dispositivo a blocchi.\\
+ \macrod{S\_ISFIFO}\texttt{(m)} & \textit{Fifo}.\\
+ \macrod{S\_ISLNK}\texttt{(m)} & Collegamento simbolico.\\
+ \macrod{S\_ISSOCK}\texttt{(m)} & Socket.\\
\hline
\end{tabular}
\caption{Macro per i tipi di file (definite in \headfile{sys/stat.h}).}
\textbf{Flag} & \textbf{Valore} & \textbf{Significato} \\
\hline
\hline
- \const{S\_IFMT} & 0170000 & Maschera per i bit del tipo di file.\\
- \const{S\_IFSOCK} & 0140000 & Socket.\\
- \const{S\_IFLNK} & 0120000 & Collegamento simbolico.\\
- \const{S\_IFREG} & 0100000 & File regolare.\\
- \const{S\_IFBLK} & 0060000 & Dispositivo a blocchi.\\
- \const{S\_IFDIR} & 0040000 & Directory.\\
- \const{S\_IFCHR} & 0020000 & Dispositivo a caratteri.\\
- \const{S\_IFIFO} & 0010000 & Fifo.\\
+ \constd{S\_IFMT} & 0170000 & Maschera per i bit del tipo di file.\\
+ \constd{S\_IFSOCK} & 0140000 & Socket.\\
+ \constd{S\_IFLNK} & 0120000 & Collegamento simbolico.\\
+ \constd{S\_IFREG} & 0100000 & File regolare.\\
+ \constd{S\_IFBLK} & 0060000 & Dispositivo a blocchi.\\
+ \constd{S\_IFDIR} & 0040000 & Directory.\\
+ \constd{S\_IFCHR} & 0020000 & Dispositivo a caratteri.\\
+ \constd{S\_IFIFO} & 0010000 & \textit{Fifo}.\\
\hline
- \const{S\_ISUID} & 0004000 & Set user ID \itindex{suid~bit} (\acr{suid})
- bit.\\
- \const{S\_ISGID} & 0002000 & Set group ID \itindex{sgid~bit}
- (\acr{sgid}) bit.\\
- \const{S\_ISVTX} & 0001000 & \itindex{sticky~bit} \acr{Sticky} bit.\\
+ \constd{S\_ISUID} & 0004000 & Set user ID (\acr{suid}) bit, vedi
+ sez.~\ref{sec:file_special_perm}).\\
+ \constd{S\_ISGID} & 0002000 & Set group ID (\acr{sgid}) bit, vedi
+ sez.~\ref{sec:file_special_perm}).\\
+ \constd{S\_ISVTX} & 0001000 & \acr{Sticky} bit, vedi
+ sez.~\ref{sec:file_special_perm}).\\
\hline
- \const{S\_IRWXU} & 00700 & Maschera per i permessi del proprietario.\\
- \const{S\_IRUSR} & 00400 & Il proprietario ha permesso di lettura.\\
- \const{S\_IWUSR} & 00200 & Il proprietario ha permesso di scrittura.\\
- \const{S\_IXUSR} & 00100 & Il proprietario ha permesso di esecuzione.\\
+ \constd{S\_IRWXU} & 00700 & Maschera per i permessi del proprietario.\\
+ \constd{S\_IRUSR} & 00400 & Il proprietario ha permesso di lettura.\\
+ \constd{S\_IWUSR} & 00200 & Il proprietario ha permesso di scrittura.\\
+ \constd{S\_IXUSR} & 00100 & Il proprietario ha permesso di esecuzione.\\
\hline
- \const{S\_IRWXG} & 00070 & Maschera per i permessi del gruppo.\\
- \const{S\_IRGRP} & 00040 & Il gruppo ha permesso di lettura.\\
- \const{S\_IWGRP} & 00020 & Il gruppo ha permesso di scrittura.\\
- \const{S\_IXGRP} & 00010 & Il gruppo ha permesso di esecuzione.\\
+ \constd{S\_IRWXG} & 00070 & Maschera per i permessi del gruppo.\\
+ \constd{S\_IRGRP} & 00040 & Il gruppo ha permesso di lettura.\\
+ \constd{S\_IWGRP} & 00020 & Il gruppo ha permesso di scrittura.\\
+ \constd{S\_IXGRP} & 00010 & Il gruppo ha permesso di esecuzione.\\
\hline
- \const{S\_IRWXO} & 00007 & Maschera per i permessi di tutti gli altri\\
- \const{S\_IROTH} & 00004 & Gli altri hanno permesso di lettura.\\
- \const{S\_IWOTH} & 00002 & Gli altri hanno permesso di esecuzione.\\
- \const{S\_IXOTH} & 00001 & Gli altri hanno permesso di esecuzione.\\
+ \constd{S\_IRWXO} & 00007 & Maschera per i permessi di tutti gli altri\\
+ \constd{S\_IROTH} & 00004 & Gli altri hanno permesso di lettura.\\
+ \constd{S\_IWOTH} & 00002 & Gli altri hanno permesso di esecuzione.\\
+ \constd{S\_IXOTH} & 00001 & Gli altri hanno permesso di esecuzione.\\
\hline
\end{tabular}
\caption{Costanti per l'identificazione dei vari bit che compongono il campo
una struttura \struct{stat} contiene la dimensione del file in byte. Questo
però è vero solo se si tratta di un file regolare, mentre nel caso di un
collegamento simbolico la dimensione è quella del \textit{pathname} che il
-collegamento stesso contiene, infine per le fifo ed i file di dispositivo
+collegamento stesso contiene, infine per le \textit{fifo} ed i file di dispositivo
questo campo è sempre nullo.
Il campo \var{st\_blocks} invece definisce la lunghezza del file in blocchi di
\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}
\label{sec:file_file_times}
Il sistema mantiene per ciascun file tre tempi, che sono registrati
-\itindex{inode} nell'\textit{inode} insieme agli altri attributi del
-file. Questi 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 questi tempi e dei relativi
-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
+nell'\textit{inode} insieme agli altri attributi del file. Questi 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 questi tempi e dei relativi 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 \textit{calendar time}, su cui
torneremo in dettaglio in sez.~\ref{sec:sys_time}.
\begin{table}[htb]
ed il tempo di ultimo cambiamento di stato (il \textit{change status time})
riportato in \var{st\_ctime}. Il primo infatti fa riferimento ad una modifica
del contenuto di un file, mentre il secondo ad una modifica dei metadati
-\itindex{inode} dell'\textit{inode}. Dato che esistono molte operazioni, come
-la funzione \func{link} e 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 questo secondo tempo.
+dell'\textit{inode}. Dato che esistono molte operazioni, come la funzione
+\func{link} e altre che vedremo in seguito, che modificano solo le
+informazioni contenute nell'\textit{inode} senza toccare il contenuto del
+file, diventa necessario l'utilizzo di questo secondo tempo.
Il tempo di ultima modifica viene usato ad esempio da programmi come
\cmd{make} per decidere quali file necessitano di essere ricompilati perché
cancellare gli articoli letti più vecchi, mentre \texttt{mutt} lo usa per
marcare i messaggi di posta che risultano letti.
-Il sistema non tiene mai 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 comando \cmd{ls} (quando usato con le
-opzioni \cmd{-l} o \cmd{-t}) mostra i tempi dei file secondo lo schema
-riportato nell'ultima colonna di tab.~\ref{tab:file_file_times}. Si noti anche
-come non esista, a differenza di altri sistemi operativi, un \textsl{tempo di
- creazione} di un file.
+Il sistema non tiene mai conto dell'ultimo accesso all'\textit{inode},
+pertanto funzioni come \func{access} o \func{stat} non hanno alcuna influenza
+sui tre tempi. Il comando \cmd{ls} (quando usato con le opzioni \cmd{-l} o
+\cmd{-t}) mostra i tempi dei file secondo lo schema riportato nell'ultima
+colonna di tab.~\ref{tab:file_file_times}. Si noti anche come non esista, a
+differenza di altri sistemi operativi, un \textsl{tempo di creazione} di un
+file.
L'aggiornamento del tempo di ultimo accesso è stato a lungo considerato un
difetto progettuale di Unix, questo infatti comporta la necessità di
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.
Si tenga presente che non è possibile modificare manualmente il tempo di
cambiamento di stato del file, che viene aggiornato direttamente dal kernel
-tutte le volte che si modifica \itindex{inode} l'\textit{inode}, e 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 \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
+tutte le volte che si modifica l'\textit{inode}, e 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 è 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.}
(solo \func{utimensat}).
\item[\errcode{EPERM}] si è richiesto un cambiamento nei tempi non al tempo
corrente, ma non si è proprietari del file o non si hanno i privilegi di
- amministratore; oppure il file è \itindex{file~attributes} immutabile o
- \textit{append-only} (vedi sez.~\ref{sec:file_perm_overview}).
+ amministratore; oppure il file è immutabile o \textit{append-only} (vedi
+ sez.~\ref{sec:file_perm_overview}).
\item[\errcode{ESRCH}] non c'è il permesso di attraversamento per una delle
componenti di \param{pathname} (solo \func{utimensat})
\end{errlist}
il valore \val{NULL} verrà impostato il tempo corrente sia per l'ultimo
accesso che per l'ultima modifica. Nei singoli elementi di \param{times} si
possono inoltre utilizzare due valori speciali per il campo \var{tv\_nsec}:
-con \const{UTIME\_NOW} si richiede l'uso del tempo corrente, mentre con
-\const{UTIME\_OMIT} si richiede di non impostare il tempo. Si può così
+con \constd{UTIME\_NOW} si richiede l'uso del tempo corrente, mentre con
+\constd{UTIME\_OMIT} si richiede di non impostare il tempo. Si può così
aggiornare in maniera specifica soltanto uno fra il tempo di ultimo accesso e
quello di ultima modifica. Quando si usa uno di questi valori speciali per
\var{tv\_nsec} il corrispondente valore di \var{tv\_sec} viene ignorato.
seconda supporta invece, rispetto ad \func{utimes}, una sintassi più complessa
che consente una indicazione sicura del file su cui operare specificando la
directory su cui si trova tramite il file descriptor \param{dirfd} ed il suo
-nome come \itindsub{pathname}{relativo} \textit{pathname relativo}
-in \param{pathname}.\footnote{su Linux solo \func{utimensat} è una
- \textit{system call} e \func{futimens} è una funzione di libreria, infatti
- se \param{pathname} è \var{NULL} \param{dirfd} viene considerato un file
- descriptor ordinario e il cambiamento del tempo applicato al file
- sottostante, qualunque esso sia, per cui \code{futimens(fd, times}) è del
- tutto equivalente a \code{utimensat(fd, NULL, times, 0)}.}
+nome come \textit{pathname relativo} in \param{pathname}.\footnote{su Linux
+ solo \func{utimensat} è una \textit{system call} e \func{futimens} è una
+ funzione di libreria, infatti se \param{pathname} è \var{NULL} \param{dirfd}
+ viene considerato un file descriptor ordinario e il cambiamento del tempo
+ applicato al file sottostante, qualunque esso sia, per cui
+ \code{futimens(fd, times}) è del tutto equivalente a \code{utimensat(fd,
+ NULL, times, 0)}.}
Torneremo su questa sintassi e sulla sua motivazione in
sez.~\ref{sec:file_openat}, quando tratteremo tutte le altre funzioni (le
-cosiddette \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}.
tipo Unix, ad esempio non è vero per il filesystem VFAT di Windows, che non
fornisce nessun supporto per l'accesso multiutente, e per il quale queste
proprietà vengono assegnate in maniera fissa con opportune opzioni di
- montaggio.} Anche questi sono mantenuti \itindex{inode} sull'\textit{inode}
-insieme alle altre proprietà e sono accessibili da programma tramite la
-funzione \func{stat} (trattata in sez.~\ref{sec:file_stat}), che restituisce
-l'utente proprietario nel campo \var{st\_uid} ed il gruppo proprietario nel
-campo \var{st\_gid} della omonima struttura \struct{stat}.
+ montaggio.} Anche questi sono mantenuti sull'\textit{inode} insieme alle
+altre proprietà e sono accessibili da programma tramite la funzione
+\func{stat} (trattata in sez.~\ref{sec:file_stat}), che restituisce l'utente
+proprietario nel campo \var{st\_uid} ed il gruppo proprietario nel campo
+\var{st\_gid} della omonima struttura \struct{stat}.
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}).
\label{fig:file_perm_bit}
\end{figure}
-I restanti tre bit (noti come \itindex{suid~bit} \textit{suid bit},
-\itindex{sgid~bit} \textit{sgid bit}, e \itindex{sticky~bit} \textit{sticky
- bit}) sono usati per indicare alcune caratteristiche più complesse del
-meccanismo del controllo di accesso su cui torneremo in seguito (in
-sez.~\ref{sec:file_special_perm}), lo schema di allocazione dei bit è
+I restanti tre bit (noti come \textit{suid bit}, \textit{sgid bit}, e
+\textit{sticky bit}) sono usati per indicare alcune caratteristiche più
+complesse del meccanismo del controllo di accesso su cui torneremo in seguito
+(in sez.~\ref{sec:file_special_perm}), lo schema di allocazione dei bit è
riportato in fig.~\ref{fig:file_perm_bit}. Come tutte le altre proprietà di
-un file anche i permessi sono memorizzati \itindex{inode} nell'\textit{inode},
-e come accennato in sez.~\ref{sec:file_types} essi sono vengono restituiti in
-una parte del campo \var{st\_mode} della struttura \struct{stat} (si veda di
-nuovo fig.~\ref{fig:file_stat_struct}).
+un file anche i permessi sono memorizzati nell'\textit{inode}, e come
+accennato in sez.~\ref{sec:file_types} essi sono vengono restituiti in una
+parte del campo \var{st\_mode} della struttura \struct{stat} (si veda di nuovo
+fig.~\ref{fig:file_stat_struct}).
In genere ci si riferisce ai tre livelli dei privilegi usando le lettere
\texttt{u} (per \textit{user}), \texttt{g} (per \textit{group}) e \texttt{o}
per un collegamento simbolico tutti i permessi come concessi. Utente e gruppo
a cui esso appartiene vengono pure ignorati quando il collegamento viene
risolto, vengono controllati solo quando viene richiesta la rimozione del
-collegamento e quest'ultimo è in una directory con lo \itindex{sticky~bit}
-\textit{sticky bit} impostato (si veda sez.~\ref{sec:file_special_perm}).
+collegamento e quest'ultimo è in una directory con lo \textit{sticky bit}
+impostato (si veda sez.~\ref{sec:file_special_perm}).
La procedura con cui il kernel stabilisce se un processo possiede un certo
permesso (di lettura, scrittura o esecuzione) si basa sul confronto fra
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}.
veda sez.~\ref{sec:file_ownership_management} per una spiegazione dettagliata
al proposito).
-Infine Linux utilizza il bit \acr{sgid} per un'ulteriore estensione mutuata
-da SVr4. Il caso in cui un file ha il bit \acr{sgid} impostato senza che lo
-sia anche il corrispondente bit di esecuzione viene utilizzato per attivare
-per quel file il \itindex{mandatory~locking} \textit{mandatory locking}
-(affronteremo questo argomento in dettaglio più avanti, in
-sez.~\ref{sec:file_mand_locking}).
+Infine Linux utilizza il bit \acr{sgid} per un'ulteriore estensione mutuata da
+SVr4. Il caso in cui un file ha il bit \acr{sgid} impostato senza che lo sia
+anche il corrispondente bit di esecuzione viene utilizzato per attivare per
+quel file il \textit{mandatory locking} (affronteremo questo argomento in
+dettaglio più avanti, in sez.~\ref{sec:file_mand_locking}).
\itindend{suid~bit}
\itindend{sgid~bit}
-
\itindbeg{sticky~bit}
L'ultimo dei bit rimanenti, identificato dalla costante \const{S\_ISVTX}, è in
ottenere la massima velocità possibile per i programmi usati più comunemente
si poteva impostare questo bit.
-L'effetto di questo bit era che il \index{segmento!testo} segmento di testo
-del programma (si veda sez.~\ref{sec:proc_mem_layout} per i dettagli) veniva
-scritto nella swap la prima volta che questo veniva lanciato, e vi permaneva
-fino al riavvio della macchina (da questo il nome di \textsl{sticky bit});
-essendo la swap un file continuo o una partizione indicizzata direttamente si
-poteva risparmiare in tempo di caricamento rispetto alla ricerca attraverso la
-struttura del filesystem. Lo \textsl{sticky bit} è indicato usando la lettera
-``\texttt{t}'' al posto della ``\texttt{x}'' nei permessi per gli altri.
+L'effetto di questo bit era che il segmento di testo del programma (si veda
+sez.~\ref{sec:proc_mem_layout} per i dettagli) veniva scritto nella swap la
+prima volta che questo veniva lanciato, e vi permaneva fino al riavvio della
+macchina (da questo il nome di \textsl{sticky bit}); essendo la swap un file
+continuo o una partizione indicizzata direttamente si poteva risparmiare in
+tempo di caricamento rispetto alla ricerca attraverso la struttura del
+filesystem. Lo \textsl{sticky bit} è indicato usando la lettera ``\texttt{t}''
+al posto della ``\texttt{x}'' nei permessi per gli altri.
Ovviamente per evitare che gli utenti potessero intasare la swap solo
l'amministratore era in grado di impostare questo bit, che venne chiamato
\textbf{\param{mode}} & \textbf{Significato} \\
\hline
\hline
- \const{R\_OK} & Verifica il permesso di lettura. \\
- \const{W\_OK} & Verifica il permesso di scrittura. \\
- \const{X\_OK} & Verifica il permesso di esecuzione. \\
- \const{F\_OK} & Verifica l'esistenza del file. \\
+ \constd{R\_OK} & Verifica il permesso di lettura. \\
+ \constd{W\_OK} & Verifica il permesso di scrittura. \\
+ \constd{X\_OK} & Verifica il permesso di esecuzione. \\
+ \constd{F\_OK} & Verifica l'esistenza del file. \\
\hline
\end{tabular}
\caption{Valori possibili per l'argomento \param{mode} della funzione
Un esempio tipico per l'uso di questa funzione è quello di un processo che sta
eseguendo un programma coi privilegi di un altro utente (ad esempio attraverso
-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, ma eseguire
-questo controllo prima di aprire il file espone al rischio di una
-\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}.
+l'uso del \textit{suid bit}) che vuole controllare se l'utente originale ha i
+permessi per accedere ad un certo file, ma eseguire questo controllo prima di
+aprire il file espone al rischio di una \textit{race condition} che apre ad un
+possibile \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 \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
Entrambe le funzioni utilizzano come secondo argomento \param{mode}, una
variabile dell'apposito tipo primitivo \type{mode\_t} (vedi
-tab.~\ref{tab:intro_primitive_types}) utilizzato per specificare i permessi sui
-file.
+tab.~\ref{tab:intro_primitive_types}) utilizzato per specificare i permessi
+sui file.
\begin{table}[!htb]
\centering
\textbf{\param{mode}} & \textbf{Valore} & \textbf{Significato} \\
\hline
\hline
- \const{S\_ISUID} & 04000 & Set user ID \itindex{suid~bit} bit.\\
- \const{S\_ISGID} & 02000 & Set group ID \itindex{sgid~bit} bit.\\
- \const{S\_ISVTX} & 01000 & Sticky \itindex{sticky~bit} bit.\\
+ \const{S\_ISUID} & 04000 & Set user ID bit.\\
+ \const{S\_ISGID} & 02000 & Set group ID bit.\\
+ \const{S\_ISVTX} & 01000 & Sticky bit.\\
\hline
\const{S\_IRWXU} & 00700 & L'utente ha tutti i permessi.\\
\const{S\_IRUSR} & 00400 & L'utente ha il permesso di lettura.\\
per il proprietario, sola lettura per il gruppo e gli altri) sono
corrispondenti al valore ottale $0644$, un programma invece avrebbe anche il
bit di esecuzione attivo, con un valore di $0755$, se si volesse attivare il
-bit \itindex{suid~bit} \acr{suid} il valore da fornire sarebbe $4755$.
+bit \acr{suid} il valore da fornire sarebbe $4755$.
Il cambiamento dei permessi di un file eseguito attraverso queste funzioni ha
comunque alcune limitazioni, previste per motivi di sicurezza. L'uso delle
non tutti i valori possibili di \param{mode} sono permessi o hanno effetto;
in particolare accade che:
\begin{enumerate*}
-\item siccome solo l'amministratore può impostare lo \itindex{sticky~bit}
- \textit{sticky bit}, se l'\ids{UID} effettivo del processo non è zero esso
- viene automaticamente cancellato, senza notifica di errore, qualora sia
- stato indicato in \param{mode}.
+\item siccome solo l'amministratore può impostare lo \textit{sticky bit}, se
+ l'\ids{UID} effettivo del processo non è zero esso viene automaticamente
+ cancellato, senza notifica di errore, qualora sia stato indicato
+ in \param{mode}.
\item per quanto detto in sez.~\ref{sec:file_ownership_management} riguardo la
creazione dei nuovi file, si può avere il caso in cui il file creato da un
processo è assegnato ad un gruppo per il quale il processo non ha privilegi.
- Per evitare che si possa assegnare il bit \itindex{sgid~bit} \acr{sgid} ad
- un file appartenente ad un gruppo per cui non si hanno diritti, questo viene
- automaticamente cancellato da \param{mode}, senza notifica di errore,
- qualora il gruppo del file non corrisponda a quelli associati al processo;
- la cosa non avviene quando l'\ids{UID} effettivo del processo è zero.
+ Per evitare che si possa assegnare il bit \acr{sgid} ad un file appartenente
+ ad un gruppo per cui non si hanno diritti, questo viene automaticamente
+ cancellato da \param{mode}, senza notifica di errore, qualora il gruppo del
+ file non corrisponda a quelli associati al processo; la cosa non avviene
+ quando l'\ids{UID} effettivo del processo è zero.
\end{enumerate*}
Per alcuni filesystem\footnote{i filesystem più comuni (\textsl{ext2},
\textsl{ext3}, \textsl{ext4}, \textsl{ReiserFS}) supportano questa
caratteristica, che è mutuata da BSD.} è inoltre prevista un'ulteriore
-misura di sicurezza, volta a scongiurare l'abuso dei \itindex{suid~bit} bit
-\acr{suid} e \acr{sgid}; essa consiste nel cancellare automaticamente questi
-bit dai permessi di un file qualora un processo che non appartenga
+misura di sicurezza, volta a scongiurare l'abuso dei bit \acr{suid} e
+\acr{sgid}; essa consiste nel cancellare automaticamente questi bit dai
+permessi di un file qualora un processo che non appartenga
all'amministratore\footnote{per la precisione un processo che non dispone
- della \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
completamente i problemi di accesso da parte di altri utenti dello stesso
gruppo, in quanto di default i permessi assegnati al gruppo non sono
sufficienti per un accesso in scrittura; in questo caso si deve aver cura di
-usare prima della creazione dei file un valore per \itindex{umask}
-\textit{umask} lasci il permesso di scrittura.\footnote{in tal caso si può
- assegnare agli utenti del gruppo una \textit{umask} di $002$, anche se la
- soluzione migliore in questo caso è usare una ACL di default (vedi
- sez.~\ref{sec:file_ACL}).}
+usare prima della creazione dei file un valore per \textit{umask} lasci il
+permesso di scrittura.\footnote{in tal caso si può assegnare agli utenti del
+ gruppo una \textit{umask} di $002$, anche se la soluzione migliore in questo
+ caso è usare una ACL di default (vedi sez.~\ref{sec:file_ACL}).}
Come avviene nel caso dei permessi esistono anche delle appropriate funzioni
di sistema, \funcd{chown} \funcd{fchown} e \funcd{lchown}, che permettono di
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
per \param{owner} e \param{group} i valori restano immutati.
Quando queste funzioni sono chiamate con successo da un processo senza i
-privilegi di amministratore entrambi i bit \itindex{suid~bit} \acr{suid} e
-\itindex{sgid~bit} \acr{sgid} vengono cancellati. Questo non avviene per il
-bit \acr{sgid} nel caso in cui esso sia usato (in assenza del corrispondente
-permesso di esecuzione) per indicare che per il file è attivo il
-\itindex{mandatory~locking} \textit{mandatory locking} (vedi
+privilegi di amministratore entrambi i bit \acr{suid} e \acr{sgid} vengono
+cancellati. Questo non avviene per il bit \acr{sgid} nel caso in cui esso sia
+usato (in assenza del corrispondente permesso di esecuzione) per indicare che
+per il file è attivo il \textit{mandatory locking} (vedi
sez.~\ref{sec:file_mand_locking}).
\hline
1&-&-&-&-&1&-&-&-&-&-&-&Eseguito conferisce l'\ids{UID} effettivo dell'utente.\\
-&1&-&-&-&1&-&-&-&-&-&-&Eseguito conferisce il \ids{GID} effettivo del gruppo.\\
- -&1&-&-&-&0&-&-&-&-&-&-&Il \itindex{mandatory~locking}
- \textit{mandatory locking} è abilitato.\\
+ -&1&-&-&-&0&-&-&-&-&-&-&Il \textit{mandatory locking} è abilitato.\\
-&-&1&-&-&-&-&-&-&-&-&-&Non utilizzato.\\
-&-&-&1&-&-&-&-&-&-&-&-&Permesso di lettura per l'utente.\\
-&-&-&-&1&-&-&-&-&-&-&-&Permesso di scrittura per l'utente.\\
significato dei vari bit dei permessi per un file ordinario; per quanto
riguarda l'applicazione dei permessi per proprietario, gruppo ed altri si
ricordi quanto illustrato in sez.~\ref{sec:file_perm_overview}. Per
-compattezza, nella tabella si sono specificati i bit di \itindex{suid~bit}
-\textit{suid}, \itindex{sgid~bit} \textit{sgid} e \textit{sticky}
-\itindex{sticky~bit} con la notazione illustrata anche in
+compattezza, nella tabella si sono specificati i bit di \textit{suid},
+\textit{sgid} e \textit{sticky} con la notazione illustrata anche in
fig.~\ref{fig:file_perm_bit}. Nella parte inferiore si sono invece riassunti
i significati dei vari bit dei permessi per una directory; anche in questo
-caso si è riapplicato ai bit di \itindex{suid~bit} \textit{suid},
-\itindex{sgid~bit} \textit{sgid} e \textit{sticky} \itindex{sticky~bit} la
-notazione illustrata in fig.~\ref{fig:file_perm_bit}.
+caso si è riapplicato ai bit di \textit{suid}, \textit{sgid} e \textit{sticky}
+la 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
\itindbeg{Extended~Attributes}
Nelle sezioni precedenti abbiamo trattato in dettaglio le varie informazioni
-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 abbiamo chiamato genericamente \textsl{metadati}) che però non
-potevano trovare spazio nei dati classici mantenuti negli \itindex{inode}
-\textit{inode}.
+che il sistema mantiene negli \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
+abbiamo chiamato genericamente \textsl{metadati}) che però non potevano
+trovare spazio nei dati classici mantenuti negli \textit{inode}.
Per risolvere questo problema alcuni sistemi unix-like (e fra questi anche
Linux) hanno introdotto un meccanismo generico, detto \textit{Extended
Attributes} che consente di associare delle informazioni ulteriori ai
singoli file.\footnote{essi ad esempio vengono usati per le ACL, che
- tratteremo in sez.~\ref{sec:file_ACL} e le \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
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 \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.
+In Linux gli attributi estesi sono sempre associati al singolo \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}; al momento della scrittura di queste dispense essi sono
\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 \textit{fifo} o i
socket. Per questo motivo essi sono stati completamente disabilitati per
tutto ciò che non sia un file regolare o una directory.\footnote{si può
verificare la semantica adottata consultando il file \texttt{fs/xattr.c}
dei sorgenti del kernel.} Inoltre per le directory è stata introdotta una
ulteriore restrizione, dovuta di nuovo alla presenza ordinaria di permessi
di scrittura completi su directory come \texttt{/tmp}. Per questo motivo,
- per evitare eventuali abusi, se una directory ha lo \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}.
+ per evitare eventuali abusi, se una directory ha lo \textit{sticky bit}
+ attivo sarà consentito scrivere i suoi \textit{extended user attributes}
+ soltanto se si è proprietari della stessa, o si hanno i privilegi
+ amministrativi della capacità \const{CAP\_FOWNER}.
\end{basedescript}
Le funzioni per la gestione degli attributi estesi, come altre funzioni di
puntato da \param{value}, e la sua dimensione totale (in byte) sarà indicata
dall'argomento \param{size}. Infine l'argomento \param{flag} consente di
controllare le modalità di sovrascrittura dell'attributo esteso, esso può
-prendere due valori: con \const{XATTR\_REPLACE} si richiede che l'attributo
+prendere due valori: con \constd{XATTR\_REPLACE} si richiede che l'attributo
esista, nel qual caso verrà sovrascritto, altrimenti si avrà errore, mentre
-con \const{XATTR\_CREATE} si richiede che l'attributo non esista, nel qual
+con \constd{XATTR\_CREATE} si richiede che l'attributo non esista, nel qual
caso verrà creato, altrimenti si avrà errore ed il valore attuale non sarà
modificato. Utilizzando per \param{flag} un valore nullo l'attributo verrà
modificato se è già presente, o creato se non c'è.
definiscono le cosiddette \textit{Posix ACL}.
A differenza di altri sistemi, come ad esempio FreeBSD, nel caso di Linux si è
-scelto di realizzare le ACL attraverso l'uso degli
-\itindex{Extended~Attributes} \textit{Extended Attributes} (appena trattati in
-sez.~\ref{sec:file_xattr}), e fornire tutte le relative funzioni di gestione
-tramite una libreria, \texttt{libacl} che nasconde i dettagli implementativi
-delle ACL e presenta ai programmi una interfaccia che fa riferimento allo
-standard POSIX 1003.1e.
+scelto di realizzare le ACL attraverso l'uso degli \textit{Extended
+ Attributes} (appena trattati in sez.~\ref{sec:file_xattr}), e fornire tutte
+le relative funzioni di gestione tramite una libreria, \texttt{libacl} che
+nasconde i dettagli implementativi delle ACL e presenta ai programmi una
+interfaccia che fa riferimento allo standard POSIX 1003.1e.
Anche in questo caso le funzioni di questa libreria non fanno parte della
\acr{glibc} e devono essere installate a parte;\footnote{la versione corrente
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
\textbf{Tipo} & \textbf{Descrizione} \\
\hline
\hline
- \const{ACL\_USER\_OBJ} & Voce che contiene i diritti di accesso del
+ \constd{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
+ \constd{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
+ \constd{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
+ \constd{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
+ \constd{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
+ \constd{ACL\_OTHER} & Voce che contiene i diritti di accesso di chi
non corrisponde a nessuna altra voce dell'ACL.\\
\hline
\end{tabular}
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.
+nella stessa directory. Si ottiene così una sorta di \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
\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 e viceversa.\footnote{per permessi
- ordinari si intende quelli mantenuti \itindex{inode} nell'\textit{inode},
- che devono restare dato che un filesystem può essere montato senza abilitare
- le ACL.}
+ ordinari si intende quelli mantenuti nell'\textit{inode}, che devono restare
+ dato che un filesystem può essere montato senza abilitare le ACL.}
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
presenza di una \textit{Default ACL} sulla directory che andrà a contenerli.
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}.
+\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, essa diventerà automaticamente anche la ACL di accesso di quest'ultimo,
\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,
La funzione alloca ed inizializza un'area di memoria che verrà usata per
mantenere i dati di una ACL contenente fino ad un massimo di \param{count}
-voci. La funzione ritorna un valore di tipo \type{acl\_t} da usare in tutte le
+voci. La funzione ritorna un valore di tipo \typed{acl\_t} da usare in tutte le
altre funzioni che operano sulla ACL. La funzione si limita alla allocazione
iniziale e non inserisce nessun valore nella ACL che resta vuota.
-Si tenga presente che pur essendo \type{acl\_t} un \index{tipo!opaco} tipo
-opaco che identifica ``\textsl{l'oggetto}'' ACL, il valore restituito dalla
-funzione non è altro che un puntatore all'area di memoria allocata per i dati
-richiesti. Pertanto in caso di fallimento verrà restituito un puntatore nullo
-di tipo ``\code{(acl\_t) NULL}'' e si dovrà, in questa come in tutte le
-funzioni seguenti che restituiscono un oggetto di tipo \type{acl\_t},
-confrontare il valore di ritorno della funzione con \val{NULL}.\footnote{a
- voler essere estremamente pignoli si dovrebbe usare ``\code{(acl\_t)
- NULL}'', ma è sufficiente fare un confronto direttamente con \val{NULL}
- essendo cura del compilatore fare le conversioni necessarie.}
+Si tenga presente che pur essendo \typed{acl\_t} un tipo opaco che identifica
+``\textsl{l'oggetto}'' ACL, il valore restituito dalla funzione non è altro
+che un puntatore all'area di memoria allocata per i dati richiesti. Pertanto
+in caso di fallimento verrà restituito un puntatore nullo di tipo
+``\code{(acl\_t) NULL}'' e si dovrà, in questa come in tutte le funzioni
+seguenti che restituiscono un oggetto di tipo \type{acl\_t}, confrontare il
+valore di ritorno della funzione con \val{NULL}.\footnote{a voler essere
+ estremamente pignoli si dovrebbe usare ``\code{(acl\_t) NULL}'', ma è
+ sufficiente fare un confronto direttamente con \val{NULL} essendo cura del
+ compilatore fare le conversioni necessarie.}
Una volta che si siano completate le operazioni sui dati di una ACL la memoria
allocata per un oggetto \type{acl\_t} dovrà essere liberata esplicitamente
funzione, che può richiedere anche la ACL relativa ad una directory, il
secondo argomento \param{type} consente di specificare se si vuole ottenere la
ACL di default o quella di accesso. Questo argomento deve essere di tipo
-\type{acl\_type\_t} e può assumere solo i due valori riportati in
+\typed{acl\_type\_t} e può assumere solo i due valori riportati in
tab.~\ref{tab:acl_type}.
\begin{table}[htb]
\textbf{Tipo} & \textbf{Descrizione} \\
\hline
\hline
- \const{ACL\_TYPE\_ACCESS} & Indica una ACL di accesso.\\
- \const{ACL\_TYPE\_DEFAULT}& Indica una ACL di default.\\
+ \constd{ACL\_TYPE\_ACCESS} & Indica una ACL di accesso.\\
+ \constd{ACL\_TYPE\_DEFAULT}& Indica una ACL di default.\\
\hline
\end{tabular}
\caption{Le costanti che identificano il tipo di ACL.}
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 (come \itindex{value~result~argument}
-\textit{value result argument}) la dimensione della stringa con la
-rappresentazione testuale, non comprendente il carattere nullo finale.
+intera in questa verrà restituita (come \textit{value result argument}) la
+dimensione della stringa con la rappresentazione testuale, non comprendente il
+carattere nullo finale.
La seconda funzione, che permette di controllare con una gran dovizia di
particolari la generazione della stringa contenente la rappresentazione
\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
+ \constd{TEXT\_ABBREVIATE} & Stampa le voci in forma abbreviata.\\
+ \constd{TEXT\_NUMERIC\_IDS} & non effettua la risoluzione numerica di
\ids{UID} e \ids{GID}.\\
- \const{TEXT\_SOME\_EFFECTIVE}& Per ciascuna voce che contiene permessi che
+ \constd{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
+ \constd{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
+ \constd{TEXT\_SMART\_INDENT} & Da usare in combinazione con le precedenti
opzioni \const{TEXT\_SOME\_EFFECTIVE} e
\const{TEXT\_ALL\_EFFECTIVE}, aumenta
automaticamente il numero di spaziatori
}
\end{funcproto}
-La funzione è del tutto è analoga a \funcd{acl\_set\_file} ma opera
+La funzione è del tutto è analoga a \func{acl\_set\_file} ma opera
esclusivamente sui file identificati tramite un file descriptor. Non dovendo
avere a che fare con directory (e con la conseguente possibilità di avere una
ACL di default) la funzione non necessita che si specifichi il tipo di ACL,
Se si vuole operare direttamente sui contenuti di un oggetto di tipo
\type{acl\_t} infatti occorre fare riferimento alle singole voci tramite gli
-opportuni puntatori di tipo \type{acl\_entry\_t}, che possono essere ottenuti
+opportuni puntatori di tipo \typed{acl\_entry\_t}, che possono essere ottenuti
dalla funzione \funcm{acl\_get\_entry} (per una voce esistente) o dalla
funzione \funcm{acl\_create\_entry} per una voce da aggiungere. Nel caso della
prima funzione si potrà poi ripetere la lettura per ottenere i puntatori alle
Quella delle quote disco è una funzionalità introdotta inizialmente da BSD e
presente in Linux fino dai kernel dalla serie 2.0, che consente di porre dei
tetti massimi al consumo delle risorse di un filesystem (spazio disco e
-\itindex{inode} \textit{inode}) da parte di utenti e gruppi.
+\textit{inode}) da parte di utenti e gruppi.
Dato che la funzionalità ha senso solo per i filesystem su cui si mantengono i
dati degli utenti\footnote{in genere la si attiva sul filesystem che contiene
\textit{hard limit}) possono essere disposti separatamente su entrambe le
risorse di un filesystem, essi cioè possono essere presenti in maniera
indipendente sia sullo spazio disco, con un massimo per il numero di blocchi,
-che sui file, con un massimo per il numero di \itindex{inode} \textit{inode}.
+che sui file, con un massimo per il numero di \textit{inode}.
La funzione di sistema che consente di controllare tutti i vari aspetti della
gestione delle quote è \funcd{quotactl}, ed il suo prototipo è:
\item[\errcode{EIO}] errore di lettura/scrittura sul file delle quote.
\item[\errcode{EMFILE}] non si può aprire il file delle quote avendo
superato il limite sul numero di file aperti nel sistema.
- \item[\errcode{ENODEV}] \param{dev} non corrisponde ad un
- \itindex{mount~point} \textit{mount point} attivo.
+ \item[\errcode{ENODEV}] \param{dev} non corrisponde ad un \textit{mount
+ point} attivo.
\item[\errcode{ENOPKG}] il kernel è stato compilato senza supporto per le
quote.
\item[\errcode{ENOTBLK}] \param{dev} non è un dispositivo a blocchi.
\vspace{3pt}
\begin{funcbox}{
\fhead{sys/quota.h}
-\fdecl{int \macro{QCMD}(subcmd,type)}
+\fdecl{int \macrod{QCMD}(subcmd,type)}
\fdesc{Imposta il comando \param{subcmd} per il tipo di quote (utente o
gruppo) \param{type}.}
}
\textbf{Comando} & \textbf{Descrizione} \\
\hline
\hline
- \const{Q\_QUOTAON} & Attiva l'applicazione delle quote disco per il
+ \constd{Q\_QUOTAON} & Attiva l'applicazione delle quote disco per il
filesystem indicato da \param{dev}, si deve passare
in \param{addr} il \textit{pathname} al file che
mantiene le quote, che deve esistere, e \param{id}
valori di tab.~\ref{tab:quotactl_id_format};
l'operazione richiede i privilegi di
amministratore.\\
- \const{Q\_QUOTAOFF} & Disattiva l'applicazione delle quote disco per il
+ \constd{Q\_QUOTAOFF}& Disattiva l'applicazione delle quote disco per il
filesystem indicato da \param{dev}, \param{id}
e \param{addr} vengono ignorati; l'operazione
richiede i privilegi di amministratore.\\
- \const{Q\_GETQUOTA} & Legge i limiti ed i valori correnti delle quote nel
+ \constd{Q\_GETQUOTA}& Legge i limiti ed i valori correnti delle quote nel
filesystem indicato da \param{dev} per l'utente o
il gruppo specificato da \param{id}; si devono avere
i privilegi di amministratore per leggere i dati
parte, il risultato viene restituito in una struttura
\struct{dqblk} all'indirizzo indicato
da \param{addr}.\\
- \const{Q\_SETQUOTA} & Imposta i limiti per le quote nel filesystem
+ \constd{Q\_SETQUOTA}& Imposta i limiti per le quote nel filesystem
indicato da \param{dev} per l'utente o il gruppo
specificato da \param{id} secondo i valori ottenuti
dalla struttura \struct{dqblk} puntata
da \param{addr}; l'operazione richiede i privilegi
di amministratore.\\
- \const{Q\_GETINFO} & Legge le informazioni (in sostanza i \textit{grace
+ \constd{Q\_GETINFO} & Legge le informazioni (in sostanza i \textit{grace
time}) delle quote del filesystem indicato
da \param{dev} sulla struttura \struct{dqinfo}
puntata da \param{addr}, \param{id} viene ignorato.\\
- \const{Q\_SETINFO} & Imposta le informazioni delle quote del filesystem
+ \constd{Q\_SETINFO} & Imposta le informazioni delle quote del filesystem
indicato da \param{dev} come ottenuti dalla
struttura \struct{dqinfo} puntata
da \param{addr}, \param{id} viene ignorato;
l'operazione richiede i privilegi di amministratore.\\
- \const{Q\_GETFMT} & Richiede il valore identificativo (quello di
+ \constd{Q\_GETFMT} & Richiede il valore identificativo (quello di
tab.~\ref{tab:quotactl_id_format}) per il formato
delle quote attualmente in uso sul filesystem
indicato da \param{dev}, che sarà memorizzato
sul buffer di 4 byte puntato da \param{addr}.\\
- \const{Q\_SYNC} & Aggiorna la copia su disco dei dati delle quote del
+ \constd{Q\_SYNC} & Aggiorna la copia su disco dei dati delle quote del
filesystem indicato da \param{dev}; in questo
caso \param{dev} può anche essere \val{NULL} nel
qual caso verranno aggiornati i dati per tutti i
filesystem con quote attive, \param{id}
e \param{addr} vengono comunque ignorati.\\
- \const{Q\_GETSTATS} & Ottiene statistiche ed altre informazioni generali
+ \constd{Q\_GETSTATS}& Ottiene statistiche ed altre informazioni generali
relative al sistema delle quote per il filesystem
indicato da \param{dev}, richiede che si
passi come argomento \param{addr} l'indirizzo di una
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.
ci sono alcuni campi (in sostanza \val{dqb\_curspace}, \val{dqb\_curinodes},
\val{dqb\_btime}, \val{dqb\_itime}) che hanno senso solo in lettura, in quanto
riportano uno stato non modificabile da \func{quotactl} come l'uso corrente di
-spazio disco ed \itindex{inode} \textit{inode}, o il tempo che resta nel caso
-si sia superato un \textit{soft limit}.
+spazio disco ed \textit{inode}, o il tempo che resta nel caso si sia superato
+un \textit{soft limit}.
Inoltre in caso di modifica di un limite si può voler operare solo su una
-delle risorse (blocchi o \itindex{inode} \textit{inode}),\footnote{non è
- possibile modificare soltanto uno dei limiti (\textit{hard} o \textit{soft})
- occorre sempre rispecificarli entrambi.} per questo la struttura prevede un
-campo apposito, \val{dqb\_valid}, il cui scopo è quello di indicare quali sono
-gli altri campi che devono essere considerati validi. Questo campo è una
-maschera binaria che deve essere espressa nei termini di OR aritmetico delle
-apposite costanti di tab.~\ref{tab:quotactl_qif_const}, dove si è riportato il
-significato di ciascuna di esse ed i campi a cui fanno riferimento.
+delle risorse (blocchi o \textit{inode}),\footnote{non è possibile modificare
+ soltanto uno dei limiti (\textit{hard} o \textit{soft}) occorre sempre
+ rispecificarli entrambi.} per questo la struttura prevede un campo apposito,
+\val{dqb\_valid}, il cui scopo è quello di indicare quali sono gli altri campi
+che devono essere considerati validi. Questo campo è una maschera binaria che
+deve essere espressa nei termini di OR aritmetico delle apposite costanti di
+tab.~\ref{tab:quotactl_qif_const}, dove si è riportato il significato di
+ciascuna di esse ed i campi a cui fanno riferimento.
\begin{table}[!htb]
\centering
\textbf{Costante} & \textbf{Descrizione} \\
\hline
\hline
- \const{QIF\_BLIMITS}& Limiti sui blocchi di
- spazio disco (\val{dqb\_bhardlimit} e
- \val{dqb\_bsoftlimit}).\\
- \const{QIF\_SPACE} & Uso corrente
- dello spazio disco (\val{dqb\_curspace}).\\
- \const{QIF\_ILIMITS}& Limiti sugli \itindex{inode} \textit{inode}
- (\val{dqb\_ihardlimit} e \val{dqb\_isoftlimit}).\\
- \const{QIF\_INODES} & Uso corrente
- degli \textit{inode} (\val{dqb\_curinodes}).\\
- \const{QIF\_BTIME} & Tempo di
- sforamento del \textit{soft limit} sul numero di
- blocchi (\val{dqb\_btime}).\\
- \const{QIF\_ITIME} & Tempo di
- sforamento del \textit{soft limit} sul numero di
- \itindex{inode} \textit{inode} (\val{dqb\_itime}).\\
- \const{QIF\_LIMITS} & L'insieme di \const{QIF\_BLIMITS} e
- \const{QIF\_ILIMITS}.\\
- \const{QIF\_USAGE} & L'insieme di \const{QIF\_SPACE} e
- \const{QIF\_INODES}.\\
- \const{QIF\_TIMES} & L'insieme di \const{QIF\_BTIME} e
- \const{QIF\_ITIME}.\\
- \const{QIF\_ALL} & Tutti i precedenti.\\
+ \constd{QIF\_BLIMITS}& Limiti sui blocchi di spazio disco
+ (\val{dqb\_bhardlimit} e \val{dqb\_bsoftlimit}).\\
+ \constd{QIF\_SPACE} & Uso corrente dello spazio disco
+ (\val{dqb\_curspace}).\\
+ \constd{QIF\_ILIMITS}& Limiti sugli \textit{inode}
+ (\val{dqb\_ihardlimit} e \val{dqb\_isoftlimit}).\\
+ \constd{QIF\_INODES} & Uso corrente degli \textit{inode}
+ (\val{dqb\_curinodes}).\\
+ \constd{QIF\_BTIME} & Tempo di sforamento del \textit{soft limit} sul
+ numero di blocchi (\val{dqb\_btime}).\\
+ \constd{QIF\_ITIME} & Tempo di sforamento del \textit{soft limit} sul
+ numero di \textit{inode} (\val{dqb\_itime}).\\
+ \constd{QIF\_LIMITS} & L'insieme di \const{QIF\_BLIMITS} e
+ \const{QIF\_ILIMITS}.\\
+ \constd{QIF\_USAGE} & L'insieme di \const{QIF\_SPACE} e
+ \const{QIF\_INODES}.\\
+ \constd{QIF\_TIMES} & L'insieme di \const{QIF\_BTIME} e
+ \const{QIF\_ITIME}.\\
+ \constd{QIF\_ALL} & Tutti i precedenti.\\
\hline
\end{tabular}
\caption{Costanti per il campo \val{dqb\_valid} di \struct{dqblk}.}
\textbf{Identificatore} & \textbf{Descrizione} \\
\hline
\hline
- \const{QFMT\_VFS\_OLD}& Il vecchio (ed obsoleto) formato delle quote.\\
- \const{QFMT\_VFS\_V0} & La versione 0 usata dal VFS di Linux, supporta
- \ids{UID} e \ids{GID} a 32 bit e limiti fino a
- $2^{42}$ byte e $2^{32}$ file.\\
- \const{QFMT\_VFS\_V1} & La versione 1 usata dal VFS di Linux, supporta
- \ids{UID} e \ids{GID} a 32 bit e limiti fino a
- $2^{64}$ byte e $2^{64}$ file.\\
+ \constd{QFMT\_VFS\_OLD}& Il vecchio (ed obsoleto) formato delle quote.\\
+ \constd{QFMT\_VFS\_V0} & La versione 0 usata dal VFS di Linux, supporta
+ \ids{UID} e \ids{GID} a 32 bit e limiti fino a
+ $2^{42}$ byte e $2^{32}$ file.\\
+ \constd{QFMT\_VFS\_V1} & La versione 1 usata dal VFS di Linux, supporta
+ \ids{UID} e \ids{GID} a 32 bit e limiti fino a
+ $2^{64}$ byte e $2^{64}$ file.\\
\hline
\end{tabular}
\caption{Valori di identificazione del formato delle quote.}
\label{tab:quotactl_id_format}
\end{table}
-
-
Altre due operazioni che necessitano di ulteriori spiegazioni sono
\const{Q\_GETINFO} e \const{Q\_SETINFO}, che consentono di ottenere i dati
relativi alle impostazioni delle altre proprietà delle quote, che al momento
\textbf{Costante} & \textbf{Descrizione} \\
\hline
\hline
- \const{IIF\_BGRACE}& Il \textit{grace period} per i blocchi
+ \constd{IIF\_BGRACE}& Il \textit{grace period} per i blocchi
(\val{dqi\_bgrace}).\\
- \const{IIF\_IGRACE}& Il \textit{grace period} per gli \textit{inode}
- \itindex{inode} (\val{dqi\_igrace}).\\
- \const{IIF\_FLAGS} & I flag delle quote (\val{dqi\_flags}) (inusato ?).\\
- \const{IIF\_ALL} & Tutti i precedenti.\\
+ \constd{IIF\_IGRACE}& Il \textit{grace period} per gli \textit{inode}
+ (\val{dqi\_igrace}).\\
+ \constd{IIF\_FLAGS} & I flag delle quote (\val{dqi\_flags}) (inusato ?).\\
+ \constd{IIF\_ALL} & Tutti i precedenti.\\
\hline
\end{tabular}
\caption{Costanti per il campo \val{dqi\_valid} di \struct{dqinfo}.}
5-16}) che in caso di successo provvede a costruire (\texttt{\small 6-12})
opportunamente una risposta restituendo tramite la opportuna funzione di
interfaccia un oggetto Python contenente i dati della struttura \struct{dqblk}
-relativi a uso corrente e limiti sia per i blocchi che per gli \itindex{inode}
+relativi a uso corrente e limiti sia per i blocchi che per gli
\textit{inode}. In caso di errore (\texttt{\small 13-15}) si usa un'altra
funzione dell'interfaccia per passare il valore di \var{errno} come eccezione.
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
\textit{inheritable} ed \textit{effective}. Questi insiemi vengono mantenuti
in forma di tre diverse maschere binarie,\footnote{il kernel li mantiene, come
i vari identificatori di sez.~\ref{sec:proc_setuid}, all'interno della
- \struct{task\_struct} di ciascun processo (vedi
+ \texttt{task\_struct} di ciascun processo (vedi
fig.~\ref{fig:proc_task_struct}), nei tre campi \texttt{cap\_effective},
\texttt{cap\_inheritable}, \texttt{cap\_permitted} del tipo
\texttt{kernel\_cap\_t}; questo era, fino al kernel 2.6.25 definito come
Per i kernel fino al 2.6.25, o se non si attiva il supporto per le
\textit{file capabilities}, il \textit{capabilities bounding set} è un
parametro generale di sistema, il cui valore viene riportato nel file
-\sysctlfile{kernel/cap-bound}. Il suo valore iniziale è definito in sede di
+\sysctlfiled{kernel/cap-bound}. Il suo valore iniziale è definito in sede di
compilazione del kernel, e da sempre ha previsto come default la presenza di
tutte le \textit{capabilities} eccetto \const{CAP\_SETPCAP}. In questa
situazione solo il primo processo eseguito nel sistema (quello con
\textbf{Flag} & \textbf{Descrizione} \\
\hline
\hline
- \const{SECURE\_KEEP\_CAPS}& Il processo non subisce la cancellazione delle
+ \constd{SECURE\_KEEP\_CAPS}&Il processo non subisce la cancellazione delle
sue \textit{capabilities} quando tutti i suoi
\ids{UID} passano ad un valore non
nullo (regola di compatibilità per il cambio
elenco), sostituisce il precedente uso
dell'operazione \const{PR\_SET\_KEEPCAPS} di
\func{prctl}.\\
- \const{SECURE\_NO\_SETUID\_FIXUP}&Il processo non subisce le modifiche
+ \constd{SECURE\_NO\_SETUID\_FIXUP}&Il processo non subisce le modifiche
delle sue \textit{capabilities} nel passaggio
da nullo a non nullo degli \ids{UID}
dei gruppi \textit{effective} e
\textit{file system} (regole di compatibilità
per il cambio di \ids{UID} nn.~1 e 2 del
precedente elenco).\\
- \const{SECURE\_NOROOT} & Il processo non assume nessuna capacità
+ \constd{SECURE\_NOROOT} & Il processo non assume nessuna capacità
aggiuntiva quando esegue un programma, anche
se ha \ids{UID} nullo o il programma ha
il \acr{suid} bit attivo ed appartiene
corrispondente flag di blocco, identificato da una costante omonima con
l'estensione \texttt{\_LOCKED}, la cui attivazione è irreversibile ed ha
l'effetto di rendere permanente l'impostazione corrente del corrispondente
-flag ordinario; in sostanza con \const{SECURE\_KEEP\_CAPS\_LOCKED} si rende
+flag ordinario; in sostanza con \constd{SECURE\_KEEP\_CAPS\_LOCKED} si rende
non più modificabile \const{SECURE\_KEEP\_CAPS}, ed analogamente avviene con
-\const{SECURE\_NO\_SETUID\_FIXUP\_LOCKED} per
-\const{SECURE\_NO\_SETUID\_FIXUP} e con \const{SECURE\_NOROOT\_LOCKED} per
+\constd{SECURE\_NO\_SETUID\_FIXUP\_LOCKED} per
+\const{SECURE\_NO\_SETUID\_FIXUP} e con \constd{SECURE\_NOROOT\_LOCKED} per
\const{SECURE\_NOROOT}.
Per l'impostazione di questi flag sono state predisposte due specifiche
%
% POSIX-draft defined capabilities.
%
- \const{CAP\_AUDIT\_CONTROL}& Abilitare e disabilitare il
+ \constd{CAP\_AUDIT\_CONTROL}& Abilitare e disabilitare il
controllo dell'auditing (dal kernel 2.6.11).\\
- \const{CAP\_AUDIT\_WRITE}&Scrivere dati nel giornale di
+ \constd{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
+ \constd{CAP\_BLOCK\_SUSPEND}&Utilizzare funzionalità che possono bloccare
la sospensione del sistema (dal kernel 3.5).\\
- \const{CAP\_CHOWN} & Cambiare proprietario e gruppo
+ \constd{CAP\_CHOWN} & Cambiare proprietario e gruppo
proprietario di un file (vedi
sez.~\ref{sec:file_ownership_management}).\\
- \const{CAP\_DAC\_OVERRIDE}& Evitare il controllo dei
- permessi di lettura, scrittura ed esecuzione dei
- file, (vedi sez.~\ref{sec:file_access_control}).\\
- \const{CAP\_DAC\_READ\_SEARCH}& Evitare il controllo dei
+ \constd{CAP\_DAC\_OVERRIDE}& Evitare il controllo dei
+ permessi di lettura, scrittura ed esecuzione dei
+ file, (vedi sez.~\ref{sec:file_access_control}).\\
+ \constd{CAP\_DAC\_READ\_SEARCH}& Evitare il controllo dei
permessi di lettura ed esecuzione per
le directory (vedi
sez.~\ref{sec:file_access_control}).\\
per tutte le operazioni privilegiate non coperte
dalle precedenti \const{CAP\_DAC\_OVERRIDE} e
\const{CAP\_DAC\_READ\_SEARCH}.\\
- \const{CAP\_FSETID} & Evitare la cancellazione
- automatica dei bit \itindex{suid~bit} \acr{suid}
- e \itindex{sgid~bit} \acr{sgid} quando un file
+ \constd{CAP\_FSETID} & Evitare la cancellazione automatica dei bit
+ \acr{suid} e \acr{sgid} quando un file
per i quali sono impostati viene modificato da
un processo senza questa capacità e la capacità
di impostare il bit \acr{sgid} su un file anche
quando questo è relativo ad un gruppo cui non si
appartiene (vedi
sez.~\ref{sec:file_perm_management}).\\
- \const{CAP\_KILL} & Mandare segnali a qualunque
+ \constd{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\_SETGID} & Manipolare i group ID dei
+ \constd{CAP\_SETFCAP} & Impostare le \textit{capabilities} di un file
+ (dal kernel 2.6.24).\\
+ \constd{CAP\_SETGID} & Manipolare i group ID dei
processi, sia il principale che i supplementari,
(vedi sez.~\ref{sec:proc_setgroups}) che quelli
trasmessi tramite i socket \textit{unix domain}
(vedi sez.~\ref{sec:unix_socket}).\\
- \const{CAP\_SETUID} & Manipolare gli user ID del
+ \constd{CAP\_SETUID} & Manipolare gli user ID del
processo (vedi sez.~\ref{sec:proc_setuid}) e di
trasmettere un user ID arbitrario nel passaggio
delle credenziali coi socket \textit{unix
% Linux specific capabilities
%
\hline
- \const{CAP\_IPC\_LOCK} & Effettuare il \textit{memory
- locking} \itindex{memory~locking} con le
+ \constd{CAP\_IPC\_LOCK} & Effettuare il \textit{memory locking} con le
funzioni \func{mlock}, \func{mlockall},
\func{shmctl}, \func{mmap} (vedi
sez.~\ref{sec:proc_mem_lock} e
sez.~\ref{sec:file_memory_map}). \\
% TODO verificare l'interazione con SHM_HUGETLB
- \const{CAP\_IPC\_OWNER} & Evitare il controllo dei permessi
+ \constd{CAP\_IPC\_OWNER}& Evitare il controllo dei permessi
per le operazioni sugli oggetti di
intercomunicazione fra processi (vedi
sez.~\ref{sec:ipc_sysv}).\\
- \const{CAP\_LEASE} & Creare dei \textit{file lease}
- \itindex{file~lease} (vedi
+ \constd{CAP\_LEASE} & Creare dei \textit{file lease} (vedi
sez.~\ref{sec:file_asyncronous_lease})
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
- sez.~\ref{sec:file_perm_overview}) se
- supportati.\\
- \const{CAP\_MKNOD} & Creare \index{file!di~dispositivo} file di
- dispositivo con \func{mknod} (vedi
+ \constd{CAP\_LINUX\_IMMUTABLE}& Impostare sui file gli attributi
+ \textit{immutable} e \textit{append-only} (vedi
+ sez.~\ref{sec:file_perm_overview}) se
+ supportati.\\
+ \constd{CAP\_MAC\_ADMIN}& Amministrare il \textit{Mandatory
+ Access Control} di \textit{Smack} (dal kernel
+ 2.6.25).\\
+ \constd{CAP\_MAC\_OVERRIDE}& Evitare il \textit{Mandatory
+ Access Control} di \textit{Smack} (dal kernel
+ 2.6.25).\\
+ \constd{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\_NET\_BIND\_SERVICE}& Porsi in ascolto su porte riservate (vedi
+ \constd{CAP\_NET\_BIND\_SERVICE}& Porsi in ascolto su porte riservate (vedi
sez.~\ref{sec:TCP_func_bind}).\\
- \const{CAP\_NET\_BROADCAST}& Consentire l'uso di socket in
- \itindex{broadcast} \textit{broadcast} e
- \itindex{multicast} \textit{multicast}.\\
- \const{CAP\_NET\_RAW} & Usare socket \texttt{RAW} e \texttt{PACKET}
+ \constd{CAP\_NET\_BROADCAST}& Consentire l'uso di socket in
+ \textit{broadcast} e \textit{multicast}.\\
+ \constd{CAP\_NET\_RAW} & Usare socket \texttt{RAW} e \texttt{PACKET}
(vedi sez.~\ref{sec:sock_type}).\\
\const{CAP\_SETPCAP} & Effettuare modifiche privilegiate alle
\textit{capabilities}.\\
\const{CAP\_SYS\_ADMIN} & Eseguire una serie di compiti amministrativi.\\
- \const{CAP\_SYS\_BOOT} & Eseguire un riavvio del sistema (vedi
+ \constd{CAP\_SYS\_BOOT} & Eseguire un riavvio del sistema (vedi
sez.~\ref{sec:sys_reboot}).\\
- \const{CAP\_SYS\_CHROOT}& Eseguire la funzione \func{chroot} (vedi
+ \constd{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).\\
- \const{CAP\_SYS\_MODULE}& Caricare e rimuovere moduli del kernel.\\
+ \constd{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}).\\
- \const{CAP\_SYS\_PACCT} & Usare le funzioni di \textit{accounting} dei
+ \constd{CAP\_SYS\_PACCT}& Usare le funzioni di \textit{accounting} dei
processi (vedi
sez.~\ref{sec:sys_bsd_accounting}).\\
- \const{CAP\_SYS\_PTRACE}& La capacità di tracciare qualunque processo con
+ \constd{CAP\_SYS\_PTRACE}& La capacità di tracciare qualunque processo con
\func{ptrace} (vedi
sez.~\ref{sec:process_ptrace}).\\
- \const{CAP\_SYS\_RAWIO} & Operare sulle porte di I/O con \func{ioperm} e
+ \constd{CAP\_SYS\_RAWIO}& Operare sulle porte di I/O con \func{ioperm} e
\func{iopl} (vedi
sez.~\ref{sec:process_io_port}).\\
\const{CAP\_SYS\_RESOURCE}& Superare le varie limitazioni sulle risorse.\\
- \const{CAP\_SYS\_TIME} & Modificare il tempo di sistema (vedi
+ \constd{CAP\_SYS\_TIME} & Modificare il tempo di sistema (vedi
sez.~\ref{sec:sys_time}).\\
- \const{CAP\_SYS\_TTY\_CONFIG}&Simulare un \textit{hangup} della console,
+ \constd{CAP\_SYS\_TTY\_CONFIG}&Simulare un \textit{hangup} della console,
con la funzione \func{vhangup}.\\
- \const{CAP\_SYSLOG} & Gestire il buffer dei messaggi
+ \constd{CAP\_SYSLOG} & Gestire il buffer dei messaggi
del kernel, (vedi sez.~\ref{sec:sess_daemon}),
introdotta dal kernel 2.6.38 come capacità
separata da \const{CAP\_SYS\_ADMIN}.\\
- \const{CAP\_WAKE\_ALARM}& Usare i timer di tipo
+ \constd{CAP\_WAKE\_ALARM}&Usare i timer di tipo
\const{CLOCK\_BOOTTIME\_ALARM} e
\const{CLOCK\_REALTIME\_ALARM}, vedi
sez.~\ref{sec:sig_timer_adv} (dal kernel 3.0).\\
\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).}
-
+\constbeg{CAP\_SETPCAP}
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}.
+
+\constend{CAP\_SETPCAP}
+\constbeg{CAP\_FOWNER}
La prima fra le capacità ``\textsl{ampie}'' che occorre dettagliare
maggiormente è \const{CAP\_FOWNER}, che rimuove le restrizioni poste ad un
sez.~\ref{sec:file_perm_management} e sez.~\ref{sec:file_file_times}), le
impostazioni degli attributi dei file e delle ACL (vedi
sez.~\ref{sec:file_xattr} e \ref{sec:file_ACL}), poter ignorare lo
-\itindex{sticky~bit} \textit{sticky bit} nella cancellazione dei file (vedi
+\textit{sticky bit} nella cancellazione dei file (vedi
sez.~\ref{sec:file_special_perm}), la possibilità di impostare il flag di
\const{O\_NOATIME} con \func{open} e \func{fcntl} (vedi
sez.~\ref{sec:file_open_close} e sez.~\ref{sec:file_fcntl_ioctl}) senza
restrizioni.
+\constend{CAP\_FOWNER}
+\constbeg{CAP\_NET\_ADMIN}
+
Una seconda capacità che copre diverse operazioni, in questo caso riguardanti
la rete, è \const{CAP\_NET\_ADMIN}, che consente di impostare le opzioni
privilegiate dei socket (vedi sez.~\ref{sec:sock_generic_options}), abilitare
-il \itindex{multicast} \textit{multicasting}, eseguire la configurazione delle
-interfacce di rete (vedi sez.~\ref{sec:sock_ioctl_netdevice}) ed impostare la
-tabella di instradamento.
+il \textit{multicasting} (vedi sez.\ref{sec:sock_ipv4_options}), eseguire la
+configurazione delle interfacce di rete (vedi
+sez.~\ref{sec:sock_ioctl_netdevice}) ed impostare la tabella di instradamento.
+
+\constend{CAP\_NET\_ADMIN}
+\constbeg{CAP\_SYS\_ADMIN}
Una terza \textit{capability} con vasto campo di applicazione è
\const{CAP\_SYS\_ADMIN}, che copre una serie di operazioni amministrative,
(\const{IOPRIO\_CLASS\_RT} e prima del kernel 2.6.25 anche
\const{IOPRIO\_CLASS\_IDLE}) per lo scheduling dell'I/O (vedi
sez.~\ref{sec:io_priority}), superare il limite di sistema sul numero massimo
-di file aperti,\footnote{quello indicato da \sysctlfile{fs/file-max}.}
+di file aperti,\footnote{quello indicato da \sysctlfiled{fs/file-max}.}
effettuare operazioni privilegiate sulle chiavi mantenute dal kernel (vedi
sez.~\ref{sec:keyctl_management}), usare la funzione \func{lookup\_dcookie},
usare \const{CLONE\_NEWNS} con \func{unshare} e \func{clone}, (vedi
sez.~\ref{sec:process_clone}).
+\constend{CAP\_SYS\_ADMIN}
+\constbeg{CAP\_SYS\_NICE}
+
Originariamente \const{CAP\_SYS\_NICE} riguardava soltanto la capacità di
aumentare le priorità di esecuzione dei processi, come la diminuzione del
valore di \textit{nice} (vedi sez.~\ref{sec:proc_sched_stand}), l'uso delle
arbitrarie nell'accesso a disco (vedi sez.~\ref{sec:io_priority}) e nelle
politiche di allocazione delle pagine di memoria ai nodi di un sistema NUMA.
+\constend{CAP\_SYS\_NICE}
+\constbeg{CAP\_SYS\_RESOURCE}
+
Infine la \textit{capability} \const{CAP\_SYS\_RESOURCE} attiene alla
possibilità di superare i limiti imposti sulle risorse di sistema, come usare
lo spazio disco riservato all'amministratore sui filesystem che lo supportano,
numero di processi, ed i limiti sulle dimensioni dei messaggi delle code del
SysV IPC (vedi sez.~\ref{sec:ipc_sysv_mq}).
+\constend{CAP\_SYS\_RESOURCE}
+
Per la gestione delle \textit{capabilities} il kernel mette a disposizione due
funzioni che permettono rispettivamente di leggere ed impostare i valori dei
tre insiemi illustrati in precedenza. Queste due funzioni di sistema sono
indicato che per poterle utilizzare fosse necessario che la macro
\macro{\_POSIX\_SOURCE} risultasse non definita (ed era richiesto di inserire
una istruzione \texttt{\#undef \_POSIX\_SOURCE} prima di includere
-\headfile{sys/capability.h}) requisito che non risulta più
+\headfiled{sys/capability.h}) requisito che non risulta più
presente.\footnote{e non è chiaro neanche quanto sia mai stato davvero
necessario.}
\centering
\begin{minipage}[c]{0.8\textwidth}
\includestruct{listati/cap_user_header_t.h}
- \end{minipage}
+ \end{minipage}
\normalsize
\caption{Definizione delle strutture a cui fanno riferimento i puntatori
\structd{cap\_user\_header\_t} e \structd{cap\_user\_data\_t} usati per
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
\itindbeg{capability~state}
Le funzioni dell'interfaccia alle \textit{capabilities} definite nelle bozze
-dello standard POSIX.1e prevedono l'uso di un \index{tipo!opaco} tipo di dato
-opaco, \type{cap\_t}, come puntatore ai dati mantenuti nel cosiddetto
+dello standard POSIX.1e prevedono l'uso di un tipo di dato opaco,
+\typed{cap\_t}, come puntatore ai dati mantenuti nel cosiddetto
\textit{capability state},\footnote{si tratta in sostanza di un puntatore ad
una struttura interna utilizzata dalle librerie, i cui campi non devono mai
essere acceduti direttamente.} in sono memorizzati tutti i dati delle
\textbf{Valore} & \textbf{Significato} \\
\hline
\hline
- \const{CAP\_EFFECTIVE} & Capacità dell'insieme \textsl{effettivo}.\\
- \const{CAP\_PERMITTED} & Capacità dell'insieme \textsl{permesso}.\\
- \const{CAP\_INHERITABLE}& Capacità dell'insieme \textsl{ereditabile}.\\
+ \constd{CAP\_EFFECTIVE} & Capacità dell'insieme \textsl{effettivo}.\\
+ \constd{CAP\_PERMITTED} & Capacità dell'insieme \textsl{permesso}.\\
+ \constd{CAP\_INHERITABLE}& Capacità dell'insieme \textsl{ereditabile}.\\
\hline
\end{tabular}
- \caption{Valori possibili per il tipo di dato \type{cap\_flag\_t} che
+ \caption{Valori possibili per il tipo di dato \typed{cap\_flag\_t} che
identifica gli insiemi delle \textit{capabilities}.}
\label{tab:cap_set_identifier}
\end{table}
\vspace{3pt}
\begin{funcbox}{
\fhead{sys/capability.h}
-\fdecl{int \macro{CAP\_DIFFERS}(value, flag)}
+\fdecl{int \macrod{CAP\_DIFFERS}(value, flag)}
\fdesc{Controlla lo stato di eventuali differenze delle \textit{capabilities}
nell'insieme \texttt{flag}.}
}
indica su quale dei tre insiemi si intende operare, sempre con i valori di
tab.~\ref{tab:cap_set_identifier}. La capacità che si intende controllare o
impostare invece deve essere specificata attraverso una variabile di tipo
-\type{cap\_value\_t}, che può prendere come valore uno qualunque di quelli
+\typed{cap\_value\_t}, che può prendere come valore uno qualunque di quelli
riportati in tab.~\ref{tab:proc_capabilities}, in questo caso però non è
possibile combinare diversi valori in una maschera binaria, una variabile di
tipo \type{cap\_value\_t} può indicare una sola capacità.\footnote{in
\textbf{Valore} & \textbf{Significato} \\
\hline
\hline
- \const{CAP\_CLEAR}& La capacità non è impostata.\\
- \const{CAP\_SET} & La capacità è impostata.\\
+ \constd{CAP\_CLEAR}& La capacità non è impostata.\\
+ \constd{CAP\_SET} & La capacità è impostata.\\
\hline
\end{tabular}
- \caption{Valori possibili per il tipo di dato \type{cap\_flag\_value\_t} che
+ \caption{Valori possibili per il tipo di dato \typed{cap\_flag\_value\_t} che
indica lo stato di una capacità.}
\label{tab:cap_value_type}
\end{table}
La funzione \func{cap\_get\_flag} legge lo stato della capacità indicata
dall'argomento \param{cap} all'interno dell'insieme indicato dall'argomento
-\param{flag} e lo restituisce come \itindex{value~result~argument}
-\textit{value result argument} nella variabile puntata
-dall'argomento \param{value\_p}. Questa deve essere di tipo
+\param{flag} e lo restituisce come \textit{value result argument} nella
+variabile puntata dall'argomento \param{value\_p}. Questa deve essere di tipo
\type{cap\_flag\_value\_t} ed assumerà uno dei valori di
tab.~\ref{tab:cap_value_type}. La funzione consente pertanto di leggere solo
lo stato di una capacità alla volta.
La funzione ritorna l'indirizzo di una stringa contente la descrizione
testuale del contenuto del \textit{capability state} \param{caps} passato come
argomento, e, qualora l'argomento \param{length\_p} sia diverso da \val{NULL},
-restituisce come \itindex{value~result~argument} \textit{value result
- argument} nella variabile intera da questo puntata la lunghezza della
-stringa. La stringa restituita viene allocata automaticamente dalla funzione e
-pertanto dovrà essere liberata con \func{cap\_free}.
+restituisce come \textit{value result argument} nella variabile intera da
+questo puntata la lunghezza della stringa. La stringa restituita viene
+allocata automaticamente dalla funzione e pertanto dovrà essere liberata con
+\func{cap\_free}.
La rappresentazione testuale, che viene usata anche dai programmi di gestione a
riga di comando, prevede che lo stato venga rappresentato con una stringa di
La prima funzione restituisce la stringa (allocata automaticamente e che dovrà
essere liberata con \func{cap\_free}) che corrisponde al valore della
capacità \param{cap}, mentre la seconda restituisce nella variabile puntata
-da \param{cap\_p}, come \itindex{value~result~argument} \textit{value result
- argument}, il valore della capacità rappresentata dalla
-stringa \param{name}.
+da \param{cap\_p}, come \textit{value result argument}, il valore della
+capacità rappresentata dalla stringa \param{name}.
Fin quei abbiamo trattato solo le funzioni di servizio relative alla
manipolazione dei \textit{capability state} come strutture di dati;
% sicurezza avanzate, con dentro chroot SELinux e AppArmor, Tomoyo, Smack,
% cgroup o altro
-% TODO: trattare la funzione setns e i namespace file descriptors (vedi
-% http://lwn.net/Articles/407495/) introdotti con il kernel 3.0, altre
-% 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
+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 \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.
+modalità di risoluzione dei \textit{pathname} assoluti da parte di un processo
+cambiando questa directory, così come si fa coi \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
\end{funcproto}
La funzione imposta la directory radice del processo a quella specificata da
-\param{path} (che ovviamente deve esistere) ed ogni
-\itindsub{pathname}{assoluto} \textit{pathname} assoluto usato dalle funzioni
-chiamate nel processo sarà risolto a partire da essa, rendendo impossibile
-accedere alla parte di albero sovrastante. Si ha così quella che viene
-chiamata una \textit{chroot jail}, in quanto il processo non può più accedere
-a file al di fuori della sezione di albero in cui è stato
+\param{path} (che ovviamente deve esistere) ed ogni \textit{pathname} assoluto
+usato dalle funzioni chiamate nel processo sarà risolto a partire da essa,
+rendendo impossibile accedere alla parte di albero sovrastante. Si ha così
+quella che viene chiamata una \textit{chroot jail}, in quanto il processo non
+può più accedere a file al di fuori della sezione di albero in cui è stato
\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 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