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
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,
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
\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 \textit{mount point} o di spostarlo
- quando \param{target} non è un \textit{mount point} o è la radice.
+ \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 \textit{mount point} su
una sottodirectory di \param{source} o si sono incontrati troppi
collegamenti simbolici nella risoluzione di un nome.
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}
In sostanza quello che avviene è che in corrispondenza del \textit{pathname}
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}.
+ 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
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
directory venga immediatamente registrata su disco in maniera sincrona
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}.
+ (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 \textit{mount point}
di un filesystem. La directory del \textit{mount point} originale deve
\item[\const{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 \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.
+ 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
- \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.
+ 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[\const{MS\_RDONLY}] Esegue il montaggio del filesystem in sola lettura,
non sarà possibile nessuna modifica ai suoi contenuti. Viene usato tutte le
\item[\const{MS\_REC}] Applica ricorsivamente a tutti i \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 \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}.
+ 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/
\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}.
+\itindbeg{shared~subtree}
+
\item[\const{MS\_SHARED}] Marca un \textit{mount point} come \textit{shared
- mount}. Si tratta di una delle nuove opzioni (insieme a
+ 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 \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
- \textit{mount point} della stessa condivisione, e la sezione di albero di
- file vista al di sotto di ciascuno di essi sarà sempre identica.
+ 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.
+
+\itindbend{shared~subtree}
\item[\const{MS\_SILENT}] Richiede la soppressione di alcuni messaggi di
avvertimento nei log del kernel (vedi sez.~\ref{sec:sess_daemon}). L'opzione
\item[\const{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
\item[\const{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 \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.
+ 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 \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}
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
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 è:
\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 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, 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
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 \textit{mount point}.
\end{errlist} ed inoltre \errval{EFAULT}, \errval{ELOOP}, \errval{EMLINK},
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
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
- 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 è:
+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 è:
\begin{funcproto}{
\fhead{sys/stat.h}
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
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}
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
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}
\item[\errcode{EINVAL}] il valore di \param{mode} non indica un file, una
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),
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.
+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
+\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.
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}:
+ 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}.}
+\fdesc{Restituisce il \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}.}
+\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.}
+\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
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}.
+vengono modificati dal valore di \textit{umask} (vedi
+sez.~\ref{sec:file_perm_management}).
\index{file!speciali|)}
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}
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
\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 \textit{calendar time}, su cui torneremo in dettaglio in
-sez.~\ref{sec:sys_time}.
+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]
\centering
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
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 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.}
+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.}
A partire dal kernel 2.6 la risoluzione dei tempi dei file, che nei campi di
tab.~\ref{tab:file_file_times} è espressa in secondi, è stata portata ai
(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}
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.
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
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}
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 \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
-\textit{at-functions} in sez.~\ref{sec:file_openat}.
+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
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},
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
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 \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 \textit{mandatory
- locking} (vedi sez.~\ref{sec:file_mand_locking}).
+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}).
\subsection{Un quadro d'insieme sui permessi}
\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.\\
\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
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
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à \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
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
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,
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 è:
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
\val{dqb\_bsoftlimit}).\\
\const{QIF\_SPACE} & Uso corrente
dello spazio disco (\val{dqb\_curspace}).\\
- \const{QIF\_ILIMITS}& Limiti sugli \itindex{inode} \textit{inode}
+ \const{QIF\_ILIMITS}& Limiti sugli \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\_ITIME} & Tempo di sforamento del \textit{soft limit} sul
+ numero di \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{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}).\\
+ (\val{dqi\_igrace}).\\
\const{IIF\_FLAGS} & I flag delle quote (\val{dqi\_flags}) (inusato ?).\\
\const{IIF\_ALL} & Tutti i precedenti.\\
\hline
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.
\const{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}.\\
+ \textit{broadcast} e \textit{multicast}.\\
\const{CAP\_NET\_RAW} & Usare socket \texttt{RAW} e \texttt{PACKET}
(vedi sez.~\ref{sec:sock_type}).\\
\const{CAP\_SETPCAP} & Effettuare modifiche privilegiate alle
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
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.
Una terza \textit{capability} con vasto campo di applicazione è
\const{CAP\_SYS\_ADMIN}, che copre una serie di operazioni amministrative,
% 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.
projects / gapil.git / commitdiff