X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=filedir.tex;h=481ef534fd92d789e0b1fcebd06d648cf775a14a;hp=5afbc548f6eaf0d8ede19698de036c04f59c6331;hb=59b107d5207f19e0049bbd1032e10cba660da92e;hpb=39154797992fca1134da0f4456dfbe2f37d82269 diff --git a/filedir.tex b/filedir.tex index 5afbc54..481ef53 100644 --- a/filedir.tex +++ b/filedir.tex @@ -537,7 +537,7 @@ prototipo \begin{errlist} \item[\errcode{EPERM}] Il filesystem non supporta la cancellazione di directory, oppure la directory che contiene \param{dirname} ha lo sticky - bit impostato e l'userid effettivo del processo non corrisponde al + bit impostato e l'user-ID effettivo del processo non corrisponde al proprietario della directory. \item[\errcode{EACCES}] Non c'è il permesso di scrittura per la directory che contiene la directory che si vuole cancellare, o non c'è il permesso @@ -672,7 +672,7 @@ 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 streams} +la lettura delle directory, basata sui cosiddetti \textit{directory stream} (chiamati così per l'analogia con i file stream dell'interfaccia standard di \capref{cha:files_std_interface}). La prima funzione di questa interfaccia è \funcd{opendir}, il cui prototipo è: @@ -830,10 +830,12 @@ il nome del relativo campo; nel nostro caso sono definite le macro 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}: +possibili valori\footnote{fino alla versione 2.1 delle \acr{glibc} questo + campo, pur presente nella struttura, non è implementato, e resta sempre al + valore \const{DT\_UNKNOWN}.} 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}. @@ -846,9 +848,9 @@ 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 è: +\func{seekdir},\footnote{sia questa funzione che \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} @@ -938,7 +940,6 @@ Per l'ordinamento sono disponibili anche due funzioni predefinite, 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 @@ -952,7 +953,154 @@ delle varie voci). Le \acr{glibc} prevedono come estensione\footnote{le glibc, del numero di versione (cioè qualcosa per cui \file{file10} viene comunque dopo \func{file4}.) +Un semplice esempio dell'uso di queste funzioni è riportato in +\figref{fig:file_my_ls}, dove si è riportata la sezione principale di un +programma che, usando la routine di scansione illustrata in +\figref{fig:file_dirscan}, stampa i nomi dei file contenuti in una directory e +la relativa dimensione (in sostanza una versione semplificata del comando +\cmd{ls}). + +\begin{figure}[!htb] + \footnotesize + \begin{lstlisting}{} +#include +#include +#include /* directory */ +#include /* C standard library */ +#include + +/* computation function for DirScan */ +int do_ls(struct dirent * direntry); +/* main body */ +int main(int argc, char *argv[]) +{ + ... + if ((argc - optind) != 1) { /* There must be remaing parameters */ + printf("Wrong number of arguments %d\n", argc - optind); + usage(); + } + DirScan(argv[1], do_ls); + exit(0); +} +/* + * Routine to print file name and size inside DirScan + */ +int do_ls(struct dirent * direntry) +{ + struct stat data; + + stat(direntry->d_name, &data); /* get stat data */ + printf("File: %s \t size: %d\n", direntry->d_name, data.st_size); + return 0; +} + \end{lstlisting} + \caption{Esempio di codice per eseguire la lista dei file contenuti in una + directory.} + \label{fig:file_my_ls} +\end{figure} + +Il programma è estremamente semplice; in \figref{fig:file_my_ls} si è omessa +la parte di gestione delle opzioni (che prevede solo l'uso di una funzione per +la stampa della sintassi, anch'essa omessa) ma il codice completo potrà essere +trovato coi sorgenti allegati nel file \file{myls.c}. + +In sostanza tutto quello che fa il programma, dopo aver controllato +(\texttt{\small 10--13}) di avere almeno un parametro (che indicherà la +directory da esaminare) è chiamare (\texttt{\small 14}) la funzione +\func{DirScan} per eseguire la scansione, usando la funzione \code{do\_ls} +(\texttt{\small 20--26}) per fare tutto il lavoro. + +Quest'ultima si limita (\texttt{\small 23}) a chiamare \func{stat} sul file +indicato dalla directory entry passata come argomento (il cui nome è appunto +\var{direntry->d\_name}), memorizzando in una opportuna struttura \var{data} i +dati ad esso relativi, per poi provvedere (\texttt{\small 24}) a stampare il +nome del file e la dimensione riportata in \var{data}. + +Dato che la funzione verrà chiamata all'interno di \func{DirScan} per ogni +voce presente questo è sufficiente a stampare la lista completa dei file e +delle relative dimensioni. Si noti infine come si restituisca sempre 0 come +valore di ritorno per indicare una esecuzione senza errori. + +\begin{figure}[!htb] + \footnotesize + \begin{lstlisting}{} +#include +#include +#include /* directory */ +#include /* C standard library */ +#include + +/* + * Function DirScan: + * + * Input: the directory name and a computation function + * Return: 0 if OK, -1 on errors + */ +int DirScan(char * dirname, int(*compute)(struct dirent *)) +{ + DIR * dir; + struct dirent *direntry; + + if ( (dir = opendir(dirname)) == NULL) { /* oper directory */ + printf("Opening %s\n", dirname); /* on error print messages */ + perror("Cannot open directory"); /* and then return */ + return -1; + } + fd = dirfd(dir); /* get file descriptor */ + fchdir(fd); /* change directory */ + /* loop on directory entries */ + while ( (direntry = readdir(dir)) != NULL) { /* read entry */ + if (compute(direntry)) { /* execute function on it */ + return -1; /* on error return */ + } + } + closedir(dir); + return 0; +} + + \end{lstlisting} + \caption{Codice della routine di scansione di una directory contenuta nel + file \file{DirScan.c}.} + \label{fig:file_dirscan} +\end{figure} +Tutto il grosso del lavoro è svolto dalla funzione \func{DirScan}, riportata +in \figref{fig:file_dirscan}. La funzione è volutamente generica e permette di +eseguire una funzione, passata come secondo argomento, su tutte le voci di una +directory. La funzione inizia con l'aprire (\texttt{\small 19--23}) uno +stream sulla directory passata come primo argomento, stampando un messaggio in +caso di errore. + +Il passo successivo (\texttt{\small 24--25}) è cambiare directory di lavoro +(vedi \secref{sec:file_work_dir}), usando in sequenza le funzione \func{dirfd} +e \func{fchdir} (in realtà si sarebbe potuto usare direttamente \func{chdir} +su \var{dirname}), in modo che durante il successivo ciclo (\texttt{\small + 27--31}) sulle singole voci dello stream ci si trovi all'interno della +directory.\footnote{questo è essenziale al funzionamento della funzione + \code{do\_ls} (e ad ogni funzione che debba usare il campo \var{d\_name}, in + quanto i nomi dei file memorizzati all'interno di una struttura + \struct{dirent} sono sempre relativi alla directory in questione, e senza + questo posizionamento non si sarebbe potuto usare \func{stat} per ottenere + le dimensioni.} + +Avendo usato lo stratagemma di fare eseguire tutte le manipolazioni necessarie +alla funzione passata come secondo argomento, il ciclo di scansione della +directory è molto semplice; si legge una voce alla volta (\texttt{\small 27}) +all'interno di una istruzione di \code{while} e fintanto che si riceve una +voce valida (cioè un puntatore diverso da \val{NULL}) si esegue +(\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. \subsection{La directory di lavoro} @@ -960,7 +1108,7 @@ dopo \func{file4}.) 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 +che è quella a cui si fa riferimento quando un pathname è espresso in forma relativa, dove il ``\textsl{relativa}'' fa riferimento appunto a questa directory. @@ -1043,7 +1191,7 @@ appunto per \textit{change directory}, il suo prototipo 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 filename, per fare questo si +tramite il file descriptor, e non solo tramite il 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 @@ -1069,7 +1217,8 @@ sembri semplice, in realt 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} (si ricordi quanto visto in \secref{sec:proc_race_cond}). + condition}\index{race condition} (si ricordi quanto visto in +\secref{sec:proc_race_cond}). Le \acr{glibc} provvedono varie funzioni per generare nomi di file temporanei, di cui si abbia certezza di unicità (al momento della generazione); la prima @@ -1366,7 +1515,7 @@ un'opportuna combinazione. \textbf{Flag} & \textbf{Valore} & \textbf{Significato} \\ \hline \hline - \const{S\_IFMT} & 0170000 & bitmask per i bit del tipo di file \\ + \const{S\_IFMT} & 0170000 & maschera per i bit del tipo di file \\ \const{S\_IFSOCK} & 0140000 & socket\index{socket} \\ \const{S\_IFLNK} & 0120000 & link simbolico \\ \const{S\_IFREG} & 0100000 & file regolare \\ @@ -1848,8 +1997,8 @@ in una directory con lo \textsl{sticky bit} impostato (si veda La procedura con cui il kernel stabilisce se un processo possiede un certo permesso (di lettura, scrittura o esecuzione) si basa sul confronto fra l'utente e il gruppo a cui il file appartiene (i valori di \var{st\_uid} e -\var{st\_gid} accennati in precedenza) e l'userid effettivo, il groupid -effettivo e gli eventuali groupid supplementari del processo.\footnote{in +\var{st\_gid} accennati in precedenza) e l'user-ID effettivo, il group-ID +effettivo e gli eventuali group-ID supplementari del processo.\footnote{in realtà Linux, per quanto riguarda l'accesso ai file, utilizza gli gli identificatori del gruppo \textit{filesystem} (si ricordi quanto esposto in \secref{sec:proc_perms}), ma essendo questi del tutto equivalenti ai primi, @@ -1858,19 +2007,19 @@ effettivo e gli eventuali groupid supplementari del processo.\footnote{in 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 effettivo +\secref{sec:file_suid_sgid}, l'user-ID effettivo e il group-ID 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 +lanciato il processo, mentre i group-ID supplementari sono quelli dei gruppi cui l'utente appartiene. I passi attraverso i quali viene stabilito se il processo possiede il diritto di accesso sono i seguenti: \begin{enumerate} -\item Se l'userid effettivo del processo è zero (corrispondente +\item Se l'user-ID effettivo del processo è zero (corrispondente all'amministratore) l'accesso è sempre garantito senza nessun ulteriore controllo. Per questo motivo \textsl{root} ha piena libertà di accesso a tutti i file. -\item Se l'userid effettivo del processo è uguale all'\acr{uid} del +\item Se l'user-ID effettivo del processo è uguale all'\acr{uid} del proprietario del file (nel qual caso si dice che il processo è proprietario del file) allora: \begin{itemize*} @@ -1880,8 +2029,8 @@ di accesso sono i seguenti: impostato, l'accesso è consentito \item altrimenti l'accesso è negato \end{itemize*} -\item Se il groupid effettivo del processo o uno dei groupid supplementari dei - processi corrispondono al \acr{gid} del file allora: +\item Se il group-ID effettivo del processo o uno dei group-ID supplementari + dei processi corrispondono al \acr{gid} del file allora: \begin{itemize*} \item se il bit dei permessi d'accesso del gruppo è impostato, l'accesso è consentito, @@ -1919,9 +2068,9 @@ corrispondono dell'utente con cui si Se però il file del programma (che ovviamente deve essere eseguibile\footnote{per motivi di sicurezza il kernel ignora i bit \acr{suid} e \acr{sgid} per gli script eseguibili.}) ha il bit \acr{suid} impostato, il -kernel assegnerà come userid effettivo al nuovo processo l'\acr{uid} del +kernel assegnerà come user-ID effettivo al nuovo processo l'\acr{uid} del proprietario del file al posto dell'\acr{uid} del processo originario. Avere -il bit \acr{sgid} impostato ha lo stesso effetto sul groupid effettivo del +il bit \acr{sgid} impostato ha lo stesso effetto sul group-ID effettivo del processo. I bit \acr{suid} e \acr{sgid} vengono usati per permettere agli utenti normali @@ -2021,10 +2170,10 @@ per la creazione di nuove directory (procedimento descritto in \secref{sec:file_dir_creat_rem}). 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 +all'user-ID effettivo del processo che lo crea; per il \acr{gid} invece prevede due diverse possibilità: \begin{itemize*} -\item il \acr{gid} del file corrisponde al groupid effettivo del processo. +\item il \acr{gid} del file corrisponde al group-ID effettivo del processo. \item il \acr{gid} del file corrisponde al \acr{gid} della directory in cui esso è creato. \end{itemize*} @@ -2050,9 +2199,9 @@ con il \acr{gid} del gruppo primario dello stesso. \label{sec:file_access} Come visto in \secref{sec:file_access_control} il controllo di accesso ad un -file viene fatto utilizzando l'userid ed il groupid effettivo del processo; ci -sono casi però in cui si può voler effettuare il controllo con l'userid reale -ed il groupid reale, vale a dire usando i valori di \acr{uid} e \acr{gid} +file viene fatto utilizzando l'user-ID ed il group-ID effettivo del processo; ci +sono casi però in cui si può voler effettuare il controllo con l'user-ID reale +ed il group-ID reale, vale a dire usando i valori di \acr{uid} e \acr{gid} relativi all'utente che ha lanciato il programma, e che, come accennato in \secref{sec:file_suid_sgid} e spiegato in dettaglio in \secref{sec:proc_perms}, non è detto siano uguali a quelli effettivi. @@ -2137,7 +2286,7 @@ filename e su un file descriptor, i loro prototipi sono: \bodydesc{Le funzioni restituiscono zero in caso di successo e -1 per un errore, in caso di errore \var{errno} può assumere i valori: \begin{errlist} - \item[\errcode{EPERM}] L'userid effettivo non corrisponde a quello del + \item[\errcode{EPERM}] L'user-ID effettivo non corrisponde a quello del proprietario del file o non è zero. \item[\errcode{EROFS}] Il file è su un filesystem in sola lettura. \end{errlist} @@ -2200,7 +2349,7 @@ bit \acr{suid} il valore da fornire sarebbe $4755$. Il cambiamento dei permessi di un file eseguito attraverso queste funzioni ha comunque alcune limitazioni, previste per motivi di sicurezza. L'uso delle -funzioni infatti è possibile solo se l'userid effettivo del processo +funzioni infatti è possibile solo se l'user-ID effettivo del processo corrisponde a quello del proprietario del file o dell'amministratore, altrimenti esse falliranno con un errore di \errcode{EPERM}. @@ -2210,7 +2359,7 @@ non tutti i valori possibili di \param{mode} sono permessi o hanno effetto; in particolare accade che: \begin{enumerate} \item siccome solo l'amministratore può impostare lo \textit{sticky bit}, se - l'userid effettivo del processo non è zero esso viene automaticamente + l'user-ID effettivo del processo non è zero esso viene automaticamente cancellato (senza notifica di errore) qualora sia stato indicato in \param{mode}. \item per quanto detto in \secref{sec:file_ownership} riguardo la creazione @@ -2220,7 +2369,7 @@ in particolare accade che: per cui non si hanno diritti, questo viene automaticamente cancellato da \param{mode} (senza notifica di errore) qualora il gruppo del file non corrisponda a quelli associati al processo (la cosa non avviene quando - l'userid effettivo del processo è zero). + l'user-ID effettivo del processo è zero). \end{enumerate} Per alcuni filesystem\footnote{il filesystem \acr{ext2} supporta questa @@ -2292,7 +2441,7 @@ sono: \bodydesc{Le funzioni restituiscono zero in caso di successo e -1 per un errore, in caso di errore \var{errno} può assumere i valori: \begin{errlist} - \item[\errcode{EPERM}] L'userid effettivo non corrisponde a quello del + \item[\errcode{EPERM}] L'user-ID effettivo non corrisponde a quello del proprietario del file o non è zero, o utente e gruppo non sono validi \end{errlist} Oltre a questi entrambe restituiscono gli errori \errval{EROFS} e @@ -2380,7 +2529,7 @@ alcun effetto qualora il processo possieda i privilegi di amministratore. \end{table} Per compattezza, nella tabella si sono specificati i bit di \acr{suid}, -\acr{sgid} e \acr{stiky} con la notazione illustrata anche in +\acr{sgid} e \acr{sticky} con la notazione illustrata anche in \figref{fig:file_perm_bit}. In \tabref{tab:file_dirperm_bits} si sono invece riassunti gli effetti dei @@ -2454,7 +2603,7 @@ radice con la funzione \funcd{chroot}, il cui prototipo \bodydesc{La funzione restituisce zero in caso di successo e -1 per un errore, in caso di errore \var{errno} può assumere i valori: \begin{errlist} - \item[\errcode{EPERM}] L'userid effettivo del processo non è zero. + \item[\errcode{EPERM}] L'user-ID effettivo del processo non è zero. \end{errlist} ed inoltre \errval{EFAULT}, \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM}, \errval{ENOTDIR}, \errval{EACCES}, \errval{ELOOP};