From: Simone Piccardi Date: Sat, 30 Jan 2010 15:43:39 +0000 (+0000) Subject: Piccole correzioni e aggiornamenti. X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=213390f6a966149331b1cb7360d8ab76b0afc416;p=gapil.git Piccole correzioni e aggiornamenti. --- diff --git a/filedir.tex b/filedir.tex index b1f8e76..e14c105 100644 --- a/filedir.tex +++ b/filedir.tex @@ -2648,9 +2648,10 @@ a scongiurare l'abuso dei \itindex{suid~bit} bit \acr{suid} e \acr{sgid}; essa consiste nel cancellare automaticamente questi bit dai permessi di un file qualora un processo che non appartenga all'amministratore\footnote{per la precisione un processo che non dispone della \itindex{capabilities} capacità - \const{CAP\_FSETID}.} effettui una scrittura. In questo modo anche se un -utente malizioso scopre un file \acr{suid} su cui può scrivere, un'eventuale -modifica comporterà la perdita di questo privilegio. + \const{CAP\_FSETID}, vedi sez.~\ref{sec:proc_capabilities}.} effettui una +scrittura. In questo modo anche se un utente malizioso scopre un file +\acr{suid} su cui può scrivere, un'eventuale modifica comporterà la perdita di +questo privilegio. Le funzioni \func{chmod} e \func{fchmod} ci permettono di modificare i permessi di un file, resta però il problema di quali sono i permessi assegnati @@ -2942,7 +2943,7 @@ un insieme di \textsl{capacit potessero essere abilitate e disabilitate in maniera indipendente per ciascun processo con privilegi di amministratore, permettendo così una granularità molto più fine nella distribuzione degli stessi che evitasse la originaria -situazione di \textsl{tutto o nulla}. +situazione di ``\textsl{tutto o nulla}''. Il meccanismo completo delle \textit{capabilities}\footnote{l'implementazione si rifà ad una bozza di quello che doveva diventare lo standard POSIX.1e, diff --git a/fileintro.tex b/fileintro.tex index 4bcbd42..0048b3b 100644 --- a/fileintro.tex +++ b/fileintro.tex @@ -68,7 +68,7 @@ viene identificato dall'utente usando quello che viene chiamato ormai così comune che mantenerne l'uso è senz'altro più chiaro dell'alternativa proposta.}, cioè il percorso che si deve fare per accedere al file a partire dalla \textit{root directory}, che è composto da una serie -di nomi separati da una \file{/}. +di nomi separati da una ``\file{/}''. All'avvio del sistema, completata la fase di inizializzazione, il kernel riceve dal bootloader l'indicazione di quale dispositivo contiene il @@ -103,21 +103,21 @@ convenzione, sono inseriti nella directory \file{/dev}). Il nome completo di un file viene chiamato \textit{pathname} ed il procedimento con cui si individua il file a cui esso fa riferimento è chiamato risoluzione del nome (\textit{filename resolution} o \textit{pathname -resolution}). La risoluzione viene fatta esaminando il \textit{pathname} da + resolution}). La risoluzione viene fatta esaminando il \textit{pathname} da sinistra a destra e localizzando ogni nome nella directory indicata dal nome -precedente usando \texttt{/} come separatore\footnote{nel caso di nome vuoto, -il costrutto \file{//} viene considerato equivalente a \file{/}.}: ovviamente, -perché il procedimento funzioni, occorre che i nomi indicati come directory -esistano e siano effettivamente directory, inoltre i permessi (si veda -sez.~\ref{sec:file_access_control}) devono consentire l'accesso all'intero -\textit{pathname}. - -Se il \textit{pathname} comincia per \texttt{/} la ricerca parte dalla -directory radice del processo; questa, a meno di un \func{chroot} (su cui -torneremo in sez.~\ref{sec:file_chroot}) è la stessa per tutti i processi ed -equivale alla directory radice dell'albero dei file: in questo caso si parla -di un \textsl{pathname assoluto} \itindsub{pathname}{assoluto}. Altrimenti la -ricerca parte dalla directory corrente (su cui torneremo in +precedente usando il carattere ``\texttt{/}'' come separatore\footnote{nel + caso di nome vuoto, il costrutto \file{//} viene considerato equivalente a + \file{/}.}: ovviamente, perché il procedimento funzioni, occorre che i nomi +indicati come directory esistano e siano effettivamente directory, inoltre i +permessi (si veda sez.~\ref{sec:file_access_control}) devono consentire +l'accesso all'intero \textit{pathname}. + +Se il \textit{pathname} comincia con il carattere ``\texttt{/}'' la ricerca +parte dalla directory radice del processo; questa, a meno di un \func{chroot} +(su cui torneremo in sez.~\ref{sec:file_chroot}) è la stessa per tutti i +processi ed equivale alla directory radice dell'albero dei file: in questo +caso si parla di un \textsl{pathname assoluto} \itindsub{pathname}{assoluto}. +Altrimenti la ricerca parte dalla directory corrente (su cui torneremo in sez.~\ref{sec:file_work_dir}) ed il pathname è detto \itindsub{pathname}{relativo} \textsl{pathname relativo}. @@ -126,7 +126,9 @@ inseriti in ogni directory: il primo fa riferimento alla directory corrente e il secondo alla directory \textsl{genitrice} (o \textit{parent directory}) cioè la directory che contiene il riferimento alla directory corrente; nel caso la directory corrente coincida con la directory radice, allora il -riferimento è a se stessa. \itindend{pathname} +riferimento è a se stessa. + +\itindend{pathname} \subsection{I tipi di file} @@ -201,33 +203,35 @@ VMS.\footnote{questo vale anche per i dispositivi a blocchi: la strutturazione \textsl{accesso diretto} riferendosi alla capacità, che non ha niente a che fare con tutto ciò, di effettuare, attraverso degli appositi \index{file!di~dispositivo} file di dispositivo, operazioni di I/O - direttamente sui dischi senza passare attraverso un filesystem (il - cosiddetto \textit{raw access}, introdotto coi kernel della serie 2.4.x).} - -Una seconda differenza è nel formato dei file ASCII: in Unix la fine riga è -codificata in maniera diversa da Windows o Mac, in particolare il fine riga è -il carattere \texttt{LF} (o \verb|\n|) al posto del \texttt{CR} (\verb|\r|) -del Mac e del \texttt{CR LF} di Windows.\footnote{per questo esistono in Linux - dei programmi come \cmd{unix2dos} e \cmd{dos2unix} che effettuano una - conversione fra questi due formati di testo.} Questo può causare alcuni -problemi qualora nei programmi si facciano assunzioni sul terminatore della -riga. + direttamente sui dischi senza passare attraverso un filesystem, il + cosiddetto \textit{raw access}, introdotto coi kernel della serie 2.4.x ed + in sostanziale disuso.} + +Una seconda differenza è nel formato dei file di testo: in Unix la fine riga è +codificata in maniera diversa da Windows o dal vecchio MacOS, in particolare +il fine riga è il carattere \texttt{LF} (o \verb|\n|) al posto del \texttt{CR} +(\verb|\r|) del vecchio MacOS e del \texttt{CR LF} di Windows.\footnote{per + questo esistono in Linux dei programmi come \cmd{unix2dos} e \cmd{dos2unix} + che effettuano una conversione fra questi due formati di testo.} Questo può +causare alcuni problemi qualora nei programmi si facciano assunzioni sul +terminatore della riga. Si ricordi infine che un kernel Unix non fornisce nessun supporto per la tipizzazione dei file di dati e che non c'è nessun supporto del sistema per le estensioni come parte del filesystem.\footnote{non è così ad esempio nel filesystem HFS dei Mac, che supporta delle risorse associate ad ogni file, che specificano fra l'altro il contenuto ed il programma da usare per - leggerlo. In realtà per alcuni filesystem, come l'XFS della SGI, esiste la - possibilità di associare delle risorse ai file, ma è una caratteristica - tutt'ora poco utilizzata, dato che non corrisponde al modello classico dei - file in un sistema Unix.} Ciò nonostante molti programmi adottano delle -convenzioni per i nomi dei file, ad esempio il codice C normalmente si mette -in file con l'estensione \file{.c}; un'altra tecnica molto usata è quella di -utilizzare i primi 4 byte del file per memorizzare un \textit{magic number} -che classifichi il contenuto; entrambe queste tecniche, per quanto usate ed -accettate in maniera diffusa, restano solo delle convenzioni il cui rispetto è -demandato alle applicazioni stesse. + leggerlo. In realtà per alcuni filesystem esiste la possibilità di + associare delle risorse ai file con gli \textit{extended attributes} (vedi + sez.~\ref{sec:file_xattr}), ma è una caratteristica tutt'ora poco + utilizzata, dato che non corrisponde al modello classico dei file in un + sistema Unix.} Ciò nonostante molti programmi adottano delle convenzioni per +i nomi dei file, ad esempio il codice C normalmente si mette in file con +l'estensione \file{.c}; un'altra tecnica molto usata è quella di utilizzare i +primi 4 byte del file per memorizzare un \textit{magic number} che classifichi +il contenuto; entrambe queste tecniche, per quanto usate ed accettate in +maniera diffusa, restano solo delle convenzioni il cui rispetto è demandato +alle applicazioni stesse. \subsection{Le due interfacce ai file} @@ -410,8 +414,9 @@ da usare per poterlo manipolare. Le \textit{dentry} ``vivono'' in memoria e non vengono mai salvate su disco, vengono usate per motivi di velocità, gli \index{inode} \textit{inode} invece stanno su disco e vengono copiati in memoria quando serve, ed ogni cambiamento -viene copiato all'indietro sul disco, gli \index{inode} inode che stanno in -memoria sono \index{inode} inode del VFS ed è ad essi che puntano le singole +viene copiato all'indietro sul disco (aggiornando i cosiddetti +\textsl{metadati} del file), gli \index{inode} inode che stanno in memoria +sono \index{inode} inode del VFS ed è ad essi che puntano le singole \textit{dentry}. La \textit{dcache} costituisce perciò una sorta di vista completa di tutto @@ -457,7 +462,8 @@ tab.~\ref{tab:file_file_operations}. sez.~\ref{sec:file_lseek}).\\ \textsl{\code{ioctl}} & Accede alle operazioni di controllo (vedi sez.~\ref{sec:file_ioctl}).\\ - \textsl{\code{readdir}}& Legge il contenuto di una directory.\\ + \textsl{\code{readdir}}& Legge il contenuto di una directory (vedi + sez.~\ref{sec:file_dir_read}).\\ \textsl{\code{poll}} & Usata nell'I/O multiplexing (vedi sez.~\ref{sec:file_multiplexing}).\\ \textsl{\code{mmap}} & Mappa il file in memoria (vedi @@ -483,7 +489,7 @@ tipo di file in questione. Pertanto è possibile scrivere allo stesso modo sulla porta seriale come su un normale file di dati; ovviamente certe operazioni (nel caso della seriale ad esempio la \code{seek}) non saranno disponibili, però con questo sistema -l'utilizzo di diversi filesystem (come quelli usati da Windows o MacOs) è +l'utilizzo di diversi filesystem (come quelli usati da Windows o MacOS) è immediato e (relativamente) trasparente per l'utente ed il programmatore. \itindend{Virtual~File~System} @@ -543,49 +549,60 @@ particolare \item L'\textit{inode} \index{inode} contiene tutte le informazioni riguardanti il file: il tipo di file, i permessi di accesso, le dimensioni, - i puntatori ai blocchi fisici che contengono i dati e così via; le - informazioni che la funzione \func{stat} fornisce provengono - dall'\textit{inode}; dentro una directory si troverà solo il nome del file e - il numero \index{inode} dell'\textit{inode} ad esso associato, cioè quella - che da qui in poi chiameremo una \textsl{voce} (come traduzione dell'inglese + i puntatori ai blocchi fisici che contengono i dati e così via, cioè quelli + che in genere vengono chiamati i \textsl{metadati} del file; le informazioni + che la funzione \func{stat} fornisce provengono dall'\textit{inode}; dentro + una directory si troverà solo il nome del file e il numero \index{inode} + dell'\textit{inode} ad esso associato, cioè quella che da qui in poi + chiameremo una ``\textsl{voce}'', come traduzione dell'inglese \textit{directory entry}, che non useremo anche per evitare confusione con - le \textit{dentry} del kernel di cui si parlava in sez.~\ref{sec:file_vfs}). + le \textit{dentry} del kernel di cui si parlava in sez.~\ref{sec:file_vfs}. \item Come mostrato in fig.~\ref{fig:file_filesys_detail} si possono avere più voci che puntano allo stesso \textit{inode}. Ogni \textit{inode} ha un - contatore che contiene il numero di riferimenti (\textit{link count}) che - sono stati fatti ad esso; solo quando questo contatore si annulla i dati del - file vengono effettivamente rimossi dal disco. Per questo la funzione per - cancellare un file si chiama \func{unlink}, ed in realtà non cancella - affatto i dati del file, ma si limita ad eliminare la relativa voce da una - directory e decrementare il numero di riferimenti \index{inode} + contatore che contiene il numero di riferimenti che sono stati fatti ad esso + (il cosiddetto \textit{link count}); solo quando questo contatore si annulla + i dati del file vengono effettivamente rimossi dal disco. Per questo la + funzione per cancellare un file si chiama \func{unlink}, ed in realtà non + cancella affatto i dati del file, ma si limita ad eliminare la relativa voce + da una directory e decrementare il numero di riferimenti \index{inode} nell'\textit{inode}. \item Il numero di \textit{inode} nella voce si riferisce ad un \textit{inode} nello stesso filesystem e non ci può essere una directory che contiene riferimenti ad \index{inode} \textit{inode} relativi ad altri filesystem. Questo limita l'uso del comando \cmd{ln} (che crea una nuova voce per un - file esistente, con la funzione \func{link}) al filesystem corrente. + file esistente con la funzione \func{link}) al filesystem corrente. \item Quando si cambia nome ad un file senza cambiare filesystem, il contenuto del file non viene spostato fisicamente, viene semplicemente creata una nuova voce per \index{inode} l'\textit{inode} in questione e rimossa la vecchia (questa è la modalità in cui opera normalmente il comando \cmd{mv} - attraverso la funzione \func{rename}). + attraverso la funzione \func{rename}). Questa operazione non modifica + minimamente neanche l'\textit{inode} del file dato che non si opera su + questo ma sulla directory che lo contiene. + +\item Gli \textit{inode} dei file, che contengono i \textsl{metadati} ed i + blocchi di spazio disco, che contengono i dati, sono risorse indipendenti ed + in genere vengono gestite come tali anche dai diversi filesystem; è pertanto + possibile sia esaurire lo spazio disco (caso più comune) che lo spazio per + gli \textit{inode}, nel primo caso non sarà possibile allocare ulteriore + spazio, ma si potranno creare file (vuoti), nel secondo non si potranno + creare nuovi file, ma si potranno estendere quelli che ci sono. \end{enumerate} -Infine è bene avere presente che, essendo file pure loro, esiste un numero di -riferimenti anche per le directory; per cui, se a partire dalla situazione -mostrata in fig.~\ref{fig:file_filesys_detail} creiamo una nuova directory -\file{img} nella directory \file{gapil}, avremo una situazione come quella in +Infine si noti che, essendo file pure loro, il numero di riferimenti esiste +anche per le directory; per cui, se a partire dalla situazione mostrata in +fig.~\ref{fig:file_filesys_detail} creiamo una nuova directory \file{img} +nella directory \file{gapil}, avremo una situazione come quella in fig.~\ref{fig:file_dirs_link}, dove per chiarezza abbiamo aggiunto dei numeri di \index{inode} inode. \begin{figure}[htb] \centering \includegraphics[width=14cm]{img/dir_links} - \caption{Organizzazione dei link per le directory.} + \caption{Organizzazione dei \textit{link} per le directory.} \label{fig:file_dirs_link} \end{figure} @@ -598,20 +615,15 @@ era partiti avr referenziata anche dalla voce ``\texttt{..}'' di \texttt{img}. -% TODO portare a ext3, ext4 e btrfs ed illustrare le problematiche che si -% possono incontrare (in particolare quelle relative alla perdita di contenuti -% in caso di crash del sistema) - \subsection{I filesystem di uso comune} \label{sec:file_ext2} Il filesystem standard più usato con Linux è il cosiddetto \textit{third extended filesystem}, identificato dalla sigla \acr{ext3}. Esso nasce come evoluzione del precedente \textit{second extended filesystem}, o \acr{ext2}, -di cui eredita gran parte delle caratteristiche di base, per questo motivo -parleremo anzitutto di questo, dato che molto di quanto diremo si applica -anche ad \acr{ext3}. - +di cui eredita gran parte delle caratteristiche di base, per questo, per +mantenere un minimo di semplicità, parleremo anzitutto di questo, dato che +molto di quanto diremo si applica anche ad \acr{ext3}. Il filesystem \acr{ext2} nasce come filesystem nativo di Linux a partire dalle prime versioni del kernel e supporta tutte le caratteristiche di un @@ -659,11 +671,6 @@ in gruppi di blocchi.\footnote{non si confonda questa definizione con \texttt{ext2\_fs.h} nella directory \texttt{include/linux} dei sorgenti del kernel.} -Ciascun gruppo di blocchi contiene una copia delle informazioni essenziali del -filesystem (superblock e descrittore del filesystem sono quindi ridondati) per -una maggiore affidabilità e possibilità di recupero in caso di corruzione del -superblock principale. - \begin{figure}[htb] \centering \includegraphics[width=9cm]{img/dir_struct} @@ -671,6 +678,11 @@ superblock principale. \label{fig:file_ext2_dirs} \end{figure} +Ciascun gruppo di blocchi contiene una copia delle informazioni essenziali del +filesystem (superblock e descrittore del filesystem sono quindi ridondati) per +una maggiore affidabilità e possibilità di recupero in caso di corruzione del +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 \index{inode} inode. @@ -682,6 +694,10 @@ 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. +% TODO portare a ext3, ext4 e btrfs ed illustrare le problematiche che si +% possono incontrare (in particolare quelle relative alla perdita di contenuti +% in caso di crash del sistema) + % LocalWords: everything is device kernel filesystem sez pathname root glibc % LocalWords: path filename bootloader proc name components fifo socket dev LF @@ -691,9 +707,9 @@ caratteri) senza sprecare spazio disco. % LocalWords: nell'header unistd stream dall'ANSI stdio locking POSIX fig type % LocalWords: register superblock dell'inode stat entry cache dcache dentry ln % LocalWords: l'inode lookup ops read write llseek ioctl readdir poll nell'I -% LocalWords: multiplexing mmap fsync fasync seek MacOs group dall' dell' img +% LocalWords: multiplexing mmap fsync fasync seek group dall' dell' img % LocalWords: count unlink nell' rename gapil second Tb attributes BSD SVr gid -% LocalWords: sgid append only log fs linux extented linked list third +% LocalWords: sgid append only log fs linux extented linked list third MacOS %%% Local Variables: diff --git a/fileunix.tex b/fileunix.tex index 3a9d1c0..4327719 100644 --- a/fileunix.tex +++ b/fileunix.tex @@ -386,6 +386,9 @@ ritorno il file descriptor con il valore pi \itindex{thread} \textit{thread}, fra l'apertura del file e l'impostazione della suddetta modalità con \func{fcntl}.} +%TODO trattare le differenze fra O_DSYNC, O_SYNC e O_RSYNC introdotte con +% il kernel 2.6.33, vedi http://lwn.net/Articles/350219/ + Questa caratteristica permette di prevedere qual è il valore del file descriptor che si otterrà al ritorno di \func{open}, e viene talvolta usata da alcune applicazioni per sostituire i file corrispondenti ai file standard diff --git a/system.tex b/system.tex index 4f6dd4e..b2f8249 100644 --- a/system.tex +++ b/system.tex @@ -1651,12 +1651,13 @@ Nello specificare un limite, oltre a fornire dei valori specifici, si pu anche usare la costante \const{RLIM\_INFINITY} che permette di sbloccare l'uso di una risorsa; ma si ricordi che solo un processo con i privilegi di amministratore\footnote{per essere precisi in questo caso quello che serve è - la \itindex{capabilities} \textit{capability} \const{CAP\_SYS\_RESOURCE}.} -può innalzare un limite al di sopra del valore corrente del limite massimo ed -usare un valore qualsiasi per entrambi i limiti. Si tenga conto infine che -tutti i limiti vengono ereditati dal processo padre attraverso una \func{fork} -(vedi sez.~\ref{sec:proc_fork}) e mantenuti per gli altri programmi eseguiti -attraverso una \func{exec} (vedi sez.~\ref{sec:proc_exec}). + la \itindex{capabilities} \textit{capability} \const{CAP\_SYS\_RESOURCE} + (vedi sez.~\ref{sec:proc_capabilities}).} può innalzare un limite al di +sopra del valore corrente del limite massimo ed usare un valore qualsiasi per +entrambi i limiti. Si tenga conto infine che tutti i limiti vengono ereditati +dal processo padre attraverso una \func{fork} (vedi sez.~\ref{sec:proc_fork}) +e mantenuti per gli altri programmi eseguiti attraverso una \func{exec} (vedi +sez.~\ref{sec:proc_exec}). \subsection{Le risorse di memoria e processore}