X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=filedir.tex;h=69af64b78326fc3f3c12b57bece96847b4e7eb34;hp=d4a7015f38a9fdc636a6fcc06b8564379e28ab4c;hb=ee41e8b34dd560d230966160fb3eb748defc3e46;hpb=caf486b327fb878e112c24b48d701a3b1d079e62 diff --git a/filedir.tex b/filedir.tex index d4a7015..69af64b 100644 --- a/filedir.tex +++ b/filedir.tex @@ -1,6 +1,6 @@ %% filedir.tex %% -%% Copyright (C) 2000-2007 Simone Piccardi. Permission is granted to +%% Copyright (C) 2000-2009 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", @@ -616,13 +616,15 @@ file nella directory. 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 \index{file!di~dispositivo} file di -dispositivo e le fifo (i socket sono un caso a parte, che tratteremo 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 -quando li si devono creare sono necessarie delle funzioni apposite. La prima -di queste funzioni è \funcd{mknod}, il suo prototipo è: +dispositivo, le fifo ed i socket (questi ultimi sono un caso a parte, essendo +associati anche alla comunicazione via rete, per cui ci saranno trattati in +dettaglio a partire da cap.~\ref{cha:socket_intro}). + +La manipolazione delle caratteristiche di questi diversi tipi di file e la +loro cancellazione può essere effettuata con le stesse funzioni che operano +sui file regolari; ma quando li si devono creare sono necessarie delle +funzioni apposite. La prima di queste funzioni è \funcd{mknod}, il cui +prototipo è: \begin{functions} \headdecl{sys/types.h} \headdecl{sys/stat.h} @@ -647,28 +649,38 @@ di queste funzioni \errval{ENOSPC}, \errval{EROFS}.} \end{functions} -La funzione permette di creare un file speciale, ma si può usare anche per -creare file regolari e fifo; l'argomento \param{mode} specifica il tipo di -file che si vuole creare ed i relativi permessi, secondo i valori riportati in -tab.~\ref{tab:file_mode_flags}, che vanno combinati con un OR binario. I -permessi sono comunque modificati nella maniera usuale dal valore di -\itindex{umask} \textit{umask} (si veda sez.~\ref{sec:file_perm_management}). - -Per il tipo di file può essere specificato solo uno fra: \const{S\_IFREG} per -un file regolare (che sarà creato vuoto), \const{S\_IFBLK} per un dispositivo -a blocchi, \const{S\_IFCHR} per un dispositivo a caratteri, \const{S\_IFSOCK} -e \const{S\_IFIFO} per una fifo. Un valore diverso comporterà l'errore -\errcode{EINVAL}. Qualora si sia specificato in \param{mode} un file di -dispositivo (\const{S\_IFBLK} o \const{S\_IFCHR}), il valore di \param{dev} -dovrà essere usato per indicare a quale dispositivo si fa riferimento con il -relativo numero. - -Solo l'amministratore può creare un file di dispositivo usando questa funzione -(il processo deve avere la \textit{capability} \const{CAP\_MKNOD}); ma in -Linux\footnote{la funzione non è prevista dallo standard POSIX, e deriva da - SVr4, con appunto questa differenza e diversi codici di errore.} l'uso per -la creazione di un file ordinario, di una fifo o di un socket è consentito -anche agli utenti normali. +La funzione, come suggerisce il nome, permette di creare un ``\textsl{nodo}'' +sul filesystem, e viene in genere utilizzata per creare i file di dispositivo, +ma si può usare anche per creare file regolari. L'argomento +\param{mode} specifica sia il tipo di file che si vuole creare che i relativi +permessi, secondo i valori riportati in tab.~\ref{tab:file_mode_flags}, che +vanno combinati con un OR binario. I permessi sono comunque modificati nella +maniera usuale dal valore di \itindex{umask} \textit{umask} (si veda +sez.~\ref{sec:file_perm_management}). + +Per il tipo di file può essere specificato solo uno fra i seguenti valori: +\const{S\_IFREG} per un file regolare (che sarà creato vuoto), +\const{S\_IFBLK} per un dispositivo a blocchi, \const{S\_IFCHR} per un +dispositivo a caratteri, \const{S\_IFSOCK} per un socket e \const{S\_IFIFO} +per una fifo;\footnote{con Linux la funzione non può essere usata per creare + directory o link simbolici, si dovranno usare le funzioni \func{mkdir} e + \func{symlink} a questo dedicate.} un valore diverso comporterà l'errore +\errcode{EINVAL}. + +Qualora si sia specificato in \param{mode} un file di dispositivo (vale a dire +o \const{S\_IFBLK} o \const{S\_IFCHR}), il valore di \param{dev} dovrà essere +usato per indicare a quale dispositivo si fa riferimento, altrimenti il suo +valore verrà ignorato. Solo l'amministratore può creare un file di +dispositivo usando questa funzione (il processo deve avere la +\textit{capability} \const{CAP\_MKNOD}), ma in Linux\footnote{questo è un + comportamento specifico di Linux, la funzione non è prevista dallo standard + POSIX.1 originale, mentre è presente in SVr4 e 4.4BSD, ma esistono + differenze nei comportamenti e nei codici di errore, tanto che questa è + stata introdotta in POSIX.1-2001 con una nota che la definisce portabile + solo quando viene usata per creare delle fifo, ma comunque deprecata essendo + utilizzabile a tale scopo la specifica \func{mkfifo}.} l'uso per la +creazione di un file ordinario, di una fifo o di un socket è consentito anche +agli utenti normali. I nuovi \itindex{inode} \textit{inode} creati con \func{mknod} apparterranno al proprietario e al gruppo del processo che li ha creati, a meno che non si @@ -677,9 +689,67 @@ semantica BSD per il filesystem (si veda sez.~\ref{sec:file_ownership_management}) in cui si va a creare \itindex{inode} l'\textit{inode}. -Per creare una fifo (un file speciale, su cui torneremo in dettaglio in -sez.~\ref{sec:ipc_named_pipe}) lo standard POSIX specifica l'uso della funzione -\funcd{mkfifo}, il cui prototipo è: +Nella creazione di un file di dispositivo occorre poi specificare +correttamente il valore di \param{dev}; questo infatti è di tipo +\type{dev\_t}, che è un tipo primitivo (vedi +tab.~\ref{tab:intro_primitive_types}) riservato per indicare un +\textsl{numero} di dispositivo; il kernel infatti identifica ciascun +dispositivo con un valore numerico. Originariamente questo era un intero a 16 +bit diviso in due parti di 8 bit chiamate rispettivamente +\itindex{major~number} \textit{major number} e \itindex{minor~number} +\textit{minor number}, che sono poi i due numeri mostrati dal comando +\texttt{ls -l} al posto della dimensione quando lo si esegue su un file di +dispositivo. + +Il \itindex{major~number} \textit{major number} identifica una classe di +dispositivi (ad esempio la seriale, o i dischi IDE) e serve in sostanza per +indicare al kernel quale è il modulo che gestisce quella classe di +dispositivi; per identificare uno specifico dispositivo di quella classe (ad +esempio una singola porta seriale, o una partizione di un disco) si usa invece +il \itindex{minor~number} \textit{minor number}. L'elenco aggiornato di questi +numeri con le relative corrispondenze ai vari dispositivi può essere trovato +nel file \texttt{Documentation/devices.txt} allegato alla documentazione dei +sorgenti del kernel. + +Data la crescita nel numero di dispositivi supportati, ben presto il limite +massimo di 256 si è rivelato troppo basso, e nel passaggio dai kernel della +serie 2.4 alla serie 2.6 è stata aumentata a 32 bit la dimensione del tipo +\type{dev\_t}, con delle dimensioni passate a 12 bit per il +\itindex{major~number} \textit{major number} e 20 bit per il +\itindex{minor~number} \textit{minor number}. La transizione però ha anche +comportato il passaggio di \type{dev\_t} a tipo opaco, e la necessità di +specificare il numero tramite delle opportune macro, così da non avere +problemi di compatibilità con eventuali ulteriori estensioni. + +Le macro sono definite nel file \file{sys/sysmacros.h}, che viene +automaticamente incluso quando si include \file{sys/types.h}; si possono +pertanto ottenere i valori del \itindex{major~number} \textit{major number} e +\itindex{minor~number} \textit{minor number} di un dispositivo rispettivamente +con le macro \macro{major} e \macro{minor}: +\begin{functions} + \headdecl{sys/types.h} + \funcdecl{int \macro{major}(dev\_t dev)} + Restituisce il \itindex{major~number} \textit{major number} del dispositivo + \param{dev}. + + \funcdecl{int \macro{minor}(dev\_t dev)} + Restituisce il \itindex{minor~number} \textit{minor number} del dispositivo + \param{dev}. +\end{functions} +\noindent mentre una volta che siano noti \itindex{major~number} \textit{major + number} e \itindex{minor~number} \textit{minor number} si potrà costruire il +relativo identificativo con la macro \macro{makedev}: +\begin{functions} + \headdecl{sys/types.h} + \funcdecl{dev\_t \macro{minor}(int major, int minor)} + + Restituisce l'identificativo di un dispositivo dati \itindex{major~number} + \textit{major number} e \itindex{minor~number} \textit{minor number}. +\end{functions} + +Infine con lo standard POSIX.1-2001 è stata introdotta una funzione specifica +per creare una fifo (tratteremo le fifo in in sez.~\ref{sec:ipc_named_pipe}); +la funzione è \funcd{mkfifo} ed il suo prototipo è: \begin{functions} \headdecl{sys/types.h} \headdecl{sys/stat.h} @@ -723,9 +793,9 @@ funzione per la lettura delle directory. Tutto questo si riflette nello standard POSIX\footnote{le funzioni sono previste pure in BSD e SVID.} che ha introdotto una apposita interfaccia per la lettura delle directory, basata sui cosiddetti \textit{directory stream} -(chiamati così per l'analogia con i file stream dell'interfaccia standard di -cap.~\ref{cha:files_std_interface}). La prima funzione di questa interfaccia è -\funcd{opendir}, il cui prototipo è: +(chiamati così per l'analogia con i file stream dell'interfaccia standard ANSI +C di cap.~\ref{cha:files_std_interface}). La prima funzione di questa +interfaccia è \funcd{opendir}, il cui prototipo è: \begin{functions} \headdecl{sys/types.h} \headdecl{dirent.h} @@ -770,8 +840,35 @@ solito si utilizza questa funzione in abbinamento alla funzione \func{fchdir} per cambiare la directory di lavoro (vedi sez.~\ref{sec:file_work_dir}) a quella relativa allo stream che si sta esaminando. -La lettura di una voce della directory viene effettuata attraverso la funzione -\funcd{readdir}; il suo prototipo è: +Viceversa se si è aperto un file descriptor corrispondente ad una directory è +possibile associarvi un \textit{directory stream} con la funzione +\funcd{fopendir},\footnote{questa funzione è però disponibile solo a partire + dalla versione 2.4 delle \acr{glibc}, e pur essendo candidata per + l'inclusione nella successiva revisione dello standard POSIX.1-2001, non è + ancora presente in nessuna specifica formale.} il cui prototipo è: +\begin{functions} + \headdecl{sys/types.h} + \headdecl{dirent.h} + + \funcdecl{DIR * fopendir(int fd)} + + Associa un \textit{directory stream} al file descriptor \param{fd}. + + \bodydesc{La funzione restituisce un puntatore al \textit{directory stream} + in caso di successo e \val{NULL} per un errore, nel qual caso \var{errno} + assumerà il valore \errval{EBADF}.} +\end{functions} + +La funzione è identica a \func{opendir}, ma ritorna un \textit{directory + stream} facendo riferimento ad un file descriptor \param{fd} che deve essere +stato aperto in precedenza e la funzione darà un errore qualora questo non +corrisponda ad una directory. Una volta utilizzata il file descriptor verrà +usato dalle funzioni che operano sul \textit{directory stream} e non deve +essere più utilizzato direttamente all'interno del proprio programma. + +Una volta che si sia aperto un \textit{directory stream} la lettura del +contenuto della directory viene effettuata attraverso la funzione +\funcd{readdir}, il suo prototipo è: \begin{functions} \headdecl{sys/types.h} \headdecl{dirent.h} @@ -787,19 +884,24 @@ La lettura di una voce della directory viene effettuata attraverso la funzione \end{functions} La funzione legge la voce corrente nella directory, posizionandosi sulla voce -successiva. I dati vengono memorizzati in una struttura \struct{dirent} (la -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 fig.~\ref{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 è: +successiva. Pertanto se si vuole leggere l'intero contenuto di una directory +occorrerà ripetere l'esecuzione della funzione fintanto che non si siano +esaurite tutte le voci in essa presenti. + +I dati vengono memorizzati in una struttura \struct{dirent} (la 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 +fig.~\ref{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 \textit{directory stream}. + +Di questa funzione esiste anche una versione \index{funzioni!rientranti} +rientrante, \func{readdir\_r}, che non usa una struttura allocata +staticamente, e può essere utilizzata anche con i \itindex{thread} +\textit{thread}, il suo prototipo è: \begin{functions} \headdecl{sys/types.h} \headdecl{dirent.h} @@ -818,6 +920,17 @@ 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). +\begin{figure}[!htb] + \footnotesize \centering + \begin{minipage}[c]{15cm} + \includestruct{listati/dirent.c} + \end{minipage} + \normalsize + \caption{La struttura \structd{dirent} per la lettura delle informazioni dei + file.} + \label{fig:file_dirent_struct} +\end{figure} + I vari campi di \struct{dirent} contengono le informazioni relative alle voci presenti nella directory; sia BSD che SVr4\footnote{lo standard POSIX prevede invece solo la presenza del campo \var{d\_fileno}, identico \var{d\_ino}, @@ -831,17 +944,6 @@ una stringa terminata da uno zero,\footnote{lo standard POSIX non specifica di \itindex{inode} \textit{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} - \includestruct{listati/dirent.c} - \end{minipage} - \normalsize - \caption{La struttura \structd{dirent} per la lettura delle informazioni dei - file.} - \label{fig:file_dirent_struct} -\end{figure} - 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 @@ -871,7 +973,7 @@ il nome del relativo campo; nel nostro caso sono definite le 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 +indica il tipo di file (fifo, directory, link simbolico, ecc.). I suoi possibili valori\footnote{fino alla versione 2.1 delle \acr{glibc} questo campo, pur presente nella struttura, non era implementato, e resta sempre al valore \const{DT\_UNKNOWN}.} sono riportati in @@ -940,7 +1042,7 @@ A parte queste funzioni di base in BSD 4.3 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 è: + \acr{libc4}.} ed il suo prototipo è: \begin{prototype}{dirent.h}{int scandir(const char *dir, struct dirent ***namelist, int(*filter)(const struct dirent *), int(*compar)(const struct dirent **, const struct dirent **))} @@ -996,17 +1098,17 @@ Per l'ordinamento, vale a dire come valori possibili per l'argomento \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 \texttt{file10} viene comunque -dopo \texttt{file4}.) +\acr{libc4}\footnote{la versione delle \acr{libc4} e \acr{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{compar} 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 +\texttt{file10} viene comunque dopo \texttt{file4}.) Un semplice esempio dell'uso di queste funzioni è riportato in fig.~\ref{fig:file_my_ls}, dove si è riportata la sezione principale di un @@ -1084,16 +1186,14 @@ voce valida (cio (\texttt{\small 27}) la funzione di elaborazione \var{compare} (che nel nostro caso sarà \code{do\_ls}), ritornando con un codice di errore (\texttt{\small 28}) qualora questa presenti una anomalia (identificata da un codice di -ritorno negativo). - -Una volta terminato il ciclo la funzione si conclude con la chiusura -(\texttt{\small 32}) dello stream\footnote{nel nostro caso, uscendo subito - dopo la chiamata, questo non servirebbe, in generale però l'operazione è - necessaria, dato che la funzione può essere invocata molte volte all'interno - dello stesso processo, per cui non chiudere gli stream comporterebbe un - consumo progressivo di risorse, con conseguente rischio di esaurimento delle - stesse} e la restituzione (\texttt{\small 33}) del codice di operazioni -concluse con successo. +ritorno negativo). Una volta terminato il ciclo la funzione si conclude con la +chiusura (\texttt{\small 32}) dello stream\footnote{nel nostro caso, uscendo + subito dopo la chiamata, questo non servirebbe, in generale però + l'operazione è necessaria, dato che la funzione può essere invocata molte + volte all'interno dello stesso processo, per cui non chiudere i + \textit{directory stream} comporterebbe un consumo progressivo di risorse, + con conseguente rischio di esaurimento delle stesse.} e la restituzione +(\texttt{\small 33}) del codice di operazioni concluse con successo. \subsection{La directory di lavoro} @@ -1101,12 +1201,15 @@ concluse con successo. \itindbeg{pathname} -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 \itindsub{pathname}{relativo}\textit{pathname} è espresso in forma -relativa, dove il ``\textsl{relativa}'' fa riferimento appunto a questa -directory. +Come accennato in sez.~\ref{sec:proc_fork} a ciascun processo è associata una +directory nel filesystem,\footnote{questa viene mantenuta all'interno dei dati + della sua \struct{task\_struct} (vedi fig.~\ref{fig:proc_task_struct}), più + precisamente nel campo \texttt{pwd} della sotto-struttura + \struct{fs\_struct}.} che è chiamata \textsl{directory corrente} o +\textsl{directory di lavoro} (in inglese \textit{current working directory}). +La directory di lavoro è quella da cui si parte quando un +\itindsub{pathname}{relativo} \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 @@ -1116,10 +1219,13 @@ resta la stessa quando viene creato un processo figlio (vedi sez.~\ref{sec:proc_fork}), la directory corrente della shell diventa anche la directory corrente di qualunque comando da essa lanciato. -In genere il kernel tiene traccia per ciascun processo \itindex{inode} -dell'\textit{inode} della directory di lavoro, per ottenere il +Dato che è il kernel che tiene traccia per ciascun processo \itindex{inode} +dell'\textit{inode} della directory di lavoro, per ottenerne il \textit{pathname} occorre usare una apposita funzione di libreria, -\funcd{getcwd}, il cui prototipo è: +\funcd{getcwd},\footnote{con Linux \func{getcwd} è una \textit{system call} + dalla versione 2.1.9, in precedenza il valore doveva essere ottenuto tramite + il filesystem \texttt{/proc} da \procfile{/proc/self/cwd}.} il cui prototipo +è: \begin{prototype}{unistd.h}{char *getcwd(char *buffer, size\_t size)} Legge il \textit{pathname} della directory di lavoro corrente. @@ -1134,23 +1240,25 @@ dell'\textit{inode} della directory di lavoro, per ottenere il \item[\errcode{EACCES}] manca il permesso di lettura o di ricerca su uno dei componenti del \textit{pathname} (cioè su una delle directory superiori alla corrente). + \item[\errcode{ENOENT}] la directory di lavoro è stata eliminata. \end{errlist}} \end{prototype} La funzione restituisce il \textit{pathname} completo della directory di -lavoro nella stringa puntata da \param{buffer}, che deve essere +lavoro corrente 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 +buffer deve essere sufficientemente largo 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 \textit{pathname} altrimenti. In questo caso ci si -deve ricordare di disallocare la stringa una volta cessato il suo utilizzo. + supportata da Linux e dalla \acr{glibc}.} 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 \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 @@ -1161,13 +1269,20 @@ dimensione superiore per un \textit{pathname}, per cui non 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 \textit{pathname} -comprendente anche dei link simbolici. Usando \func{getcwd} infatti, essendo -il \textit{pathname} ricavato risalendo all'indietro l'albero della directory, -si perderebbe traccia di ogni passaggio attraverso eventuali link simbolici. +Un uso comune di \func{getcwd} è quello di salvare la directory di lavoro +iniziale per poi potervi tornare in un tempo successivo, un metodo alternativo +più veloce, se non si è a corto di file descriptor, è invece quello di aprire +la directory corrente (vale a dire ``\texttt{.}'') e tornarvi in seguito con +\func{fchdir}. + +Una seconda usata per ottenere la directory di lavoro è \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 \textit{pathname} comprendente anche dei link simbolici. Usando +\func{getcwd} infatti, essendo il \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 @@ -1239,10 +1354,10 @@ invocazioni della funzione continueranno a restituire nomi unici fino ad un massimo di \const{TMP\_MAX} volte. Al nome viene automaticamente aggiunto come prefisso la directory specificata da \const{P\_tmpdir}. -Di questa funzione esiste una versione rientrante, \func{tmpnam\_r}, che non -fa nulla quando si passa \val{NULL} come argomento. Una funzione simile, -\funcd{tempnam}, permette di specificare un prefisso per il file -esplicitamente, il suo prototipo è: +Di questa funzione esiste una versione \index{funzioni!rientranti} rientrante, +\func{tmpnam\_r}, che non fa nulla quando si passa \val{NULL} come argomento. +Una funzione simile, \funcd{tempnam}, permette di specificare un prefisso per +il file esplicitamente, il suo prototipo è: \begin{prototype}{stdio.h}{char *tempnam(const char *dir, const char *pfx)} Restituisce il puntatore ad una stringa contente un nome di file valido e non esistente al momento dell'invocazione. @@ -1253,19 +1368,19 @@ esplicitamente, il suo prototipo \end{prototype} La funzione alloca con \code{malloc} la stringa in cui restituisce il nome, -per cui è sempre rientrante, occorre però ricordarsi di disallocare il -puntatore che restituisce. L'argomento \param{pfx} specifica un prefisso di -massimo 5 caratteri per il nome provvisorio. La funzione assegna come -directory per il file temporaneo (verificando che esista e sia accessibili), -la prima valida delle seguenti: -\begin{itemize*} -\item La variabile di ambiente \const{TMPNAME} (non ha effetto se non è +per cui è sempre \index{funzioni!rientranti} rientrante, occorre però +ricordarsi di disallocare con \code{free} il puntatore che restituisce. +L'argomento \param{pfx} specifica un prefisso di massimo 5 caratteri per il +nome provvisorio. La funzione assegna come directory per il file temporaneo +(verificando che esista e sia accessibili), la prima valida delle seguenti: +\begin{itemize} +\item La variabile di ambiente \const{TMPDIR} (non ha effetto se non è definita o se il programma chiamante è \itindex{suid~bit} \acr{suid} o \itindex{sgid~bit} \acr{sgid}, vedi sez.~\ref{sec:file_special_perm}). \item il valore dell'argomento \param{dir} (se diverso da \val{NULL}). \item Il valore della costante \const{P\_tmpdir}. \item la directory \file{/tmp}. -\end{itemize*} +\end{itemize} In ogni caso, anche se la generazione del nome è casuale, ed è molto difficile ottenere un nome duplicato, nulla assicura che un altro processo non possa @@ -1277,7 +1392,8 @@ queste funzioni occorre sempre aprire il nuovo file in modalit esistente. Per evitare di dovere effettuare a mano tutti questi controlli, lo standard -POSIX definisce la funzione \funcd{tmpfile}, il cui prototipo è: +POSIX definisce la funzione \funcd{tmpfile}, che permette di ottenere in +maniera sicura l'accesso ad un file temporaneo, il suo prototipo è: \begin{prototype}{stdio.h}{FILE *tmpfile (void)} Restituisce un file temporaneo aperto in lettura/scrittura. @@ -1291,13 +1407,14 @@ POSIX definisce la funzione \funcd{tmpfile}, il cui prototipo ed inoltre \errval{EFAULT}, \errval{EMFILE}, \errval{ENFILE}, \errval{ENOSPC}, \errval{EROFS} e \errval{EACCES}.} \end{prototype} -\noindent essa restituisce direttamente uno stream già aperto (in modalità + +La funzione restituisce direttamente uno stream già aperto (in modalità \code{r+b}, si veda sez.~\ref{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 le \acr{glibc} prima tentano con \const{P\_tmpdir} e poi con \file{/tmp}. Questa -funzione è rientrante e non soffre di problemi di \itindex{race~condition} -\textit{race condition}. +funzione è \index{funzioni!rientranti} rientrante e non soffre di problemi di +\itindex{race~condition} \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 @@ -2702,12 +2819,13 @@ classi di attributi riportate in tab.~\ref{tab:extended_attribute_class}. Dato che uno degli usi degli \textit{Extended Attributes} è quello che li -impiega per realizzare delle estensioni (come le ACL, \index{SELinux} SELinux, -ecc.) al tradizionale meccanismo dei controlli di accesso di Unix, l'accesso -ai loro valori viene regolato in maniera diversa a seconda sia della loro -classe sia di quali, fra le estensioni che li utilizzano, sono poste in uso. -In particolare, per ciascuna delle classi riportate in -tab.~\ref{tab:extended_attribute_class}, si hanno i seguenti casi: +impiega per realizzare delle estensioni (come le \itindex{Access~Control~List} +ACL, \index{SELinux} SELinux, ecc.) al tradizionale meccanismo dei controlli +di accesso di Unix, l'accesso ai loro valori viene regolato in maniera diversa +a seconda sia della loro classe sia di quali, fra le estensioni che li +utilizzano, sono poste in uso. In particolare, per ciascuna delle classi +riportate in tab.~\ref{tab:extended_attribute_class}, si hanno i seguenti +casi: \begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}} \item[\texttt{security}] L'accesso agli \textit{extended security attributes} dipende dalle politiche di sicurezza stabilite da loro stessi tramite @@ -2724,12 +2842,12 @@ tab.~\ref{tab:extended_attribute_class}, si hanno i seguenti casi: \item[\texttt{system}] Anche l'accesso agli \textit{extended system attributes} dipende dalle politiche di accesso che il kernel realizza anche utilizzando gli stessi valori in essi contenuti. Ad esempio nel caso - delle ACL l'accesso è consentito in lettura ai processi che hanno la - capacità di eseguire una ricerca sul file (cioè hanno il permesso di lettura - sulla directory che contiene il file) ed in scrittura al proprietario del - file o ai processi dotati della \textit{capability} \index{capabilities} - \const{CAP\_FOWNER}.\footnote{vale a dire una politica di accesso analoga a - quella impiegata per gli ordinari permessi dei file.} + delle \itindex{Access~Control~List} ACL l'accesso è consentito in lettura ai + processi che hanno la capacità di eseguire una ricerca sul file (cioè hanno + il permesso di lettura sulla directory che contiene il file) ed in scrittura + al proprietario del file o ai processi dotati della \textit{capability} + \index{capabilities} \const{CAP\_FOWNER}.\footnote{vale a dire una politica + di accesso analoga a quella impiegata per gli ordinari permessi dei file.} \item[\texttt{trusted}] L'accesso ai \textit{trusted extended attributes}, sia per la lettura che per la scrittura, è consentito soltanto ai processi con @@ -3566,6 +3684,186 @@ disallocato con una chiamata ad \func{acl\_free}. Si tenga presente infine che questa funzione è una estensione specifica di Linux, e non è presente nella bozza dello standard POSIX.1e. +Per quanto utile per la visualizzazione o l'impostazione da comando delle ACL, +la forma testuale non è la più efficiente per poter memorizzare i dati +relativi ad una ACL, ad esempio quando si vuole eseguirne una copia a scopo di +archiviazione. Per questo è stata prevista la possibilità di utilizzare una +rappresentazione delle ACL in una apposita forma binaria contigua e +persistente. È così possibile copiare il valore di una ACL in un buffer e da +questa rappresentazione tornare indietro e generare una ACL. + +Lo standard POSIX.1e prevede a tale scopo tre funzioni, la prima e più +semplice è \funcd{acl\_size}, che consente di ottenere la dimensione che avrà +la citata rappresentazione binaria, in modo da poter allocare per essa un +buffer di dimensione sufficiente, il suo prototipo è: +\begin{functions} + \headdecl{sys/types.h} + \headdecl{sys/acl.h} + + \funcdecl{ssize\_t acl\_size(acl\_t acl)} + + Determina la dimensione della rappresentazione binaria di una ACL. + + \bodydesc{La funzione restituisce in caso di successo la dimensione in byte + della rappresentazione binaria della ACL indicata da \param{acl} e $-1$ in + caso di errore, nel qual caso \var{errno} assumerà uno dei valori: + \begin{errlist} + \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida. + \end{errlist} + +} +\end{functions} + +Prima di effettuare la lettura della rappresentazione binaria è sempre +necessario allocare un buffer di dimensione sufficiente a contenerla, pertanto +prima si dovrà far ricorso a \funcd{acl\_size} per ottenere tale dimensione e +poi allocare il buffer con una delle funzioni di +sez.~\ref{sec:proc_mem_alloc}. Una volta terminato l'uso della +rappresentazione binaria, il buffer dovrà essere esplicitamente disallocato. + +La funzione che consente di leggere la rappresentazione binaria di una ACL è +\funcd{acl\_copy\_ext}, il cui prototipo è: +\begin{functions} + \headdecl{sys/types.h} + \headdecl{sys/acl.h} + + \funcdecl{ssize\_t acl\_copy\_ext(void *buf\_p, acl\_t acl, ssize\_t size)} + + Ottiene la rappresentazione binaria di una ACL. + + \bodydesc{La funzione restituisce in caso di successo la dimensione in byte + della rappresentazione binaria della ACL indicata da \param{acl} e $-1$ in + caso di errore, nel qual caso \var{errno} assumerà uno dei valori: + \begin{errlist} + \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida o + \param{size} è negativo o nullo. + \item[\errcode{ERANGE}] il valore di \param{size} è più piccolo della + dimensione della rappresentazione della ACL. + \end{errlist} + +} +\end{functions} + +La funzione salverà la rappresentazione binaria della ACL indicata da +\param{acl} sul buffer posto all'indirizzo \param{buf\_p} e lungo \param{size} +byte, restituendo la dimensione della stessa come valore di ritorno. Qualora +la dimensione della rappresentazione ecceda il valore di \param{size} la +funzione fallirà con un errore di \errcode{ERANGE}. La funzione non ha nessun +effetto sulla ACL indicata da \param{acl}. + +Viceversa se si vuole ripristinare una ACL a partire dalla rappresentazione +binaria della stessa disponibile in un buffer si potrà usare la funzione +\funcd{acl\_copy\_int}, il cui prototipo è: +\begin{functions} + \headdecl{sys/types.h} + \headdecl{sys/acl.h} + + \funcdecl{ssize\_t acl\_copy\_int(const void *buf\_p)} + + Ripristina la rappresentazione binaria di una ACL. + + \bodydesc{La funzione restituisce un oggetto di tipo \type{acl\_t} in caso + di successo e \code{(acl\_t)NULL} in caso di errore, nel qual caso + \var{errno} assumerà uno dei valori: + \begin{errlist} + \item[\errcode{EINVAL}] il buffer all'indirizzo \param{buf\_p} non contiene + una rappresentazione corretta di una ACL. + \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare un oggetto + \type{acl\_t} per la ACL richiesta. + \end{errlist} + +} +\end{functions} + +La funzione in caso di successo alloca autonomamente un oggetto di tipo +\type{acl\_t} che viene restituito come valore di ritorno con il contenuto +della ACL rappresentata dai dati contenuti nel buffer puntato da +\param{buf\_p}. Si ricordi che come per le precedenti funzioni l'oggetto +\type{acl\_t} dovrà essere disallocato esplicitamente al termine del suo +utilizzo. + +Una volta che si disponga della ACL desiderata, questa potrà essere impostata +su un file o una directory. Per far questo sono disponibili due funzioni; la +prima è \funcd{acl\_set\_file}, il cui prototipo è: +\begin{functions} + \headdecl{sys/types.h} + \headdecl{sys/acl.h} + + \funcdecl{int acl\_set\_file(const char *path, acl\_type\_t type, acl\_t + acl)} + + Imposta una ACL su un file. + + \bodydesc{La funzione restituisce $0$ in caso di successo e $-1$ in caso di + errore, nel qual caso \var{errno} assumerà uno dei valori: + \begin{errlist} + \item[\errcode{EACCES}] o un generico errore di accesso a \param{path} o il + valore di \param{type} specifica una ACL il cui tipo non può essere + assegnato a \param{path}. + \item[\errcode{EINVAL}] o \param{acl} non è una ACL valida, o \param{type} + ha in valore non corretto. + \item[\errcode{ENOSPC}] non c'è spazio disco sufficiente per contenere i + dati aggiuntivi della ACL. + \item[\errcode{ENOTSUP}] si è cercato di impostare una ACL su un file + contenuto in un filesystem che non supporta le ACL. + \end{errlist} + ed inoltre \errval{ENOENT}, \errval{ENOTDIR}, \errval{ENAMETOOLONG}, + \errval{EROFS}, \errval{EPERM}. +} +\end{functions} + +La funzione ... + +%TODO: finire + +La seconda funzione che consente di impostare una ACL è +\funcd{acl\_set\_fd}, il cui prototipo è: +\begin{functions} + \headdecl{sys/types.h} + \headdecl{sys/acl.h} + + \funcdecl{int acl\_set\_fd(int fd, acl\_t acl)} + + Imposta una ACL su un file descriptor. + + \bodydesc{La funzione restituisce $0$ in caso di successo e $-1$ in caso di + errore, nel qual caso \var{errno} assumerà uno dei valori: + \begin{errlist} + \item[\errcode{EBADF}]. + \item[\errcode{EINVAL}] o \param{acl} non è una ACL valida, o \param{type} + ha in valore non corretto. + \item[\errcode{ENOSPC}] non c'è spazio disco sufficiente per contenere i + dati aggiuntivi della ACL. + \item[\errcode{ENOTSUP}] si è cercato di impostare una ACL su un file + contenuto in un filesystem che non supporta le ACL. + \end{errlist} + ed inoltre \errval{EBADF}, \errval{EROFS}, \errval{EPERM}. +} +\end{functions} + +Le funzioni viste finora operano a livello di una intera ACL, eseguendo in una +sola volta tutte le operazioni relative a tutte le voci in essa contenuta. In +generale è possibile modificare un singolo valore all'interno di una singola +voce direttamente con le funzioni previste dallo standardo POSIX.1e. Queste +funzioni però sono alquanto macchinose da utilizzare per cui è probabilmente +più semplice operare direttamente sulla rappresentazione testuale. Questo è il +motivo per non tratteremo nei dettagli dette funzioni, fornendone solo una +descrizione sommaria; chi fosse interessato potrà ricorrere alle pagina di +manuale. + +Se si vuole operare direttamente sui contenuti di un oggetto di tipo +\type{acl\_t} infatti occorre fare riferimento alle singole voci tramite gli +opportuni puntatori di tipo \type{acl\_entry\_t}, che possono essere ottenuti +dalla funzione \funcd{acl\_get\_entry} (per una voce esistente) o dalla +funzione \funcd{acl\_create\_entry} per una voce da aggiungere. Nel caso della +prima funzione si potrà poi ripetere la lettura per ottenere i puntatori alle +singoli voci. + +Una volta ottenuti detti puntatori si porà operare sui contenuti delle singole +voci ... + + +%TODO: finire \itindend{Access~Control~List} @@ -3609,10 +3907,9 @@ padre da ogni processo figlio, in generale i processi risolvono i \itindsub{pathname}{assoluto} \textit{pathname} assoluti a partire sempre dalla stessa directory, che corrisponde alla radice 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ò -cambiare la sua directory radice con la funzione \funcd{chroot}, il cui -prototipo è: +In certe situazioni però è utile poter impedire che un processo possa accedere +a tutto il filesystem; per far questo si può cambiare la sua directory radice +con la funzione \funcd{chroot}, il cui prototipo è: \begin{prototype}{unistd.h}{int chroot(const char *path)} Cambia la directory radice del processo a quella specificata da \param{path}. @@ -3647,7 +3944,8 @@ resta con la directory di lavoro fuori dalla \textit{chroot jail}, potr comunque accedere a tutto il resto del filesystem usando \itindsub{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. +(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 @@ -3665,7 +3963,6 @@ programmi e librerie) di cui il server potrebbe avere bisogno. - % LocalWords: sez like filesystem unlink MacOS Windows VMS inode kernel unistd % LocalWords: un'etichetta int const char oldpath newpath errno EXDEV EPERM st % LocalWords: EEXIST EMLINK EACCES ENAMETOOLONG ENOTDIR EFAULT ENOMEM EROFS ls @@ -3702,9 +3999,9 @@ programmi e librerie) di cui il server potrebbe avere bisogno. % LocalWords: fsetxattr flags XATTR REPLACE listxattr llistxattr flistxattr by % LocalWords: removexattr lremovexattr fremovexattr attributename lacl acl % LocalWords: OBJ setfacl len any prefix separator options NUMERIC IDS SMART +% LocalWords: INDENT major number IDE Documentation makedev fopendir proc %%% Local Variables: %%% mode: latex %%% TeX-master: "gapil" %%% End: -% LocalWords: INDENT