%% filedir.tex
%%
-%% Copyright (C) 2000-2004 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2005 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",
\errval{ENOSPC}, \errval{EIO}.}
\end{prototype}
-La funzione crea sul pathname \param{newpath} un collegamento diretto al file
-indicato da \param{oldpath}. Per quanto detto la creazione di un nuovo
-collegamento diretto non copia il contenuto del file, ma si limita a creare
-una voce nella directory specificata da \param{newpath} e ad aumentare di uno
-il numero di riferimenti al file (riportato nel campo \var{st\_nlink} della
-struttura \struct{stat}, vedi sez.~\ref{sec:file_stat}) aggiungendo il nuovo
-nome ai precedenti. Si noti che uno stesso file può essere così chiamato con
-vari nomi in diverse directory.
+La funzione crea sul \index{\textit{pathname}}\textit{pathname}
+\param{newpath} un collegamento diretto al file indicato da \param{oldpath}.
+Per quanto detto la creazione di un nuovo collegamento diretto non copia il
+contenuto del file, ma si limita a creare una voce nella directory specificata
+da \param{newpath} e ad aumentare di uno il numero di riferimenti al file
+(riportato nel campo \var{st\_nlink} della struttura \struct{stat}, vedi
+sez.~\ref{sec:file_stat}) aggiungendo il nuovo nome ai precedenti. Si noti che
+uno stesso file può essere così chiamato con vari nomi in diverse directory.
Per quanto dicevamo in sez.~\ref{sec:file_filesystem} la creazione di un
-collegamento diretto è possibile solo se entrambi i pathname sono nello stesso
-filesystem; inoltre il filesystem deve supportare i collegamenti diretti (il
-meccanismo non è disponibile ad esempio con il filesystem \acr{vfat} di
-Windows).
+collegamento diretto è possibile solo se entrambi i
+\index{\textit{pathname}}\textit{pathname} sono nello stesso filesystem;
+inoltre il filesystem deve supportare i collegamenti diretti (il meccanismo
+non è disponibile ad esempio con il filesystem \acr{vfat} di Windows).
La funzione inoltre opera sia sui file ordinari che sugli altri oggetti del
filesystem, con l'eccezione delle directory. In alcune versioni di Unix solo
La funzione cancella il nome specificato da \param{pathname} nella relativa
directory e decrementa il numero di riferimenti nel relativo
inode\index{inode}. Nel caso di link simbolico cancella il link simbolico; nel
-caso di socket\index{socket}, fifo o file di dispositivo\index{file!di
- dispositivo} rimuove il nome, ma come per i file i processi che hanno aperto
-uno di questi oggetti possono continuare ad utilizzarlo.
+caso di socket\index{socket}, fifo o file di
+dispositivo\index{file!di~dispositivo} rimuove il nome, ma come per i file i
+processi che hanno aperto uno di questi oggetti possono continuare ad
+utilizzarlo.
Per cancellare una voce in una directory è necessario avere il permesso di
scrittura su di essa, dato che si va a rimuovere una voce dal suo contenuto, e
\item[\errcode{EINVAL}] \param{newpath} contiene un prefisso di
\param{oldpath} o più in generale si è cercato di creare una directory come
sotto-directory di se stessa.
- \item[\errcode{ENOTDIR}] Uno dei componenti dei pathname non è una directory
- o \param{oldpath} è una directory e \param{newpath} esiste e non è una
+ \item[\errcode{ENOTDIR}] Uno dei componenti dei
+ \index{\textit{pathname}}\textit{pathname} non è una directory o
+ \param{oldpath} è una directory e \param{newpath} esiste e non è una
directory.
\end{errlist}
ed inoltre \errval{EACCES}, \errval{EPERM}, \errval{EMLINK},
fig.~\ref{fig:file_link_loop} è un usato 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 contenuti nella
- directory \file{/boot} con lo stesso pathname con cui verrebbero visti dal
- sistema operativo, anche se essi si trovano, come accade spesso, su una
- partizione separata (che \cmd{grub}, all'avvio, vede come radice).}
+ directory \file{/boot} con lo stesso \textit{pathname} con cui verrebbero
+ visti dal sistema operativo, anche se essi si trovano, come accade spesso,
+ su una partizione separata (che \cmd{grub}, all'avvio, vede 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
\file{/boot/boot/boot} e così via.
Per questo motivo il kernel e le librerie prevedono che nella risoluzione di
-un pathname possano essere seguiti un numero limitato di link simbolici, il
-cui valore limite è specificato dalla costante \const{MAXSYMLINKS}. Qualora
-questo limite venga superato viene generato un errore ed \var{errno} viene
-impostata al valore \errcode{ELOOP}.
+un \index{\textit{pathname}}\textit{pathname} possano essere seguiti un numero
+limitato di link simbolici, il cui valore limite è specificato dalla costante
+\const{MAXSYMLINKS}. Qualora questo limite venga superato viene generato un
+errore ed \var{errno} viene impostata al valore \errcode{ELOOP}.
Un punto da tenere sempre presente è che, come abbiamo accennato, un link
simbolico può fare riferimento anche ad un file che non esiste; ad esempio
La funzione crea una nuova directory vuota, che contiene cioè solo le due voci
standard (\file{.} e \file{..}), con il nome indicato dall'argomento
-\param{dirname}. Il nome può essere indicato sia come pathname assoluto che
-relativo.
+\param{dirname}. Il nome può essere indicato sia come
+\index{\textit{pathname}}\textit{pathname} assoluto che relativo.
I permessi di accesso alla directory (vedi sez.~\ref{sec:file_access_control})
sono specificati da \param{mode}, i cui possibili valori sono riportati in
La funzione cancella la directory \param{dirname}, che deve essere vuota (la
directory deve cioè contenere soltanto le due voci standard \file{.} e
-\file{..}). Il nome può essere indicato con il pathname assoluto o relativo.
+\file{..}). Il nome può essere indicato con il
+\index{\textit{pathname}}\textit{pathname} assoluto o relativo.
La modalità con cui avviene la cancellazione è analoga a quella di
\func{unlink}: fintanto che il numero di link all'inode\index{inode} della
Finora abbiamo parlato esclusivamente di file, directory e link simbolici; in
sez.~\ref{sec:file_file_types} abbiamo visto però che il sistema prevede pure
-degli altri tipi di file speciali, come i file di dispositivo
-\index{file!di dispositivo}
-e le fifo (i socket\index{socket} sono un caso a parte, che
-vedremo in cap.~\ref{cha:socket_intro}).
+degli altri tipi di file speciali, come i file di dispositivo
+\index{file!di~dispositivo} e le fifo (i socket\index{socket} sono un caso a
+parte, che vedremo in cap.~\ref{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 regolari; ma
A ciascun processo è associata una directory nel filesystem che è chiamata
\textsl{directory corrente} o \textsl{directory di lavoro} (in inglese
\textit{current working directory}) che è quella a cui si fa riferimento
-quando un pathname è espresso in forma relativa, dove il ``\textsl{relativa}''
-fa riferimento appunto a questa directory.
+quando un \index{\textit{pathname}}\textit{pathname} è espresso in forma
+relativa, dove il ``\textsl{relativa}'' fa riferimento appunto a questa
+directory.
Quando un utente effettua il login, questa directory viene impostata alla
\textit{home directory} del suo account. Il comando \cmd{cd} della shell
directory corrente di qualunque comando da essa lanciato.
In genere il kernel tiene traccia per ciascun processo dell'inode\index{inode}
-della directory di lavoro, per ottenere il pathname occorre usare una apposita
-funzione di libreria, \funcd{getcwd}, il cui prototipo è:
+della directory di lavoro, per ottenere il
+\index{\textit{pathname}}\textit{pathname} occorre usare una apposita funzione
+di libreria, \funcd{getcwd}, il cui prototipo è:
\begin{prototype}{unistd.h}{char *getcwd(char *buffer, size\_t size)}
- Legge il pathname della directory di lavoro corrente.
+ Legge il \textit{pathname} della directory di lavoro corrente.
\bodydesc{La funzione restituisce il puntatore \param{buffer} se riesce,
\val{NULL} se fallisce, in quest'ultimo caso la variabile
\item[\errcode{EINVAL}] L'argomento \param{size} è zero e \param{buffer} non
è nullo.
\item[\errcode{ERANGE}] L'argomento \param{size} è più piccolo della
- lunghezza del pathname.
+ lunghezza del \textit{pathname}.
\item[\errcode{EACCES}] Manca il permesso di lettura o di ricerca su uno dei
- componenti del pathname (cioè su una delle directory superiori alla
- corrente).
+ componenti del \textit{pathname} (cioè su una delle directory superiori
+ alla corrente).
\end{errlist}}
\end{prototype}
-La funzione restituisce il pathname completo della directory di lavoro nella
-stringa puntata da \param{buffer}, che deve essere precedentemente allocata,
-per una dimensione massima di \param{size}. 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
-\param{size} la funzione restituisce un errore.
+La funzione restituisce il \index{\textit{pathname}}\textit{pathname} completo
+della directory di lavoro nella stringa puntata da \param{buffer}, che deve
+essere precedentemente allocata, per una dimensione massima di \param{size}.
+Il buffer deve essere sufficientemente lungo da poter contenere il
+\textit{pathname} completo più lo zero di terminazione della stringa. Qualora
+esso ecceda le dimensioni specificate con \param{size} la funzione restituisce
+un errore.
Si può anche specificare un puntatore nullo come
\param{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 \param{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 volta cessato il suo utilizzo.
+della lunghezza esatta del \index{\textit{pathname}}\textit{pathname}
+altrimenti. In questo caso ci si deve ricordare di disallocare la stringa una
+volta cessato il suo utilizzo.
Di questa funzione esiste una versione \code{char *getwd(char *buffer)} fatta
per compatibilità all'indietro con BSD, che non consente di specificare la
dimensione del buffer; esso deve essere allocato in precedenza ed avere una
dimensione superiore a \const{PATH\_MAX} (di solito 256 byte, vedi
sez.~\ref{sec:sys_limits}); il problema è che in Linux non esiste una
-dimensione superiore per un pathname, per cui non è detto che il buffer sia
-sufficiente a contenere il nome del file, e questa è la ragione principale per
-cui questa funzione è deprecata.
+dimensione superiore per un \index{\textit{pathname}}\textit{pathname}, per
+cui non è detto che il buffer sia sufficiente a contenere il nome del file, e
+questa è la ragione principale per cui questa funzione è deprecata.
Una seconda funzione simile è \code{char *get\_current\_dir\_name(void)} che è
sostanzialmente equivalente ad una \code{getcwd(NULL, 0)}, con la sola
differenza che essa ritorna il valore della variabile di ambiente \val{PWD},
-che essendo costruita dalla shell può contenere un pathname comprendente anche
-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.
+che essendo costruita dalla shell può contenere un \textit{pathname}
+comprendente anche dei link simbolici. Usando \func{getcwd} infatti, essendo
+il \index{\textit{pathname}}\textit{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 si può usare la funzione \funcd{chdir}
(equivalente del comando di shell \cmd{cd}) il cui nome sta appunto per
quale si hanno i permessi di accesso.
Dato che anche le directory sono file, è possibile riferirsi ad esse anche
-tramite il file descriptor, e non solo tramite il pathname, per fare questo si
-usa \funcd{fchdir}, il cui prototipo è:
+tramite il file descriptor, e non solo tramite il
+\index{\textit{pathname}}\textit{pathname}, per fare questo si usa
+\funcd{fchdir}, il cui prototipo è:
\begin{prototype}{unistd.h}{int fchdir(int fd)}
Identica a \func{chdir}, ma usa il file descriptor \param{fd} invece del
- pathname.
+ \textit{pathname}.
\bodydesc{La funzione restituisce zero in caso di successo e -1 per un
errore, in caso di errore \var{errno} assumerà i valori \errval{EBADF} o
prima vista. Infatti anche se sembrerebbe banale generare un nome a caso e
creare il file dopo aver controllato che questo non esista, nel momento fra il
controllo e la creazione si ha giusto lo spazio per una possibile \textit{race
- condition}\index{race condition} (si ricordi quanto visto in
+ condition}\index{\textit{race~condition}} (si ricordi quanto visto in
sez.~\ref{sec:proc_race_cond}).
Le \acr{glibc} provvedono varie funzioni per generare nomi di file temporanei,
standard non specifica in quale directory verrà aperto il file, ma le
\acr{glibc} prima tentano con \const{P\_tmpdir} e poi con \file{/tmp}. Questa
funzione è rientrante e non soffre di problemi di \textit{race
- condition}\index{race condition}.
+ condition}\index{\textit{race~condition}}.
Alcune versioni meno recenti di Unix non supportano queste funzioni; in questo
caso si possono usare le vecchie funzioni \funcd{mktemp} e \func{mkstemp} che
\end{prototype}
\noindent dato che \param{template} deve poter essere modificata dalla
funzione non si può usare una stringa costante. Tutte le avvertenze riguardo
-alle possibili \textit{race condition}\index{race condition} date per
+alle possibili \textit{race condition}\index{\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}
del processo più una lettera, il che mette a disposizione solo 26 possibilità
più gli altri eventuali codici di errore di \func{mkdir}.}
\end{prototype}
\noindent la directory è creata con permessi \code{0700} (al solito si veda
-cap.~\ref{cha:file_unix_interface} per i dettagli); dato che la creazione della
-directory è sempre esclusiva i precedenti problemi di \textit{race
- condition}\index{race condition} non si pongono.
+cap.~\ref{cha:file_unix_interface} per i dettagli); dato che la creazione
+della directory è sempre esclusiva i precedenti problemi di \textit{race
+ condition}\index{\textit{race~condition}} non si pongono.
\section{La manipolazione delle caratteristiche dei files}
Il campo \var{st\_size} contiene la dimensione del file in byte (se si tratta
di un file regolare, nel caso di un link simbolico la dimensione è quella del
-pathname che contiene, per le fifo è sempre nullo).
+\index{\textit{pathname}}\textit{pathname} che contiene, per le fifo è sempre
+nullo).
Il campo \var{st\_blocks} definisce la lunghezza del file in blocchi di 512
byte. Il campo \var{st\_blksize} infine definisce la dimensione preferita per
per \func{truncate} si hanno:
\begin{errlist}
\item[\errcode{EACCES}] il file non ha permesso di scrittura o non si ha il
- permesso di esecuzione una delle directory del pathname.
+ permesso di esecuzione una delle directory del
+ \index{\textit{pathname}}\textit{pathname}.
\item[\errcode{ETXTBSY}] Il file è un programma in esecuzione.
\end{errlist}
ed anche \errval{ENOTDIR}, \errval{ENAMETOOLONG}, \errval{ENOENT},
limiteremo ad un riassunto delle regole generali, entrando nei dettagli più
avanti.
-La prima regola è che per poter accedere ad un file attraverso il suo pathname
-occorre il permesso di esecuzione in ciascuna delle directory che compongono
-il pathname; lo stesso vale per aprire un file nella directory corrente (per
-la quale appunto serve il diritto di esecuzione).
+La prima regola è che per poter accedere ad un file attraverso il suo
+\textit{pathname} occorre il permesso di esecuzione in ciascuna delle
+directory che compongono il \textit{pathname}; lo stesso vale per aprire un
+file nella directory corrente (per la quale appunto serve il diritto di
+esecuzione).
Per una directory infatti il permesso di esecuzione significa che essa può
-essere attraversata nella risoluzione del pathname, ed è distinto dal permesso
-di lettura che invece implica che si può leggere il contenuto della directory.
+essere attraversata nella risoluzione del
+\index{\textit{pathname}}\textit{pathname}, ed è distinto dal permesso di
+lettura che invece implica che si può leggere il contenuto della directory.
Questo significa che se si ha il permesso di esecuzione senza permesso di
lettura si potrà lo stesso aprire un file in una directory (se si hanno i
programma ad una sezione limitata del filesystem, per cui ne parleremo in
questa sezione.
-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
+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
\struct{fs\_struct}; vedi fig.~\ref{fig:proc_task_struct}.} che, pur essendo
di norma corrispondente alla radice dell'albero di file e directory come visto
dal kernel (ed illustrato in sez.~\ref{sec:file_organization}), ha per il
processo il significato specifico di directory rispetto alla quale vengono
-risolti i pathname assoluti.\footnote{cioè quando un processo chiede la
- risoluzione di un pathname, il kernel usa sempre questa directory come punto
- di partenza.} Il fatto che questo valore sia specificato per ogni processo
-apre allora la possibilità di modificare le modalità di risoluzione dei
-pathname assoluti da parte di un processo cambiando questa directory, così
-come si fa coi pathname relativi cambiando la directory di lavoro.
+risolti i \index{\textit{pathname}!assoluto}\textit{pathname}
+assoluti.\footnote{cioè quando un processo chiede la risoluzione di un
+ \textit{pathname}, il kernel usa sempre questa directory come punto di
+ partenza.} Il fatto che questo valore sia specificato per ogni processo apre
+allora la possibilità di modificare le modalità di risoluzione dei
+\textit{pathname} assoluti da parte di un processo cambiando questa directory,
+così come si fa coi \index{\textit{pathname}!relativo}\textit{pathname}
+relativi cambiando la directory di lavoro.
Normalmente la directory radice di un processo coincide anche con la radice
del filesystem usata dal kernel, e dato che il suo valore viene ereditato dal
-padre da ogni processo figlio, in generale i processi risolvono i pathname
-assoluti a partire sempre dalla stessa directory, che corrisponde alla
-\file{/} del sistema.
+padre da ogni processo figlio, in generale i processi risolvono i
+\index{\textit{pathname}!assoluto}\textit{pathname} assoluti a partire sempre
+dalla stessa directory, che corrisponde alla \file{/} del sistema.
In certe situazioni però, per motivi di sicurezza, è utile poter impedire che
un processo possa accedere a tutto il filesystem; per far questo si può
\errval{EROFS} e \errval{EIO}.}
\end{prototype}
\noindent in questo modo la directory radice del processo diventerà
-\param{path} (che ovviamente deve esistere) ed ogni pathname assoluto usato
-dalle funzioni chiamate nel processo sarà risolto a partire da essa, rendendo
+\param{path} (che ovviamente deve esistere) ed ogni
+\index{\textit{pathname}!assoluto}\textit{pathname} assoluto usato dalle
+funzioni chiamate nel processo sarà risolto a partire da essa, rendendo
impossibile accedere alla parte di albero sovrastante. Si ha così quella che
viene chiamata una \textit{chroot jail}, in quanto il processo non può più
accedere a file al di fuori della sezione di albero in cui è stato
Questo è il motivo per cui la funzione è efficace solo se dopo averla eseguita
si cedono i privilegi di root. Infatti se per un qualche motivo il processo
resta con la directory di lavoro fuori dalla \textit{chroot jail}, potrà
-comunque accedere a tutto il resto del filesystem usando pathname relativi, i
-quali, partendo dalla directory di lavoro che è fuori della \textit{chroot
- jail}, potranno (con l'uso di \texttt{..}) risalire fino alla radice
-effettiva del filesystem.
+comunque accedere a tutto il resto del filesystem usando
+\index{\textit{pathname}!relativo}\textit{pathname} relativi, i quali,
+partendo dalla directory di lavoro che è fuori della \textit{chroot jail},
+potranno (con l'uso di \texttt{..}) risalire fino alla radice effettiva del
+filesystem.
Ma se ad un processo restano i privilegi di amministratore esso potrà comunque
portare la sua directory di lavoro fuori dalla \textit{chroot jail} in cui si
projects / gapil.git / blobdiff