\section{La gestione di file e directory}
+\label{sec:file_dir}
Come già accennato in \secref{sec:file_filesystem} in un sistema unix-like la
gestione dei file ha delle caratteristiche specifiche che derivano
Come spiegato in \secref{sec:file_filesystem} l'accesso al contenuto di un
file su disco avviene attraverso il suo inode\index{inode}, e il nome che si
-trova in una directory è solo una etichetta associata ad un puntatore a che fa
+trova in una directory è solo un'etichetta associata ad un puntatore a che fa
riferimento al suddetto inode.
Questo significa che la realizzazione di un link è immediata in quanto uno
restrizioni è applicata).
Una delle caratteristiche di queste funzioni è che la creazione/rimozione
-della nome dalla directory e l'incremento/decremento del numero di riferimenti
+del nome dalla directory e l'incremento/decremento del numero di riferimenti
nell'inode devono essere effettuati in maniera atomica (si veda
\secref{sec:proc_atom_oper}) senza possibili interruzioni fra le due
-operazioni, per questo entrambe queste funzioni sono realizzate tramite una
+operazioni. Per questo entrambe queste funzioni sono realizzate tramite una
singola system call.
Si ricordi infine che il file non viene eliminato dal disco fintanto che tutti
-i riferimenti ad esso sono stati cancellati, solo quando il \textit{link
+i riferimenti ad esso sono stati cancellati: solo quando il \textit{link
count} mantenuto nell'inode diventa zero lo spazio occupato viene rimosso. A
-questo però si aggiunge una altra condizione, e cioè che non ci siano processi
+questo però si aggiunge un'altra condizione, e cioè che non ci siano processi
che abbiano detto file aperto.
Questa proprietà viene spesso usata per essere sicuri di non lasciare file
\end{prototype}
Per cambiare nome ad un file o a una directory (che devono comunque essere
-nello stesso filesystem) si usa invece la funzione \func{rename}\footnote{la
+nello stesso filesystem) si usa invece la funzione \func{rename},\footnote{la
funzione è definita dallo standard ANSI C solo per i file, POSIX estende la
- funzione anche alle directory}, il cui prototipo è:
+ funzione anche alle directory.} il cui prototipo è:
\begin{prototype}{stdio.h}
{int rename(const char *oldpath, const char *newpath)}
In ogni caso se \var{newpath} esiste e l'operazione fallisce per un qualche
motivo (come un crash del kernel), \func{rename} garantisce di lasciare
-presente una istanza di \var{newpath}. Tuttavia nella sovrascrittura potrà
+presente un'istanza di \var{newpath}. Tuttavia nella sovrascrittura potrà
esistere una finestra in cui sia \var{oldpath} che \var{newpath} fanno
riferimento allo stesso file.
Per ovviare a queste limitazioni i sistemi Unix supportano un'altra forma di
link (i cosiddetti \textit{soft link} o \textit{symbolic link}), che sono,
-come avviene in altri sistemi operativi, dei file speciali che contengono il
+come avviene in altri sistemi operativi, dei file speciali che contengono
semplicemente il riferimento ad un altro file (o directory). In questo modo è
-possibile effettuare link anche attraverso filesystem diversi, a file posti
-in filesystem che non supportano i link diretti, a delle directory, ed anche a
+possibile effettuare link anche attraverso filesystem diversi, a file posti in
+filesystem che non supportano i link diretti, a delle directory, ed anche a
file che non esistono ancora.
Il sistema funziona in quanto i link simbolici sono contrassegnati come tali
Un caso comune che si può avere con i link simbolici è la creazione dei
cosiddetti \textit{loop}. La situazione è illustrata in \curfig, che riporta
la struttura della directory \file{/boot}. Come si vede si è creato al suo
-interno un link simbolico che punta di nuovo a \file{/boot}\footnote{Questo
+interno un link simbolico che punta di nuovo a \file{/boot}.\footnote{Questo
tipo di loop è stato effettuato per poter permettere a \cmd{grub} (un
bootloader in grado di leggere direttamente da vari filesystem il file da
lanciare come sistema operativo) di vedere i file in questa directory con lo
stesso path con cui verrebbero visti dal sistema operativo, anche se essi si
trovano, come è solito, su una partizione separata (e che \cmd{grub}
- vedrebbe come radice).}.
+ vedrebbe come radice).}
Questo può causare problemi per tutti quei programmi che effettuano la
scansione di una directory senza tener conto dei link simbolici, ad esempio se
$ cat temporaneo
cat: temporaneo: No such file or directory
\end{verbatim}%$
-con un errore che può sembrare sbagliato, dato che una ispezione con \cmd{ls}
+con un errore che può sembrare sbagliato, dato che un'ispezione con \cmd{ls}
ci mostrerebbe invece l'esistenza di \file{temporaneo}.
\label{sec:file_mknod}
Finora abbiamo parlato esclusivamente di file, directory e link simbolici; in
-\secref{sec:file_file_types} abbiamo visto però che il sistema preveda pure
-degli altri tipi di file, come i file di dispositivo e le fifo (i socket sono
-un caso a parte, che vedremo in \secref{cha:socket_intro}).
+\secref{sec:file_file_types} abbiamo visto però che il sistema prevede pure
+degli altri tipi di file speciali, come i file di dispositivo e le fifo (i
+socket sono un caso a parte, che vedremo in \capref{cha:socket_intro}).
La manipolazione delle caratteristiche di questi file e la loro cancellazione
può essere effettuata con le stesse funzioni che operano sui file normali; ma
\capref{cha:files_std_interface}); la funzione \func{opendir} apre uno di
questi stream e la funzione \func{readdir} legge il contenuto della directory,
i cui elementi sono le \textit{directory entry} (da distinguersi da quelle
-della cache di cui parlavamo in \secref{sec:file_vfs}) in una opportuna
+della cache di cui parlavamo in \secref{sec:file_vfs}) in un'opportuna
struttura \var{struct dirent}.
(NdA Il resto va scritto!!! É noioso e lo farò più avanti).
A ciascun processo è associato ad una directory nel filesystem che è chiamata
directory corrente o directory di lavoro (\textit{current working directory})
che è quella a cui si fa riferimento quando un filename è espresso in forma
-relativa, dove il relativa fa riferimento appunto a questa directory.
+relativa, dove il ``relativa'' fa riferimento appunto a questa directory.
Quando un utente effettua il login questa directory viene settata alla
\textit{home directory} del suo account. Il comando \cmd{cd} della shell
Il buffer deve essere sufficientemente lungo da poter contenere il pathname
completo più lo zero di terminazione della stringa. Qualora esso ecceda le
dimensioni specificate con \var{size} la funzione restituisce un errore. Si
-può anche specificare un puntatore nullo come \var{buffer}\footnote{questa è
- una estensione allo standard POSIX.1, supportata da Linux}, nel qual caso la
+può anche specificare un puntatore nullo come \var{buffer},\footnote{questa è
+ un'estensione allo standard POSIX.1, supportata da Linux.} nel qual caso la
stringa sarà allocata automaticamente per una dimensione pari a \var{size}
qualora questa sia diversa da zero, o della lunghezza esatta del pathname
altrimenti. In questo caso ci si deve ricordare di disallocare la stringa una
sostanzialmente equivalente ad una \code{getcwd(NULL, 0)}, con la sola
differenza che essa ritorna il valore della variabile di ambiente \macro{PWD},
che essendo costruita dalla shell può contenere un pathname comprendente anche
-con dei link simbolici. Usando \func{getcwd} infatti, essendo il
-pathname ricavato risalendo all'indietro l'albero della directory, si
-perderebbe traccia di ogni passaggio attraverso eventuali link simbolici.
+dei link simbolici. Usando \func{getcwd} infatti, essendo il pathname ricavato
+risalendo all'indietro l'albero della directory, si perderebbe traccia di ogni
+passaggio attraverso eventuali link simbolici.
Per cambiare la directory di lavoro corrente si può usare la funzione
\func{chdir} (equivalente del comando di shell \cmd{cd}) il cui nome sta
\end{itemize*}
In ogni caso, anche se la generazione del nome è casuale, ed è molto difficile
-ottere un nome duplicato, nulla assicura che un altro processo non possa avere
-creato, fra l'ottenimento del nome e l'apertura del file, un altro file con lo
-stesso nome; per questo motivo quando si usa il nome ottenuto da una di queste
-funzioni occorre sempre aprire il nuovo file in modalità di esclusione (cioè
-con l'opzione \macro{O\_EXCL} per i file descriptor o con il flag \code{x} per
-gli stream) che fa fallire l'apertura in caso il file sia già esistente.
+ottenere un nome duplicato, nulla assicura che un altro processo non possa
+avere creato, fra l'ottenimento del nome e l'apertura del file, un altro file
+con lo stesso nome; per questo motivo quando si usa il nome ottenuto da una di
+queste funzioni occorre sempre aprire il nuovo file in modalità di esclusione
+(cioè con l'opzione \macro{O\_EXCL} per i file descriptor o con il flag
+\code{x} per gli stream) che fa fallire l'apertura in caso il file sia già
+esistente.
Per evitare di dovere effettuare a mano tutti questi controlli, lo standard
POSIX definisce la funzione \func{tempfile}, il cui prototipo è:
\noindent essa restituisce direttamente uno stream già aperto (in modalità
\code{r+b}, si veda \secref{sec:file_fopen}) e pronto per l'uso, che viene
automaticamente cancellato alla sua chiusura o all'uscita dal programma. Lo
-standard non specifica in quale directory verrà aperto il file, ma \acr{glibc}
-prima tentano con \macro{P\_tmpdir} e poi con \file{/tmp}. Questa funzione è
-rientrante e non soffre di problemi di \textit{race condition}.
+standard non specifica in quale directory verrà aperto il file, ma le
+\acr{glibc} prima tentano con \macro{P\_tmpdir} e poi con \file{/tmp}. Questa
+funzione è rientrante e non soffre di problemi di \textit{race condition}.
Alcune versioni meno recenti di Unix non supportano queste funzioni; in questo
caso si possono usare le vecchie funzioni \func{mktemp} e \func{mkstemp} che
\macro{S\_ISSOCK(m)} & socket \\
\hline
\end{tabular}
- \caption{Macro per i tipi di file (definite in \texttt{sys/stat.h})}
+ \caption{Macro per i tipi di file (definite in \texttt{sys/stat.h}).}
\label{tab:file_type_macro}
\end{table}
binaria che permette di estrarre i bit nei quali viene memorizzato il tipo di
file, i valori successivi sono le costanti corrispondenti ai singoli bit, e
possono essere usati per effettuare la selezione sul tipo di file voluto, con
-una opportuna combinazione.
+un'opportuna combinazione.
\begin{table}[htb]
\centering
\hline
\end{tabular}
\caption{Costanti per l'identificazione dei vari bit che compongono il campo
- \var{st\_mode} (definite in \file{sys/stat.h})}
+ \var{st\_mode} (definite in \file{sys/stat.h}).}
\label{tab:file_mode_flags}
\end{table}
per l'interfaccia degli stream); scrivere sul file a blocchi di dati di
dimensione inferiore sarebbe inefficiente.
-Si tenga conto che lunghezza del file riportata in \var{st\_size} non è detto
-che corrisponda all'occupazione dello spazio su disco per via della possibile
-esistenza dei cosiddetti \textit{holes} (letteralmente \textsl{buchi}) che
-si formano tutte le volte che si va a scrivere su un file dopo aver eseguito
-una \func{lseek} (vedi \secref{sec:file_lseek}) oltre la sua conclusione
-corrente.
+Si tenga conto che la lunghezza del file riportata in \var{st\_size} non è
+detto che corrisponda all'occupazione dello spazio su disco per via della
+possibile esistenza dei cosiddetti \textit{holes} (letteralmente
+\textsl{buchi}) che si formano tutte le volte che si va a scrivere su un file
+dopo aver eseguito una \func{lseek} (vedi \secref{sec:file_lseek}) oltre la
+sua fine.
In questo caso si avranno risultati differenti a seconda del modo in cui si
calcola la lunghezza del file, ad esempio il comando \cmd{du}, (che riporta il
\func{utime} & \cmd{-c} \\
\hline
\end{tabular}
- \caption{I tre tempi associati a ciascun file}
+ \caption{I tre tempi associati a ciascun file.}
\label{tab:file_file_times}
\end{table}
directory sono file (che contengono una lista di nomi) che il sistema tratta
in maniera del tutto analoga a tutti gli altri.
-Per questo motivo tutte le volte che compiremo una operazione su un file che
+Per questo motivo tutte le volte che compiremo un'operazione su un file che
comporta una modifica del nome contenuto nella directory, andremo anche a
scrivere sulla directory che lo contiene cambiandone il tempo di modifica. Un
esempio di questo può essere la cancellazione di un file, invece leggere o
Control List} che possono essere aggiunte al filesystem standard con
opportune patch, e sono presenti in filesystem non ancora inclusi nel kernel
ufficiale come \textsl{xfs}, o meccanismi di controllo ancora più
- sofisticati come il \textit{mandatory access control} di SE-Linux} ma nella
+ sofisticati come il \textit{mandatory access control} di SE-Linux.} ma nella
maggior parte dei casi il meccanismo standard è più che sufficiente a
soffisfare tutte le necessità più comuni. I tre permessi di base associati ad
ogni file sono:
dettaglio in \secref{sec:proc_perms}).
La presenza dei bit \acr{suid} e \acr{sgid} su un file può essere rilevata con
-il comando \cmd{ls -l}, che una lettera \cmd{s} al posto della \cmd{x} in
-corrispondenza dei permessi di utente o gruppo. La stessa lettera \cmd{s} può
-essere usata nel comando \cmd{chmod} per settare questi bit. Infine questi bit
-possono essere controllati all'interno di \var{st\_mode} con l'uso delle due
-costanti \macro{S\_ISUID} e \macro{S\_IGID}, i cui valori sono riportati in
-\tabref{tab:file_mode_flags}.
+il comando \cmd{ls -l}, che visualizza una lettera \cmd{s} al posto della
+\cmd{x} in corrispondenza dei permessi di utente o gruppo. La stessa lettera
+\cmd{s} può essere usata nel comando \cmd{chmod} per settare questi bit.
+Infine questi bit possono essere controllati all'interno di \var{st\_mode} con
+l'uso delle due costanti \macro{S\_ISUID} e \macro{S\_IGID}, i cui valori sono
+riportati in \tabref{tab:file_mode_flags}.
Gli stessi bit vengono ad assumere in significato completamente diverso per le
directory, normalmente infatti Linux usa la convenzione di SVR4 per indicare
proposito).
Infine Linux utilizza il bit \acr{sgid} per una ulteriore estensione mutuata
-da SVR4. Il caso in cui un file ha il bit \acr{sgid} settato senza che lo sia
+da SVr4. Il caso in cui un file ha il bit \acr{sgid} settato senza che lo sia
anche il corrispondente bit di esecuzione viene utilizzato per attivare per
quel file il \textit{mandatory locking} (argomento che affronteremo in
dettagliopiù avanti in \secref{sec:file_mand_locking}).
sostanzialmente inutile questo procedimento.
Benché ormai non venga più utilizzato per i file, lo \textsl{sticky bit} ha
-invece assunto un uso importante per le directory\footnote{lo \textsl{sticky
- bit} per le directory è una estensione non definita nello standard POSIX,
- Linux però la supporta, così come BSD e SVR4.}; in questo caso se il bit è
+invece assunto un uso importante per le directory;\footnote{lo \textsl{sticky
+ bit} per le directory è un'estensione non definita nello standard POSIX,
+ Linux però la supporta, così come BSD e SVR4.} in questo caso se il bit è
settato un file potrà essere rimosso dalla directory soltanto se l'utente ha
il permesso di scrittura su di essa ed inoltre è vera una delle seguenti
condizioni:
partenza, in tutte le sottodirectory. La semantica SVr4 offre la possibilità
di scegliere, ma per ottenere lo stesso risultato di coerenza che si ha con
BSD necessita che per le nuove directory venga anche propagato anche il bit
-\acr{sgid}. Questo è il comportamento di default di \func{mkdir}, ed é in
+\acr{sgid}. Questo è il comportamento di default di \func{mkdir}, ed è in
questo modo ad esempio che Debian assicura che le sottodirectory create nelle
home di un utente restino sempre con il \acr{gid} del gruppo primario dello
stesso.
\hline
\end{tabular}
\caption{Valori possibile per il parametro \var{mode} della funzione
- \func{access}}
+ \func{access}.}
\label{tab:file_access_mode_val}
\end{table}
Per alcuni filesystem\footnote{il filesystem \acr{ext2} supporta questa
caratteristica, che è mutuata da BSD.} è inoltre prevista una ulteriore
-misura di sicurezza, volta ad scongiurare l'abuso dei bit \acr{suid} e
+misura di sicurezza, volta a scongiurare l'abuso dei bit \acr{suid} e
\acr{sgid}; essa consiste nel cancellare automaticamente questi bit qualora un
processo che non appartenga all'amministratore scriva su un file. In questo
modo anche se un utente malizioso scopre un file \acr{suid} su cui può
-scrivere, una eventuale modifica comporterà la perdita di ogni ulteriore
+scrivere, un'eventuale modifica comporterà la perdita di ogni ulteriore
privilegio.
\subsection{La funzione \func{umask}}
Questa maschera è una caratteristica di ogni processo\footnote{è infatti
contenuta nel campo \var{umask} di \var{fs\_struct}, vedi
- \figref{fig:proc_task_struct}} e viene utilizzata per impedire che alcuni
+ \figref{fig:proc_task_struct}.} e viene utilizzata per impedire che alcuni
permessi possano essere assegnati ai nuovi file in sede di creazione. I bit
indicati nella maschera vengono infatti esclusi quando un nuovo file viene
creato.
suo gruppo primario o uno dei gruppi a cui appartiene.
La funzione \func{chown} segue i link simbolici, per operare direttamente su
-in link simbolico si deve usare la funzione \func{lchown}.\footnote{fino alla
+un link simbolico si deve usare la funzione \func{lchown}.\footnote{fino alla
versione 2.1.81 in Linux \func{chown} non seguiva i link simbolici, da
allora questo comportamento è stato assegnato alla funzione \func{lchown},
introdotta per l'occasione, ed è stata creata una nuova system call per
- \func{chown} che seguisse i link simbolici} La funzione \func{fchown} opera
+ \func{chown} che seguisse i link simbolici.} La funzione \func{fchown} opera
su un file aperto, essa è mutuata da BSD, ma non è nello standard POSIX.
Un'altra estensione rispetto allo standard POSIX è che specificando -1 come
-valore per \var{owner} e \var{group} i valori restano immutati.
+valore per \var{owner} e \var{group} i valori restano immutati.
Quando queste funzioni sono chiamate con successo da un processo senza i
privilegi di root entrambi i bit \acr{suid} e \acr{sgid} vengono
projects / gapil.git / blobdiff