X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=filedir.tex;h=b985da195568042040b81c218dc8ef698f2cae92;hp=ad974943d873267d91a6becdd49627d0e58f4fce;hb=608bbf38416013dc331e1ef2e5dfe01855b6158b;hpb=16e64b5dbce90526045cf9c0c95690c08d64a2dc diff --git a/filedir.tex b/filedir.tex index ad97494..b985da1 100644 --- a/filedir.tex +++ b/filedir.tex @@ -108,7 +108,6 @@ funzione restituisce l'errore \macro{EPERM}. La rimozione di un file (o più precisamente della voce che lo referenzia all'interno di una directory) si effettua con la funzione \func{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 @@ -167,19 +166,18 @@ processo (quando tutti i file vengono chiusi). \label{sec:file_remove} Al contrario di quanto avviene con altri unix in Linux non è possibile usare -\func{unlink} sulle directory; per cancellare una directory si può usare la +\func{unlink} sulle directory; per cancellare una directory si può usare la funzione \func{rmdir} (vedi \secref{sec:file_dir_creat_rem}), oppure la funzione \func{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 \func{unlink} e per -le directory è identica alla \func{rmdir}: - +supportano i link diretti). Per i file è identica a \func{unlink} e per le +directory è identica a \func{rmdir}: \begin{prototype}{stdio.h}{int remove(const char *pathname)} Cancella un nome dal filesystem. Usa \func{unlink} per i file e \func{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 + qual caso il file non viene toccato. Per i codici di errore vedi quanto riportato nelle descrizioni di \func{unlink} e \func{rmdir}. \end{prototype} @@ -187,7 +185,6 @@ Per cambiare nome ad un file o a una directory (che devono comunque essere nello stesso filesystem) si usa invece la funzione \func{rename}\footnote{la funzione è definita dallo standard ANSI C solo per i file, POSIX estende la funzione anche alle directory}, il cui prototipo è: - \begin{prototype}{stdio.h} {int rename(const char *oldpath, const char *newpath)} @@ -211,19 +208,12 @@ nello stesso filesystem) si usa invece la funzione \func{rename}\footnote{la \item \macro{EINVAL} \var{newpath} contiene un prefisso di \var{oldpath} o più in generale si è cercato di creare una directory come sottodirectory di se stessa. - \item \macro{EMLINK} \var{oldpath} ha già il massimo numero di link - consentiti o è una directory e la directory che contiene \var{newpath} ha - già il massimo numero di link. \item \macro{ENOTDIR} Uno dei componenti dei pathname non è una directory o \var{oldpath} è una directory e \var{newpath} esiste e non è una directory. - \item \macro{EPERM} le directory contenenti \var{oldpath} o \var{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. \end{errlist} - ed inoltre \macro{EACCESS}, \macro{ENOENT}, \macro{ENOMEM}, \macro{EROFS}, - \macro{ELOOP} e \macro{ENOSPC}. + ed inoltre \macro{EACCESS}, \macro{EPERM}, \macro{EMLINK}, \macro{ENOENT}, + \macro{ENOMEM}, \macro{EROFS}, \macro{ELOOP} e \macro{ENOSPC}. \end{prototype} Il comportamento della funzione è diverso a seconda che si voglia rinominare @@ -265,7 +255,7 @@ riferimento allo stesso file. Come abbiamo visto in \secref{sec:file_link} la funzione \func{link} crea riferimenti agli inodes, pertanto può funzionare soltanto per file che -risiedono sullo stesso filesysteme solo per un filesystem di tipo unix. +risiedono sullo stesso filesysteme e solo per un filesystem di tipo unix. Inoltre abbiamo visto che in Linux non è consentito eseguire un link diretto ad una directory. @@ -273,17 +263,16 @@ 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 speciali che contengono il semplicemente il riferimento ad un altro file (o directory). In questo modo è -possibile effettuare link anche attraverso filesystem diversi, in filesystem -che non supportano i link diretti, link alle directory, e pure a file che non -esistono ancora. +possibile effettuare link anche attraverso filesystem diversi, a file posti in +filesystem che non supportano i link diretti, a delle directory, e anche 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 per alcune -funzioni di libreria (come \func{open} o \func{stat}) l'indicazione di un link -simbolico l'applicazione della funzione al file da esso specificato. La -funzione che permette di creare un nuovo link simbolico è \func{symlink}; il -suo prototipo è: - +funzioni di libreria (come \func{open} o \func{stat}) dare come parametro un +link simbolico comporta l'applicazione della funzione al file da esso +specificato. La funzione che permette di creare un nuovo link simbolico è +\func{symlink}; il suo prototipo è: \begin{prototype}{unistd.h} {int symlink(const char * oldpath, const char * newpath)} Crea un nuovo link simbolico di nome \func{newpath} il cui contenuto è @@ -292,50 +281,30 @@ suo prototipo La funzione restituisce zero in caso di successo e -1 per un errore, nel qual caso la variabile \var{errno} restituisce i valori: \begin{errlist} - \item \macro{EEXIST} esiste già un file \var{newpath}. - \item \macro{EROFS} \var{newpath} è su un filesystem montato in sola lettura. + \item \macro{EPERM} il filesystem che contiene \var{newpath} non supporta i + link simbolici. \item \macro{ENOENT} una componente di \var{newpath} non esiste o \func{oldpath} è una stringa vuota. + \item \macro{EEXIST} esiste già un file \var{newpath}. + \item \macro{EROFS} \var{newpath} è su un filesystem montato in sola lettura. \end{errlist} - ed inoltre \macro{ENAMETOOLONG}, \macro{ENOSPC}, \macro{ENOMEM}, - \macro{ELOOP}, \macro{EACCES}, \macro{EIO} e \macro{ENOTDIR}. + ed inoltre \macro{EFAULT}, \macro{EACCES}, \macro{ENAMETOOLONG}, + \macro{ENOTDIR}, \macro{ENOMEM}, \macro{ELOOP}, \macro{ENOSPC} e + \macro{EIO}. \end{prototype} +Si tenga presente che la funzione non effettua nessun controllo sull'esistenza +di un file di nome \var{oldpath}, ma si limita ad inserire quella stringa nel +link simbolico. Pertanto un link simbolico può anche riferirsi ad un file che +non esiste: quello che viene chiamato un \textit{dangling link}, letteralmente +\textsl{link ciondolante}. - - - -Inoltre esistono funzioni apposite, come la \func{readlink} e la \func{lstat} -per accedere alle informazioni del link invece che a quelle del file a cui -esso fa riferimento. Dato che, come indicato in \secref{tab:file_symb_effect}, -la funzione \func{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 \var{path} nel buffer - \var{buff} di dimensione \var{size}. Non chiude la stringa con un - carattere nullo e la tronca a \var{size} nel caso il buffer sia troppo - piccolo per contenerla. - - La funzione restituisce il numero di caratteri letti dentro \var{buff} o - -1 per un errore, in caso di errore. La variabile \var{errno} viene - settata secondo i codici di errore: - \begin{errlist} - \item \macro{EEXIST} Un file (o una directory) con quel nome esiste di - già. - \item \macro{EROFS} La directory su cui si vuole inserire il nuovo link è - su un filesystem montato in sola lettura. - \item \macro{ENOSPC} La directory o il filesystem in cui si vuole creare il - link è piena e non c'è ulteriore spazio disponibile. - \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. +Come accennato i link simbolici sono risolti automaticamente dal kernel +all'invocazione delle varie system call; in \ntab\ si è riportato un elenco +dei comportamenti delle varie funzioni di libreria che operano sui file nei +confronti della risoluzione dei link simbolici, specificando quali seguono il +link simbolico e quali invece possono operare direttamente sul suo contenuto. \begin{table}[htb] \centering \footnotesize @@ -370,10 +339,42 @@ link simbolico e quali possono operare direttamente sul suo contenuto. \caption{Uso dei link simbolici da parte di alcune funzioni.} \label{tab:file_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 + +Si noti che non si è specificato il comportamento delle funzioni che operano +con i file descriptor, in quanto la risoluzione del link simbolico viene in genere effettuata dalla funzione che restituisce il file descriptor -(normalmente la \func{open}). +(normalmente la \func{open}) e tutte le operazioni seguenti fanno riferimento +solo a quest'ultimo. + +Dato che, come indicato in \tabref{tab:file_symb_effect}, funzioni come la +\func{open} seguono i link simbolici, occorrono funzioni apposite per accedere +alle informazioni del link invece che a quelle del file a cui esso fa +riferimento. Quando si vuole leggere il contenuto di un link simbolico si usa +la funzione \func{readlink}, il cui prototipo è: +\begin{prototype}{unistd.h} +{int readlink(const char * path, char * buff, size\_t size)} + Legge il contenuto del link simbolico indicato da \var{path} nel buffer + \var{buff} di dimensione \var{size}. + + La funzione restituisce il numero di caratteri letti dentro \var{buff} o -1 + per un errore, nel qual caso la variabile \var{errno} viene settata a: + \begin{errlist} + \item \macro{EINVAL} \var{file} non è un link simbolico o \var{size} non è + positiva. + \item \macro{EROFS} La directory su cui si vuole inserire il nuovo link è + su un filesystem montato in sola lettura. + \item \macro{ENOSPC} La directory o il filesystem in cui si vuole creare il + link è piena e non c'è ulteriore spazio disponibile. + \end{errlist} + ed inoltre \macro{ENOTDIR}, \macro{ENAMETOOLONG}, \macro{ENOENT}, + \macro{EACCES}, \macro{ELOOP}, \macro{EIO}, \macro{EFAULT} e \macro{ENOMEM}. +\end{prototype} + +La funzione apre il link simbolico, ne legge il contenuto, lo scrive nel +buffer, e lo richiude. Si tenga presente che la funzione non termina la +stringa con un carattere nullo e la tronca alla dimensione specificata da +\var{size} per evitare di sovrascrivere oltre le dimensioni del buffer. + \begin{figure}[htb] \centering @@ -397,27 +398,30 @@ Questo pu scansione di una directory senza tener conto dei link simbolici, ad esempio se lanciassimo un comando del tipo \cmd{grep -r linux *}, il loop nella directory porterebbe il comando ad esaminare \file{/boot}, \file/{boot/boot}, -\file/{boot/boot/boot} e così via, fino a generare un errore (che poi è -\macro{ELOOP}) quando viene superato il numero massimo di link simbolici -consentiti (uno dei limiti del sistema, posto proprio per poter uscire da -questo tipo di situazione). - -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: +\file/{boot/boot/boot} e così via. + +Per questo motivo il kernel e le librerie prevedono che nella risoluzione di +un pathname possano essere seguiti un numero limitato di link simbolici, il +cui valore limite è specificato dalla costante \macro{MAXSYMLINKS}; qualora +questo limite venga superato viene generato un errore ed \var{errno} viene +settata al valore \macro{ELOOP}. + +Un punto da tenere sempre presente è il fatto che un link simbolico può fare +riferimento 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 (quello che viene chiamato un -\textit{dangling link}, letteralemnte \textsl{link ciondolante}). Aprendo in -scrittura \file{temporaneo} questo verrà scritto; ma se cercassimo di -accederlo in sola lettura (ad esempio con \cmd{cat}) otterremmo: +anche se \file{/tmp/tmp\_file} non esiste. Questo può generare confusione, in +quanto aprendo in scrittura \file{temporaneo} verrà creato +\file{/tmp/tmp\_file} e scritto; ma accedendo in sola lettura a +\file{temporaneo}, ad esempio con \cmd{cat}, otterremmo: \begin{verbatim} $ cat temporaneo cat: temporaneo: No such file or directory \end{verbatim}%$ -con un errore che può sembrare sbagliato, dato \cmd{ls} ci mostrerebbe -l'esistenza di \file{temporaneo}. +con un errore che può sembrare sbagliato, dato che invece \cmd{ls} ci +mostrerebbe l'esistenza di \file{temporaneo}. \subsection{Le funzioni \func{mkdir} e \func{rmdir}} @@ -426,8 +430,7 @@ l'esistenza di \file{temporaneo}. Queste due funzioni servono per creare e cancellare delle directory e sono omonime degli analoghi comandi di shell. Per poter accedere ai tipi usati da queste funzioni si deve includere il file \file{sys/types.h}, il -protoripo della prima è: - +prototipo della prima è: \begin{prototype}{sys/stat.h} {int mkdir (const char * dirname, mode\_t mode)} Crea una nuova directory vuota con il nome indicato da \var{dirname}, @@ -454,12 +457,21 @@ protoripo della prima \macro{EROFS}. \end{prototype} - - +La funzione crea una nuova directory vuota (che contiene solo le due voci +standard \file{.} e \file{..}). I permessi di accesso (vedi la trattazione in +\secref{sec:file_access_control}) specificati da \var{mode} (i cui possibili +valori sono riportati in \tabref{tab:file_permission_const}) sono modificati +dalla maschera di creazione dei file (si veda \secref{sec:file_umask}). La +titolarità della nuova directory è settata secondo quanto riportato in +\secref{sec:file_ownership}. + +La seconda funzione serve ad eliminare una directory già vuota (la directory +deve cioè contenere soltanto le due voci standard \file{.} e \file{..}); il +suo prototipo è: \begin{prototype}{sys/stat.h} - {int rmdir (const char * dirname)} - Cancella la directory \var{dirname}, che deve essere vuota. Il nome può - essere indicato con il pathname assoluto o relativo. + {int rmdir (const char * dirname)} Cancella la directory \var{dirname}, che + deve essere vuota. Il nome può essere indicato con il pathname assoluto o + relativo. La funzione restituisce zero in caso di successo e -1 per un errore, nel qual caso \var{errno} assumerà i valori: @@ -479,7 +491,14 @@ protoripo della prima ed inoltre anche \macro{EFAULT}, \macro{ENAMETOOLONG}, \macro{ENOENT}, \macro{ENOTDIR}, \macro{ENOMEM}, \macro{ELOOP}, \macro{EROFS}. \end{prototype} - + +La modalità con cui avviene la cancellazione è analoga a quella di +\func{unlink}, fintanto che il numero di link all'inode della directory non +diventa nullo e nessun processo ha la directory aperta lo spazio occupato su +disco non viene rilasciato. Se un processo ha la directory aperta la funzione +rimuove il link all'inode e nel caso sia l'ultimo, pure le voci standard +\file{.} e \file{..}, ed il kernel non consentirà di creare più nuovi file +nella directory. \subsection{Accesso alle directory} @@ -488,51 +507,48 @@ protoripo della prima 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. +contengono o ricerche sui medesimi. Solo il kernel scrivere direttamente in +una directory (onde evitare inconsistenze all'interno del filesystem), i +processi devono creare i file usando le apposite funzioni. Per accedere al contenuto delle directory si usano i cosiddetti \textit{directory streams} (chiamati così per l'analogia con i file stream); la funzione \func{opendir} apre uno di questi stream e la funzione \func{readdir} legge il contenuto della directory, i cui elementi sono le \textit{directory entry} (da distinguersi da quelle della cache di cui -parlavamo in \secref{sec:file_vfs}) in una opportuna struttura -\var{struct dirent}. +parlavamo in \secref{sec:file_vfs}) in una opportuna struttura \var{struct + dirent}. (NdA Il resto va scritto!!! É noioso e lo farò più avanti). - \subsection{La directory di lavoro} \label{sec:file_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). +relativa, dove il relativa fa riferimento appunto a questa directory. Quando un utente effettua il login questa directory viene settata alla -cosiddetta \textit{home directory} del suo account, il comando \cmd{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 +\textit{home directory} del suo account. Il comando \cmd{cd} della shell +consente di cambiarla a piacere, spostandosi da una directory ad un'altra, il +comando \cmd{pwd} la stampa sul terminale. Siccome la directory corrente +resta la stessa quando viene creato un processo figlio (vedi +\secref{sec:proc_fork}), 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. - +In genere il kernel tiene traccia per ciascun processo dell'inode della +directory di lavoro corrente, per ottenere il pathname occorre usare una +apposita funzione di libreria, \func{getcwd}, il cui prototipo è: \begin{prototype}{unistd.h}{char * getcwd (char * buffer, size\_t size)} Restituisce il filename completo della directory di lavoro corrente nella stringa puntata da \var{buffer}, che deve essere precedentemente - allocata, per una dimensione massima di \var{size}. Si può anche - specificare un puntatore nullo come \var{buffer}, nel qual caso la - stringa sarà allocata automaticamente per una dimensione pari a - \var{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. + allocata, per una dimensione massima di \var{size}. - La funzione restituisce il puntatore \var{buffer} se riesce, - \macro{NULL} se fallisce, in quest'ultimo caso la variabile - \var{errno} è settata con i seguenti codici di errore: + La funzione restituisce il puntatore \var{buffer} se riesce, \macro{NULL} se + fallisce, in quest'ultimo caso la variabile \var{errno} è settata con i + seguenti codici di errore: \begin{errlist} \item \macro{EINVAL} L'argomento \var{size} è zero e \var{buffer} non è nullo. @@ -544,6 +560,16 @@ corrente. \end{errlist} \end{prototype} +Il buffer deve essere sufficientemente lungo da poter contenere il pathname +completo più lo zero di terminazione della stringa. Qualora esso ecceda le +dimensioni specificate con \var{size} la funzione restituiece un errore. Si +può anche specificare un puntatore nullo come \var{buffer}\footnote{questa è + una estensione allo standard POSIX.1, supportata da Linux}, nel qual caso la +stringa sarà allocata automaticamente per una dimensione pari a \var{size} +qualora questa sia diversa da zero, o della lunghezza esatta del pathname +altrimenti. In questo caso ci si deve ricordare di disallocare la stringa una +volta cessato il suo utilizzo. + Di questa funzione esiste una versione \func{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 @@ -553,33 +579,40 @@ superiore per un pathname, per cui non contenere il nome del file, e questa è la ragione principale per cui questa funzione è deprecata. -Una seconda funzione simile è \func{char * get\_current\_dir\_name(void)} -che è sostanzialmente equivalente ad una \func{getcwd(NULL, 0)}, con la sola -differenza che essa ritorna il valore della variabile di ambiente -\macro{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 \var{pathname}. -\end{prototype} +Una seconda funzione simile è \func{char * get\_current\_dir\_name(void)} che +è sostanzialmente equivalente ad una \func{getcwd(NULL, 0)}, con la sola +differenza che essa ritorna il valore della variabile di ambiente \macro{PWD}, +che essendo costruita dalla shell può contenere anche dei riferimenti +simbolici; nel caso di \func{getcwd} infatti, essendo il pathname ricavato +risalendo all'indietro l'albero della directory, si perderebbe traccia di ogni +passaggio attraverso eventuali pathname. + +Altre due funzioni, \func{chdir} e \func{fchdir}, vengono usate, come dice il +nome (che deriva da \textit{change directory}), per cambiare la directory di +lavoro corrente. Dato che anche le directory sono file, è possibile riferirsi +ad esse anche tramite il file descriptor dell'interfaccia a basso livello, e +non solo tramite il filename, i prototipi di queste funzioni sono: +\begin{functions} + \headdecl{unistd.h} + \funcdecl{int chdir (const char * path)} + Cambia la directory di lavoro corrente a quella specificata dal pathname + contenuto nella stringa \var{path}. -\begin{prototype}{unistd.h}{int fchdir (int filedes)} - Analoga alla precedente, ma usa un file descriptor invece del pathname. + \funcdecl{int fchdir (int fd)} 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 \var{errno} viene settata secondo i codici di - errore standard di accesso ai file (trattati in dettaglio in - \secref{sec:file_access_control}) ai quali si aggiunge il codice - \macro{ENOTDIR} nel caso il \var{filename} indichi un file che non sia una - directory. -\end{prototype} + errore, in caso di errore \var{errno} viene settata per \func{chdir} ai + valori: + \begin{errlist} + \item \macro{ENOTDIR} Uno dei componenti di \var{path} non è una directory. + \item \macro{EACCESS} Manca il permesso di ricerca su uno dei componenti di + \func{path}. + \end{errlist} + ed inoltre \macro{EFAULT}, \macro{ENAMETOOLONG}, \macro{ENOENT}, + \macro{ENOMEM}, \macro{ELOOP} e \macro{EIO}. Per \func{fchdir} invece gli + errori sono \macro{EBADF} e \macro{EACCES}. +\end{functions} @@ -656,7 +689,7 @@ struct stat { \end{lstlisting} \end{minipage} \normalsize - \caption{La struttura \texttt{stat} per la lettura delle informazioni dei + \caption{La struttura \var{stat} per la lettura delle informazioni dei file} \label{fig:file_stat_struct} \end{figure} @@ -972,7 +1005,6 @@ esiste. 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)} @@ -1222,7 +1254,7 @@ proprietario del file al posto dell'uid del processo originario. Avere il bit \acr{sgid} settato ha lo stesso effetto sull'\textit{effective group id} del processo. -I bit \textsl{suid} e \textsl{sgid} vengono usati per permettere agli utenti +I bit \acr{suid} e \acr{sgid} vengono usati 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, quest'ultimo ovviamente può essere scritto solo @@ -1351,7 +1383,6 @@ l'\acr{uid} dell'utente che ha lanciato il programma, che, come accennato in \secref{sec:file_suid_sgid} e spiegato in \secref{sec:proc_perms} non è detto sia uguale all'\textit{effective user id}). Per far questo si può usare la funzione \func{access}, il cui prototipo è: - \begin{prototype}{unistd.h} {int access(const char *pathname, int mode)} @@ -1378,7 +1409,6 @@ possa scrivere come in un file, e il fatto che un file abbia permesso di esecuzione non comporta che contenga un programma eseguibile. La funzione ritorna zero solo se tutte i permessi controllati sono disponibili, in caso contrario (o di errore) ritorna -1. - \begin{table}[htb] \centering \footnotesize @@ -1494,7 +1524,7 @@ particolare: l'\textit{effective user id} del processo è zero). \end{itemize} -Per alcuni filesystem\footnote{il filesystem \textsl{ext2} supporta questa +Per alcuni filesystem\footnote{il filesystem \acr{ext2} supporta questa caratteristica, che è mutuata da BSD.} è inoltre prevista una ulteriore misura di sicurezza, volta ad scongiurare l'abuso dei bit \acr{suid} e \acr{sgid}; essa consiste nel cancellare automaticamente questi bit qualora un @@ -1503,7 +1533,6 @@ modo anche se un utente malizioso scopre un file \acr{suid} su cui pu scrivere, un eventuale modifica comporterà la perdita di ogni ulteriore privilegio. - \subsection{La funzione \func{umask}} \label{sec:file_umask}