sistema (come mount point).
\item[\errcode{EINVAL}] \param{newpath} contiene un prefisso di
\param{oldpath} o più in generale si è cercato di creare una directory come
- sottodirectory di se stessa.
+ 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
directory.
il filesystem su cui si è cercato di creare \func{pathname} non supporta
l'operazione.
\item[\errcode{EINVAL}] Il valore di \param{mode} non indica un file, una
- fifo o un dipositivo.
+ fifo o un dispositivo.
\item[\errcode{EEXIST}] \param{pathname} esiste già o è un link simbolico.
\end{errlist}
ed inoltre anche \errval{EFAULT}, \errval{EACCES}, \errval{ENAMETOOLONG},
per cambiare la directory di lavoro (vedi \secref{sec:file_work_dir}) a quella
relativa allo stream che si sta esaminando.
-La lettura di una voce nella directory viene effettuata attraverso la funzione
+La lettura di una voce della directory viene effettuata attraverso la funzione
\funcd{readdir}; il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h} \headdecl{dirent.h}
Legge una voce dal \textit{directory stream}.
- \bodydesc{La funzione restituisce il puntatore alla struttura contentente i
+ \bodydesc{La funzione restituisce il puntatore alla struttura contenente i
dati in caso di successo e \val{NULL} altrimenti, in caso di descrittore
non valido \var{errno} assumerà il valore \errval{EBADF}, il valore
\val{NULL} viene restituito anche quando si raggiunge la fine dello
La funzione legge la voce corrente nella directory, posizionandosi sulla voce
successiva. I dati vengono memorizzati in una struttura \struct{dirent} (la
-cui definizione in Linux è riportata in \figref{fig:file_dirent_struct}). La
-funzione restituisce il puntatore alla struttura; si tenga presente però che
-quest'ultima viene sovrascritta tutte le volte che si ripete una lettura sullo
-stesso stream.
+cui definizione\footnote{la definizione è quella usata a Linux, che si trova
+ nel file \file{/usr/include/bits/dirent.h}, essa non contempla la presenza
+ del campo \var{d\_namlen} che indica la lunghezza del nome del file (ed
+ infatti la macro \macro{\_DIRENT\_HAVE\_D\_NAMLEN} non è definita).} è
+riportata in \figref{fig:file_dirent_struct}). La funzione restituisce il
+puntatore alla struttura; si tenga presente però che quest'ultima è allocata
+staticamente, per cui viene sovrascritta tutte le volte che si ripete la
+lettura di una voce sullo stesso stream.
+
+Di questa funzione esiste anche una versione rientrante, \func{readdir\_r},
+che non usa una struttura allocata staticamente, e può essere utilizzata anche
+con i thread; il suo prototipo è:
+\begin{functions}
+ \headdecl{sys/types.h} \headdecl{dirent.h}
+
+ \funcdecl{int readdir\_r(DIR *dir, struct dirent *entry,
+ struct dirent **result)}
+
+ Legge una voce dal \textit{directory stream}.
+
+ \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
+ errore, gli errori sono gli stessi di \func{readdir}.}
+\end{functions}
+
+La funzione restituisce in \param{result} (come \textit{value result
+ argument}) l'indirizzo dove sono stati salvati i dati, che di norma
+corrisponde a quello della struttura precedentemente allocata e specificata
+dall'argomento \param{entry} (anche se non è assicurato che la funzione usi lo
+spazio fornito dall'utente).
+
+I vari campi di \struct{dirent} contengono le informazioni relative alle voci
+presenti nella directory; sia BSD che SVr4\footnote{POSIX prevede invece solo
+ la presenza del campo \var{d\_fileno}, identico \var{d\_ino}, che in Linux è
+ definito come alias di quest'ultimo. Il campo \var{d\_name} è considerato
+ dipendente dall'implementazione.} prevedono che siano sempre presenti il
+campo \var{d\_name}, che contiene il nome del file nella forma di una stringa
+terminata da uno zero,\footnote{lo standard POSIX non specifica una lunghezza,
+ ma solo un limite \const{NAME\_MAX}; in SVr4 la lunghezza del campo è
+ definita come \code{NAME\_MAX+1} che di norma porta al valore di 256 byte
+ usato anche in Linux.} ed il campo \var{d\_ino}, che contiene il numero di
+inode cui il file è associato (di solito corrisponde al campo \var{st\_ino} di
+\struct{stat}).
\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{15cm}
\begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
struct dirent {
- ino_t d_ino; /* inode number */
- off_t d_off; /* offset to the next dirent */
- unsigned short int d_reclen; /* length of this record */
- unsigned char d_type; /* type of file */
- char d_name[256]; /* We must not include limits.h! */
+ ino_t d_ino; /* inode number */
+ off_t d_off; /* offset to the next dirent */
+ unsigned short int d_reclen; /* length of this record */
+ unsigned char d_type; /* type of file */
+ char d_name[256]; /* We must not include limits.h! */
};
\end{lstlisting}
\end{minipage}
\label{fig:file_dirent_struct}
\end{figure}
-I vari campi contengono le informazioni relative ai file della directory; il
-solo campo obbligatorio secondo lo standard POSIX è \var{d\_name}, che
-contiene il nome del file nella forma di una stringa terminata da uno zero, la
-cui lunghezza è riportata nel campo \var{d\_reclen}.\footnote{lo standard
- POSIX non specifica una lunghezza, ma solo un limite \const{NAME\_MAX},
- anche se di norma il valore massimo per un nome è di 256 byte.}
-
-Il campo \var{d\_ino} contiene il numero di inode cui il file è associato ed
-il campo \var{d\_type} il tipo di file (fifo, directory, link simbolico,
-ecc.). Entrambi questi campi derivano da BSD e non appartengono allo standard;
-la presenza del tipo di file è segnalata dalla macro
-\macro{\_DIRENT\_HAVE\_D\_TYPE}; i possibili valori del campo \var{d\_type}
-sono riportati in \tabref{tab:file_dtype_macro}.
+La presenza di ulteriori campi opzionali è segnalata dalla definizione di
+altrettante macro nella forma \code{\_DIRENT\_HAVE\_D\_XXX} dove \code{XXX} è
+il nome del relativo campo; nel nostro caso sono definite le macro
+\macro{\_DIRENT\_HAVE\_D\_TYPE}, \macro{\_DIRENT\_HAVE\_D\_OFF} e
+\macro{\_DIRENT\_HAVE\_D\_RECLEN}.
\begin{table}[htb]
\centering
\label{tab:file_dtype_macro}
\end{table}
+Per quanto riguarda il significato dei campi opzionali, il campo \var{d\_type}
+indica il tipo di file (fifo, directory, link simbolico, ecc.); i suoi
+possibili valori sono riportati in \tabref{tab:file_dtype_macro}; per la
+conversione da e verso l'analogo valore mantenuto dentro il campo
+\var{st\_mode} di \struct{stat} sono definite anche due macro di conversione
+\macro{IFTODT} e \macro{DTTOIF}:
+\begin{functions}
+ \funcdecl{int IFTODT(mode\_t MODE)} Converte il tipo di file dal formato di
+ \var{st\_mode} a quello di \var{d\_type}.
+
+ \funcdecl{mode\_t DTTOIF(int DTYPE)} Converte il tipo di file dal formato di
+ \var{d\_type} a quello di \var{st\_mode}.
+\end{functions}
+
+Il campo \var{d\_off} contiene invece la posizione della voce successiva della
+directory, mentre il campo \var{d\_reclen} la lunghezza totale della voce
+letta. Con questi due campi diventa possibile, determinando la posizione delle
+varie voci, spostarsi all'interno dello stream usando la funzione
+\func{seekdir},\footnote{sia questa funzione, che la corrispondente
+ \func{telldir}, sono estensioni prese da BSD, non previste dallo standard
+ POSIX.} il cui prototipo è:
+\begin{prototype}{dirent.h}{void seekdir(DIR *dir, off\_t offset)}
+ Cambia la posizione all'interno di un \textit{directory stream}.
+\end{prototype}
+La funzione non ritorna nulla e non segnala errori, è però necessario che il
+valore dell'argomento \param{offset} sia valido per lo stream \param{dir};
+esso pertanto deve essere stato ottenuto o dal valore di \var{d\_off} di
+\struct{dirent} o dal valore restituito dalla funzione \func{telldir}, che
+legge la posizione corrente; il prototipo di quest'ultima è:
+\begin{prototype}{dirent.h}{off\_t telldir(DIR *dir)}
+ Ritorna la posizione corrente in un \textit{directory stream}.
+
+ \bodydesc{La funzione restituisce la posizione corrente nello stream (un
+ numero positivo) in caso di successo, e -1 altrimenti, nel qual caso
+ \var{errno} assume solo il valore di \errval{EBADF}, corrispondente ad un
+ valore errato per \param{dir}.}
+\end{prototype}
+La sola funzione di posizionamento nello stream prevista dallo standard POSIX
+è \funcd{rewinddir}, che riporta la posizione a quella iniziale; il suo
+prototipo è:
+\begin{functions}
+ \headdecl{sys/types.h} \headdecl{dirent.h}
+
+ \funcdecl{void rewinddir(DIR *dir)}
+
+ Si posiziona all'inizio di un \textit{directory stream}.
+\end{functions}
Una volta completate le operazioni si può chiudere il \textit{directory
qual caso \var{errno} assume il valore \errval{EBADF}.}
\end{functions}
+A parte queste funzioni di base in BSD 4.3 è stata introdotta un'altra
+funzione che permette di eseguire una scansione completa (con tanto di ricerca
+ed ordinamento) del contenuto di una directory; la funzione è
+\funcd{scandir}\footnote{in Linux questa funzione è stata introdotta fin dalle
+ libc4.} ed il suo prototipo è:
+\begin{prototype}{dirent.h}{int scandir(const char *dir,
+ struct dirent ***namelist, int(*select)(const struct dirent *),
+ int(*compar)(const struct dirent **, const struct dirent **))}
+
+ Esegue una scansione di un \textit{directory stream}.
+
+ \bodydesc{La funzione restituisce in caso di successo il numero di voci
+ trovate, e -1 altrimenti.}
+\end{prototype}
+
+Al solito, per la presenza fra gli argomenti di due puntatori a funzione, il
+prototipo non è molto comprensibile; queste funzioni però sono quelle che
+controllano rispettivamente la selezione di una voce (\param{select}) e
+l'ordinamento di tutte le voci selezionate (\param{compar}).
+
+La funzione legge tutte le voci della directory indicata dall'argomento
+\param{dir}, passando ciascuna di esse come argomento alla funzione di
+\param{select}; se questa ritorna un valore diverso da zero la voce viene
+inserita in una struttura allocata dinamicamente con \func{malloc}, qualora si
+specifichi un valore \val{NULL} per \func{select} vengono selezionate tutte le
+voci. Tutte le voci selezionate vengono poi inserite un una lista (anch'essa
+allocata con \func{malloc}, che viene riordinata tramite \func{qsort} usando
+la funzione \param{compar} come criterio di ordinamento; alla fine l'indirizzo
+della lista ordinata è restituito nell'argomento \param{namelist}.
+
+Per l'ordinamento sono disponibili anche due funzioni predefinite,
+\funcd{alphasort} e \funcd{versionsort}, i cui prototipi sono:
+\begin{functions}
+ \headdecl{dirent.h}
+
+ \funcdecl{int alphasort(const void *a, const void *b)}
+
+ \funcdecl{int versionsort(const void *a, const void *b)}
+
+ Funzioni per l'ordinamento delle voci di \textit{directory stream}.
+
+ \bodydesc{Le funzioni restituiscono un valore minore, uguale o maggiore di
+ zero qualora il primo argomento sia rispettivamente minore, uguale o
+ maggiore del secondo.}
+\end{functions}
+
+
+La funzione \func{alphasort} deriva da BSD ed è presente in Linux fin dalle
+libc4\footnote{la versione delle libc4 e libc5 usa però come argomenti dei
+ puntatori a delle strutture \struct{dirent}; le glibc usano il prototipo
+ originario di BSD, mostrato anche nella definizione, che prevede puntatori a
+ \ctyp{void}.} e deve essere specificata come argomento \param{compare} per
+ottenere un ordinamento alfabetico (secondo il valore del campo \var{d\_name}
+delle varie voci). Le \acr{glibc} prevedono come estensione\footnote{le glibc,
+ a partire dalla versione 2.1, effettuano anche l'ordinamento alfabetico
+ tenendo conto delle varie localizzazioni, usando \func{strcoll} al posto di
+ \func{strcmp}.} anche \func{versionsort}, che ordina i nomi tenendo conto
+del numero di versione (cioè qualcosa per cui \file{file10} viene comunque
+dopo \func{file4}.)
+
+
+
\subsection{La directory di lavoro}
\label{sec:file_work_dir}
A ciascun processo è associata 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 ``\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
-1 in caso di errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
\item[\errcode{EINVAL}] \param{template} non termina con \code{XXXXXX}.
- \item[\errcode{EEXIST}] non è riuscita a creare un file temporano, il
+ \item[\errcode{EEXIST}] non è riuscita a creare un file temporaneo, il
contenuto di \param{template} è indefinito.
\end{errlist}}
\end{prototype}
del controllo di accesso ai file, che viene implementato per qualunque
filesystem standard.\footnote{per standard si intende che implementa le
caratteristiche previste dallo standard POSIX. In Linux sono disponibili
- anche una serie di altri filesystem, come quelli di Windiws e del Mac, che
+ anche una serie di altri filesystem, come quelli di Windows e del Mac, che
non supportano queste caratteristiche.} In questa sezione ne esamineremo i
concetti essenziali e le funzioni usate per gestirne i vari aspetti.
come il \textit{mandatory access control} di SE-Linux.} ma nella maggior
parte dei casi il meccanismo standard è più che sufficiente a soddisfare tutte
le necessità più comuni. I tre permessi di base associati ad ogni file sono:
-\begin{itemize}
+\begin{itemize*}
\item il permesso di lettura (indicato con la lettera \texttt{r}, dall'inglese
\textit{read}).
\item il permesso di scrittura (indicato con la lettera \texttt{w},
dall'inglese \textit{write}).
\item il permesso di esecuzione (indicato con la lettera \texttt{x},
dall'inglese \textit{execute}).
-\end{itemize}
+\end{itemize*}
mentre i tre livelli su cui sono divisi i privilegi sono:
-\begin{itemize}
+\begin{itemize*}
\item i privilegi per l'utente proprietario del file.
\item i privilegi per un qualunque utente faccia parte del gruppo cui
appartiene il file.
\item i privilegi per tutti gli altri utenti.
-\end{itemize}
+\end{itemize*}
L'insieme dei permessi viene espresso con un numero a 12 bit; di questi i nove
meno significativi sono usati a gruppi di tre per indicare i permessi base di
Per una spiegazione dettagliata degli identificatori associati ai processi si
veda \secref{sec:proc_perms}; normalmente, a parte quanto vedremo in
-\secref{sec:file_suid_sgid}, l'userid effettivo e il groupid effectivo
+\secref{sec:file_suid_sgid}, l'userid effettivo e il groupid effettivo
corrispondono ai valori dell'\acr{uid} e del \acr{gid} dell'utente che ha
lanciato il processo, mentre i groupid supplementari sono quelli dei gruppi
cui l'utente appartiene.
impostato 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:
-\begin{itemize}
+\begin{itemize*}
\item l'utente è proprietario del file
\item l'utente è proprietario della directory
\item l'utente è l'amministratore
-\end{itemize}
+\end{itemize*}
un classico esempio di directory che ha questo bit impostato è \file{/tmp}, i
permessi infatti di solito sono i seguenti:
\begin{verbatim}
Lo standard POSIX prescrive che l'\acr{uid} del nuovo file corrisponda
all'userid effettivo del processo che lo crea; per il \acr{gid} invece prevede
due diverse possibilità:
-\begin{itemize}
+\begin{itemize*}
\item il \acr{gid} del file corrisponde al groupid effettivo del processo.
\item il \acr{gid} del file corrisponde al \acr{gid} della directory in cui
esso è creato.
-\end{itemize}
+\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
Usare la semantica BSD ha il vantaggio che il \acr{gid} viene sempre
automaticamente propagato, restando coerente a quello della directory di
-partenza, in tutte le sottodirectory.
+partenza, in tutte le sotto-directory.
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
predefinito del comando \cmd{mkdir}, ed è in questo modo ad esempio che Debian
-assicura che le sottodirectory create nella home di un utente restino sempre
+assicura che le sotto-directory create nella home di un utente restino sempre
con il \acr{gid} del gruppo primario dello stesso.
\acr{s}&\acr{s}&\acr{t}&r&w&x&r&w&x&r&w&x& \\
\hline
\hline
- 1&-&-&-&-&-&-&-&-&-&-&-&Se eseguito ha i permessi del propritario\\
- -&1&-&-&-&1&-&-&-&-&-&-&Se eseguito ha i permessi del gruppo propritario\\
+ 1&-&-&-&-&-&-&-&-&-&-&-&Se eseguito ha i permessi del proprietario\\
+ -&1&-&-&-&1&-&-&-&-&-&-&Se eseguito ha i permessi del gruppo proprietario\\
-&1&-&-&-&0&-&-&-&-&-&-&Il \textit{mandatory locking} è abilitato\\
-&-&1&-&-&-&-&-&-&-&-&-&Non utilizzato\\
-&-&-&1&-&-&-&-&-&-&-&-&Permesso di lettura per il proprietario\\
\label{sec:file_chroot}
Benché non abbia niente a che fare con permessi, utenti e gruppi, la funzione
-\func{chroot} viene usata spesso per restringere le capacità di acccesso di un
+\func{chroot} viene usata spesso per restringere le capacità di accesso di un
programma ad una sezione limitata del filesystem, per cui ne parleremo in
questa sezione.
\figref{fig:proc_task_struct}.} che è la directory che per il processo
costituisce la radice dell'albero dei file e rispetto alla quale vengono
risolti i pathname assoluti (si ricordi quanto detto in
-\secref{sec:file_organization}). La radice viene eredidata dal padre per ogni
+\secref{sec:file_organization}). La radice viene ereditata dal padre per ogni
processo figlio, e quindi di norma coincide con la \file{/} del sistema.
In certe situazioni però per motivi di sicurezza non si vuole che un processo
Ma quando ad un processo restano i privilegi di root esso potrà sempre portare
la directory di lavoro corrente fuori dalla \textit{chroot jail} creando una
-sottodirectory ed eseguendo una \func{chroot} su di essa. Per questo motivo
+sotto-directory ed eseguendo una \func{chroot} su di essa. Per questo motivo
l'uso di questa funzione non ha molto senso quando un processo necessita dei
privilegi di root per le sue normali operazioni.
-Un caso tipico di uso di \func{chroot} è quello di un server ftp anonimo, in
+Un caso tipico di uso di \func{chroot} è quello di un server FTP anonimo, in
questo caso infatti si vuole che il server veda solo i file che deve
trasferire, per cui in genere si esegue una \func{chroot} sulla directory che
contiene i file. Si tenga presente però che in questo caso occorrerà
projects / gapil.git / blobdiff