X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=filedir.tex;h=0264b90e5709d9fd5ec2ffe9806ce9d277072366;hp=9b4025ec5606dcc71bfb89e66bd2d6addf3d4be0;hb=da0899b61653d07d75c8df134906261f1afd2485;hpb=9aad56ecd71e4f36e09f001cdd30b2106beec5c4 diff --git a/filedir.tex b/filedir.tex index 9b4025e..0264b90 100644 --- a/filedir.tex +++ b/filedir.tex @@ -515,7 +515,7 @@ per creare una directory \end{functions} La funzione crea una nuova directory vuota, che contiene cioè solo le due voci -standard \file{.} e \file{..}, con il nome indicato dall'argomento +standard (\file{.} e \file{..}), con il nome indicato dall'argomento \param{dirname}. Il nome può essere indicato sia come pathname assoluto che relativo. @@ -752,11 +752,9 @@ directory corrente di qualunque comando da essa lanciato. In genere il kernel tiene traccia per ciascun processo dell'inode\index{inode} della directory di lavoro corrente, per ottenere il pathname occorre usare una -apposita funzione di libreria, \func{getcwd}, il cui prototipo è: +apposita funzione di libreria, \funcd{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 \param{buffer}, che deve essere precedentemente allocata, - per una dimensione massima di \param{size}. + Legge il pathname della directory di lavoro corrente. \bodydesc{La funzione restituisce il puntatore \param{buffer} se riesce, \val{NULL} se fallisce, in quest'ultimo caso la variabile @@ -772,15 +770,19 @@ apposita funzione di libreria, \func{getcwd}, il cui prototipo \end{errlist}} \end{prototype} -Il buffer deve essere sufficientemente lungo da poter contenere il pathname +La funzione restituisce il pathname completo della directory di lavoro +corrente nella stringa puntata da \param{buffer}, che deve essere +precedentemente allocata, per una dimensione massima di \param{size}. Il +buffer deve essere sufficientemente lungo da poter contenere il pathname completo più lo zero di terminazione della stringa. Qualora esso ecceda le -dimensioni specificate con \param{size} la funzione restituisce un errore. Si -può anche specificare un puntatore nullo come \param{buffer},\footnote{questa è - un'estensione allo standard POSIX.1, supportata da Linux.} nel qual caso la -stringa sarà allocata automaticamente per una dimensione pari a \param{size} -qualora questa sia diversa da zero, o della lunghezza esatta del pathname -altrimenti. In questo caso ci si deve ricordare di disallocare la stringa una -volta cessato il suo utilizzo. +dimensioni specificate con \param{size} la funzione restituisce un errore. + +Si può anche specificare un puntatore nullo come +\param{buffer},\footnote{questa è un'estensione allo standard POSIX.1, + supportata da Linux.} nel qual caso la stringa sarà allocata automaticamente +per una dimensione pari a \param{size} qualora questa sia diversa da zero, o +della lunghezza esatta del pathname altrimenti. In questo caso ci si deve +ricordare di disallocare la stringa una volta cessato il suo utilizzo. Di questa funzione esiste una versione \code{char *getwd(char *buffer)} fatta per compatibilità all'indietro con BSD, che non consente di specificare @@ -800,7 +802,7 @@ risalendo all'indietro l'albero della directory, si perderebbe traccia di ogni passaggio attraverso eventuali link simbolici. Per cambiare la directory di lavoro corrente si può usare la funzione -\func{chdir} (equivalente del comando di shell \cmd{cd}) il cui nome sta +\funcd{chdir} (equivalente del comando di shell \cmd{cd}) il cui nome sta appunto per \textit{change directory}, il suo prototipo è: \begin{prototype}{unistd.h}{int chdir(const char *pathname)} Cambia la directory di lavoro corrente in \param{pathname}. @@ -820,7 +822,7 @@ quale si hanno i permessi di accesso. Dato che anche le directory sono file, è possibile riferirsi ad esse anche tramite il file descriptor, e non solo tramite il filename, per fare questo si -usa \func{fchdir}, il cui prototipo è: +usa \funcd{fchdir}, il cui prototipo è: \begin{prototype}{unistd.h}{int fchdir(int fd)} Identica a \func{chdir}, ma usa il file descriptor \param{fd} invece del pathname. @@ -849,7 +851,7 @@ controllo e la creazione si ha giusto lo spazio per una possibile \textit{race Le \acr{glibc} provvedono varie funzioni per generare nomi di file temporanei, di cui si abbia certezza di unicità (al momento della generazione); la prima -di queste funzioni è \func{tmpnam} il cui prototipo è: +di queste funzioni è \funcd{tmpnam} il cui prototipo è: \begin{prototype}{stdio.h}{char *tmpnam(char *string)} Restituisce il puntatore ad una stringa contente un nome di file valido e non esistente al momento dell'invocazione. @@ -868,7 +870,7 @@ prefisso la directory specificata da \const{P\_tmpdir}. Di questa funzione esiste una versione rientrante, \func{tmpnam\_r}, che non fa nulla quando si passa \val{NULL} come parametro. Una funzione simile, -\func{tempnam}, permette di specificare un prefisso per il file +\funcd{tempnam}, permette di specificare un prefisso per il file esplicitamente, il suo prototipo è: \begin{prototype}{stdio.h}{char *tempnam(const char *dir, const char *pfx)} Restituisce il puntatore ad una stringa contente un nome di file valido e @@ -904,7 +906,7 @@ queste funzioni occorre sempre aprire il nuovo file in modalit esistente. Per evitare di dovere effettuare a mano tutti questi controlli, lo standard -POSIX definisce la funzione \func{tempfile}, il cui prototipo è: +POSIX definisce la funzione \funcd{tempfile}, il cui prototipo è: \begin{prototype}{stdio.h}{FILE *tmpfile (void)} Restituisce un file temporaneo aperto in lettura/scrittura. @@ -927,10 +929,10 @@ funzione condition}\index{race condition}. Alcune versioni meno recenti di Unix non supportano queste funzioni; in questo -caso si possono usare le vecchie funzioni \func{mktemp} e \func{mkstemp} che +caso si possono usare le vecchie funzioni \funcd{mktemp} e \func{mkstemp} che modificano una stringa di input che serve da modello e che deve essere conclusa da 6 caratteri \code{X} che verranno sostituiti da un codice -unico. La prima delle due è analoga a \func{tmpnam} e genera un nome casuale, +unico. La prima delle due è analoga a \funcd{tmpnam} e genera un nome casuale, il suo prototipo è: \begin{prototype}{stlib.h}{char *mktemp(char *template)} Genera un filename univoco sostituendo le \code{XXXXXX} finali di @@ -953,9 +955,7 @@ possibilit indovinare. Per tutti questi motivi la funzione è deprecata e non dovrebbe mai essere usata. - - -La seconda funzione, \func{mkstemp} è sostanzialmente equivalente a +La seconda funzione, \funcd{mkstemp} è sostanzialmente equivalente a \func{tmpfile}, ma restituisce un file descriptor invece di uno stream; il suo prototipo è: \begin{prototype}{stlib.h}{int mkstemp(char *template)} @@ -982,7 +982,7 @@ certezza di essere i soli utenti del file. I permessi sono impostati al valore In OpenBSD è stata introdotta un'altra funzione\footnote{introdotta anche in Linux a partire dalle \acr{glibc} 2.1.91.} simile alle precedenti, -\func{mkdtemp}, che crea una directory temporanea; il suo prototipo è: +\funcd{mkdtemp}, che crea una directory temporanea; il suo prototipo è: \begin{prototype}{stlib.h}{char *mkdtemp(char *template)} Genera una directory temporaneo il cui nome è ottenuto sostituendo le \code{XXXXXX} finali di \param{template}. @@ -1410,7 +1410,7 @@ avr \label{sec:file_utime} I tempi di ultimo accesso e modifica possono essere cambiati usando la -funzione \func{utime}, il cui prototipo è: +funzione \funcd{utime}, il cui prototipo è: \begin{prototype}{utime.h} {int utime(const char *filename, struct utimbuf *times)} @@ -1500,33 +1500,27 @@ Esistono varie estensioni a questo modello,\footnote{come le \textit{Access come il \textit{mandatory access control} di SE-Linux.} ma nella maggior parte dei casi il meccanismo standard è più che sufficiente a soddisfare tutte le necessità più comuni. I tre permessi di base associati ad ogni file sono: -\begin{itemize*} +\begin{itemize} \item il permesso di lettura (indicato con la lettera \texttt{r}, dall'inglese \textit{read}). \item il permesso di scrittura (indicato con la lettera \texttt{w}, dall'inglese \textit{write}). \item il permesso di esecuzione (indicato con la lettera \texttt{x}, dall'inglese \textit{execute}). -\end{itemize*} +\end{itemize} mentre i tre livelli su cui sono divisi i privilegi sono: -\begin{itemize*} +\begin{itemize} \item i privilegi per l'utente proprietario del file. \item i privilegi per un qualunque utente faccia parte del gruppo cui appartiene il file. \item i privilegi per tutti gli altri utenti. -\end{itemize*} +\end{itemize} L'insieme dei permessi viene espresso con un numero a 12 bit; di questi i nove meno significativi sono usati a gruppi di tre per indicare i permessi base di lettura, scrittura ed esecuzione e sono applicati rispettivamente rispettivamente al proprietario, al gruppo, a tutti gli altri. -I restanti tre bit (noti come \acr{suid}, \acr{sgid}, e \textsl{sticky}) sono -usati per indicare alcune caratteristiche più complesse del meccanismo del -controllo di accesso su cui torneremo in seguito (in -\secref{sec:file_suid_sgid} e \secref{sec:file_sticky}); lo schema di -allocazione dei bit è riportato in \figref{fig:file_perm_bit}. - \begin{figure}[htb] \centering \includegraphics[width=6cm]{img/fileperm} @@ -1535,6 +1529,12 @@ allocazione dei bit \label{fig:file_perm_bit} \end{figure} +I restanti tre bit (noti come \acr{suid}, \acr{sgid}, e \textsl{sticky}) sono +usati per indicare alcune caratteristiche più complesse del meccanismo del +controllo di accesso su cui torneremo in seguito (in +\secref{sec:file_suid_sgid} e \secref{sec:file_sticky}); lo schema di +allocazione dei bit è riportato in \figref{fig:file_perm_bit}. + Anche i permessi, come tutte le altre informazioni pertinenti al file, sono memorizzati nell'inode\index{inode}; in particolare essi sono contenuti in alcuni bit del campo \var{st\_mode} della struttura \struct{stat} (si veda di @@ -1589,6 +1589,7 @@ la quale appunto serve il diritto di esecuzione). Per una directory infatti il permesso di esecuzione significa 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} @@ -1768,22 +1769,23 @@ invece assunto un uso importante per le directory;\footnote{lo \textsl{sticky impostato un file potrà essere rimosso dalla directory soltanto se l'utente ha il permesso di scrittura su di essa ed inoltre è vera una delle seguenti condizioni: -\begin{itemize*} +\begin{itemize} \item l'utente è proprietario del file \item l'utente è proprietario della directory \item l'utente è l'amministratore -\end{itemize*} +\end{itemize} un classico esempio di directory che ha questo bit impostato è \file{/tmp}, i -permessi infatti di solito sono impostati come: +permessi infatti di solito sono i seguenti: \begin{verbatim} $ ls -ld /tmp drwxrwxrwt 6 root root 1024 Aug 10 01:03 /tmp \end{verbatim}%$ -in questo modo chiunque può creare file in questa directory (che infatti è -normalmente utilizzata per la creazione di file temporanei), ma solo l'utente -che ha creato un certo file potrà cancellarlo o rinominarlo. In questo modo si -evita che un utente possa, più o meno consapevolmente, cancellare i file degli -altri. +quindi con lo \textsl{sticky bit} bit impostato. In questo modo qualunque +utente nel sistema può creare dei file in questa directory (che, come +suggerisce il nome, è normalmente utilizzata per la creazione di file +temporanei), ma solo l'utente che ha creato un certo file potrà cancellarlo o +rinominarlo. In questo modo si evita che un utente possa, più o meno +consapevolmente, cancellare i file temporanei creati degli altri utenti. \subsection{La titolarità di nuovi file e directory} @@ -1799,11 +1801,11 @@ per la creazione di nuove directory (procedimento descritto in Lo standard POSIX prescrive che l'\acr{uid} del nuovo file corrisponda all'userid effettivo del processo che lo crea; per il \acr{gid} invece prevede due diverse possibilità: -\begin{itemize*} +\begin{itemize} \item il \acr{gid} del file corrisponde al groupid effettivo del processo. \item il \acr{gid} del file corrisponde al \acr{gid} della directory in cui esso è creato. -\end{itemize*} +\end{itemize} in genere BSD usa sempre la seconda possibilità, che viene per questo chiamata semantica BSD. Linux invece segue quella che viene chiamata semantica SVr4; di norma cioè il nuovo file viene creato, seguendo la prima opzione, con il @@ -1812,13 +1814,14 @@ bit \acr{sgid} impostato allora viene usata la seconda opzione. Usare la semantica BSD ha il vantaggio che il \acr{gid} viene sempre automaticamente propagato, restando coerente a quello della directory di -partenza, in tutte le sottodirectory. La semantica SVr4 offre la possibilità -di scegliere, ma per ottenere lo stesso risultato di coerenza che si ha con -BSD necessita che per le nuove directory venga anche propagato anche il bit -\acr{sgid}. Questo è il comportamento predefinito di \cmd{mkdir}, ed è in -questo modo ad esempio che Debian assicura che le sottodirectory create nella -home di un utente restino sempre con il \acr{gid} del gruppo primario dello -stesso. +partenza, in tutte le sottodirectory. + +La semantica SVr4 offre la possibilità di scegliere, ma per ottenere lo stesso +risultato di coerenza che si ha con BSD necessita che per le nuove directory +venga anche propagato anche il bit \acr{sgid}. Questo è il comportamento +predefinito del comando \cmd{mkdir}, ed è in questo modo ad esempio che Debian +assicura che le sottodirectory create nella home di un utente restino sempre +con il \acr{gid} del gruppo primario dello stesso. \subsection{La funzione \func{access}} @@ -1830,13 +1833,13 @@ sono casi per ed il groupid reale, vale a dire usando i valori di \acr{uid} e \acr{gid} relativi all'utente che ha lanciato il programma, e che, come accennato in \secref{sec:file_suid_sgid} e spiegato in dettaglio in -\secref{sec:proc_perms}, non è detto siano uguali a quelli effettivi. Per far -questo si può usare la funzione \func{access}, il cui prototipo è: +\secref{sec:proc_perms}, non è detto siano uguali a quelli effettivi. + +Per far questo si può usare la funzione \funcd{access}, il cui prototipo è: \begin{prototype}{unistd.h} {int access(const char *pathname, int mode)} -Verifica i permessi di accesso, indicati da \param{mode}, per il file indicato -da \param{pathname}. +Verifica i permessi di accesso. \bodydesc{La funzione ritorna 0 se l'accesso è consentito, -1 se l'accesso non è consentito ed in caso di errore; nel qual caso la variabile \var{errno} @@ -1852,14 +1855,15 @@ da \param{pathname}. \errval{ENOTDIR}, \errval{ELOOP}, \errval{EIO}.} \end{prototype} -I valori possibili per l'argomento \param{mode} sono esprimibili come -combinazione delle costanti numeriche riportate in -\tabref{tab:file_access_mode_val} (attraverso un OR binario delle stesse). I -primi tre valori implicano anche la verifica dell'esistenza del file, se si -vuole verificare solo quest'ultima si può usare \const{F\_OK}, o anche -direttamente \func{stat}. Nel caso in cui \param{pathname} si riferisca ad un -link simbolico, questo viene seguito ed il controllo è fatto sul file a cui -esso fa riferimento. +La funzione verifica i permessi di accesso, indicati da \param{mode}, per il +file indicato da \param{pathname}. I valori possibili per l'argomento +\param{mode} sono esprimibili come combinazione delle costanti numeriche +riportate in \tabref{tab:file_access_mode_val} (attraverso un OR binario delle +stesse). I primi tre valori implicano anche la verifica dell'esistenza del +file, se si vuole verificare solo quest'ultima si può usare \const{F\_OK}, o +anche direttamente \func{stat}. Nel caso in cui \param{pathname} si riferisca +ad un link simbolico, questo viene seguito ed il controllo è fatto sul file a +cui esso fa riferimento. La funzione controlla solo i bit dei permessi di accesso, si ricordi che il fatto che una directory abbia permesso di scrittura non significa che ci si @@ -2011,7 +2015,7 @@ perdita di questo privilegio. Oltre che dai valori indicati in sede di creazione, i permessi assegnati ai nuovi file sono controllati anche da una maschera di bit impostata con la -funzione \func{umask}, il cui prototipo è: +funzione \funcd{umask}, il cui prototipo è: \begin{prototype}{stat.h} {mode\_t umask(mode\_t mask)} @@ -2220,7 +2224,7 @@ processo figlio, e quindi di norma coincide con la \file{/} del sistema. In certe situazioni però per motivi di sicurezza non si vuole che un processo possa accedere a tutto il filesystem; per questo si può cambiare la directory -radice con la funzione \func{chroot}, il cui prototipo è: +radice con la funzione \funcd{chroot}, il cui prototipo è: \begin{prototype}{unistd.h}{int chroot(const char *path)} Cambia la directory radice del processo a quella specificata da \param{path}.