X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=filedir.tex;h=db9c352402dc45ab9846afe37bd79ca9fa471008;hp=0d6dbdba57a2fb2fe0e10d76745a240af656a4ee;hb=d99b4995b23505a9afde30adf3a716aa7a55f0e9;hpb=34ed932cc43ebd3df23ce3255984bba0301b7231 diff --git a/filedir.tex b/filedir.tex index 0d6dbdb..db9c352 100644 --- a/filedir.tex +++ b/filedir.tex @@ -2,525 +2,259 @@ \label{cha:files_and_dirs} In questo capitolo tratteremo in dettaglio le modalità con cui si gestiscono -files e directories, ed in particolare esamineremo come è strutturato il -sistema base di protezioni e controllo di accesso ai files, e tutta -l'interfaccia che permette la manipolazione dei vari attributi di files e -directories. Tutto quello che riguarda invece la manipolazione del contenuto -dei file è lasciato ai capitoli successivi. +file e directory, ed in particolare esamineremo come è strutturato il sistema +base di protezioni e controllo di accesso ai file, e tutta l'interfaccia che +permette la manipolazione dei vari attributi di file e directory. Tutto quello +che riguarda invece la manipolazione del contenuto dei file è lasciato ai +capitoli successivi. -\section{La gestione di file e directory} -Le prime funzioni che considereremo sono quelle relative alla gestione di file -e directory, secondo le caratteristiche standard che essi presentano in un -filesystem unix, la cui struttura abbiamo esaminato in precedenza (vedi -\secref{sec:fileintr_filesystem}). +\section{Il controllo di accesso ai file} +\label{sec:filedir_access_control} -\subsection{Le funzioni \texttt{link} e \texttt{unlink}} -\label{sec:fileintr_link} +Una delle caratteristiche fondamentali di tutti i sistemi unix-like è quella +del controllo di accesso ai file, che viene implementato per qualunque +filesystem standard. In questa sezione ne esamineremo i concetti essenziali e +le funzioni usate per gestirne i vari aspetti. + + +\subsection{I permessi per l'accesso ai file} +\label{sec:filedir_perm_overview} + +Il controllo di accesso ai file in unix segue un modello abbastanza semplice, +ma adatto alla gran parte delle esigenze, in cui si dividono i permessi su tre +livelli. Si tenga conto poi che quanto diremo è vero solo per filesystem di +tipo unix, e non è detto che sia applicabile a un filesystem +qualunque\footnote{ed infatti non è vero per il filesystem vfat di Windows, + per il quale vengono assegnati in maniera fissa con un opzione in fase di + montaggio}. Esistono inoltre estensioni che permettono di implementare le +ACL (\textit{Access Control List}) che sono un meccanismo di controllo di +accesso molto più sofisticato. + +Ad ogni file unix associa sempre l'utente che ne è proprietario (il cosiddetto +\textit{owner}) e il gruppo di appartenenza, secondo il meccanismo degli +identificatori di utenti e gruppi (\textsl{uid} e \textsl{gid}), e accessibili +da programm tramite i campi \var{st\_uid} e \var{st\_gid} della struttura +\var{stat} (si veda \secref{sec:filedir_stat}). Ad ogni file viene inoltre +associato un insieme di permessi che sono divisi in tre classi, e cioè +attribuiti rispettivamente all'utente proprietario del file, a un qualunque +utente faccia parte del gruppo cui appartiene il file, e a tutti gli altri +utenti. -Una delle caratteristiche usate quando si opera con i file è quella di poter -creare dei nomi fittizi (alias o collegamenti) per potersi riferire allo -stesso file accedendovi da directory diverse. Questo è possibile anche in -ambiente unix, dove tali collegamenti sono usualmente chiamati \textit{link}, -ma data la struttura del sistema ci sono due metodi sostanzialmente diversi -per fare questa operazione. +I permessi sono espressi da un insieme di 12 bit: di questi i nove meno +significativi sono usati a gruppi di tre per indicare i permessi base di +lettura, scrittura ed esecuzione (indicati rispettivamente con le lettere +\textsl{w}, \textit{r} \textsl{x} nei comandi di sistema) applicabili +rispettivamente al proprietario, al gruppo, a tutti. I restanti tre bit +(\textsl{suid}, \textsl{sgid}, e \textsl{sticky}) sono usati per indicare +alcune caratteristiche più complesse su cui torneremo in seguito (vedi +\secref{sec:filedir_suid_sgid} e \secref{sec:filedir_sticky}). + +Anche i permessi sono tenuti per ciascun file (di qualunque tipo, quindi anche +per le fifo, i socket e i file di dispositivo) nell'inode, in opportuni bit +del campo \var{st\_mode} della struttura letta da \func{stat} (vedi +\figref{fig:filedir_stat_struct}). + + +In genere ci si riferisce a questi permessi usando le lettere \textsl{u} (per +\textit{user}), \textsl{g} (per \textit{group}) e \textsl{o} (per +\textit{other}), inoltre se si vuole indicare tutti questi gruppi insieme si +usa la lettera \textsl{a} (per \textit{all}). Si tenga ben presente questa +distinzione, dato che in certi casi, mutuando la termimologia in uso nel VMS, +si parla dei permessi base come di permessi di owner, group ed all, le cui +iniziali possono da luogo a confuzione. Le costanti che permettono di accedere +al valore numerico di questi bit sono riportate in \ntab. -Come si è appena detto l'accesso al contenuto di un file su disco avviene -attraverso il suo inode, e il nome che si trova in una directory è solo una -etichetta associata ad un puntatore a detto inode. Questo significa che la -realizzazione di un link è immediata in quanto uno stesso file può avere tanti -nomi diversi allo stesso tempo, dati da altrettante diverse associazioni allo -stesso inode; si noti poi che nessuno di questi nomi viene ad assumere una -particolare preferenza rispetto agli altri. +\begin{table}[htb] + \centering + \footnotesize + \begin{tabular}[c]{|c|l|} + \hline + \var{st\_mode} bit & Significato \\ + \hline + \hline + \macro{S\_IRUSR} & \textit{user-read}, l'utente può leggere \\ + \macro{S\_IWUSR} & \textit{user-write}, l'utente può scrivere \\ + \macro{S\_IXUSR} & \textit{user-execute}, l'utente può eseguire \\ + \hline + \macro{S\_IRGRP} & \textit{group-read}, il gruppo può leggere \\ + \macro{S\_IWGRP} & \textit{group-write}, il gruppo può scrivere \\ + \macro{S\_IXGRP} & \textit{group-execute}, il gruppo può eseguire\\ + \hline + \macro{S\_IROTH} & \textit{other-read}, tutti possono leggere \\ + \macro{S\_IWOTH} & \textit{other-write}, tutti possono scrivere \\ + \macro{S\_IXOTH} & \textit{other-execute}, tutti possono eseguire\\ + \hline + \end{tabular} + \caption{I bit dei permessi di accesso ai file, come definiti in + \texttt{}} + \label{tab:file_bit_perm} +\end{table} -Per aggiungere un nome ad un inode si utilizza la funzione \texttt{link}; si -suole chiamare questo tipo di associazione un collegamento diretto (o -\textit{hard link}). Il prototipo della funzione e le sue caratteristiche -principali, come risultano dalla man page, sono le seguenti: -\begin{prototype}{unistd.h} -{int link(const char * oldpath, const char * newpath)} - Crea un nuovo collegamento diretto al file indicato da \texttt{oldpath} - dandogli nome \texttt{newpath}. - - La funzione restituisce zero in caso di successo e -1 per un errore, in caso - di errore. La variabile \texttt{errno} viene settata secondo i seguenti - codici di errore: - \begin{errlist} - \item \texttt{EXDEV} \texttt{oldpath} e \texttt{newpath} non sono sullo - stesso filesystem. - \item \texttt{EPERM} il filesystem che contiene \texttt{oldpath} e - \texttt{newpath} non supporta i link diretti o è una directory. - \item \texttt{EFAULT} una delle stringhe passate come parametri è fuori - dello spazio di indirizzi del processo. - \item \texttt{EACCESS} errore di accesso (mancano i permessi per scrivere o - per attraversare le directories), vedi \secref{sec:filedir_access_control} - per i dettagli. - \item \texttt{ENAMETOOLONG} una dei due pathname è troppo lungo. - \item \texttt{ENOENT} un componente di \texttt{oldpath} o \texttt{newpath} - non esiste o è un link simbolico spezzato. - \item \texttt{ENOTDIR} un componente di \texttt{oldpath} o \texttt{newpath} - non è una directory. - \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a - completare l'operazione. - \item \texttt{EROFS} la directory su cui si vuole inserire il nuovo link è - su un filesystem montato readonly. - \item \texttt{EEXIST} un file (o una directory) con quel nome esiste di - già. - \item \texttt{EMLINK} ci sono troppi link al file \texttt{oldpath} (il - numero massimo è specificato dalla variabile \texttt{LINK\_MAX}, vedi - \secref{sec:xxx_limits}). - \item \texttt{ELOOP} si incontrati troppi link simbolici nella risoluzione - di \texttt{oldpath} o \texttt{newpath}. - \item \texttt{ENOSPC} la directory in cui si vuole creare il link non ha - spazio per ulteriori voci. - \item \texttt{EIO} c'è stato un errore di input/output. - \end{errlist} -\end{prototype} +Questi permessi vengono usati in maniera diversa dalle varie funzioni, e a +seconda che si riferiscano a file, link simbolici o directory, qui ci +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, e 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 ha il significato +specifico 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. 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 permessi opportuni per il medesimo) ma non si potrà +vederlo con \cmd{ls} (per crearlo occorrerà anche il permesso di scrittura per +la directory). + +Il permesso di lettura per un file consente di aprirlo con le opzioni di sola +lettura (\macro{O\_RDONLY}) o di lettura-scrittura (\macro{O\_RDWR}) e +leggerne il contenuto. Il permesso di scrittura consente di aprire un file in +sola scrittura (\macro{O\_WRONLY}) o lettura-scrittura (\macro{O\_RDWR}) e +modificarne il contenuto, lo stesso permesso è necessario per poter troncare +il file con l'opzione \macro{O\_TRUNC}. + +Non si può creare un file fintanto che non si disponga del permesso di +esecuzione e di quello di scrittura per la directory di destinazione; gli +stessi permessi occorrono per cancellare un file da una directory (si ricordi +che questo non implica necessariamente la rimozione fisica del file), non è +necessario nessun tipo di permesso per il file stesso (infatti esso non viene +toccato, viene solo modificato il contenute della directory). + +Per poter eseguire un file (che sia un programma compilato od uno script di +shell), occorre il permesso di esecuzione per il medesimo, inoltre solo i file +regolari possono essere eseguiti. + +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'\textit{effective user id}, +l'\textit{effective group id} e gli eventuali \textit{supplementary group id} +del processo. + +Per una spiegazione dettagliata degli identificatori associati ai processi si +veda \secref{sec:prochand_perms}; normalmente, a parte quanto vedremo in +\secref{sec:filedir_suid_sgid}, l'\textit{effective user id} e +l'\textit{effective group id} corrispondono a uid e gid dell'utente che ha +lanciato il processo, mentre i \textit{supplementary group id} sono quelli dei +gruppi cui l'utente appartiene. + +% Quando un processo cerca l'accesso al file esso controlla i propri uid e gid +% confrontandoli con quelli del file e se l'operazione richiesta è compatibile +% con i permessi associati al file essa viene eseguita, altrimenti viene +% bloccata ed è restituito un errore di \texttt{EPERM}. Questo procedimento non +% viene eseguito per l'amministratore di sistema (il cui uid è zero) il quale +% a +% pertanto accesso senza restrizione a qualunque file del sistema. -La creazione di un nuovo collegamento diretto non copia il contenuto del file, -ma si limita ad aumentare di uno il numero di referenze al file aggiungendo il -nuovo nome ai precedenti. Si noti che uno stesso file può essere così -richiamato in diverse directory. - -Per quanto dicevamo in \secref{sec:fileintr_filesystem} la creazione del -collegamento diretto è possibile solo se entrambi i pathname sono nello stesso -filesystem; inoltre il filesystem deve supportare i collegamenti diretti (non è -il caso ad esempio del filesystem \texttt{vfat} di windows). +% In realtà il procedimento è più complesso di quanto descritto in maniera +% elementare qui; inoltre ad un processo sono associati diversi identificatori, +% torneremo su questo in maggiori dettagli in seguito in +% \secref{sec:proc_perms}. + +I passi attraverso i quali viene stabilito se il processo possiede il diritto +di accesso sono i seguenti: +\begin{itemize} +\item Se l'\textit{effective user id} 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'\textit{effective user id} del processo è uguale all'uid del + proprietario del file (nel qual caso si dice che il processo è proprietario + del file) allora: + \begin{itemize} + \item se il relativo\footnote{per relativo si intende il bit di user-read se + il processo, vuole accedere in scrittura, quello di user-write per + l'accesso in scrittura, etc.} bit dei permessi d'accesso dell'utente è + settato, l'accesso è consentito + \item altrimenti l'accesso è negato + \end{itemize} +\item Se l'\textit{effective group id} del processo o uno dei + \textit{supplementary group id} dei processi corrispondono al gid del file + allora: + \begin{itemize} + \item se il bit dei permessi d'accesso del gruppo è settato, l'accesso è + consentito, altrimenti l'accesso è negato + \end{itemize} +\item se il bit dei permessi d'accesso per tutti gli altri è settato, + l'accesso è consentito, altrimenti l'accesso è negato. +\end{itemize} + +Si tenga presente che questi passi vengono eseguiti esattamente in +quest'ordine. Questo vuol dire che se un processo è il proprietario di un file +l'accesso è consentito o negato solo sulla base dei permessi per l'utente; i +permessi per il gruppo non vengono neanche controllati; lo stesso vale se il +processo appartiene ad un gruppo appropriato, in questo caso i permessi per +tutti gli altri non vengono controllati. -La funzione opera sui file ordinari, come sugli altri oggetti del filesystem, -in alcuni filesystem solo l'amministratore è in grado di creare un -collegamento diretto ad un'altra directory, questo lo si fa perché in questo -caso è possibile creare dei circoli nel filesystem (vedi -\secref{sec:fileintr_symlink}) che molti programmi non sono in grado di -gestire e la cui rimozione diventa estremamente complicata (in genere occorre -far girare il programma \texttt{fsck} per riparare il filesystem); data la sua -pericolosità in generale nei filesystem usati in Linux questa caratteristica è -stata disabilitata, e la funzione restituisce l'errore \texttt{EPERM}. +\subsection{I flag \texttt{suid} e \texttt{sgid}} +\label{sec:filedir_suid_sgid} -La rimozione di un file (o più precisamente della voce che lo referenzia) si -effettua con la funzione \texttt{unlink}; il suo prototipo è il seguente: +Quandi si lancia un programma in genere l'\textit{effective user id} e +l'\textit{effective group id} sono settati rispettivamente all'uid e al gid +dell'utente che ha lanciato il programma. -\begin{prototype}{unistd.h}{int unlink(const char * pathname)} - Cancella il nome specificato dal pathname nella relativa directory e - decrementa il numero di riferimenti nel relativo inode. Nel caso di link - simbolico cancella il link simbolico; nel caso di socket, fifo o file di - dispositivo rimuove il nome, ma come per i file i processi che hanno aperto - uno di questi oggetti possono continuare ad utilizzarlo. - - La funzione restituisce zero in caso di successo e -1 per un errore, nel - qual caso il file non viene toccato. La variabile \texttt{errno} viene - settata secondo i seguenti codici di errore: - \begin{errlist} - \item \texttt{EACCESS} errore di accesso (mancano i permessi per scrivere o - per attraversare le directories), vedi \secref{sec:filedir_access_control} - per i dettagli. - \item \texttt{EISDIR} \texttt{pathname} si riferisce ad una directory - (valore specifico ritornato da linux che non consente l'uso di - \texttt{unlink} con le directory, e non conforme allo standard POSIX, che - prescrive invece l'uso di \texttt{EPERM} in caso l'operazione non sia - consnetita o il processo non abbia privilegi sufficienti). - \item \texttt{EFAULT} la stringa - passata come parametro è fuori dello spazio di indirizzi del processo. - \item \texttt{ENAMETOOLONG} il pathname troppo lungo. - \item \texttt{ENOENT} uno dei componenti del pathname non esiste o è un link - simbolico spezzato. - \item \texttt{ENOTDIR} uno dei componenti del pathname non è una directory. - \item \texttt{EISDIR} \texttt{pathname} fa riferimento a una directory. - \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a - completare l'operazione. - \item \texttt{EROFS} \texttt{pathname} è su un filesystem montato in sola - lettura. - \item \texttt{ELOOP} ci sono troppi link simbolici nella risoluzione del - pathname. - \item \texttt{EIO} errore di input/output. - \end{errlist} -\end{prototype} -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 -il diritto di esecuzione sulla directory che la contiene (torneremo in -dettaglio sui permessi e gli attributi fra poco), se inoltre lo -\textit{sticky} bit è settato occorrerà anche essere proprietari del file o -proprietari della directory (o root, per cui nessuna delle restrizioni è -applicata). +Ma nei dodici bit del campo \var{st\_mode} relativi ai permessi esiste un bit +speciale, il \textit{set-user-ID bit} o suid, che se settato fa si che quando +un programma viene lanciato invece di avere assegnato come \textit{effective + user id} l'uid di chi lo lancia, assume quello del proprietario del file. +Analogamente il \textit{set-group-ID bit} o sgid settato per un file ha lo +stesso effetto sull'\textit{effective group id}. -Una delle caratteristiche di queste funzioni è che la creazione/rimozione -della nome dalla directory e l'incremento/decremento del numero di riferimenti -nell'inode deve essere una operazione atomica (cioè non interrompibile da -altri) processi, per questo entrambe queste funzioni sono realizzate tramite -una singola system call. +Questa caratteristica viene usata per permettere agli utenti normali di usare +programmi che abbisognano di privilegi speciali; l'esempio classico è il +comando \cmd{passwd} che ha la necessità di modificare il file delle password, +che può essere scritto solo dall'amministratore. Per questo il comando +\cmd{passwd} appartiene a root e ha il suid bit settato per cui quando viene +lanciato da un utente normale ha comunque i privilegi di root. -Si ricordi infine che il file non viene eliminato dal disco fintanto che tutti -i riferimenti ad esso sono stati cancellati, solo quando il \textit{link - count} mantenuto nell'inode diventa zero lo spazio occupato viene rimosso. A -questo però si aggiunge una altra condizione, e cioè che non ci siano processi -che abbiano detto file aperto. Come accennato questa proprietà viene spesso -usata per essere sicuri di non lasciare file temporanei su disco in caso di -crash dei programmi; la tecnica è quella di aprire il file e chiamare -\texttt{unlink} subito dopo. +Chiaramente avere un processo che ha privilegi superiori a quelli che avrebbe +normalmente un utente comporta vari rischi, e questo tipo di programmi devono +essere scritti accuratamente (torneremo sull'argomento in +\secref{sec:prochand_perms}). -\subsection{Le funzioni \texttt{remove} e \texttt{rename}} -\label{sec:fileintr_remove} +I due bit suid e sgid possono essere controllati all'interno di \var{st\_mode} +con l'uso delle due costanti \macro{S\_ISUID} e \macro{S\_ISGID}, definite in +\tabref{tab:filedir_file_mode_flags}. -Al contrario di quanto avviene con altri unix in Linux non è possibile usare -\texttt{unlink} sulle directory, per cancellare una directory si può usare la -funzione \texttt{rmdir} (vedi \secref{sec:filedir_dir_creat_rem}), oppure la -funzione \texttt{remove}. Questa è la funzione prevista dallo standard ANSI C -per cancellare un file o una directory (e funziona anche per i sistemi che non -supportano i link diretti), che per i file è identica alla \texttt{unlink} e -per le directory è identica alla \texttt{rmdir}: -\begin{prototype}{stdio.h}{int remove(const char *pathname)} - Cancella un nome dal filesystem. Usa \texttt{unlink} per i file e - \texttt{rmdir} per le directory. - - La funzione restituisce zero in caso di successo e -1 per un errore, nel - qual caso il file non viene toccato. Per i codici di errori vedi quanto - riportato nella descrizione di \texttt{unlink} e \texttt{rmdir}. -\end{prototype} +\subsection{Il flag \texttt{sticky}} +\label{sec:filedir_sticky} -Per cambiare nome ad un file si usa invece la funzione \texttt{rename}, il -vantaggio nell'uso di questa funzione al posto della chiamata successiva di -\texttt{unlink} e \texttt{link} è che l'operazione è eseguita atomicamente, in -questo modo non c'è la possibilità che un processo che cerchi di accedere al -nuovo nome dopo che il vecchio è stato cambiato lo trovi mancante. +L'ultimo -\begin{prototype}{stdio.h} -{int rename(const char *oldpath, const char *newpath)} - Rinomina un file, spostandolo fra directory diverse quando richiesto. +\subsection{La titolarità di nuovi files e directory} +\label{sec:filedir_ownership} - La funzione restituisce zero in caso di successo e -1 per un errore, nel - qual caso il file non viene toccato. La variabile \texttt{errno} viene - settata secondo i seguenti codici di errore: - \begin{errlist} - \item \texttt{EISDIR} \texttt{newpath} è una directory già esistente mentre - \texttt{oldpath} non è una directory. - \item \texttt{EXDEV} \texttt{oldpath} e \texttt{newpath} non sono sullo - stesso filesystem. - \item \texttt{ENOTEMPTY} \texttt{newpath} è una directory già esistente e - non vuota. - \item \texttt{EBUSY} o \texttt{oldpath} o \texttt{newpath} sono in uso da - parte di qualche processo (come directory di lavoro o come root) o del - sistema (come mount point). - \item \texttt{EINVAL} \texttt{newpath} contiene un prefisso di - \texttt{oldpath} o più in generale si è cercato di creare una directory - come sottodirectory di se stessa. - \item \texttt{EMLINK} \texttt{oldpath} ha già il massimo numero di link - consentiti o è una directory e la directory che contiene \texttt{newpath} - ha già il massimo numero di link. - \item \texttt{ENOTDIR} Uno dei componenti dei pathname non è una directory - o\texttt{oldpath} è una directory e \texttt{newpath} esiste e non è una - directory. - \item \texttt{EFAULT} o \texttt{oldpath} o \texttt{newpath} è fuori dello - spazio di indirizzi del processo. - \item \texttt{EACCESS} Non c'è il permesso di scrittura per la directory in - cui si vuole creare il nuovo link o una delle directory del pathname non - consente la ricerca (permesso di esecuzione). - \item \texttt{EPERM} le directory contenenti \texttt{oldpath} o - \texttt{newpath} hanno lo sticky bit attivo e i permessi del processo non - consentono rispettivamente la cancellazione e la creazione del file, o il - filesystem non supporta i link. - \item \texttt{ENAMETOOLONG} uno dei pathname è troppo lungo. - \item \texttt{ENOENT} Uno dei componenti del pathname non esiste o è un link - simbolico spezzato. - \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a - completare l'operazione. - \item \texttt{EROFS} I file sono su un filesystem montato in sola lettura. - \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione del - pathname. - \item \texttt{ENOSPC} Il device di destinazione non ha più spazio per la - nuova voce. - \end{errlist} -\end{prototype} -\subsection{I link simbolici} -\label{sec:fileintr_symlink} +\subsection{La funzione \texttt{access}} +\label{sec:filedir_access} -Siccome la funzione \texttt{link} crea riferimenti agli inodes, essa può -funzionare soltanto per file che risiedono sullo stesso filesystem, dato che -in questo caso è garantita l'unicità dell'inode, e solo per un filesystem di -tipo unix. Inoltre in Linux non è consentito eseguire un link diretto ad una -directory. -Per ovviare a queste limitazioni i sistemi unix supportano un'altra forma di -link (i cosiddetti \textit{soft link} o \textit{symbolic link}), che sono, -come avviene in altri sistemi operativi, dei file che contengono il -semplicemente il riferimento ad un altro file (o directory). In questo modo è -possibile effettuare link anche attraverso filesystem diversi e a directory, e -pure a file che non esistono ancora. +\subsection{La funzione \texttt{umask}} +\label{sec:filedir_umask} -Il sistema funziona in quanto i link simbolici sono contrassegnati come tali -al kernel (analogamente a quanto avviene per le directory) per cui la chiamata -ad una \texttt{open} o una \texttt{stat} su un link simbolico comporta la -lettura del contenuto del medesimo e l'applicazione della funzione al file -specificato da quest'ultimo. Invece altre funzioni come quelle per cancellare -o rinominare i file operano direttamente sul link simbolico (per l'elenco vedi -\ntab). Inoltre esistono funzioni apposite, come la \texttt{readlink} e la -\texttt{lstat} per accedere alle informazioni del link invece che a quelle del -file a cui esso fa riferimento. -Le funzioni per operare sui link simbolici sono le seguenti, esse sono tutte -dichiarate nell'header file \texttt{unistd.h}. +\subsection{Le funzioni \texttt{chmod} e \texttt{fchmod}} +\label{sec:filedir_chmod} -\begin{prototype}{unistd.h} -{int symlink(const char * oldname, const char * newname)} - Crea un nuovo link simbolico al file indicato da \texttt{oldname} dandogli - nome \texttt{newname}. - - La funzione restituisce zero in caso di successo e -1 per un errore, in caso - di errore. La variabile \texttt{errno} viene settata secondo i codici di - errore standard di accesso ai files (trattati in dettaglio in - \secref{sec:filedir_access_control}) ai quali si aggiungono i seguenti: - \begin{errlist} - \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di - già. - \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è - su un filesystem montato readonly. - \item \texttt{ENOSPC} La directory o il filesystem in cui si vuole creare il - link è piena e non c'è ulteriore spazio disponibile. - \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione di - \texttt{oldname} o di \texttt{newname}. - \end{errlist} -\end{prototype} +\subsection{Le funzioni \texttt{chown}, \texttt{fchown} e \texttt{lchown}} +\label{sec:filedir_chown} -Dato che la funzione \texttt{open} segue i link simbolici, è necessaria usare -un'altra funzione quando si vuole leggere il contenuto di un link simbolico, -questa funzione è la: -\begin{prototype}{unistd.h} -{int readlink(const char * path, char * buff, size\_t size)} - Legge il contenuto del link simbolico indicato da \texttt{path} nel buffer - \texttt{buff} di dimensione \texttt{size}. Non chiude la stringa con un - carattere nullo e la tronca a \texttt{size} nel caso il buffer sia troppo - piccolo per contenerla. - - La funzione restituisce il numero di caratteri letti dentro \texttt{buff} o - -1 per un errore, in caso di errore. La variabile \texttt{errno} viene - settata secondo i codici di errore: - \begin{errlist} - \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di - già. - \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è - su un filesystem montato readonly. - \item \texttt{ENOSPC} La directory o il filesystem in cui si vuole creare il - link è piena e non c'è ulteriore spazio disponibile. - \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione di - \texttt{oldname} o di \texttt{newname}. - \end{errlist} -\end{prototype} -In \ntab\ si è riportato un elenco dei comportamenti delle varie funzioni che -operano sui file rispetto ai link simbolici; specificando quali seguono il -link simbolico e quali possono operare direttamente sul suo contenuto. -\begin{table}[htb] - \centering - \footnotesize - \begin{tabular}[c]{|l|c|c|} - \hline - Funzione & Segue il link & Non segue il link \\ - \hline - \hline - \func{access} & $\bullet$ & \\ - \func{chdir} & $\bullet$ & \\ - \func{chmod} & $\bullet$ & \\ - \func{chown} & & $\bullet$ \\ - \func{creat} & $\bullet$ & \\ - \func{exec} & $\bullet$ & \\ - \func{lchown} & $\bullet$ & $\bullet$ \\ - \func{link} & & \\ - \func{lstat} & & $\bullet$ \\ - \func{mkdir} & $\bullet$ & \\ - \func{mkfifo} & $\bullet$ & \\ - \func{mknod} & $\bullet$ & \\ - \func{open} & $\bullet$ & \\ - \func{opendir} & $\bullet$ & \\ - \func{pathconf} & $\bullet$ & \\ - \func{readlink} & & $\bullet$ \\ - \func{remove} & & $\bullet$ \\ - \func{rename} & & $\bullet$ \\ - \func{stat} & $\bullet$ & \\ - \func{truncate} & $\bullet$ & \\ - \func{unlink} & & $\bullet$ \\ - \hline - \end{tabular} - \caption{Uso dei link simbolici da parte di alcune funzioni.} - \label{tab:filedir_symb_effect} -\end{table} -si noti che non si è specificato il comportamento delle funzioni che operano -con i file descriptor, in quanto la gestione del link simbolico viene in -genere effttuata dalla funzione che restituisce il file descriptor -(normalmente la \func{open}). - -\begin{figure}[htb] - \centering - \includegraphics[width=5cm]{img/link_loop.eps} - \caption{Esempio di loop nel filesystem creato con un link simbolico.} - \label{fig:filedir_link_loop} -\end{figure} - -Un caso comune che si può avere con i link simbolici è la creazione dei -cosiddetti \textit{loop}. La situazione è illustrata in \curfig, che riporta -la struttura della directory \file{/boot}. Come si vede si è creato al suo -interno un link simbolico che punta di nuovo a \file{/boot}\footnote{Questo - tipo di loop è stato effettuato per poter permettere a \cmd{grub} (un - bootloader estremamente avanzato in grado di accedere direttamente - attraverso vari filesystem al file da lanciare come sistema operativo) di - vedere i file in questa directory, che è montata su una partizione separata - (e che grub vedrebbe come radice), con lo stesso path con cui verrebbero - visti dal sistema operativo.}. - -Questo può causare problemi per tutti quei programmi che effettuassero uno -scan di una directory senza tener conto dei link simbolici, in quel caso -infatti il loop nella directory - -Un secondo punto da tenere presente è che un link simbolico può essere fatto -anche ad un file che non esiste; ad esempio possiamo creare un file temporaneo -nella nostra directory con un link del tipo: -\begin{verbatim} -$ln -s /tmp/tmp_file temporaneo -\end{verbatim}%$ -ma anche se \file{/tmp/tmp_file} non esiste. Aprendo in scrittura -\file{temporaneo} questo verrà scritto; ma se cercassimo di accederlo in sola -lettura (ad esempio con \cmd{cat}) otterremmo: -\begin{verbatim} -$ cat prova -cat: prova: No such file or directory -\end{verbatim}%$ -con un errore che sembra sbagliato, dato \cmd{ls} ci mostrerebbe l'esistenza -di \file{temporaneo}. - - -\subsection{Le funzioni \texttt{mkdir} e \texttt{rmdir}} -\label{sec:filedir_dir_creat_rem} - -Per creare una nuova directory si può usare la seguente funzione, omonima -dell'analogo comando di shell \texttt{mkdir}; per accedere ai tipi usati -programma deve includere il file \texttt{sys/types.h}. - -\begin{prototype}{sys/stat.h} -{int mkdir (const char * dirname, mode\_t mode)} - Questa funzione crea una nuova directory vuota con il nome indicato da - \texttt{dirname}, assegnandole i permessi indicati da \texttt{mode}. Il nome - può essere indicato con il pathname assoluto o relativo. - - La funzione restituisce zero in caso di successo e -1 per un errore, in caso - di errore \texttt{errno} viene settata secondo i codici di errore standard - di accesso ai files (trattati in dettaglio in - \secref{sec:filedir_access_control}) ai quali si aggiungono i seguenti: - \begin{errlist} - \item \texttt{EACCESS} - Non c'è il permesso di scrittura per la directory in cui si vuole inserire - la nuova directory. - \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di già. - \item \texttt{EMLINK} La directory in cui si vuole creare la nuova directory - contiene troppi file. Sotto Linux questo normalmente non avviene perché il - filesystem standard consente la creazione di un numero di file maggiore di - quelli che possono essere contenuti nell'hard-disk, ma potendo avere a che - fare anche con filesystem di altri sistemi questo errore può presentarsi. - \item \texttt{ENOSPC} Non c'è abbastanza spazio sul file system per creare - la nuova directory. - \item \texttt{EROFS} La directory su cui si vuole inserire la nuova - directory è su un filesystem montato readonly. - \end{errlist} -\end{prototype} - - -\subsection{Accesso alle directory} -\label{sec:filedir_dir_read} - -Benché le directory siano oggetti del filesystem come tutti gli altri non ha -ovviamente senso aprirle come fossero dei file di dati. Può però essere utile -poterne leggere il contenuto ad esempio per fare la lista dei file che esse -contengono o ricerche sui medesimi. - -Per accedere al contenuto delle directory si usano i cosiddetti -\textit{directory streams} (chiamati così per l'analogia con i file stream); -la funzione \texttt{opendir} apre uno di questi stream e la funzione -\texttt{readdir} legge il contenuto della directory, i cui elementi sono le -\textit{directory entries} (da distinguersi da quelle della cache di cui -parlavamo in \secref{sec:fileintr_vfs}) in una opportuna struttura -\texttt{struct dirent}. +%La struttura fondamentale che contiene i dati essenziali relativi ai file è il +%cosiddetto \textit{inode}; questo conterrà informazioni come il +%tipo di file (file di dispositivo, directory, file di dati, per un elenco +%completo vedi \ntab), i permessi (vedi \secref{sec:file_perms}), le date (vedi +%\secref{sec:file_times}). -\subsection{La directory di lavoro} -\label{sec:filedir_work_dir} - -A ciascun processo è associato ad una directory nel filesystem che è chiamata -directory corrente o directory di lavoro (\textit{current working directory}) -che è quella a cui si fa riferimento quando un filename è espresso in forma -relativa (relativa appunto a questa directory). - -Quando un utente effettua il login questa directory viene settata alla -cosiddetta \textit{home directory} del suo account, il comando \texttt{cd} -della shell consente di cambiarla a piacere, spostandosi da una directory ad -un'altra. Siccome la directory corrente resta la stessa quando viene creato -un processo figlio, la directory corrente della shell diventa anche la -directory corrente di qualunque comando da essa lanciato. - -Le funzioni qui descritte servono esaminare e cambiare la directory di lavoro -corrente. - -\begin{prototype}{unistd.h}{char * getcwd (char * buffer, size\_t size)} - Restituisce il filename completo della directory di lavoro corrente nella - stringa puntata da \texttt{buffer}, che deve essere precedentemente - allocata, per una dimensione massima di \texttt{size}. Si può anche - specificare un puntatore nullo come \textit{buffer}, nel qual caso la - stringa sarà allocata automaticamente per una dimensione pari a - \texttt{size} qualora questa sia diversa da zero, o della lunghezza esatta - del pathname altrimenti. In questo caso si deve ricordare di disallocare la - stringa una volta cessato il suo utilizzo. - - La funzione restituisce il puntatore \texttt{buffer} se riesce, - \texttt{NULL} se fallisce, in quest'ultimo caso la variabile - \texttt{errno} è settata con i seguenti codici di errore: - \begin{errlist} - \item \texttt{EINVAL} L'argomento \texttt{size} è zero e \texttt{buffer} non - è nullo. - \item \texttt{ERANGE} L'argomento \texttt{size} è più piccolo della - lunghezza del pathname. - \item \texttt{EACCESS} Manca il permesso di lettura o di ricerca su uno dei - componenti del pathname (cioè su una delle directory superiori alla - corrente). - \end{errlist} -\end{prototype} - -Di questa funzione esiste una versione \texttt{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 \texttt{PATH\_MAX} (di solito 256 bytes, vedi -\secref{sec:xxx_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. - -Una seconda funzione simile è \texttt{char * get\_current\_dir\_name(void)} -che è sostanzialmente equivalente ad una \texttt{getcwd(NULL, 0)}, con la sola -differenza che essa ritorna il valore della variabile di ambiente -\texttt{PWD}, che essendo costruita dalla shell può contenere anche dei -riferimenti simbolici. - -Come già detto in unix anche le directory sono file, è possibile pertanto -riferirsi ad esse tramite il file descriptor dell'interfaccia a basso livello, -e non solo tramite il filename; per questo motivo ci sono due diverse funzioni -per cambiare directory di lavoro. - -\begin{prototype}{unistd.h}{int chdir (const char * pathname)} - Come dice il nome (che significa \textit{change directory}) questa funzione - serve a cambiare la directory di lavoro a quella specificata dal pathname - contenuto nella stringa \texttt{pathname}. -\end{prototype} - -\begin{prototype}{unistd.h}{int fchdir (int filedes)} - Analoga alla precedente, ma usa un file descriptor invece del pathname. - - Entrambe le funzioni restituiscono zero in caso di successo e -1 per un - errore, in caso di errore \texttt{errno} viene settata secondo i codici di - errore standard di accesso ai files (trattati in dettaglio in - \secref{sec:filedir_access_control}) ai quali si aggiunge il codice - \texttt{ENOTDIR} nel caso il \texttt{filename} indichi un file che non sia - una directory. -\end{prototype} \section{La manipolazione delle caratteristiche dei files} @@ -583,7 +317,7 @@ riservati per estensioni come tempi pi \footnotesize \centering \begin{minipage}[c]{15cm} - \begin{lstlisting}[]{} + \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{} struct stat { dev_t st_dev; /* device */ ino_t st_ino; /* inode */ @@ -619,10 +353,11 @@ Come riportato in \tabref{tab:fileintr_file_types} in Linux oltre ai file e alle directory esistono vari altri oggetti che possono stare su un filesystem; il tipo di file è ritornato dalla \texttt{stat} nel campo \texttt{st\_mode}. -Dato che il valore numerico può variare a seconda delle implementazioni lo +Dato che il valore numerico può variare a seconda delle implementazioni, lo standard POSIX definisce un insieme di macro per verificare il tipo di files, -queste venfono usate anche da Linux che supporta pure le estensioni per link -simbolici e socket definite da BDS, l'elenco è riportato in \ntab: +queste vengono usate anche da Linux che supporta pure le estensioni per link +simbolici e socket definite da BSD, l'elenco completo di tutte le macro +definite in GNU/Linux è riportato in \ntab: \begin{table}[htb] \centering \footnotesize @@ -631,7 +366,7 @@ simbolici e socket definite da BDS, l'elenco Macro & Tipo del file \\ \hline \hline - \macro{S\_ISREG(m)} & file normale \\ + \macro{S\_ISREG(m)} & file regolare \\ \macro{S\_ISDIR(m)} & directory \\ \macro{S\_ISCHR(m)} & device a caraetteri \\ \macro{S\_ISBLK(m)} & device a blocchi\\ @@ -656,34 +391,37 @@ per questo sempre in \texttt{sys/stat.h} sono definiti i flag riportati in Flag & Valore & Significato \\ \hline \hline - \macro{S\_IFMT} & 0170000 & bitmask for the file type bitfields \\ - \macro{S\_IFSOCK} & 0140000 & socket \\ - \macro{S\_IFLNK} & 0120000 & symbolic link \\ - \macro{S\_IFREG} & 0100000 & regular file \\ - \macro{S\_IFBLK} & 0060000 & block device \\ - \macro{S\_IFDIR} & 0040000 & directory \\ - \macro{S\_IFCHR} & 0020000 & character device \\ - \macro{S\_IFIFO} & 0010000 & fifo \\ - \macro{S\_ISUID} & 0004000 & set UID bit \\ - \macro{S\_ISGID} & 0002000 & set GID bit (see below) \\ - \macro{S\_ISVTX} & 0001000 & sticky bit (see below) \\ - \macro{S\_IRWXU} & 00700 & mask for file owner permissions \\ - \macro{S\_IRUSR} & 00400 & owner has read permission \\ - \macro{S\_IWUSR} & 00200 & owner has write permission \\ - \macro{S\_IXUSR} & 00100 & owner has execute permission \\ - \macro{S\_IRWXG} & 00070 & mask for group permissions \\ - \macro{S\_IRGRP} & 00040 & group has read permission \\ - \macro{S\_IWGRP} & 00020 & group has write permission \\ - \macro{S\_IXGRP} & 00010 & group has execute permission \\ - \macro{S\_IRWXO} & 00007 & mask for permissions for others (not in - group) \\ - \macro{S\_IROTH} & 00004 & others have read permission \\ - \macro{S\_IWOTH} & 00002 & others have write permisson \\ - \macro{S\_IXOTH} & 00001 & others have execute permission \\ + \macro{S\_IFMT} & 0170000 & bitmask per i bit del tipo di file \\ + \macro{S\_IFSOCK} & 0140000 & socket \\ + \macro{S\_IFLNK} & 0120000 & link simbolico \\ + \macro{S\_IFREG} & 0100000 & file regolare \\ + \macro{S\_IFBLK} & 0060000 & device a blocchi \\ + \macro{S\_IFDIR} & 0040000 & directory \\ + \macro{S\_IFCHR} & 0020000 & device a caratteri \\ + \macro{S\_IFIFO} & 0010000 & fifo \\ + \hline + \macro{S\_ISUID} & 0004000 & set UID bit \\ + \macro{S\_ISGID} & 0002000 & set GID bit \\ + \macro{S\_ISVTX} & 0001000 & sticky bit \\ + \hline + \macro{S\_IRWXU} & 00700 & bitmask per i permessi del proprietario \\ + \macro{S\_IRUSR} & 00400 & il proprietario ha permesso di lettura \\ + \macro{S\_IWUSR} & 00200 & il proprietario ha permesso di scrittura \\ + \macro{S\_IXUSR} & 00100 & il proprietario ha permesso di esecuzione\\ + \hline + \macro{S\_IRWXG} & 00070 & bitmask per i permessi del gruppo \\ + \macro{S\_IRGRP} & 00040 & il gruppo ha permesso di lettura \\ + \macro{S\_IWGRP} & 00020 & il gruppo ha permesso di scrittura \\ + \macro{S\_IXGRP} & 00010 & il gruppo ha permesso di esecuzione \\ + \hline + \macro{S\_IRWXO} & 00007 & bitmask per i permessi di tutti gli altri\\ + \macro{S\_IROTH} & 00004 & gli altri hanno permesso di lettura \\ + \macro{S\_IWOTH} & 00002 & gli altri hanno permesso di esecuzione \\ + \macro{S\_IXOTH} & 00001 & gli altri hanno permesso di esecuzione \\ \hline \end{tabular} - \caption{Flag per il campo \var{st\_mode} (definite in - \texttt{sys/stat.h})} + \caption{Costanti per l'identificazione dei vari bit che compongono il campo + \var{st\_mode} (definite in \texttt{sys/stat.h})} \label{tab:filedir_file_mode_flags} \end{table} @@ -692,8 +430,8 @@ memorizzato il tipo di files, mentre gli altri possono essere usati per effettuare delle selezioni sul tipo di file voluto, combinando opportunamente i vari flag; ad esempio se si volesse controllare se un file è una directory o un file ordinario si potrebbe definire la condizione: -\begin{lstlisting} -#define IS_FILE_DIR(x) ( ((x) & S_IFMT) & (S_IFDIR | S_IFREG) ) +\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{} +#define IS_FILE_DIR(x) (((x) & S_IFMT) & (S_IFDIR | S_IFREG)) \end{lstlisting} in cui prima si estraggono da \var{st\_mode} i bit relativi al tipo di file e poi si effettua il confronto con la combinazione di tipi scelta. @@ -755,135 +493,676 @@ le due funzioni: \item \texttt{ENOENT} il file non esiste. \item \texttt{ENAMETOOLONG} il filename è troppo lungo. \end{errlist} -\end{functions} - -Se il file è più lungo della lunghezza specificata i dati in eccesso saranno -perduti; il comportamento in caso di lunghezza inferiore non è specificato e -dipende dall'implementazione: il file può essere lasciato invariato o esteso -fino alla lunghezza scelta; in quest'ultimo caso lo spazio viene riempito con -zeri (e in genere si ha la creazione di un hole nel file). - -\subsection{I tempi dei file} -\label{sec:filedir_file_times} - -Il sistema mantiene per ciascun file tre tempi. Questi sono registrati -nell'inode insieme agli altri attibuti del file e possono essere letti tramite -la funzione \func{stat}, che li restituisce attraverso tre campi della -struttura in \figref{fig:filedir_stat_struct} il cui signifato è riportato -nello schema in \ntab: +\end{functions} + +Se il file è più lungo della lunghezza specificata i dati in eccesso saranno +perduti; il comportamento in caso di lunghezza inferiore non è specificato e +dipende dall'implementazione: il file può essere lasciato invariato o esteso +fino alla lunghezza scelta; in quest'ultimo caso lo spazio viene riempito con +zeri (e in genere si ha la creazione di un hole nel file). + + +\subsection{I tempi dei file} +\label{sec:filedir_file_times} + +Il sistema mantiene per ciascun file tre tempi. Questi sono registrati +nell'inode insieme agli altri attibuti del file e possono essere letti tramite +la funzione \func{stat}, che li restituisce attraverso tre campi della +struttura in \figref{fig:filedir_stat_struct}. Il significato di detti tempi e +dei relativi campi è riportato nello schema in \ntab: + +\begin{table}[htb] + \centering + \begin{tabular}[c]{|c|l|l|c|} + \hline + Membro & Significato & Funzione&opzione \\ + \hline + \hline + \var{st\_atime}& ultimo accesso ai dati del file &\func{read}& \cmd{-u}\\ + \var{st\_mtime}& ultima modifica ai dati del file &\func{write}& default\\ + \var{st\_ctime}& ultima modifica ai dati dell'inode&\func{chmod}, + \func{utime} & \cmd{-c} \\ + \hline + \end{tabular} + \caption{I tre tempi associati a ciascun file} + \label{tab:filedir_file_times} +\end{table} + +Il primo punto da tenere presente è la differenza fra il cosiddetto tempo di +modifica (il \textit{modification time} \var{st\_mtime}) e il tempo di +cambiamento di stato (il \textit{chage time} \var{st\_ctime}). Il primo +infatti fa riferimento ad una modifica del contenuto di un file, mentre il +secondo ad una modifica dell'inode; siccome esistono molte operazioni (come la +funzione \func{link} e molte altre che vedremo in seguito) che modificano solo +le informazioni contenute nell'inode senza toccare il file, diventa necessario +l'utilizzo di un altro tempo. + +Il sistema non tiene conto dell'ultimo accesso all'inode, pertanto funzioni +come \func{access} o \func{stat} non hanno alcuna influenza sui tre tempi. Il +tempo di ultimo accesso viene di solito usato per cancellare i file che non +servono più dopo un certo lasso di tempo (ad esempio \cmd{leafnode} cancella i +vecchi articoli sulla base di questo tempo). + +Il tempo di ultima modifica invece viene usato da \cmd{make} per decidere +quali file necessitano di essere ricompilati o (talvolta insieme anche al +tempo di cambiamento di stato) per decidere quali file devono essere +archiviati per il backup. Il comando \cmd{ls} (quando usato con le opzioni +\cmd{-l} o \cmd{-t}) mostra i tempi dei file secondo lo schema riportato +nell'ultima colonna di \curtab. + +L'effetto delle varie funzioni di manipolazione dei file sui tempi è +illustrato in \ntab. Si sono riportati gli effetti sia per il file a cui si fa +riferimento, sia per la directory che lo contiene; questi ultimi possono +essere capiti se si tiene conto di quanto già detto, e cioè che anche le +directory sono files, che il sistema tratta in maniera del tutto analoga agli +altri. + +Per questo motivo tutte le volte che compiremo una operazione su un file che +comporta una modifica della sua directory entry, andremo anche a scrivere +sulla directory che lo contiene cambiandone il tempo di modifica. Un esempio +di questo può essere la cancellazione di un file, mentre leggere o scrivere o +cambiarne i permessi ha effetti solo sui tempi del file. + +\begin{table}[htb] + \centering + \footnotesize + \begin{tabular}[c]{|l|c|c|c|c|c|c|l|} + \hline + \multicolumn{1}{|c|}{Funzione} + &\multicolumn{3}{p{2cm}}{File o directory di riferimento} + &\multicolumn{3}{p{2cm}}{Directory genitrice del riferimento} + &\multicolumn{1}{|c|}{Note} \\ + \cline{2-7} + & \textsl{(a)} & \textsl{(m)}& \textsl{(c)} + & \textsl{(a)} & \textsl{(m)}& \textsl{(c)}& \\ + \hline + \hline + \func{chmod}, \func{fchmod} + & & &$\bullet$& & & & \\ + \func{chown}, \func{fchown} + & & &$\bullet$& & & & \\ + \func{creat} + &$\bullet$&$\bullet$&$\bullet$& &$\bullet$&$\bullet$& con + \macro{O\_CREATE} \\ \func{creat} + & &$\bullet$&$\bullet$& &$\bullet$&$\bullet$& + con \macro{O\_TRUNC} \\ \func{exec} + &$\bullet$& & & & & & \\ + \func{lchown} + & & &$\bullet$& & & & \\ + \func{link} + & & &$\bullet$& &$\bullet$&$\bullet$& \\ + \func{mkdir} + &$\bullet$&$\bullet$&$\bullet$& &$\bullet$&$\bullet$& \\ + \func{mkfifo} + &$\bullet$&$\bullet$&$\bullet$& &$\bullet$&$\bullet$& \\ + \func{open} + &$\bullet$&$\bullet$&$\bullet$& &$\bullet$&$\bullet$& con + \macro{O\_CREATE} \\ \func{open} + & &$\bullet$&$\bullet$& & & & con + \macro{O\_TRUNC} \\ \func{pipe} + &$\bullet$&$\bullet$&$\bullet$& & & & \\ + \func{read} + &$\bullet$& & & & & & \\ + \func{remove} + & & &$\bullet$& &$\bullet$&$\bullet$& using + \func{unlink}\\ \func{remove} + & & & & &$\bullet$&$\bullet$& using + \func{rmdir}\\ \func{rename} + & & &$\bullet$& &$\bullet$&$\bullet$& per entrambi + gli argomenti\\ \func{rmdir} + & & & & &$\bullet$&$\bullet$& \\ + \func{truncate}, \func{ftruncate} + & &$\bullet$&$\bullet$& & & & \\ + \func{unlink} + & & &$\bullet$& &$\bullet$&$\bullet$& \\ + \func{utime} + &$\bullet$&$\bullet$&$\bullet$& & & & \\ + \func{write} + & &$\bullet$&$\bullet$& & & & \\ + \hline + \end{tabular} + \caption{Effetti delle varie funzioni su tempi di ultimo accesso + \textsl{(a)}, ultima modifica \textsl{(m)} e ultimo cambiamento + \textsl{(c)}} + \label{tab:filedir_times_effects} +\end{table} + +Si noti infine come \var{st\_ctime} non abbia nulla a che fare con il tempo di +creazione del file, usato da molti altri sistemi operativi, che in unix non +esiste. + + +\subsection{La funzione \texttt{utime}} +\label{sec:filedir_utime} + +I tempi di ultimo accesso e modifica possono essere cambiati usando la +funzione \func{utime}, il cui prototipo è: + +\begin{prototype}{utime.h} +{int utime(const char * filename, struct utimbuf *times)} + +Cambia i tempi di ultimo accesso e modifica dell'inode specificato da +\var{filename} secondo i campi \var{actime} e \var{modtime} di \var{times}. Se +questa è \macro{NULL} allora viene usato il tempo corrente. + +La funzione restituisce zero in caso di successo e -1 in caso di errore, nel +qual caso \var{errno} è settata opportunamente. +\begin{errlist} +\item \texttt{EACCESS} non si ha il permesso di scrittura sul file. +\item \texttt{ENOENT} \var{filename} non esiste. +\end{errlist} +\end{prototype} + +La struttura \var{utimebuf} usata da \func{utime} è definita come: +\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{} +struct utimbuf { + time_t actime; /* access time */ + time_t modtime; /* modification time */ +}; +\end{lstlisting} + +L'effetto della funzione e i privilegi necessari per eseguirla dipendono da +cosa è l'argomento \var{times}; se è \textit{NULL} la funzione setta il tempo +corrente ed è sufficiente avere accesso in scrittura al file; se invece si è +specificato un valore la funzione avrà successo solo se si è proprietari del +file (o si hanno i privilegi di amministratore). + +Si tenga presente che non è comunque possibile specificare il tempo di +cambiamento di stato del file, che viene comunque cambiato dal kernel tutte le +volte che si modifica l'inode (quindi anche alla chiamata di \func{utime}). +Questo serve anche come misura di sicurezza per evitare che si possa +modificare un file nascondendo completamente le proprie tracce. In realtà la +cosa resta possibile, se si è in grado di accedere al device, scrivendo +direttamente sul disco senza passare attraverso il filesystem, ma ovviamente è +molto più complicato da realizzare. + + + + + + +\section{La manipolazione di file e directory} + +Come già accennato in \secref{sec:fileintr_filesystem} in un sistema unix-like +i file hanno delle caratteristiche specifiche dipendenti dall'architettura del +sistema, esamineremo qui allora le funzioni usate per la creazione di link +simbolici e diretti e per la gestione delle directory, approfondendo quanto +già accennato in precedenza. + + +\subsection{Le funzioni \texttt{link} e \texttt{unlink}} +\label{sec:fileintr_link} + +Una delle caratteristiche comuni a vari sistemi operativi è quella di poter +creare dei nomi fittizi (alias o collegamenti) per potersi riferire allo +stesso file accedendovi da directory diverse. Questo è possibile anche in +ambiente unix, dove tali collegamenti sono usualmente chiamati \textit{link}, +ma data la struttura del sistema ci sono due metodi sostanzialmente diversi +per fare questa operazione. + +Come spiegato in \secref{sec:fileintr_architecture} l'accesso al contenuto di +un file su disco avviene attraverso il suo inode, e il nome che si trova in +una directory è solo una etichetta associata ad un puntatore a detto inode. +Questo significa che la realizzazione di un link è immediata in quanto uno +stesso file può avere tanti nomi diversi allo stesso tempo, dati da +altrettante diverse associazioni allo stesso inode; si noti poi che nessuno di +questi nomi viene ad assumere una particolare preferenza rispetto agli altri. + +Per aggiungere un nome ad un inode si utilizza la funzione \texttt{link}; si +suole chiamare questo tipo di associazione un collegamento diretto (o +\textit{hard link}). Il prototipo della funzione e le sue caratteristiche +principali, come risultano dalla man page, sono le seguenti: +\begin{prototype}{unistd.h} +{int link(const char * oldpath, const char * newpath)} + Crea un nuovo collegamento diretto al file indicato da \texttt{oldpath} + dandogli nome \texttt{newpath}. + + La funzione restituisce zero in caso di successo e -1 in caso di errore. La + variabile \texttt{errno} viene settata opportunamente, i principali codici + di errore sono: + \begin{errlist} + \item \texttt{EXDEV} \texttt{oldpath} e \texttt{newpath} non sono sullo + stesso filesystem. + \item \texttt{EPERM} il filesystem che contiene \texttt{oldpath} e + \texttt{newpath} non supporta i link diretti o è una directory. + \item \texttt{EEXIST} un file (o una directory) con quel nome esiste di + già. + \item \texttt{EMLINK} ci sono troppi link al file \texttt{oldpath} (il + numero massimo è specificato dalla variabile \texttt{LINK\_MAX}, vedi + \secref{sec:xxx_limits}). + \end{errlist} + +\end{prototype} + +La creazione di un nuovo collegamento diretto non copia il contenuto del file, +ma si limita ad aumentare di uno il numero di referenze al file (come si può +controllare con il campo \var{st\_nlink} di \var{stat}) aggiungendo il nuovo +nome ai precedenti. Si noti che uno stesso file può essere così richiamato in +diverse directory. + +Per quanto dicevamo in \secref{sec:fileintr_filesystem} la creazione del +collegamento diretto è possibile solo se entrambi i pathname sono nello stesso +filesystem; inoltre il filesystem deve supportare i collegamenti diretti (non è +il caso ad esempio del filesystem \texttt{vfat} di windows). + +La funzione opera sui file ordinari, come sugli altri oggetti del filesystem, +in alcuni filesystem solo l'amministratore è in grado di creare un +collegamento diretto ad un'altra directory, questo lo si fa perché in questo +caso è possibile creare dei circoli nel filesystem (vedi +\secref{sec:fileintr_symlink}) che molti programmi non sono in grado di +gestire e la cui rimozione diventa estremamente complicata (in genere occorre +far girare il programma \texttt{fsck} per riparare il filesystem); data la sua +pericolosità in generale nei filesystem usati in Linux questa caratteristica è +stata disabilitata, e la funzione restituisce l'errore \texttt{EPERM}. + +La rimozione di un file (o più precisamente della voce che lo referenzia) si +effettua con la funzione \texttt{unlink}; il suo prototipo è il seguente: + +\begin{prototype}{unistd.h}{int unlink(const char * pathname)} + Cancella il nome specificato dal pathname nella relativa directory e + decrementa il numero di riferimenti nel relativo inode. Nel caso di link + simbolico cancella il link simbolico; nel caso di socket, fifo o file di + dispositivo rimuove il nome, ma come per i file i processi che hanno aperto + uno di questi oggetti possono continuare ad utilizzarlo. + + La funzione restituisce zero in caso di successo e -1 per un errore, nel + qual caso il file non viene toccato. La variabile \texttt{errno} viene + settata secondo i seguenti codici di errore: + \begin{errlist} + \item \texttt{EISDIR} \var{pathname} si riferisce ad una directory + (valore specifico ritornato da linux che non consente l'uso di + \texttt{unlink} con le directory, e non conforme allo standard POSIX, che + prescrive invece l'uso di \texttt{EPERM} in caso l'operazione non sia + consnetita o il processo non abbia privilegi sufficienti). + \item \texttt{EROFS} \var{pathname} è su un filesystem montato in sola + lettura. + \item \texttt{EISDIR} \var{pathname} fa riferimento a una directory. + \end{errlist} +\end{prototype} + +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 +il diritto di esecuzione sulla directory che la contiene (torneremo in +dettaglio sui permessi e gli attributi fra poco), se inoltre lo +\textit{sticky} bit è settato occorrerà anche essere proprietari del file o +proprietari della directory (o root, per cui nessuna delle restrizioni è +applicata). + +Una delle caratteristiche di queste funzioni è che la creazione/rimozione +della nome dalla directory e l'incremento/decremento del numero di riferimenti +nell'inode deve essere una operazione atomica (cioè non interrompibile da +altri) processi, per questo entrambe queste funzioni sono realizzate tramite +una singola system call. + +Si ricordi infine che il file non viene eliminato dal disco fintanto che tutti +i riferimenti ad esso sono stati cancellati, solo quando il \textit{link + count} mantenuto nell'inode diventa zero lo spazio occupato viene rimosso. A +questo però si aggiunge una altra condizione, e cioè che non ci siano processi +che abbiano detto file aperto. Come accennato questa proprietà viene spesso +usata per essere sicuri di non lasciare file temporanei su disco in caso di +crash dei programmi; la tecnica è quella di aprire il file e chiamare +\texttt{unlink} subito dopo. + +\subsection{Le funzioni \texttt{remove} e \texttt{rename}} +\label{sec:fileintr_remove} + +Al contrario di quanto avviene con altri unix in Linux non è possibile usare +\texttt{unlink} sulle directory, per cancellare una directory si può usare la +funzione \texttt{rmdir} (vedi \secref{sec:filedir_dir_creat_rem}), oppure la +funzione \texttt{remove}. Questa è la funzione prevista dallo standard ANSI C +per cancellare un file o una directory (e funziona anche per i sistemi che non +supportano i link diretti), che per i file è identica alla \texttt{unlink} e +per le directory è identica alla \texttt{rmdir}: + +\begin{prototype}{stdio.h}{int remove(const char *pathname)} + Cancella un nome dal filesystem. Usa \texttt{unlink} per i file e + \texttt{rmdir} per le directory. + + La funzione restituisce zero in caso di successo e -1 per un errore, nel + qual caso il file non viene toccato. Per i codici di errori vedi quanto + riportato nella descrizione di \texttt{unlink} e \texttt{rmdir}. +\end{prototype} + +Per cambiare nome ad un file si usa invece la funzione \texttt{rename}, il +vantaggio nell'uso di questa funzione al posto della chiamata successiva di +\texttt{unlink} e \texttt{link} è che l'operazione è eseguita atomicamente, in +questo modo non c'è la possibilità che un processo che cerchi di accedere al +nuovo nome dopo che il vecchio è stato cambiato lo trovi mancante. + +\begin{prototype}{stdio.h} +{int rename(const char *oldpath, const char *newpath)} + Rinomina un file, spostandolo fra directory diverse quando richiesto. + + La funzione restituisce zero in caso di successo e -1 per un errore, nel + qual caso il file non viene toccato. La variabile \texttt{errno} viene + settata secondo i seguenti codici di errore: + \begin{errlist} + \item \texttt{EISDIR} \texttt{newpath} è una directory già esistente mentre + \texttt{oldpath} non è una directory. + \item \texttt{EXDEV} \texttt{oldpath} e \texttt{newpath} non sono sullo + stesso filesystem. + \item \texttt{ENOTEMPTY} \texttt{newpath} è una directory già esistente e + non vuota. + \item \texttt{EBUSY} o \texttt{oldpath} o \texttt{newpath} sono in uso da + parte di qualche processo (come directory di lavoro o come root) o del + sistema (come mount point). + \item \texttt{EINVAL} \texttt{newpath} contiene un prefisso di + \texttt{oldpath} o più in generale si è cercato di creare una directory + come sottodirectory di se stessa. + \item \texttt{EMLINK} \texttt{oldpath} ha già il massimo numero di link + consentiti o è una directory e la directory che contiene \texttt{newpath} + ha già il massimo numero di link. + \item \texttt{ENOTDIR} Uno dei componenti dei pathname non è una directory + o\texttt{oldpath} è una directory e \texttt{newpath} esiste e non è una + directory. + \item \texttt{EFAULT} o \texttt{oldpath} o \texttt{newpath} è fuori dello + spazio di indirizzi del processo. + \item \texttt{EACCESS} Non c'è il permesso di scrittura per la directory in + cui si vuole creare il nuovo link o una delle directory del pathname non + consente la ricerca (permesso di esecuzione). + \item \texttt{EPERM} le directory contenenti \texttt{oldpath} o + \texttt{newpath} hanno lo sticky bit attivo e i permessi del processo non + consentono rispettivamente la cancellazione e la creazione del file, o il + filesystem non supporta i link. + \item \texttt{ENAMETOOLONG} uno dei pathname è troppo lungo. + \item \texttt{ENOENT} Uno dei componenti del pathname non esiste o è un link + simbolico spezzato. + \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a + completare l'operazione. + \item \texttt{EROFS} I file sono su un filesystem montato in sola lettura. + \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione del + pathname. + \item \texttt{ENOSPC} Il device di destinazione non ha più spazio per la + nuova voce. + \end{errlist} +\end{prototype} + +\subsection{I link simbolici} +\label{sec:fileintr_symlink} + +Siccome la funzione \texttt{link} crea riferimenti agli inodes, essa può +funzionare soltanto per file che risiedono sullo stesso filesystem, dato che +in questo caso è garantita l'unicità dell'inode, e solo per un filesystem di +tipo unix. Inoltre in Linux non è consentito eseguire un link diretto ad una +directory. + +Per ovviare a queste limitazioni i sistemi unix supportano un'altra forma di +link (i cosiddetti \textit{soft link} o \textit{symbolic link}), che sono, +come avviene in altri sistemi operativi, dei file che contengono il +semplicemente il riferimento ad un altro file (o directory). In questo modo è +possibile effettuare link anche attraverso filesystem diversi e a directory, e +pure a file che non esistono ancora. + +Il sistema funziona in quanto i link simbolici sono contrassegnati come tali +al kernel (analogamente a quanto avviene per le directory) per cui la chiamata +ad una \texttt{open} o una \texttt{stat} su un link simbolico comporta la +lettura del contenuto del medesimo e l'applicazione della funzione al file +specificato da quest'ultimo. Invece altre funzioni come quelle per cancellare +o rinominare i file operano direttamente sul link simbolico (per l'elenco vedi +\ntab). Inoltre esistono funzioni apposite, come la \texttt{readlink} e la +\texttt{lstat} per accedere alle informazioni del link invece che a quelle del +file a cui esso fa riferimento. + +Le funzioni per operare sui link simbolici sono le seguenti, esse sono tutte +dichiarate nell'header file \texttt{unistd.h}. + +\begin{prototype}{unistd.h} +{int symlink(const char * oldname, const char * newname)} + Crea un nuovo link simbolico al file indicato da \texttt{oldname} dandogli + nome \texttt{newname}. + + La funzione restituisce zero in caso di successo e -1 per un errore, in caso + di errore. La variabile \texttt{errno} viene settata secondo i codici di + errore standard di accesso ai files (trattati in dettaglio in + \secref{sec:filedir_access_control}) ai quali si aggiungono i seguenti: + \begin{errlist} + \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di + già. + \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è + su un filesystem montato readonly. + \item \texttt{ENOSPC} La directory o il filesystem in cui si vuole creare il + link è piena e non c'è ulteriore spazio disponibile. + \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione di + \texttt{oldname} o di \texttt{newname}. + \end{errlist} +\end{prototype} + +Dato che la funzione \texttt{open} segue i link simbolici, è necessaria usare +un'altra funzione quando si vuole leggere il contenuto di un link simbolico, +questa funzione è la: + +\begin{prototype}{unistd.h} +{int readlink(const char * path, char * buff, size\_t size)} + Legge il contenuto del link simbolico indicato da \texttt{path} nel buffer + \texttt{buff} di dimensione \texttt{size}. Non chiude la stringa con un + carattere nullo e la tronca a \texttt{size} nel caso il buffer sia troppo + piccolo per contenerla. + + La funzione restituisce il numero di caratteri letti dentro \texttt{buff} o + -1 per un errore, in caso di errore. La variabile \texttt{errno} viene + settata secondo i codici di errore: + \begin{errlist} + \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di + già. + \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è + su un filesystem montato readonly. + \item \texttt{ENOSPC} La directory o il filesystem in cui si vuole creare il + link è piena e non c'è ulteriore spazio disponibile. + \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione di + \texttt{oldname} o di \texttt{newname}. + \end{errlist} +\end{prototype} +In \ntab\ si è riportato un elenco dei comportamenti delle varie funzioni che +operano sui file rispetto ai link simbolici; specificando quali seguono il +link simbolico e quali possono operare direttamente sul suo contenuto. \begin{table}[htb] \centering - \begin{tabular}[c]{|c|l|l|c|} - \var{st\_atime}& ultimo accesso ai dati del file &\func{read}& \cmd{-u}\\ - \var{st\_mtime}& ultima modifica ai dati del file &\func{write}& default\\ - \var{st\_ctime}& ultima modifica ai dati dell'inode&\func{chmod}, - \func{utime} & \cmd{-c} \\ + \footnotesize + \begin{tabular}[c]{|l|c|c|} + \hline + Funzione & Segue il link & Non segue il link \\ + \hline + \hline + \func{access} & $\bullet$ & \\ + \func{chdir} & $\bullet$ & \\ + \func{chmod} & $\bullet$ & \\ + \func{chown} & & $\bullet$ \\ + \func{creat} & $\bullet$ & \\ + \func{exec} & $\bullet$ & \\ + \func{lchown} & $\bullet$ & $\bullet$ \\ + \func{link} & & \\ + \func{lstat} & & $\bullet$ \\ + \func{mkdir} & $\bullet$ & \\ + \func{mkfifo} & $\bullet$ & \\ + \func{mknod} & $\bullet$ & \\ + \func{open} & $\bullet$ & \\ + \func{opendir} & $\bullet$ & \\ + \func{pathconf} & $\bullet$ & \\ + \func{readlink} & & $\bullet$ \\ + \func{remove} & & $\bullet$ \\ + \func{rename} & & $\bullet$ \\ + \func{stat} & $\bullet$ & \\ + \func{truncate} & $\bullet$ & \\ + \func{unlink} & & $\bullet$ \\ + \hline \end{tabular} - \caption{I tre tempi associati a ciascun file} - \label{tab:filedir_file_times} + \caption{Uso dei link simbolici da parte di alcune funzioni.} + \label{tab:filedir_symb_effect} \end{table} +si noti che non si è specificato il comportamento delle funzioni che operano +con i file descriptor, in quanto la gestione del link simbolico viene in +genere effttuata dalla funzione che restituisce il file descriptor +(normalmente la \func{open}). +\begin{figure}[htb] + \centering + \includegraphics[width=5cm]{img/link_loop.eps} + \caption{Esempio di loop nel filesystem creato con un link simbolico.} + \label{fig:filedir_link_loop} +\end{figure} -La differenza principale di cui tenere presente è quella fra tempo di modifica -\var{st\_mtime} e tempo di cambiamento di stato \var{st\_ctime}. Il primo -infatti fa riferimento ad una modifica del contenuto di un file, mentre il -secondo ad una modifica dell'inode; siccome esistono molte operazioni (come la -funzione \func{link} e molte altre che vedremo in seguito) che modificano solo -le informazioni contenute nell'inode senza toccare il file, dato che queste -ultime sono separate dal contenuto del file diventa necessario l'utilizzo di -un altro tempo. Si noti inoltre come \var{st\_ctime} non abbia nulla a che -fare con il tempo di creazione usato da molti altri sistemi operativi, che in -unix non esiste. - - - - -\subsection{La funzione \texttt{utime}} -\label{sec:filedir_utime} - - - - -\section{Il controllo di accesso ai file} -\label{sec:filedir_access_control} - - -In unix è implementata da qualunque filesystem standard una forma elementare -(ma adatta alla maggior parte delle esigenze) di controllo di accesso ai -files. Torneremo sull'argomento in dettaglio più avanti (vedi -\secref{sec:filedir_access_control}), qui ci limitiamo ad una introduzione dei -concetti essenziali. - -Si tenga conto poi che quanto diremo è vero solo per filesystem di tipo Unix, -e non è detto che sia applicabile (ed infatti non è vero per il filesystem di -Windows) a un filesystem qualunque. Esistono inoltre estensioni che permettono -di implementare le ACL (\textit{Access Control List}) che sono un meccanismo -di controllo di accesso molto più sofisticato. +Un caso comune che si può avere con i link simbolici è la creazione dei +cosiddetti \textit{loop}. La situazione è illustrata in \curfig, che riporta +la struttura della directory \file{/boot}. Come si vede si è creato al suo +interno un link simbolico che punta di nuovo a \file{/boot}\footnote{Questo + tipo di loop è stato effettuato per poter permettere a \cmd{grub} (un + bootloader estremamente avanzato in grado di accedere direttamente + attraverso vari filesystem al file da lanciare come sistema operativo) di + vedere i file in questa directory, che è montata su una partizione separata + (e che grub vedrebbe come radice), con lo stesso path con cui verrebbero + visti dal sistema operativo.}. -Ad ogni file Unix associa sempre l'utente che ne è proprietario (il cosiddetto -\textit{owner}) e il gruppo di appartenenza, secondo il meccanismo degli uid e -gid accennato in \secref{sec:intro_multiuser}, e un insieme di permessi che -sono divisi in tre classi, e cioè attribuiti rispettivamente al proprietario, -a qualunque utente faccia parte del gruppo cui appartiene il file, e a tutti -gli altri utenti. +Questo può causare problemi per tutti quei programmi che effettuassero uno +scan di una directory senza tener conto dei link simbolici, in quel caso +infatti il loop nella directory -I permessi sono espressi da un insieme di 12 bit: di questi i nove meno -significativi sono usati a gruppi di tre per indicare i permessi base di -lettura, scrittura ed esecuzione (indicati rispettivamente con le lettere -\textit{w}, \textit{r} \textit{x}) applicabili rispettivamente al -proprietario, al gruppo, a tutti (una descrizione più dettagliata dei vari -permessi associati ai file è riportata in \secref{sec:filedir_suid_sgid}). I -restanti tre bit sono usati per indicare alcune caratteristiche più complesse -(\textit{suid}, \textit{sgid}, e \textit{sticky}) su cui pure torneremo in -seguito (vedi \secref{sec:filedir_suid_sgid} e \secref{sec:filedir_sticky}). - -Tutte queste informazioni sono tenute per ciascun file nell'inode. Quando un -processo cerca l'accesso al file esso controlla i propri uid e gid -confrontandoli con quelli del file e se l'operazione richiesta è compatibile -con i permessi associati al file essa viene eseguita, altrimenti viene -bloccata ed è restituito un errore di \texttt{EPERM}. Questo procedimento non -viene eseguito per l'amministratore di sistema (il cui uid è zero) il quale ha -pertanto accesso senza restrizione a qualunque file del sistema. +Un secondo punto da tenere presente è che un link simbolico può essere fatto +anche ad un file che non esiste; ad esempio possiamo creare un file temporaneo +nella nostra directory con un link del tipo: +\begin{verbatim} +$ln -s /tmp/tmp_file temporaneo +\end{verbatim}%$ +ma anche se \file{/tmp/tmp\_file} non esiste. Aprendo in scrittura +\file{temporaneo} questo verrà scritto; ma se cercassimo di accederlo in sola +lettura (ad esempio con \cmd{cat}) otterremmo: +\begin{verbatim} +$ cat prova +cat: prova: No such file or directory +\end{verbatim}%$ +con un errore che sembra sbagliato, dato \cmd{ls} ci mostrerebbe l'esistenza +di \file{temporaneo}. -% In realtà il procedimento è più complesso di quanto descritto in maniera -% elementare qui; inoltre ad un processo sono associati diversi identificatori, -% torneremo su questo in maggiori dettagli in seguito in \secref{sec:proc_perms}. +\subsection{Le funzioni \texttt{mkdir} e \texttt{rmdir}} +\label{sec:filedir_dir_creat_rem} +Per creare una nuova directory si può usare la seguente funzione, omonima +dell'analogo comando di shell \texttt{mkdir}; per accedere ai tipi usati +programma deve includere il file \texttt{sys/types.h}. -\subsection{I flag \texttt{suid} e \texttt{sgid}} -\label{sec:filedir_suid_sgid} +\begin{prototype}{sys/stat.h} +{int mkdir (const char * dirname, mode\_t mode)} + Questa funzione crea una nuova directory vuota con il nome indicato da + \texttt{dirname}, assegnandole i permessi indicati da \texttt{mode}. Il nome + può essere indicato con il pathname assoluto o relativo. + + La funzione restituisce zero in caso di successo e -1 per un errore, in caso + di errore \texttt{errno} viene settata secondo i codici di errore standard + di accesso ai files (trattati in dettaglio in + \secref{sec:filedir_access_control}) ai quali si aggiungono i seguenti: + \begin{errlist} + \item \texttt{EACCESS} + Non c'è il permesso di scrittura per la directory in cui si vuole inserire + la nuova directory. + \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di già. + \item \texttt{EMLINK} La directory in cui si vuole creare la nuova directory + contiene troppi file. Sotto Linux questo normalmente non avviene perché il + filesystem standard consente la creazione di un numero di file maggiore di + quelli che possono essere contenuti nell'hard-disk, ma potendo avere a che + fare anche con filesystem di altri sistemi questo errore può presentarsi. + \item \texttt{ENOSPC} Non c'è abbastanza spazio sul file system per creare + la nuova directory. + \item \texttt{EROFS} La directory su cui si vuole inserire la nuova + directory è su un filesystem montato readonly. + \end{errlist} +\end{prototype} + +\subsection{Accesso alle directory} +\label{sec:filedir_dir_read} +Benché le directory siano oggetti del filesystem come tutti gli altri non ha +ovviamente senso aprirle come fossero dei file di dati. Può però essere utile +poterne leggere il contenuto ad esempio per fare la lista dei file che esse +contengono o ricerche sui medesimi. +Per accedere al contenuto delle directory si usano i cosiddetti +\textit{directory streams} (chiamati così per l'analogia con i file stream); +la funzione \texttt{opendir} apre uno di questi stream e la funzione +\texttt{readdir} legge il contenuto della directory, i cui elementi sono le +\textit{directory entries} (da distinguersi da quelle della cache di cui +parlavamo in \secref{sec:fileintr_vfs}) in una opportuna struttura +\texttt{struct dirent}. +\subsection{La directory di lavoro} +\label{sec:filedir_work_dir} -\subsection{La titolarità di nuovi files e directory} -\label{sec:filedir_ownership} +A ciascun processo è associato ad una directory nel filesystem che è chiamata +directory corrente o directory di lavoro (\textit{current working directory}) +che è quella a cui si fa riferimento quando un filename è espresso in forma +relativa (relativa appunto a questa directory). -\subsection{La funzione \texttt{access}} -\label{sec:filedir_access} +Quando un utente effettua il login questa directory viene settata alla +cosiddetta \textit{home directory} del suo account, il comando \texttt{cd} +della shell consente di cambiarla a piacere, spostandosi da una directory ad +un'altra. Siccome la directory corrente resta la stessa quando viene creato +un processo figlio, la directory corrente della shell diventa anche la +directory corrente di qualunque comando da essa lanciato. -\subsection{La funzione \texttt{umask}} -\label{sec:filedir_umask} +Le funzioni qui descritte servono esaminare e cambiare la directory di lavoro +corrente. -\subsection{Le funzioni \texttt{chmod} e \texttt{fchmod}} -\label{sec:filedir_chmod} +\begin{prototype}{unistd.h}{char * getcwd (char * buffer, size\_t size)} + Restituisce il filename completo della directory di lavoro corrente nella + stringa puntata da \texttt{buffer}, che deve essere precedentemente + allocata, per una dimensione massima di \texttt{size}. Si può anche + specificare un puntatore nullo come \textit{buffer}, nel qual caso la + stringa sarà allocata automaticamente per una dimensione pari a + \texttt{size} qualora questa sia diversa da zero, o della lunghezza esatta + del pathname altrimenti. In questo caso si deve ricordare di disallocare la + stringa una volta cessato il suo utilizzo. + + La funzione restituisce il puntatore \texttt{buffer} se riesce, + \texttt{NULL} se fallisce, in quest'ultimo caso la variabile + \texttt{errno} è settata con i seguenti codici di errore: + \begin{errlist} + \item \texttt{EINVAL} L'argomento \texttt{size} è zero e \texttt{buffer} non + è nullo. + \item \texttt{ERANGE} L'argomento \texttt{size} è più piccolo della + lunghezza del pathname. + \item \texttt{EACCESS} Manca il permesso di lettura o di ricerca su uno dei + componenti del pathname (cioè su una delle directory superiori alla + corrente). + \end{errlist} +\end{prototype} -\subsection{Il flag \texttt{sticky}} -\label{sec:filedir_sticky} +Di questa funzione esiste una versione \texttt{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 \texttt{PATH\_MAX} (di solito 256 bytes, vedi +\secref{sec:xxx_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. -\subsection{Le funzioni \texttt{chown}, \texttt{fchown} e \texttt{lchown}} -\label{sec:filedir_chown} +Una seconda funzione simile è \texttt{char * get\_current\_dir\_name(void)} +che è sostanzialmente equivalente ad una \texttt{getcwd(NULL, 0)}, con la sola +differenza che essa ritorna il valore della variabile di ambiente +\texttt{PWD}, che essendo costruita dalla shell può contenere anche dei +riferimenti simbolici. +Come già detto in unix anche le directory sono file, è possibile pertanto +riferirsi ad esse tramite il file descriptor dell'interfaccia a basso livello, +e non solo tramite il filename; per questo motivo ci sono due diverse funzioni +per cambiare directory di lavoro. +\begin{prototype}{unistd.h}{int chdir (const char * pathname)} + Come dice il nome (che significa \textit{change directory}) questa funzione + serve a cambiare la directory di lavoro a quella specificata dal pathname + contenuto nella stringa \texttt{pathname}. +\end{prototype} + +\begin{prototype}{unistd.h}{int fchdir (int filedes)} + Analoga alla precedente, ma usa un file descriptor invece del pathname. + Entrambe le funzioni restituiscono zero in caso di successo e -1 per un + errore, in caso di errore \texttt{errno} viene settata secondo i codici di + errore standard di accesso ai files (trattati in dettaglio in + \secref{sec:filedir_access_control}) ai quali si aggiunge il codice + \texttt{ENOTDIR} nel caso il \texttt{filename} indichi un file che non sia + una directory. +\end{prototype} -%La struttura fondamentale che contiene i dati essenziali relativi ai file è il -%cosiddetto \textit{inode}; questo conterrà informazioni come il -%tipo di file (file di dispositivo, directory, file di dati, per un elenco -%completo vedi \ntab), i permessi (vedi \secref{sec:file_perms}), le date (vedi -%\secref{sec:file_times}).