X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=filedir.tex;h=73cc8e6d0e42695bf12683115f50988272cf4f53;hp=c9fc3c8b6366928a9562acfaf46fc2e5a9911166;hb=4aa6c51696d2b11c572eccd37238db1691785573;hpb=f10ada1c0b49d3bbdb22dbe3a61e27914584d70b diff --git a/filedir.tex b/filedir.tex index c9fc3c8..73cc8e6 100644 --- a/filedir.tex +++ b/filedir.tex @@ -1,6 +1,6 @@ %% filedir.tex %% -%% Copyright (C) 2000-2011 Simone Piccardi. Permission is granted to +%% Copyright (C) 2000-2012 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", @@ -544,7 +544,7 @@ le seguenti: gruppo primario del processo, eccetto il caso in cui la directory ha il bit di \acr{sgid} impostato (per una descrizione dettagliata del significato di questi termini si veda sez.~\ref{sec:file_access_control}), nel qual caso - file e subdirectory ereditano sia il \acr{gid} che lo \acr{sgid}. + file e subdirectory ereditano sia il \ids{GID} che lo \acr{sgid}. \item l'amministratore può scegliere la dimensione dei blocchi del filesystem in fase di creazione, a seconda delle sue esigenze: blocchi più grandi permettono un accesso più veloce, ma sprecano più spazio disco. @@ -647,7 +647,12 @@ il cui prototipo è:\footnote{la funzione è una versione specifica di Linux che \itindex{mount~point} \textit{mount point} o di spostarlo quando \param{target} non è un \itindex{mount~point} \textit{mount point} o è la radice. - \item[\errcode{EMFILE}] la tabella dei device \textit{dummy} è piena. + \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 link simolici 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. \item[\errcode{ENODEV}] il tipo \param{filesystemtype} non esiste o non è configurato nel kernel. \item[\errcode{ENOTBLK}] non si è usato un \textit{block device} per @@ -656,30 +661,29 @@ il cui prototipo è:\footnote{la funzione è una versione specifica di Linux che dispositivo \param{source} è sbagliato. \item[\errcode{EPERM}] il processo non ha i privilegi di amministratore. \end{errlist} - ed inoltre \errval{EFAULT}, \errval{ELOOP}, \errval{ENOMEM}, - \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOTDIR} nel loro - significato generico.} + ed inoltre \errval{EFAULT}, \errval{ENOMEM}, \errval{ENAMETOOLONG}, + \errval{ENOENT}, \errval{ENOTDIR} nel loro significato generico.} \end{funcproto} -La funzione monta sulla directory indicata \param{target}, detta +La funzione monta sulla directory indicata da \param{target}, detta \itindex{mount~point} \textit{mount point}, il filesystem contenuto nel file -di dispositivo indicato \param{source}. In entrambi i casi, come daremo per +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 \itindex{pathname} \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 \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 +\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.} Il tipo di filesystem che si vuole montare è specificato dall'argomento \param{filesystemtype}, che deve essere una delle stringhe @@ -691,78 +695,369 @@ nessun file di dispositivo, il contenuto di \param{source} viene ignorato. L'argomento \param{data} viene usato per passare le impostazioni relative alle caratteristiche specifiche di ciascun filesystem. Si tratta di una stringa di parole chiave (separate da virgole e senza spazi) che indicano le cosiddette -opzioni del filesystem che devono essere impostate, in sostanza viene usato il -contenuto del parametro dell'opzione \texttt{-o} del comando \texttt{mount}. I -valori utilizzabili dipendono dal tipo di filesystem e ciascuno ha i suoi, -pertanto si rimanda alla documentazione della pagina di manuale di questo -comando. +``\textsl{opzioni}'' del filesystem che devono essere impostate; in genere +viene usato direttamente il contenuto del parametro dell'opzione \texttt{-o} +del comando \texttt{mount}. I valori utilizzabili dipendono dal tipo di +filesystem e ciascuno ha i suoi, pertanto si rimanda alla documentazione della +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. - -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 in diversi \itindex{mount~point} \textit{mount point} lo stesso -filesystem, sia montare più filesystem sullo stesso \itindex{mount~point} -\textit{mount point}, nel qual caso vale quanto appena detto, e solo il +mascherato dal contenuto della directory radice del filesystem montato. Fino +ai kernel della serie 2.2.x non era possibile montare un filesytem 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 +qual caso vale comunque quanto detto in precedenza, e cioè che solo il contenuto dell'ultimo filesystem montato sarà visibile. -Ciascun filesystem è dotato di caratteristiche specifiche che possono essere -attivate o meno, alcune di queste sono generali (anche se non è detto siano -disponibili in ogni filesystem), e vengono specificate come opzioni di -montaggio con l'argomento \param{mountflags}. - -In Linux \param{mountflags} deve essere un intero a 32 bit i cui 16 più -significativi sono un \itindex{magic~number} \textit{magic - number}\footnote{che nel caso è \code{0xC0ED}, si può usare la costante - \const{MS\_MGC\_MSK} per ottenere la parte di \param{mountflags} riservata - al \textit{magic number}.} mentre i 16 meno significativi sono usati per -specificare le opzioni; essi sono usati come maschera binaria e vanno -impostati con un OR aritmetico della costante \const{MS\_MGC\_VAL} con i -valori riportati nell'elenco seguente: - -\begin{basedescript}{\desclabelstyle{\pushlabel}} - -\item[\const{MS\_BIND}] Effettua un cosiddetto \textit{bind mount}, in - sostanza . - -\item[\const{MS\_DIRSYNC}] . - -\item[\const{MS\_MANDLOCK}] Consente il \textit{mandatory locking} - \itindex{mandatory~locking} (vedi - sez.~\ref{sec:file_mand_locking}). - -\item[\const{MS\_MOVE}] Sposta atomicamente il punto di montaggio. - -\item[\const{MS\_NOATIME}] Non aggiorna gli \textit{access time} (vedi - sez.~\ref{sec:file_file_times}). - -\item[\const{MS\_NODEV}] Impedisce l'accesso ai file di dispositivo. +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 +non è detto che tutti i filesystem le supportino, che si specificano tramite +l'argomento \param{mountflags}. L'argomento inoltre può essere utilizzato per +modificare il comportamento della funzione, facendole compiere una operazione +diversa (ad esempio un rimontaggio, invece che un montaggio). + +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 devono essere impostati con un OR aritmetico dei rispettivi flag, +identificati 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 è + 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 + stavolta indicherà la directory che si vuole montare (e non un file di + dispositivo) e \param{target} che indicherà la directory su cui verrà + effettuato il \textit{bind mount}. Gli argomenti \param{filesystemtype} + e \param{data} vengono ignorati. + + In sostanza quello che avviene è che in corrispondenza del \index{pathname} + \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}. + + 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 corripondenza 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 + cui quest'ultima è contenuta. Questo potrebbe non corrispondere alla + porzione di albero che sta sotto \param{source} qualora in una + sottodirectory di quest'ultima si fosse effettuato un altro montaggio. In + tal caso infatti nella porzione di albero sotto \param{source} si troverebbe + il contenuto del nuovo filesystem (o di un altro \textit{bind mount}) mentre + sotto \param{target} ci sarebbe il contenuto presente nel filesystem + originale.\footnote{questo evita anche il problema dei \textit{loop} di + fig.~\ref{fig:file_link_loop}, dato che se anche si montasse su + \param{target} una directory in cui essa è contenuta, il cerchio non + potrebbe chiudersi perché ritornati a \param{target} dentro il + \textit{bind mount} vi si troverebbe solo il contenuto originale e non si + potrebbe tornare indietro.} + + Fino al kernel 2.6.26 questo flag doveva essere usato da solo, in quanto il + \textit{bind mount} continuava ad utilizzare le stesse opzioni del montaggio + originale, dal 2.6.26 è stato introdotto il supporto per il cosiddetto + \textit{read-only bind mount} e viene onorata la presenza del flag + \const{MS\_RDONLY}. In questo modo si ottiene che l'accesso ai file sotto + \param{target} sia effettuabile esclusivamente in sola lettura. + + Il supporto per il \textit{bind mount} consente di superare i limiti + presenti per gli \textit{hard link} (di cui parleremo in + sez.~\ref{sec:file_link}) ottenendo un qualcosa di analogo in cui si può + fare riferimento alla porzione dell'albero dei file di un filesystem + presente a partire da una certa directory utilizzando una qualunque altra + directory, anche se questa sta su un filesystem diverso. Si può così fornire + una alternativa all'uso dei link simbolici (di cui parleremo in + sez.~\ref{sec:file_symlink}) che funziona correttamente anche all'intero di + un \textit{chroot} (argomento su cui torneremo in + 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 + (introdotta a partire dai kernel della serie 2.6). L'opzione si applica a + tutte le directory del filesystem, ma su alcuni filesystem è possibile + impostarla a livello di singole directory o per i sottorami di una directory + con il comando \cmd{lsattr}.\footnote{questo avviene tramite delle opportune + \texttt{ioctl} (vedi sez.~\ref{sec:file_ioctl}).} + + Questo consente di ridurre al minimo il rischio di perdita dei dati delle + directory in caso di crollo improvviso del sistema, al costo di una certa + perdita di prestazioni dato che le funzioni di scrittura relative ad + 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[\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 + nell'argomento \param{target}. Tutti gli altri argomenti della funzione + vengono ignorati. + + Lo spostamento avviene atomicamente, ed il ramo di albero presente + sotto \param{source} sarà immediatamante 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 + \textit{pathname} relativi all'interno del filesystem non possa fallire. + +\item[\const{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 + elevato visto che una qualunque lettura comporta comunque una scrittura su + disco,\footnote{e questo ad esempio ha conseguenze molto pesanti nell'uso + della batteria sui portatili.} questa opzione consente di disabilitarla + completamente. La soluzione può risultare troppo drastica dato che + l'informazione viene comunque utilizzata da alcuni programmi, per cui nello + 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 + 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}.} + + 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 + il controllo dei contenuti, in particolar modo quelli posti su dispositivi + rimuovibili. In questo modo si evitano alla radice possibili situazioni in + cui un utente malizioso inserisce su uno di questi filesystem dei file di + dispositivo con permessi ``opportunamente'' ampliati che gli consentano di + accedere anche a risorse cui non dovrebbe. + +\item[\const{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 + 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. + + Anche in questo caso viene utilizzata per fornire un accesso più controllato + a quei filesystem di cui gli utenti hanno il controllo dei contenuti. Da + questo punto di vista l'opzione è meno importante delle analoghe + \const{MS\_NODEV} e \const{MS\_NOSUID} in quanto l'esecuzione di un + programma creato dall'utente pone un livello di rischio nettamente + inferiore, ed è in genere consentita per i file contenuti nella sua home + directory.\footnote{cosa che renderebbe superfluo l'attivazione di questa + opzione, il cui uso ha senso solo per ambienti molto controllati in cui si + 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. + + 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 \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. + + 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. + +\item[\const{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 \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}. + +\item[\const{MS\_RELATIME}] Indica di effettuare l'aggiornamento degli + \textit{access time} sul filesystem soltanto quando questo risulti + antecendente il valore corrente del \textit{modification time} o del + \textit{change time} (per i tempi dei file si veda + sez.~\ref{sec:file_file_times}). L'opzione è disponibile a partire dal + kernel 2.6.20, mentre dal 2.6.30 questo è diventato il comportamento di + default del sistema, che può essere riportato a quello tradizionale con + l'uso di \const{MS\_STRICTATIME}. Sempre dal 2.6.30 il comportamento è stato + anche modificato e l'\textit{access time} viene comunque aggiornato se è più + vecchio di un giorno. + + L'opzione consente di evitare i problemi di prestazioni relativi + all'aggiornamento dell'\textit{access time} senza avere impatti negativi + riguardo le funzionalità, il comportamento adottato infatti consente di + rendere evidente che vi è stato un accesso dopo la scrittura, ed evitando al + contempo ulteriori operazioni su disco negli accessi successivi. In questo + modo l'informazione relativa al fatto che un file sia stato letto resta + disponibile, ed i programmi che ne fanno uso continuano a funzionare. Con + 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 + 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 + il montaggio originale, mentre \param{data} che \param{mountflags} + conterranno le nuove opzioni, \param{filesystemtype} viene ignorato. + + Qualunque opzione specifica del filesystem indicata con \param{data} può + essere modificata, mentre con \param{mountflags} possono essere modificate + solo alcune opzioni generiche. Con i kernel più recenti queste sono soltanto + \const{MS\_MANDLOCK}, \const{MS\_RDONLY} e \const{MS\_SYNCHRONOUS}, prima + del kernel 2.6.16 potevano essere modificate anche le ulteriori + \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 \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 \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 cioè vengono ``\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. + +\item[\const{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 \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. + + 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{slave}, cioè ``\textsl{condividano}'' ogni ulteriore operazione di + montaggio o smontaggio che avviene su una directory al di sotto del + \textit{mount point} originale. Le operazioni di montaggio e smontaggio in + 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 \textit{mount point} originale. + +\item[\const{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 + 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}). + + Questa opzione consente di ridurre al minimo il rischio di perdita dei dati + in caso di crollo improvviso del sistema, al costo di una pesante perdita di + prestazioni dato che tutte le funzioni di scrittura non saranno più + bufferizzate e si bloccheranno fino all'arrivo dei dati sul disco. Per un + 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 \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. + + Un \textit{mount point} marcato in questo modo disabilità la capacità di + eseguire dei \itindex{bind~mount} \textit{bind mount}. 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}. -\item[\const{MS\_NODIRATIME}] Non aggiorna gli \textit{access time} delle - directory. -\item[\const{MS\_NOEXEC}] Impedisce di eseguire programmi. - -\item[\const{MS\_NOSUID}] Ignora i bit \itindex{suid~bit} \acr{suid} e - \itindex{sgid~bit} \acr{sgid}. - -\item[\const{MS\_RDONLY}] Monta in sola lettura. - -\item[\const{MS\_RELATIME}] . - -\item[\const{MS\_REMOUNT}] Rimonta il filesystem cambiando le opzioni. - -\item[\const{MS\_SILENT}] . +\end{basedescript} -\item[\const{MS\_STRICTATIME}] . -\item[\const{MS\_SYNCHRONOUS}] Abilita la scrittura sincrona. +% NOTE per \const{MS\_SLAVE},\const{MS\_SHARE}, \const{MS\_PRIVATE} e +% \const{MS\_UNBINDABLE} dal 2.6.15 vedi shared subtrees, in particolare +% * http://lwn.net/Articles/159077/ e +% * Documentation/filesystems/sharedsubtree.txt -% TODO aggiornare con i nuovi flag di man mount -% verificare i readonly mount bind del 2.6.26 -\end{basedescript} +% TODO: (bassa priorità) non documentati ma presenti in sys/mount.h: +% * MS_POSIXACL +% * MS_KERNMOUNT +% * MS_I_VERSION +% * MS_ACTIVE +% * MS_NOUSER La funzione \func{mount} può essere utilizzata anche per effettuare il \textsl{rimontaggio} di un filesystem, cosa che permette di cambiarne al volo @@ -995,10 +1290,12 @@ complicata (in genere per questo tipo di errori occorre far girare il programma \cmd{fsck} per riparare il filesystem). Data la pericolosità di questa operazione e la disponibilità dei link -simbolici che possono fornire la stessa funzionalità senza questi problemi, -nel caso di Linux questa capacità è stata completamente disabilitata, e al -tentativo di creare un link diretto ad una directory la funzione \func{link} -restituisce l'errore \errcode{EPERM}. +simbolici (che vedremo in sez.~\ref{sec:file_symlink}) e dei +\itindex{bind~mount} \textit{bind mount} (già visti in +sez.~\ref{sec:sys_file_config}) che possono fornire la stessa funzionalità +senza questi problemi, nel caso di Linux questa capacità è stata completamente +disabilitata, e al tentativo di creare un link diretto ad una directory la +funzione \func{link} restituisce l'errore \errcode{EPERM}. Un ulteriore comportamento peculiare di Linux è quello in cui si crea un \textit{hard link} ad un link simbolico. In questo caso lo standard POSIX @@ -1010,10 +1307,9 @@ iniziale di Linux ma a partire dai kernel della serie 2.0.x\footnote{per la kernel di sviluppo 1.3.56, ed è stato temporaneamente ripristinato anche durante lo sviluppo della serie 2.1.x, per poi tornare al comportamento attuale fino ad oggi (per riferimento si veda - \href{http://lwn.net/Articles/293902} - {\texttt{http://lwn.net/Articles/293902}}).} è stato adottato un -comportamento che non segue più lo standard per cui l'\textit{hard link} viene -creato rispetto al link simbolico, e non al file cui questo punta. + \url{http://lwn.net/Articles/293902}).} è stato adottato un comportamento +che non segue più lo standard per cui l'\textit{hard link} viene creato +rispetto al link simbolico, e non al file cui questo punta. La ragione di questa differenza rispetto allo standard, presente anche in altri sistemi unix-like, sono dovute al fatto che un link simbolico può fare @@ -1454,7 +1750,7 @@ La funzione che permette la cancellazione di una directory è invece \begin{errlist} \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 l'\acr{uid} effettivo + \itindex{sticky~bit} \textit{sticky bit} impostato e l'\ids{UID} effettivo del processo non corrisponde al proprietario della directory. \item[\errcode{EACCES}] non c'è il permesso di scrittura per la directory che contiene la directory che si vuole cancellare, o non c'è il permesso @@ -2359,7 +2655,7 @@ La funzionane genera un nome univoco sostituendo le \code{XXXXXX} finali di 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 \acr{pid} +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 @@ -2744,6 +3040,8 @@ accesso in lettura sui dati bufferizzati. Questo comporta un ovvio costo sia in termini di prestazioni, che di consumo di risorse come la batteria per i portatili, o cicli di riscrittura per i dischi su memorie riscrivibili. +% TODO aggiustare per il contenuto duplicato con le analoghe MS_* + Per questo motivo, onde evitare di mantenere una informazione che nella maggior parte dei casi non interessa, è sempre stato possibile disabilitare l'aggiornamento del tempo di ultimo accesso con l'opzione di montaggio @@ -3078,7 +3376,7 @@ concetti essenziali e le funzioni usate per gestirne i vari aspetti. Ad ogni file Linux associa sempre l'utente che ne è proprietario (il cosiddetto \textit{owner}) ed un gruppo di appartenenza, secondo il meccanismo -degli identificatori di utente e gruppo (\acr{uid} e \acr{gid}). Questi valori +degli identificatori di utente e gruppo (\ids{UID} e \ids{GID}). Questi valori sono accessibili da programma tramite la funzione \func{stat}, e sono mantenuti nei campi \var{st\_uid} e \var{st\_gid} della struttura \struct{stat} (si veda sez.~\ref{sec:file_stat}).\footnote{questo è vero solo @@ -3225,8 +3523,8 @@ 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 l'utente e il gruppo a cui il file appartiene (i valori di \var{st\_uid} e -\var{st\_gid} accennati in precedenza) e l'\acr{uid} effettivo, il \acr{gid} -effettivo e gli eventuali \acr{gid} supplementari del processo.\footnote{in +\var{st\_gid} accennati in precedenza) e l'\ids{UID} effettivo, il \ids{GID} +effettivo e gli eventuali \ids{GID} supplementari del processo.\footnote{in realtà Linux, per quanto riguarda l'accesso ai file, utilizza gli identificatori del gruppo \textit{filesystem} (si ricordi quanto esposto in sez.~\ref{sec:proc_perms}), ma essendo questi del tutto equivalenti ai primi, @@ -3235,19 +3533,19 @@ effettivo e gli eventuali \acr{gid} supplementari del processo.\footnote{in Per una spiegazione dettagliata degli identificatori associati ai processi si veda sez.~\ref{sec:proc_perms}; normalmente, a parte quanto vedremo in -sez.~\ref{sec:file_special_perm}, l'\acr{uid} effettivo e il \acr{gid} effettivo -corrispondono ai valori dell'\acr{uid} e del \acr{gid} dell'utente che ha -lanciato il processo, mentre i \acr{gid} supplementari sono quelli dei gruppi +sez.~\ref{sec:file_special_perm}, l'\ids{UID} effettivo e il \ids{GID} effettivo +corrispondono ai valori dell'\ids{UID} e del \ids{GID} dell'utente che ha +lanciato il processo, mentre i \ids{GID} supplementari sono quelli dei gruppi cui l'utente appartiene. I passi attraverso i quali viene stabilito se il processo possiede il diritto di accesso sono i seguenti: \begin{enumerate} -\item Se l'\acr{uid} effettivo del processo è zero (corrispondente +\item Se l'\ids{UID} effettivo del processo è zero (corrispondente all'amministratore) l'accesso è sempre garantito senza nessun ulteriore controllo. Per questo motivo \textsl{root} ha piena libertà di accesso a tutti i file. -\item Se l'\acr{uid} effettivo del processo è uguale all'\acr{uid} del +\item Se l'\ids{UID} effettivo del processo è uguale all'\ids{UID} del proprietario del file (nel qual caso si dice che il processo è proprietario del file) allora: \begin{itemize*} @@ -3257,8 +3555,8 @@ di accesso sono i seguenti: impostato, l'accesso è consentito \item altrimenti l'accesso è negato \end{itemize*} -\item Se il \acr{gid} effettivo del processo o uno dei \acr{gid} supplementari - dei processi corrispondono al \acr{gid} del file allora: +\item Se il \ids{GID} effettivo del processo o uno dei \ids{GID} supplementari + dei processi corrispondono al \ids{GID} del file allora: \begin{itemize*} \item se il bit dei permessi d'accesso del gruppo è impostato, l'accesso è consentito, @@ -3299,9 +3597,9 @@ corrispondono a quelli dell'utente con cui si è entrati nel sistema. Se però il file del programma (che ovviamente deve essere eseguibile\footnote{per motivi di sicurezza il kernel ignora i bit \acr{suid} e \acr{sgid} per gli script eseguibili.}) ha il bit \acr{suid} impostato, il -kernel assegnerà come \acr{uid} effettivo al nuovo processo l'\acr{uid} del -proprietario del file al posto dell'\acr{uid} del processo originario. Avere -il bit \acr{sgid} impostato ha lo stesso effetto sul \acr{gid} effettivo del +kernel assegnerà come \ids{UID} effettivo al nuovo processo l'\ids{UID} del +proprietario del file al posto dell'\ids{UID} del processo originario. Avere +il bit \acr{sgid} impostato ha lo stesso effetto sul \ids{GID} effettivo del processo. I bit \acr{suid} e \acr{sgid} vengono usati per permettere agli utenti normali @@ -3398,10 +3696,10 @@ consapevolmente, cancellare i file temporanei creati degli altri utenti. \label{sec:file_perm_management} Come visto in sez.~\ref{sec:file_access_control} il controllo di accesso ad un -file viene fatto utilizzando l'\acr{uid} ed il \acr{gid} effettivo del processo; -ci sono casi però in cui si può voler effettuare il controllo con l'\acr{uid} -reale ed il \acr{gid} reale, vale a dire usando i valori di \acr{uid} e -\acr{gid} relativi all'utente che ha lanciato il programma, e che, come +file viene fatto utilizzando l'\ids{UID} ed il \ids{GID} effettivo del processo; +ci sono casi però in cui si può voler effettuare il controllo con l'\ids{UID} +reale ed il \ids{GID} reale, vale a dire usando i valori di \ids{UID} e +\ids{GID} relativi all'utente che ha lanciato il programma, e che, come accennato in sez.~\ref{sec:file_special_perm} e spiegato in dettaglio in sez.~\ref{sec:proc_perms}, non è detto siano uguali a quelli effettivi. @@ -3491,7 +3789,7 @@ filename e su un file descriptor, i loro prototipi sono: \bodydesc{Le funzioni restituiscono zero in caso di successo e -1 per un errore, in caso di errore \var{errno} può assumere i valori: \begin{errlist} - \item[\errcode{EPERM}] l'\acr{uid} effettivo non corrisponde a quello del + \item[\errcode{EPERM}] l'\ids{UID} effettivo non corrisponde a quello del proprietario del file o non è zero. \item[\errcode{EROFS}] il file è su un filesystem in sola lettura. \end{errlist} @@ -3555,7 +3853,7 @@ bit \itindex{suid~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 -funzioni infatti è possibile solo se l'\acr{uid} effettivo del processo +funzioni infatti è possibile solo se l'\ids{UID} effettivo del processo corrisponde a quello del proprietario del file o dell'amministratore, altrimenti esse falliranno con un errore di \errcode{EPERM}. @@ -3565,7 +3863,7 @@ 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'\acr{uid} effettivo del processo non è zero esso + \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 @@ -3575,7 +3873,7 @@ in particolare accade che: 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'\acr{uid} effettivo del processo è zero). + (la cosa non avviene quando l'\ids{UID} effettivo del processo è zero). \end{enumerate} Per alcuni filesystem\footnote{i filesystem più comuni (\textsl{ext2}, @@ -3648,21 +3946,21 @@ quale utente e gruppo esso deve appartenere. Lo stesso problema si presenta per la creazione di nuove directory (procedimento descritto in sez.~\ref{sec:file_dir_creat_rem}). -Lo standard POSIX prescrive che l'\acr{uid} del nuovo file corrisponda -all'\acr{uid} effettivo del processo che lo crea; per il \acr{gid} invece prevede -due diverse possibilità: +Lo standard POSIX prescrive che l'\ids{UID} del nuovo file corrisponda +all'\ids{UID} effettivo del processo che lo crea; per il \ids{GID} invece +prevede due diverse possibilità: \begin{itemize*} -\item il \acr{gid} del file corrisponde al \acr{gid} effettivo del processo. -\item il \acr{gid} del file corrisponde al \acr{gid} della directory in cui +\item il \ids{GID} del file corrisponde al \ids{GID} effettivo del processo. +\item il \ids{GID} del file corrisponde al \ids{GID} della directory in cui esso è creato. \end{itemize*} in genere BSD usa sempre la seconda possibilità, che viene per questo chiamata semantica BSD. Linux invece segue quella che viene chiamata semantica SVr4; di norma cioè il nuovo file viene creato, seguendo la prima opzione, con il -\acr{gid} del processo, se però la directory in cui viene creato il file ha il +\ids{GID} del processo, se però la directory in cui viene creato il file ha il bit \acr{sgid} impostato allora viene usata la seconda opzione. -Usare la semantica BSD ha il vantaggio che il \acr{gid} viene sempre +Usare la semantica BSD ha il vantaggio che il \ids{GID} viene sempre automaticamente propagato, restando coerente a quello della directory di partenza, in tutte le sotto-directory. @@ -3671,7 +3969,7 @@ risultato di coerenza che si ha con BSD necessita che quando si creano nuove directory venga anche propagato anche il bit \acr{sgid}. Questo è il comportamento predefinito del comando \cmd{mkdir}, ed è in questo modo ad esempio che le varie distribuzioni assicurano che le sotto-directory create -nella home di un utente restino sempre con il \acr{gid} del gruppo primario +nella home di un utente restino sempre con il \ids{GID} del gruppo primario dello stesso. La presenza del bit \acr{sgid} è inoltre molto comoda quando si hanno @@ -3703,7 +4001,7 @@ l'utente che il gruppo a cui un file appartiene; i rispettivi prototipi sono: \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 per un errore, nel qual caso caso \var{errno} assumerà i valori: \begin{errlist} - \item[\errcode{EPERM}] l'\acr{uid} effettivo non corrisponde a quello del + \item[\errcode{EPERM}] l'\ids{UID} effettivo non corrisponde a quello del proprietario del file o non è zero, o utente e gruppo non sono validi \end{errlist} Oltre a questi entrambe restituiscono gli errori \errval{EROFS} e @@ -4414,15 +4712,15 @@ identificatori del gruppo \textit{effective} del processo, ma in presenza di ACL i passi attraverso i quali viene stabilito se esso ha diritto di accesso sono i seguenti: \begin{enumerate*} -\item Se l'\acr{uid} del processo è nullo l'accesso è sempre garantito senza +\item Se l'\ids{UID} del processo è nullo l'accesso è sempre garantito senza nessun controllo. -\item Se l'\acr{uid} del processo corrisponde al proprietario del file allora: +\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, l'accesso è consentito; \item altrimenti l'accesso è negato. \end{itemize*} -\item Se l'\acr{uid} del processo corrisponde ad un qualunque qualificatore +\item Se l'\ids{UID} del processo corrisponde ad un qualunque qualificatore presente in una voce \const{ACL\_USER} allora: \begin{itemize*} \item se la voce \const{ACL\_USER} corrispondente e la voce @@ -4430,7 +4728,7 @@ sono i seguenti: consentito; \item altrimenti l'accesso è negato. \end{itemize*} -\item Se è il \acr{gid} del processo o uno dei \acr{gid} supplementari +\item Se è il \ids{GID} del processo o uno dei \ids{GID} supplementari corrisponde al gruppo proprietario del file allora: \begin{itemize*} \item se la voce \const{ACL\_GROUP\_OBJ} e una eventuale voce @@ -4439,7 +4737,7 @@ sono i seguenti: l'accesso è consentito; \item altrimenti l'accesso è negato. \end{itemize*} -\item Se è il \acr{gid} del processo o uno dei \acr{gid} supplementari +\item Se è il \ids{GID} del processo o uno dei \ids{GID} supplementari corrisponde ad un qualunque qualificatore presente in una voce \const{ACL\_GROUP} allora: \begin{itemize*} @@ -4783,7 +5081,7 @@ tab.~\ref{tab:acl_to_text_options}. \hline \const{TEXT\_ABBREVIATE} & stampa le voci in forma abbreviata.\\ \const{TEXT\_NUMERIC\_IDS} & non effettua la risoluzione numerica di - \acr{uid} e \acr{gid}.\\ + \ids{UID} e \ids{GID}.\\ \const{TEXT\_SOME\_EFFECTIVE}& per ciascuna voce che contiene permessi che vengono eliminati dalla \const{ACL\_MASK} viene generato un commento con i permessi @@ -5109,7 +5407,7 @@ La funzione richiede che il filesystem sul quale si vuole operare sia montato con il supporto delle quote abilitato; esso deve essere specificato con il nome del file di dispositivo nell'argomento \param{dev}. Per le operazioni che lo richiedono inoltre si dovrà indicare con l'argomento \param{id} l'utente o -il gruppo (specificati rispettivamente per \acr{uid} e \acr{gid}) su cui si +il gruppo (specificati rispettivamente per \ids{UID} e \ids{GID}) su cui si vuole operare. Alcune operazioni usano l'argomento \param{addr} per indicare un indirizzo ad un area di memoria il cui utilizzo dipende dall'operazione stessa. @@ -5218,10 +5516,10 @@ l'amministratore può ottenere i dati di tutti. \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 - \acr{uid} e \acr{gid} a 32 bit e limiti fino a + \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 - \acr{uid} e \acr{GID} a 32 bit e limiti fino a + \ids{UID} e \ids{GID} a 32 bit e limiti fino a $2^{64}$ byte e $2^{64}$ file.\\ \hline \end{tabular} @@ -5689,7 +5987,7 @@ nell'esecuzione di un qualunque programma l'amministratore perderebbe tutti i privilegi originali dal processo. Per questo motivo se un programma senza \textit{capabilities} assegnate viene -eseguito da un processo con \acr{uid} reale 0, esso verrà trattato come +eseguito da un processo con \ids{UID} reale 0, esso verrà trattato come se tanto il \textit{permitted set} che l'\textit{inheritable set} fossero con tutte le \textit{capabilities} abilitate, con l'\textit{effective set} attivo, col risultato di fornire comunque al processo tutte le capacità presenti nel @@ -5698,19 +5996,19 @@ il \acr{suid} bit ed appartiene all'amministratore, in entrambi i casi si riesce così a riottenere il comportamento classico di un sistema unix-like. Una seconda circostanza è quella relativa a cosa succede alle -\textit{capabilities} di un processo nelle possibili transizioni da \acr{uid} -nullo a \acr{uid} non nullo o viceversa (corrispondenti rispettivamente a +\textit{capabilities} di un processo nelle possibili transizioni da \ids{UID} +nullo a \ids{UID} non nullo o viceversa (corrispondenti rispettivamente a cedere o riottenere i i privilegi di amministratore) che si possono effettuare con le varie funzioni viste in sez.~\ref{sec:proc_setuid}. In questo caso la casistica è di nuovo alquanto complessa, considerata anche la presenza dei diversi gruppi di identificatori illustrati in tab.~\ref{tab:proc_uid_gid}, si avrà allora che: \begin{enumerate*} -\item se si passa da \acr{uid} effettivo nullo a non nullo +\item se si passa da \ids{UID} effettivo nullo a non nullo l'\textit{effective set} del processo viene totalmente azzerato, se - viceversa si passa da \acr{uid} effettivo non nullo a nullo il + viceversa si passa da \ids{UID} effettivo non nullo a nullo il \textit{permitted set} viene copiato nell'\textit{effective set}; -\item se si passa da \textit{file system} \acr{uid} nullo a non nullo verranno +\item se si passa da \textit{file system} \ids{UID} nullo a non nullo verranno cancellate dall'\textit{effective set} del processo tutte le capacità attinenti i file, e cioè \const{CAP\_LINUX\_IMMUTABLE}, \const{CAP\_MKNOD}, \const{CAP\_DAC\_OVERRIDE}, \const{CAP\_DAC\_READ\_SEARCH}, @@ -5745,7 +6043,7 @@ Per questo motivo a partire dal kernel 2.6.26, se le \textit{file ulteriore maschera binaria, chiamata \textit{securebits flags}, su cui sono mantenuti una serie di flag (vedi tab.~\ref{tab:securebits_values}) il cui valore consente di modificare queste regole speciali che si applicano ai -processi con \acr{uid} nullo. La maschera viene sempre mantenuta +processi con \ids{UID} nullo. La maschera viene sempre mantenuta attraverso una \func{fork}, mentre attraverso una \func{exec} viene sempre cancellato il flag \const{SECURE\_KEEP\_CAPS}. @@ -5759,22 +6057,22 @@ cancellato il flag \const{SECURE\_KEEP\_CAPS}. \hline \const{SECURE\_KEEP\_CAPS}& Il processo non subisce la cancellazione delle sue \textit{capabilities} quando tutti i suoi - \acr{uid} passano ad un valore non + \ids{UID} passano ad un valore non nullo (regola di compatibilità per il cambio - di \acr{uid} n.~3 del precedente + di \ids{UID} n.~3 del precedente 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 delle sue \textit{capabilities} nel passaggio - da nullo a non nullo degli \acr{uid} + da nullo a non nullo degli \ids{UID} dei gruppi \textit{effective} e \textit{file system} (regole di compatibilità - per il cambio di \acr{uid} nn.~1 e 2 del + per il cambio di \ids{UID} nn.~1 e 2 del precedente elenco).\\ \const{SECURE\_NOROOT} & Il processo non assume nessuna capacità aggiuntiva quando esegue un programma, anche - se ha \acr{uid} nullo o il programma ha + se ha \ids{UID} nullo o il programma ha il \acr{suid} bit attivo ed appartiene all'amministratore (regola di compatibilità per l'esecuzione di programmi senza @@ -6010,8 +6308,8 @@ capacità), o di impostare i \textit{securebits} delle \textit{capabilities}. La prima fra le capacità ``\textsl{ampie}'' che occorre dettagliare maggiormente è \const{CAP\_FOWNER}, che rimuove le restrizioni poste ad un processo che non ha la proprietà di un file in un vasto campo di -operazioni;\footnote{vale a dire la richiesta che l'\acr{uid} effettivo del - processo (o meglio l'\acr{uid} di filesystem, vedi +operazioni;\footnote{vale a dire la richiesta che l'\ids{UID} effettivo del + processo (o meglio l'\ids{UID} di filesystem, vedi sez.~\ref{sec:proc_setuid}) coincida con quello del proprietario.} queste comprendono i cambiamenti dei permessi e dei tempi del file (vedi sez.~\ref{sec:file_perm_management} e sez.~\ref{sec:file_file_times}), le @@ -6036,7 +6334,7 @@ disattivare la swap, montare, rimontare e smontare filesystem (vedi sez.~\ref{sec:sys_file_config}), effettuare operazioni di controllo su qualunque oggetto dell'IPC di SysV (vedi sez.~\ref{sec:ipc_sysv}), operare sugli attributi estesi dei file di classe \texttt{security} o \texttt{trusted} -(vedi sez.~\ref{sec:file_xattr}), specificare un \acr{uid} arbitrario +(vedi sez.~\ref{sec:file_xattr}), specificare un \ids{UID} arbitrario nella trasmissione delle credenziali dei socket (vedi sez.~\ref{sec:socket_credential_xxx}), assegnare classi privilegiate (\const{IOPRIO\_CLASS\_RT} e prima del kernel 2.6.25 anche @@ -6659,7 +6957,7 @@ funzione. -\subsection{La funzione \func{chroot}} +\subsection{La gestione dei {chroot}} \label{sec:file_chroot} % TODO introdurre nuova sezione sulle funzionalità di sicurezza avanzate, con @@ -6673,6 +6971,8 @@ Benché non abbia niente a che fare con permessi, utenti e gruppi, la funzione programma ad una sezione limitata del filesystem, per cui ne parleremo in questa sezione. +% TODO riferimenti ai bind mount, link simbolici ecc. + Come accennato in sez.~\ref{sec:proc_fork} ogni processo oltre ad una directory di lavoro, ha anche una directory \textsl{radice}\footnote{entrambe sono contenute in due campi (rispettivamente \var{pwd} e \var{root}) di @@ -6705,7 +7005,7 @@ con la funzione \funcd{chroot}, il cui prototipo è: \bodydesc{La funzione restituisce zero in caso di successo e -1 per un errore, in caso di errore \var{errno} può assumere i valori: \begin{errlist} - \item[\errcode{EPERM}] l'\acr{uid} effettivo del processo non è zero. + \item[\errcode{EPERM}] l'\ids{UID} effettivo del processo non è zero. \end{errlist} ed inoltre \errval{EFAULT}, \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM}, \errval{ENOTDIR}, \errval{EACCES}, \errval{ELOOP};