X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=filedir.tex;h=c9884c4f4e6acf56a9c851ade4307375581f011d;hp=1f0edcd66b40e82a0c62684b45025bd8aeb4170a;hb=f5e0b5be624d5a5a0b7a414ec7e957b0f86b2a56;hpb=429f6e0da8fc282eb6611b6fe83fdf58ae8da611 diff --git a/filedir.tex b/filedir.tex index 1f0edcd..c9884c4 100644 --- a/filedir.tex +++ b/filedir.tex @@ -2,595 +2,618 @@ \label{cha:files_and_dirs} In questo capitolo tratteremo in dettaglio le modalità con cui si gestiscono -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. +file e directory, iniziando dalle funzioni di libreria che si usano per +copiarli, spostarli e cambiarne i nomi. Esamineremo poi l'interfaccia che +permette la manipolazione dei vari attributi di file e directory ed alla +fine faremo una trattazione dettagliata su come è strutturato il sistema base +di protezioni e controllo di accesso ai file e sulle funzioni che ne +permettono la gestione. Tutto quello che riguarda invece la manipolazione del +contenuto dei file è lasciato ai capitoli successivi. -\section{Il controllo di accesso ai file} -\label{sec:file_access_control} - -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:file_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 i permessi 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 (\acr{uid} e \acr{gid}). Questi valori -sono accessibili da programma tramite i campi \var{st\_uid} e \var{st\_gid} -della struttura \var{stat} (si veda \secref{sec:file_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. - -I permessi, così come vengono presi dai comandi e dalle routine di sistema, -sono espressi da un numero 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 nei comandi di sistema con le lettere \cmd{w}, \cmd{r} e -\cmd{x}) ed applicabili rispettivamente al proprietario, al gruppo, a tutti -gli altri. I restanti tre bit (\acr{suid}, \acr{sgid}, e -\textsl{sticky}) sono usati per indicare alcune caratteristiche più complesse -su cui torneremo in seguito (vedi \secref{sec:file_suid_sgid} e -\secref{sec:file_sticky}). - -Anche i permessi, come tutte le altre informazioni generali, sono tenuti per -ciascun file nell'inode; in particolare essi sono contenuti in alcuni bit -del campo \var{st\_mode} della struttura letta da \func{stat} (di nuovo si veda -\secref{sec:file_stat} per i dettagli). - -In genere ci si riferisce a questo raggruppamento dei permessi usando le -lettere \cmd{u} (per \textit{user}), \cmd{g} (per \textit{group}) e \cmd{o} -(per \textit{other}), inoltre se si vuole indicare tutti i raggruppamenti -insieme si usa la lettera \cmd{a} (per \textit{all}). Si tenga ben presente -questa distinzione dato che in certi casi, mutuando la terminologia in uso nel -VMS, si parla dei permessi base come di permessi per \textit{owner}, -\textit{group} ed \textit{all}, le cui iniziali possono dar luogo a confusione. -Le costanti che permettono di accedere al valore numerico di questi bit nel -campo \var{st\_mode} sono riportate in \ntab. - -\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} - -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). - -Avere 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. Avere 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 del contenuto del file dal -disco), non è necessario nessun tipo di permesso per il file stesso (infatti -esso non viene toccato, viene solo modificato il contenuto della directory, -rimuovendo la voce che ad esso fa rifermento). +\section{La gestione di file e directory} -Per poter eseguire un file (che sia un programma compilato od uno script di -shell, od un altro tipo di file eseguibile riconosciuto dal kernel), occorre -avere il permesso di esecuzione, inoltre solo i file regolari possono essere -eseguiti. +Come già accennato in \secref{sec:file_filesystem} in un sistema unix-like la +gestione dei file ha delle caratteristiche specifiche che derivano +direttamente dall'architettura del sistema; in questa sezione esamineremo le +funzioni usate per manipolazione nel filesytem di file e directory, per la +creazione di link simbolici e diretti, per la gestione e la lettura delle +directory; il tutto mettendo in evidenza le conseguenze della struttura +standard della gestione dei file in un sistema unix-like, già accennate al +capitolo precedente. -I permessi per un link simbolico sono ignorati, contano quelli del file a cui -fa riferimento; per questo in genere \cmd{ls} per un link simbolico riporta -tutti i permessi come concessi; utente e gruppo a cui esso appartiene vengono -ignorati quando il link viene risolto, vengono controllati solo quando viene -richiesta la rimozione del link e quest'ultimo è in una directory con lo -\textsl{sticky bit} settato (si veda \secref{sec:file_sticky}). -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:proc_perms}; normalmente, a parte quanto vedremo in -\secref{sec:file_suid_sgid}, l'\textit{effective user id} e -l'\textit{effective group id} corrispondono a \acr{uid} e \acr{gid} -dell'utente che ha lanciato il processo, mentre i \textit{supplementary group - id} sono quelli dei gruppi cui l'utente appartiene. - -I passi attraverso i quali viene stabilito se il processo possiede il diritto -di accesso sono i seguenti: -\begin{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 \acr{gid} del - file allora: - \begin{itemize} - \item se il bit dei permessi d'accesso del gruppo è settato, l'accesso è - consentito, - \item 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. - - -\subsection{I bit \acr{suid} e \acr{sgid}} -\label{sec:file_suid_sgid} - -Come si è accennato (in \secref{sec:file_perm_overview}) nei dodici bit del -campo \var{st\_mode} usati per il controllo di accesso oltre ai bit dei -permessi veri e propri, ci sono altri tre bit che vengono usati per indicare -alcune proprietà speciali dei file. Due di questi sono i bit detti -\acr{suid} (o \textit{set-user-ID bit}) e \acr{sgid} (o -\textit{set-group-ID bit}) che sono identificati dalle constanti -\macro{S\_ISUID} e \macro{S\_ISGID}. - -Come spiegato in dettaglio in \secref{sec:proc_exec}, quando si lancia un -programma il comportamendo normale del kernel è quello di settare -l'\textit{effective user id} e l'\textit{effective group id} del nuovo -processo all'\acr{uid} e al \acr{gid} del processo corrente, che normalmente -corrispondono dell'utente con cui si è entrati nel sistema. - -Se però il file del programma\footnote{per motivi di sicurezza il kernel - ignora i bit \acr{suid} e \acr{sgid} per gli script eseguibili} (che -ovviamente deve essere eseguibile) ha il bit \acr{suid} settato, il kernel -assegnerà come \textit{effective user id} al nuovo processo l'uid del -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 -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 -dall'amministratore, ma non è necessario chiamare l'amministratore per -cambiare la propria password. Infatti il comando \cmd{passwd} appartiene a -root ma ha il bit suid settato per cui quando viene lanciato da un utente -normale parte con i privilegi di root. +\subsection{Le funzioni \func{link} e \func{unlink}} +\label{sec:file_link} -Chiaramente avere un processo che ha privilegi superiori a quelli che avrebbe -normalmente l'utente che lo ha lanciato comporta vari rischi, e questo tipo di -programmi devono essere scritti accuratamente per evitare che possano essere -usati per guadagnare privilegi non consentiti (torneremo sull'argomento in -\secref{sec:proc_perms}). +Una caratteristica comune a diversi sistemi operativi è quella di poter creare +dei nomi fittizi (come gli alias del MacOS o i collegamenti di Windows) che +permettono di fare riferimento allo stesso file chiamandolo con nomi diversi +o accedendovi da directory diverse. -La presenza dei bit \acr{suid} e \acr{sgid} su un file può essere -rilevata con il comando \cmd{ls -l}, in tal caso comparirà la lettera \cmd{s} -al posto della \cmd{x} in corrispondenza dei permessi di utente o gruppo. La -stessa lettera \cmd{s} può essere usata nel comando \cmd{chmod} per settare -questi bit. Infine questi bit possono essere controllati all'interno di -\var{st\_mode} con l'uso delle due costanti \macro{S\_ISUID} e -\macro{S\_IGID}, i cui valori sono riportati in -\tabref{tab:file_mode_flags}. - -Gli stessi bit vengono ad assumere in significato completamente diverso per le -directory, normalmente infatti Linux usa la convenzione di SVR4 per indicare -con questi bit l'uso della semantica BSD nella creazione di nuovi file (si -veda \secref{sec:file_ownership} per una spiegazione dettagliata al -proposito). +Questo è possibile anche in ambiente unix, dove tali collegamenti sono +usualmente chiamati \textit{link}; ma data la struttura del sistema di +gestione dei file (ed in particolare quanto trattato in +\secref{sec:file_architecture}) ci sono due metodi sostanzialmente diversi per +fare questa operazione. -Infine Linux utilizza il bit \acr{sgid} per una ulteriore estensione -mutuata da SVR4. Il caso in cui il file abbia il bit \acr{sgid} settato ma -non il corrispondente bit di esecuzione viene utilizzato per attivare per -quel file il \textit{mandatory locking} (argomento che affronteremo nei -dettagli in \secref{sec:xxx_mandatory_lock}). +Come spiegato in \secref{sec:file_filesystem} 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 che fa +riferimento al suddetto 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. -\subsection{Il bit \textsl{sticky}} -\label{sec:file_sticky} +Per aggiungere un nome ad un inode si utilizza la funzione \func{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 \var{oldpath} + dandogli nome \var{newpath}. + + La funzione restituisce zero in caso di successo e -1 in caso di errore. La + variabile \var{errno} viene settata opportunamente, i principali codici di + errore sono: + \begin{errlist} + \item \macro{EXDEV} \var{oldpath} e \var{newpath} non sono sullo + stesso filesystem. + \item \macro{EPERM} il filesystem che contiene \var{oldpath} e + \macro{newpath} non supporta i link diretti o è una directory. + \item \macro{EEXIST} un file (o una directory) con quel nome esiste di + già. + \item \macro{EMLINK} ci sono troppi link al file \var{oldpath} (il + numero massimo è specificato dalla variabile \macro{LINK\_MAX}, vedi + \secref{sec:sys_limits}). + \end{errlist} + ed inoltre \macro{EACCES}, \macro{ENAMETOOLONG}, \macro{ENOTDIR}, + \macro{EFAULT}, \macro{ENOMEM}, \macro{EROFS}, \macro{ELOOP}, + \macro{ENOSPC}, \macro{EIO}. +\end{prototype} -L'ultimo dei bit rimanenti, identificato dalla costante \macro{S\_ISVTX}, è in -parte un rimasuglio delle origini dei sistemi unix. A quell'epoca infatti la -memoria virtuale e l'accesso ai files erano molto meno sofisticati e per -ottenere la massima velocità possibile per i programmi usati più comunemente -si poteva settare questo bit. +La creazione di un nuovo collegamento diretto non copia il contenuto del file, +ma si limita a creare una voce nella directory specificata con \var{newpath} e +ad aumentare di uno il numero di referenze al file (riportato nel campo +\var{st\_nlink} della struttura \var{stat}, vedi \secref{sec:file_stat}) +aggiungendo il nuovo nome ai precedenti. Si noti che uno stesso file può +essere così chiamato con vari nomi in diverse directory. + +Per quanto dicevamo in \secref{sec:file_filesystem} la creazione di un +collegamento diretto è possibile solo se entrambi i pathname sono nello stesso +filesystem; inoltre il filesystem deve supportare i collegamenti diretti (il +meccanismo non è disponibile ad esempio con il filesystem \acr{vfat} di +Windows). + +La funzione inoltre opera sia sui file ordinari che sugli altri oggetti del +filesystem, con l'eccezione delle directory. In alcuni versioni di unix solo +l'amministratore è in grado di creare un collegamento diretto ad un'altra +directory, questo viene fatto perché con una tale operazione è possibile +creare dei circoli nel filesystem (vedi l'esempio mostrato in +\secref{sec:file_symlink}, dove riprenderemo il discorso) che molti programmi +non sono in grado di gestire e la cui rimozione diventerebbe estremamente +complicata (in genere per questo tipo di errori occorre far girare il +programma \cmd{fsck} per riparare il filesystem). + +Data la pericolosità di questa operazione e la disponibilità dei link +simbolici che possono fornire la stessa funzionalità senza questi problemi, +nei filesystem usati in Linux questa caratteristica è stata completamente +disabilitata, e al tentativo di creare un link diretto ad una directory la +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 + 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 \var{errno} viene + settata secondo i seguenti codici di errore: + \begin{errlist} + \item \macro{EISDIR} \var{pathname} si riferisce ad una directory + (valore specifico ritornato da Linux che non consente l'uso di + \var{unlink} con le directory, e non conforme allo standard POSIX, che + prescrive invece l'uso di \macro{EPERM} in caso l'operazione non sia + consentita o il processo non abbia privilegi sufficienti). + \item \macro{EROFS} \var{pathname} è su un filesystem montato in sola + lettura. + \item \macro{EISDIR} \var{pathname} fa riferimento a una directory. + \end{errlist} + ed inoltre: \macro{EACCES}, \macro{EFAULT}, \macro{ENOENT}, \macro{ENOTDIR}, + \macro{ENOMEM}, \macro{EROFS}, \macro{ELOOP}, \macro{EIO}. +\end{prototype} -L'effetto di questo bit era che il segmento di testo del programma (si veda -\secref{sec:proc_mem_layout} per i dettagli) veniva scritto nella swap la -prima volta che questo veniva lanciato, e vi permaneva fino al riavvio della -mecchina (da questo il nome di \textsl{sticky bit}); essendo la swap un file -continuo indicizzato direttamente in questo modo si poteva risparmiare in -tempo di caricamento rispetto alla ricerca del file su disco. Lo -\textsl{sticky bit} è indicato usando la lettera \cmd{t} al posto della -\cmd{x} nei permessi per gli altri. +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 in \secref{sec:file_access_control}), +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). -Ovviamente per evitare che gli utenti potessero intasare la swap solo -l'amministratore era in grado di settare questo bit, che venne chiamato anche -con il nome di \textit{saved text bit}, da cui deriva quello della costante. -Le attuali implementazioni di memoria virtuale e filesystem rendono -sostanzialmente inutile questo procedimento. +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 (si veda +\secref{sec:proc_atom_oper}), per questo entrambe queste funzioni sono +realizzate tramite una singola system call. -Benché ormai non venga più utilizzato per i file, lo \textsl{sticky bit} ha -assunto un uso corrente per le directory\footnote{lo \textsl{sticky bit} per - le directory è una estensione non definita nello standard POSIX, Linux però - la supporta, così come BSD e SVR4}, in questo caso se il bit è settato un -file potrà essere rimosso dalla directory soltanto se l'utente ha il permesso -di scrittura ed inoltre è vera una delle seguenti condizioni: -\begin{itemize} -\item l'utente è proprietario del file -\item l'utente è proprietario della directory -\item l'utente è l'amministratore -\end{itemize} -un classico esempio di directory che ha questo bit settato è \file{/tmp}, i -permessi infatti di solito sono settati come: -\begin{verbatim} -$ ls -ld /tmp -drwxrwxrwt 6 root root 1024 Aug 10 01:03 /tmp -\end{verbatim}%$ -in questo modo chiunque può leggere, scrivere ed eseguire i file temporanei -ivi memorizzati, sia crearne di nuovi, ma solo l'utente che ha creato un file -nella directory potrà cancellarlo o rinominarlo, così si può evitare che un -utente possa, più o meno consapevolemnte, cancellare i file degli altri. +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. +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 \func{unlink} subito dopo, in questo modo il +contenuto del file è sempre disponibile all'interno del processo attraverso il +suo file descriptor (vedi \secref{sec:file_fd}) fintanto che il processo non +chiude il file, ma non ne resta traccia in nessuna directory, e lo spazio +occupato su disco viene immediatamente rilasciato alla conclusione del +processo (quando tutti i file vengono chiusi). -\subsection{La titolarità di nuovi file e directory} -\label{sec:file_ownership} -Vedremo in \secref{sec:file_base_func} come creare nuovi file, ma se è -possibile specificare in sede di creazione quali permessi applicare ad un -file, non si può indicare a quale utente e gruppo esso deve appartenere. Lo -stesso problema di presenta per la creazione di nuove directory (procedimento -descritto in \secref{sec:file_dir_creat_rem}). +\subsection{Le funzioni \func{remove} e \func{rename}} +\label{sec:file_remove} -Lo standard POSIX prescrive che l'uid del nuovo file corrisponda -all'\textit{effective user id} del processo che lo crea; per il \acr{gid} -invece prevede due diverse possibilità: -\begin{itemize} -\item il \acr{gid} del file corrisponde all'\textit{effective group id} del - processo. -\item il \acr{gid} del file corrisponde al gid della directory in cui esso è - creato. -\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 -\acr{gid} del processo, se però la directory in cui viene creato il file ha il -bit \acr{sgid} settato allora viene usata la seconda opzione.. +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 +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). 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 errore vedi quanto + riportato nelle descrizioni di \func{unlink} e \func{rmdir}. +\end{prototype} -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 una maggiore -possibilità di scelta, ma per ottenere lo stesso risultato necessita che per -le nuove directory venga anche propagato anche il bit \acr{sgid}. Questo è -comunque il comportamento di default di \func{mkdir}, ed é in questo modo ad -esempio che Debian assicura che le sottodirectory create nelle home di un -utente restino sempre con il \acr{gid} del gruppo primario dello stesso. +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)} + + Rinomina \var{oldpath} in \var{newpath}, eseguendo se necessario lo + spostamento di un file fra directory diverse. Eventuali altri link diretti + allo stesso file non vengono influenzati. + + La funzione restituisce zero in caso di successo e -1 per un errore, nel + qual caso il file non viene toccato. La variabile \var{errno} viene settata + secondo i seguenti codici di errore: + \begin{errlist} + \item \macro{EISDIR} \var{newpath} è una directory mentre \var{oldpath} non + è una directory. + \item \macro{EXDEV} \var{oldpath} e \var{newpath} non sono sullo stesso + filesystem. + \item \macro{ENOTEMPTY} \var{newpath} è una directory già esistente e non + vuota. + \item \macro{EBUSY} o \var{oldpath} o \var{newpath} sono in uso da parte di + qualche processo (come directory di lavoro o come radice) o del sistema + (come mount point). + \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{ENOTDIR} Uno dei componenti dei pathname non è una directory o + \var{oldpath} è una directory e \var{newpath} esiste e non è una + directory. + \end{errlist} + 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 +un file o una directory; se ci riferisce a un file allora \var{newpath}, se +esiste, non deve essere una directory (altrimenti si ha l'errore +\macro{EISDIR}). Nel caso \var{newpath} indichi un file esistente questo viene +cancellato e rimpiazzato (atomicamente). + +Se \var{oldpath} è una directory allora \var{newpath} se esiste deve essere +una directory vuota, altrimenti si avranno gli errori \macro{ENOTDIR} (se non +è una directory) o \macro{ENOTEMPTY} (se non è vuota). Chiaramente +\var{newpath} non può contenere \var{oldpath} altrimenti si avrà un errore +\macro{EINVAL}. + +Se \var{oldpath} si riferisce a un link simbolico questo sarà rinominato; se +\var{newpath} è un link simbolico verrà cancellato come qualunque altro file. +Infine qualora \var{oldpath} e \var{newpath} siano due nomi dello stesso file +lo standard POSIX prevede che la funzione non dia errore, e non faccia nulla, +lasciando entrambi i nomi; Linux segue questo standard, anche se come fatto +notare dal manuale delle glibc, il comportamento più ragionevole sarebbe +quello di cancellare \var{oldpath}. + +Il vantaggio nell'uso di questa funzione al posto della chiamata successiva di +\func{link} e \func{unlink} è che l'operazione è eseguita atomicamente, non +può esistere cioè nessun istante in cui un altro processo può trovare attivi +entrambi i nomi dello stesso file, o, in caso di sostituzione di un file +esistente, non trovare quest'ultimo prima che la sostituzione sia stata +eseguita. + +In ogni caso se \var{newpath} esiste e l'operazione fallisce per un qualche +motivo (come un crash del kernel), \func{rename} garantisce di lasciare +presente una istanza di \var{newpath}, tuttavia nella sovrascrittura potrà +esistere una finestra in cui sia \var{oldpath} che \var{newpath} fanno +riferimento allo stesso file. -\subsection{La funzione \texttt{access}} -\label{sec:file_access} -Come detto in \secref{sec:file_access_control} il controllo di accesso ad -un file viene fatto usando \textit{effective user id} e \textit{effective - group id} del processo, ma ci sono casi in cui si può voler effettuare il -controllo usando il \textit{real user id} e il \textit{real group id} (cioè -l'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 è: +\subsection{I link simbolici} +\label{sec:file_symlink} -\begin{prototype}{unistd.h} -{int access(const char *pathname, int mode)} +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 filesystem e solo per un filesystem di tipo unix. +Inoltre abbiamo visto che in Linux non è consentito eseguire un link diretto +ad una directory. - La funzione verifica i permessi di accesso, indicati da \var{mode}, per il - file indicato da \var{pathname}. +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, 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}) 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 è + \func{oldpath}. - La funzione ritorna 0 se l'accesso è consentito, -1 altrimenti; in - quest'ultimo caso la variabile \texttt{errno} viene settata secondo i codici - di errore: \macro{EACCES}, \macro{EROFS}, \macro{EFAULT}, \macro{EINVAL}, - \macro{ENAMETOOLONG}, \macro{ENOENT}, \macro{ENOTDIR}, \macro{ELOOP}, + 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{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{EFAULT}, \macro{EACCES}, \macro{ENAMETOOLONG}, + \macro{ENOTDIR}, \macro{ENOMEM}, \macro{ELOOP}, \macro{ENOSPC} e \macro{EIO}. \end{prototype} -I valori possibili per il parametro \var{mode} sono esprimibili come -combinazione delle costanti numeriche riportate in \ntab\ (attraverso un OR -binario). I primi tre valori implicano anche la verifica dell'esistenza del -file, se si vuole verificare solo quest'ultimaa si può usare \macro{F\_OK}, o -anche direttamente \func{stat}. In caso \var{pathname} si riferisca ad un link -simbolico il controllo è fatto sul file a cui esso fa riferimento. +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}. -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 -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. +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 - \begin{tabular}{|c|l|} - \hline - \var{mode} & Significato \\ - \hline - \hline - \macro{R\_OK} & verifica il permesso di lettura \\ - \macro{W\_OK} & verifica il permesso di scritture \\ - \macro{X\_OK} & verifica il permesso di esecuzione \\ - \macro{F\_OK} & verifica l'esistenza del file \\ + \footnotesize + \begin{tabular}[c]{|l|c|c|} \hline + \textbf{Funzione} & \textbf{Segue il link} & \textbf{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{Valori possibile per il parametro \var{mode} della funzione - \func{access}} - \label{tab:file_access_mode_val} + \caption{Uso dei link simbolici da parte di alcune funzioni.} + \label{tab:file_symb_effect} \end{table} -Un esempio tipico per l'uso di questa funzione è quello di un processo che sta -eseguendo un programma coi privilegi di un altro utente (attraverso l'uso del -suid bit) che vuole controllare se l'utente originale ha i permessi per -accedere ad un certo file. +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}) 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. -\subsection{Le funzioni \texttt{chmod} e \texttt{fchmod}} -\label{sec:file_chmod} -Per cambiare i permessi di un file il sistema mette ad disposizione due -funzioni, che operano rispettivamente su un filename e su un file descriptor, -i cui prototipi sono: +\begin{figure}[htb] + \centering + \includegraphics[width=5cm]{img/link_loop} + \caption{Esempio di loop nel filesystem creato con un link simbolico.} + \label{fig:file_link_loop} +\end{figure} -\begin{functions} - \headdecl{sys/types.h} - \headdecl{sys/stat.h} - - \funcdecl{int chmod(const char *path, mode\_t mode)} Cambia i permessi del - file indicato da \var{path} al valore indicato da \var{mode}. +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 effettuano la +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. + +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}%$ +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 che invece \cmd{ls} ci +mostrerebbe l'esistenza di \file{temporaneo}. + + +\subsection{Le funzioni \func{mkdir} e \func{rmdir}} +\label{sec:file_dir_creat_rem} + +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 +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}, + assegnandole i permessi indicati da \var{mode}. Il nome può essere indicato + con il pathname assoluto o relativo. - \funcdecl{int fchmod(int fd, mode\_t mode)} Analoga alla precedente, ma usa - il file descriptor \var{fd} per indicare il file. + La funzione restituisce zero in caso di successo e -1 per un errore, nel + qual caso \var{errno} assumerà i valori: + \begin{errlist} + \item \macro{EEXIST} Un file (o una directory) con quel nome esiste di già. + \item \macro{EACCESS} + Non c'è il permesso di scrittura per la directory in cui si vuole inserire + la nuova directory. + \item \macro{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 nel disco, ma potendo avere a che + fare anche con filesystem di altri sistemi questo errore può presentarsi. + \item \macro{ENOSPC} Non c'è abbastanza spazio sul file system per creare + la nuova directory o si è esaurita la quota disco dell'utente. + \end{errlist} + ed inoltre anche \macro{EPERM}, \macro{EFAULT}, \macro{ENAMETOOLONG}, + \macro{ENOENT}, \macro{ENOTDIR}, \macro{ENOMEM}, \macro{ELOOP}, + \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. - Le funzioni restituiscono zero in caso di successo e -1 per un errore, in - caso di errore \texttt{errno} può assumere i valori: + La funzione restituisce zero in caso di successo e -1 per un errore, nel + qual caso \var{errno} assumerà i valori: \begin{errlist} - \item \macro{EPERM} L'\textit{effective user id} non corrisponde a quello - del proprietario del file o non è zero. + \item \macro{EPERM} Il filesystem non supporta la cancellazione di + directory, oppure la directory che contiene \var{dirname} ha lo sticky bit + settato e l'\textit{effective user id} del processo non corrisponde al + proprietario della directory. + \item \macro{EACCESS} Non c'è il permesso di scrittura per la directory che + contiene la directory che si vuole cancellare, o non c'è il permesso di + attraversare (esecuzione) una delle directory specificate in + \var{dirname}. + \item \macro{EBUSY} La directory specificata è la directory di lavoro o la + radice di qualche processo. + \item \macro{ENOTEMPTY} La directory non è vuota. \end{errlist} - ed inoltre \macro{EROFS} e \macro{EIO}; \func{chmod} restituisce anche - \macro{EFAULT}, \macro{ENAMETOOLONG}, \macro{ENOENT}, \macro{ENOMEM}, - \macro{ENOTDIR}, \macro{EACCES}, \macro{ELOOP}; \func{fchmod} anche - \macro{EBADF}. -\end{functions} - -I valori possibili per \var{mode} sono indicati in \ntab. I valori possono -esser combinati con l'OR binario delle relative macro, o specificati -direttamente, come per l'analogo comando di shell, con il valore ottale. Ad -esempio i permessi standard assegnati ai nuovi file (lettura e scrittura per -il proprietario, sola lettura per il gruppo e gli altri) sono corrispondenti -al valore ottale $0644$, un programma invece avrebbe anche il bit di -esecuzione attivo, con un valore di $0755$, se si volesse attivare il bit suid -il valore da fornire sarebbe $4755$. - -\begin{table}[!htb] - \centering - \begin{tabular}[c]{|c|c|l|} - \hline - \var{mode} & Valore & Significato \\ - - \hline - \hline - \macro{S\_ISUID} & 04000 & set user ID \\ - \macro{S\_ISGID} & 02000 & set group ID \\ - \macro{S\_ISVTX} & 01000 & sticky bit \\ - \hline - \macro{S\_IRWXU} & 00700 & l'utente ha tutti i permessi \\ - \macro{S\_IRUSR} & 00400 & l'utente ha il permesso di lettura \\ - \macro{S\_IWUSR} & 00200 & l'utente ha il permesso di scrittura \\ - \macro{S\_IXUSR} & 00100 & l'utente ha il permesso di esecuzione \\ - \hline - \macro{S\_IRWXG} & 00070 & il gruppo ha tutti i permessi \\ - \macro{S\_IRGRP} & 00040 & il gruppo ha il permesso di lettura \\ - \macro{S\_IWGRP} & 00020 & il gruppo ha il permesso di scrittura \\ - \macro{S\_IXGRP} & 00010 & il gruppo ha il permesso di esecuzione \\ - \hline - \macro{S\_IRWXO} & 00007 & gli altri hanno tutti i permessi \\ - \macro{S\_IROTH} & 00004 & gli altri hanno il permesso di lettura \\ - \macro{S\_IWOTH} & 00002 & gli altri hanno il permesso di scrittura \\ - \macro{S\_IXOTH} & 00001 & gli altri hanno il permesso di esecuzione \\ - \hline - \end{tabular} - \caption{I valori delle costanti usate per indicare i permessi dei file.} - \label{tab:file_permission_const} -\end{table} + ed inoltre anche \macro{EFAULT}, \macro{ENAMETOOLONG}, \macro{ENOENT}, + \macro{ENOTDIR}, \macro{ENOMEM}, \macro{ELOOP}, \macro{EROFS}. +\end{prototype} -Il cambiamento dei permessi di un file attraverso queste funzioni ha comunque -alcune limitazioni, provviste per motivi di sicurezza. Questo significa che -anche se si è proprietari del file non tutte le operazioni sono permesse, in -particolare: -\begin{itemize} -\item siccome solo l'amministratore può settare lo \textit{sticky bit} se se - l'\textit{effective user id} del processo non è zero esso viene - automaticamente cancellato (senza notifica di errore) qualora sia stato - indicato in \var{mode}. -\item per via della semantica SVR4 nella creazione dei nuovi file, si può - avere il caso in cui il file creato da un processo è assegnato a un gruppo - per il quale il processo non ha privilegi. Per evitare che si possa - assegnare il bit \acr{sgid} ad un file appartenente a un gruppo per cui - non si hanno diritti, questo viene automaticamente cancellato (senza - notifica di errore) da \var{mode} qualora il gruppo del file non corrisponda - a quelli associati al processo (la cosa non avviene quando - l'\textit{effective user id} del processo è zero). -\end{itemize} +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. -Per alcuni filesystem\footnote{il filesystem \textsl{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 -processo che non appartenga all'amministratore scriva su un file. In questo -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{Accesso alle directory} +\label{sec:file_dir_read} -\subsection{La funzione \texttt{umask}} -\label{sec:file_umask} +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. 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. -Oltre che dai valori indicati in sede di creazione, i permessi assegnati ai -nuovi file sono controllati anche da una maschera di bit settata con la -funzione \func{umask}, il cui prototipo è: +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}. -\begin{prototype}{stat.h} -{mode\_t umask(mode\_t mask)} +(NdA Il resto va scritto!!! É noioso e lo farò più avanti). - Setta la maschera dei permessi dei bit al valore specificato da \var{mask} - (di cui vengono presi solo i 9 bit meno significativi). - - La funzione ritorna il precedente valore della maschera. È una delle poche - funzioni che non restituisce codici di errore. -\end{prototype} -Questa maschera è una caratteristica di ogni processo e viene utilizzata per -impedire che alcuni permessi possano essere assegnati ai nuovi file in sede di -creazione, i bit indicati nella maschera vengono infatti esclusi quando un -nuovo file viene creato. +\subsection{La directory di lavoro} +\label{sec:file_work_dir} -In genere questa maschera serve per impostare un default che escluda alcuni -permessi (usualmente quello di scrittura per il gruppo e gli altri, -corrispondente ad un valore di $022$). Essa è utile perché le routine -dell'interfaccia ANSI C degli stream non prevedono l'esistenza dei permessi, e -pertanto tutti i nuovi file vengono sempre creati con un default di $666$ -(cioè permessi di lettura e scrittura per tutti, si veda -\tabref{tab:file_permission_const} per un confronto); in questo modo è -possibile cancellare automaticamente i permessi non voluti, senza doverlo fare -esplicitamente. +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, dove il relativa fa riferimento appunto a questa directory. -In genere il valore di \func{umask} viene stabilito una volta per tutte al -login a $022$, e di norma gli utenti non hanno motivi per modificarlo. Se però -si vuole che un processo possa creare un file che chiunque possa leggere -allora occorrerà cambiare il valore di \func{umask}. +Quando un utente effettua il login questa directory viene settata alla +\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. -\subsection{Le funzioni \texttt{chown}, \texttt{fchown} e \texttt{lchown}} -\label{sec:file_chown} +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}. + + 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. + \item \macro{ERANGE} L'argomento \var{size} è più piccolo della + lunghezza del pathname. + \item \macro{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} -Come per i permessi, il sistema fornisce anche delle funzioni che permettano -di cambiare utente e gruppo cui il file appartiene; le funzioni in questione -sono tre e i loro prototipi sono i seguenti: +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 restituisce 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 +dimensione superiore a \macro{PATH\_MAX} (di solito 256 byte, vedi +\secref{sec:sys_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 è \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{sys/types.h} - \headdecl{sys/stat.h} + \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}. - \funcdecl{int chown(const char *path, uid\_t owner, gid\_t group)} - \funcdecl{int fchown(int fd, uid\_t owner, gid\_t group)} - \funcdecl{int lchown(const char *path, uid\_t owner, gid\_t group)} - - Le funzioni cambiano utente e gruppo di appartenenza di un file ai valori - specificati dalle variabili \var{owner} e \var{group}. - - Le funzioni restituiscono zero in caso di successo e -1 per un errore, in - caso di errore \texttt{errno} viene settato ai valori: + \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 per \func{chdir} ai + valori: \begin{errlist} - \item \macro{EPERM} L'\textit{effective user id} non corrisponde a quello - del proprietario del file o non è zero, o utente e gruppo non sono validi + \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} - Oltre a questi entrambe restituiscono gli errori \macro{EROFS} e - \macro{EIO}; \func{chown} restituisce anche \macro{EFAULT}, - \macro{ENAMETOOLONG}, \macro{ENOENT}, \macro{ENOMEM}, \macro{ENOTDIR}, - \macro{EACCES}, \macro{ELOOP}; \func{fchown} anche \macro{EBADF}. + 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} -In Linux soltanto l'amministratore può cambiare il proprietario di un file, -seguendo la semantica di BSD che non consente agli utenti di assegnare i loro -file ad altri (per evitare eventuali aggiramenti delle quote). -L'amministratore può cambiare il gruppo di un file, il proprietario può -cambiare il gruppo dei file che gli appartengono solo se il nuovo gruppo è il -suo gruppo primario o uno dei gruppi a cui appartiene. - -La funzione \func{chown} segue i link simbolici, per operare direttamente su -in link simbolico si deve usare la funzione \func{lchown}\footnote{fino alla - versione 2.1.81 in Linux \func{chown} non seguiva i link simbolici, da - allora questo comportamento è stato assegnato alla funzione \func{lchown}, - introdotta per l'occazione, ed è stata creata una nuova system call per - \func{chown} che seguisse i link simbolici}. La funzione \func{fchown} opera -su un file aperto, essa è mututata da BSD, ma non è nello standard POSIX. -Un'altra estensione rispetto allo standard POSIX è che specificando -1 come -valore per \var{owner} e \var{group} i valori restano immutati. - -Quando queste funzioni sono chiamate con successo da un processo senza i -privilegi di root entrambi i bit \acr{suid} e \acr{sgid} vengono -cancellati. Questo non avviene per il bit \acr{sgid} nel caso in cui esso -sia usato (in assenza del corrispondente permesso di esecuzione) per indicare -che per il file è attivo il \textit{mandatory locking}. - -%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}). - \section{La manipolazione delle caratteristiche dei files} @@ -601,19 +624,19 @@ generali relative alle caratteristiche di ciascun file, a partire dalle informazioni relative al controllo di accesso, sono mantenute nell'inode. Vedremo in questa sezione come sia possibile leggere tutte queste informazioni -usando la funzione \texttt{stat}, che permette l'accesso a tutti i dati +usando la funzione \func{stat}, che permette l'accesso a tutti i dati memorizzati nell'inode; esamineremo poi le varie funzioni usate per manipolare tutte queste informazioni (eccetto quelle che riguardano la gestione del -controllo di accesso, già trattate in in \secref{sec:file_access_control}). +controllo di accesso, trattate in in \secref{sec:file_access_control}). -\subsection{Le funzioni \texttt{stat}, \texttt{fstat} e \texttt{lstat}} +\subsection{Le funzioni \func{stat}, \func{fstat} e \func{lstat}} \label{sec:file_stat} La lettura delle informazioni relative ai file è fatta attraverso la famiglia -delle funzioni \func{stat}; questa è la funzione che il comando \cmd{ls} usa -per poter ottenere e mostrare tutti i dati dei files. I prototipi di queste -funzioni sono i seguenti: +delle funzioni \func{stat}; questa è la funzione che ad esempio usa il comando +\cmd{ls} per poter ottenere e mostrare tutti i dati dei files. I prototipi di +queste funzioni sono i seguenti: \begin{functions} \headdecl{sys/types.h} \headdecl{sys/stat.h} @@ -632,12 +655,12 @@ funzioni sono i seguenti: descriptor \var{filedes}. Le funzioni restituiscono zero in caso di successo e -1 per un errore, in - caso di errore \texttt{errno} può assumere uno dei valori: \macro{EBADF}, + caso di errore \var{errno} può assumere uno dei valori: \macro{EBADF}, \macro{ENOENT}, \macro{ENOTDIR}, \macro{ELOOP}, \macro{EFAULT}, \macro{EACCESS}, \macro{ENOMEM}, \macro{ENAMETOOLONG}. \end{functions} -La struttura \texttt{stat} è definita nell'header \texttt{sys/stat.h} e in +La struttura \var{stat} è definita nell'header \file{sys/stat.h} e in generale dipende dall'implementazione, la versione usata da Linux è mostrata in \nfig, così come riportata dalla man page (in realtà la definizione effettivamente usata nel kernel dipende dall'architettura e ha altri campi @@ -666,14 +689,14 @@ 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} Si noti come i vari membri della struttura siano specificati come tipi nativi del sistema (di quelli definiti in \tabref{tab:xxx_sys_types}, e dichiarati in -\texttt{sys/types.h}). +\file{sys/types.h}). \subsection{I tipi di file} @@ -681,25 +704,25 @@ del sistema (di quelli definiti in \tabref{tab:xxx_sys_types}, e dichiarati in Come riportato in \tabref{tab:file_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} +il tipo di file è ritornato dalla \func{stat} nel campo \var{st\_mode} (che è quello che contiene anche le informazioni relative ai permessi). 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 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. +simbolici e socket definite da BSD, l'elenco completo di tutte le macro è +riportato in \ntab. \begin{table}[htb] \centering \footnotesize \begin{tabular}[c]{|l|l|} \hline - Macro & Tipo del file \\ + \textbf{Macro} & \textbf{Tipo del file} \\ \hline \hline \macro{S\_ISREG(m)} & file regolare \\ \macro{S\_ISDIR(m)} & directory \\ - \macro{S\_ISCHR(m)} & device a caraetteri \\ + \macro{S\_ISCHR(m)} & device a caratteri \\ \macro{S\_ISBLK(m)} & device a blocchi\\ \macro{S\_ISFIFO(m)} & fifo \\ \macro{S\_ISLNK(m)} & link simbolico \\ @@ -712,14 +735,14 @@ definite in GNU/Linux Oltre a queste macro è possibile usare direttamente il valore di \var{st\_mode} per ricavare il significato dei vari bit in esso memorizzati, -per questo sempre in \texttt{sys/stat.h} sono definiti i flag riportati in +per questo sempre in \file{sys/stat.h} sono definiti i flag riportati in \ntab: \begin{table}[htb] \centering \footnotesize \begin{tabular}[c]{|l|c|l|} \hline - Flag & Valore & Significato \\ + \textbf{Flag} & \textbf{Valore} & \textbf{Significato} \\ \hline \hline \macro{S\_IFMT} & 0170000 & bitmask per i bit del tipo di file \\ @@ -752,7 +775,7 @@ per questo sempre in \texttt{sys/stat.h} sono definiti i flag riportati in \hline \end{tabular} \caption{Costanti per l'identificazione dei vari bit che compongono il campo - \var{st\_mode} (definite in \texttt{sys/stat.h})} + \var{st\_mode} (definite in \file{sys/stat.h})} \label{tab:file_mode_flags} \end{table} @@ -776,7 +799,7 @@ Il membro \var{st\_size} contiene la dimensione del file in byte (se il file pathname che contiene). Il campo \var{st\_blocks} definisce la lunghezza del file in blocchi di 512 -bytes. Il campo \var{st\_blksize} infine definisce la dimensione preferita per +byte. Il campo \var{st\_blksize} infine definisce la dimensione preferita per i trasferimenti sui file (che è la dimensione usata anche dalle librerie del C per l'interfaccia degli stream); scrivere sul file a blocchi di dati di dimensione inferiore sarebbe inefficiente. @@ -791,18 +814,18 @@ corrente. In tal caso si avranno differenti risultati a seconda del modi in cui si calcola la lunghezza del file, ad esempio il comando \cmd{du}, (che riporta il numero di blocchi occupati) potrà dare una dimensione inferiore, mentre se si -legge dal file (ad esempio usando \cmd{wc -c}), dato che in tal caso per le -parti non scritte vengono restituiti degli zeri, si avrà lo stesso risultato -di \cmd{ls}. - -Se è sempre possibile allargare un file scrivendoci sopra od usando la -funzione \func{seek} per spostarsi oltre la sua fine. Esistono però anche casi -in cui si può avere bisogno di effettuare un troncamento scartando i dati al -di là della dimensione scelta come nuova fine del file. - -Un file può essere troncato a zero aprendolo con il flag \macro{O\_TRUNC}, ma -questo è un caso particolare; per qualunque altra dimensione si possono usare -le due funzioni: +legge dal file (ad esempio usando il comando \cmd{wc -c}), dato che in tal +caso per le parti non scritte vengono restituiti degli zeri, si avrà lo stesso +risultato di \cmd{ls}. + +Se è sempre possibile allargare un file, scrivendoci sopra od usando la +funzione \func{seek} per spostarsi oltre la sua fine, esistono anche casi in +cui si può avere bisogno di effettuare un troncamento, scartando i dati +presenti al di là della dimensione scelta come nuova fine del file. + +Un file può sempre essere troncato a zero aprendolo con il flag +\macro{O\_TRUNC}, ma questo è un caso particolare; per qualunque altra +dimensione si possono usare le due funzioni: \begin{functions} \headdecl{unistd.h} \funcdecl{int truncate(const char *file\_name, off\_t length)} Fa si che la dimensione del file \var{file\_name} sia troncata ad @@ -812,19 +835,19 @@ le due funzioni: eccetto che si usa con un file aperto, specificato tramite il suo file descriptor \var{fd}. - Le funzioni restituiscono zero in caso di successo e -1 per un errore, in - caso di errore \texttt{errno} viene settato opportunamente; per - \func{ftruncate} si hanno i valori: + Le funzioni restituiscono zero in caso di successo e -1 per un errore, nel + qual caso \var{errno} viene settato opportunamente; per \func{ftruncate} si + hanno i valori: \begin{errlist} \item \macro{EBADF} \var{fd} non è un file descriptor. - \item \texttt{EINVAL} \var{fd} è un riferimento ad un socket, non a un file + \item \macro{EINVAL} \var{fd} è un riferimento ad un socket, non a un file o non è aperto in scrittura. \end{errlist} per \func{truncate} si hanno: \begin{errlist} - \item \texttt{EACCES} il file non ha permesso di scrittura o non si ha il + \item \macro{EACCES} il file non ha permesso di scrittura o non si ha il permesso di esecuzione una delle directory del pathname. - \item \texttt{ETXTBSY} Il file è un programma in esecuzione. + \item \macro{ETXTBSY} Il file è un programma in esecuzione. \end{errlist} ed anche \macro{ENOTDIR}, \macro{ENAMETOOLONG}, \macro{ENOENT}, \macro{EROFS}, \macro{EIO}, \macro{EFAULT}, \macro{ELOOP}. @@ -834,23 +857,25 @@ Se il file 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). +zeri (e in genere si ha la creazione di un \textit{hole} nel file). \subsection{I tempi dei file} \label{sec:file_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:file_stat_struct}. Il significato di detti tempi e -dei relativi campi è riportato nello schema in \ntab: +nell'inode insieme agli altri attributi del file e possono essere letti +tramite la funzione \func{stat}, che li restituisce attraverso tre campi della +struttura \var{stat} di \figref{fig:file_stat_struct}. Il significato di detti +tempi e dei relativi campi è riportato nello schema in \ntab: \begin{table}[htb] \centering + \footnotesize \begin{tabular}[c]{|c|l|l|c|} \hline - Membro & Significato & Funzione&opzione \\ + \textbf{Membro} & \textbf{Significato} & \textbf{Funzione} + & \textbf{Opzione} \\ \hline \hline \var{st\_atime}& ultimo accesso ai dati del file &\func{read}& \cmd{-u}\\ @@ -865,7 +890,7 @@ dei relativi campi 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 +cambiamento di stato (il \textit{change 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 @@ -874,9 +899,9 @@ 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). +tempo di ultimo accesso (ai dati) 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 @@ -889,27 +914,35 @@ 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. +directory sono file (che contengono una lista di nomi) che il sistema tratta +in maniera del tutto analoga a tutti gli 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. +comporta una modifica del nome contenuto nella directory, 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, invece leggere o +scrivere o cambiare i permessi di un file ha effetti solo sui tempi di +quest'ultimo. \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} \\ + \multicolumn{1}{|p{3cm}|}{\centering{\vspace{6pt}\textbf{Funzione}}} & + \multicolumn{3}{|p{3cm}|}{\centering{File o directory di riferimento}}& + \multicolumn{3}{|p{3cm}|}{\centering{Directory genitrice del riferimento}} + &\multicolumn{1}{|p{3.6cm}|}{\centering{\vspace{6pt}\textbf{Note}}} \\ \cline{2-7} - & \textsl{(a)} & \textsl{(m)}& \textsl{(c)} - & \textsl{(a)} & \textsl{(m)}& \textsl{(c)}& \\ + \cline{2-7} + \multicolumn{1}{|p{3cm}|}{} + &\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(a)}}} + &\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(m)}}} + &\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(c)}}} + &\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(a)}}} + &\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(m)}}} + &\multicolumn{1}{|p{.8cm}|}{\centering{\textsl{(c)}}} + &\multicolumn{1}{|p{3cm}|}{} \\ \hline \hline \func{chmod}, \func{fchmod} @@ -956,540 +989,641 @@ cambiarne i permessi ha effetti solo sui tempi del file. & &$\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)}} + \caption{Prospetto dei cambiamenti effettuati sui tempi di ultimo + accesso \textsl{(a)}, ultima modifica \textsl{(m)} e ultimo cambiamento + \textsl{(c)} dalle varie funzioni operanti su file e directory.} \label{tab:file_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 +creazione del file, usato in molti altri sistemi operativi, ma che in unix non esiste. -\subsection{La funzione \texttt{utime}} -\label{sec:file_utime} +\subsection{La funzione \func{utime}} +\label{sec:file_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 \macro{EACCESS} non si ha il permesso di scrittura sul file. +\item \macro{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 è \macro{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 +in questo modo la cosa è molto più complicata da realizzare. + + + +\section{Il controllo di accesso ai file} +\label{sec:file_access_control} + +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:file_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 i permessi 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 (\acr{uid} e \acr{gid}). Questi valori +sono accessibili da programma tramite i campi \var{st\_uid} e \var{st\_gid} +della struttura \var{stat} (si veda \secref{sec:file_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. + +I permessi, così come vengono presi dai comandi e dalle routine di sistema, +sono espressi da un numero 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 nei comandi di sistema con le lettere \cmd{w}, \cmd{r} e +\cmd{x}) ed applicabili rispettivamente al proprietario, al gruppo, a tutti +gli altri. I restanti tre bit (\acr{suid}, \acr{sgid}, e +\textsl{sticky}) sono usati per indicare alcune caratteristiche più complesse +su cui torneremo in seguito (vedi \secref{sec:file_suid_sgid} e +\secref{sec:file_sticky}). + +Anche i permessi, come tutte le altre informazioni generali, sono tenuti per +ciascun file nell'inode; in particolare essi sono contenuti in alcuni bit +del campo \var{st\_mode} della struttura letta da \func{stat} (di nuovo si veda +\secref{sec:file_stat} per i dettagli). + +In genere ci si riferisce a questo raggruppamento dei permessi usando le +lettere \cmd{u} (per \textit{user}), \cmd{g} (per \textit{group}) e \cmd{o} +(per \textit{other}), inoltre se si vuole indicare tutti i raggruppamenti +insieme si usa la lettera \cmd{a} (per \textit{all}). Si tenga ben presente +questa distinzione dato che in certi casi, mutuando la terminologia in uso nel +VMS, si parla dei permessi base come di permessi per \textit{owner}, +\textit{group} ed \textit{all}, le cui iniziali possono dar luogo a confusione. +Le costanti che permettono di accedere al valore numerico di questi bit nel +campo \var{st\_mode} sono riportate in \ntab. + +\begin{table}[htb] + \centering + \footnotesize + \begin{tabular}[c]{|c|l|} + \hline + \textbf{\var{st\_mode}} bit & \textbf{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} + +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). + +Avere 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. Avere 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 del contenuto del file dal +disco), non è necessario nessun tipo di permesso per il file stesso (infatti +esso non viene toccato, viene solo modificato il contenuto della directory, +rimuovendo la voce che ad esso fa rifermento). + +Per poter eseguire un file (che sia un programma compilato od uno script di +shell, od un altro tipo di file eseguibile riconosciuto dal kernel), occorre +avere il permesso di esecuzione, inoltre solo i file regolari possono essere +eseguiti. + +I permessi per un link simbolico sono ignorati, contano quelli del file a cui +fa riferimento; per questo in genere \cmd{ls} per un link simbolico riporta +tutti i permessi come concessi; utente e gruppo a cui esso appartiene vengono +ignorati quando il link viene risolto, vengono controllati solo quando viene +richiesta la rimozione del link e quest'ultimo è in una directory con lo +\textsl{sticky bit} settato (si veda \secref{sec:file_sticky}). + +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\footnote{in realtà Linux per quanto riguarda l'accesso ai file + utilizza al posto degli \textit{effective id} i \textit{filesystem id} (si + veda \secref{sec:proc_perms}), ma essendo questi del tutto equivalenti ai + primi, eccetto il caso in cui si voglia scrivere un server NFS, ignoreremo + questa differenza}. + +Per una spiegazione dettagliata degli identificatori associati ai processi si +veda \secref{sec:proc_perms}; normalmente, a parte quanto vedremo in +\secref{sec:file_suid_sgid}, l'\textit{effective user id} e +l'\textit{effective group id} corrispondono a \acr{uid} e \acr{gid} +dell'utente che ha lanciato il processo, mentre i \textit{supplementary group + id} sono quelli dei gruppi cui l'utente appartiene. + +I passi attraverso i quali viene stabilito se il processo possiede il diritto +di accesso sono i seguenti: +\begin{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'\acr{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 \acr{gid} del + file allora: + \begin{itemize} + \item se il bit dei permessi d'accesso del gruppo è settato, l'accesso è + consentito, + \item 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. + -I tempi di ultimo accesso e modifica possono essere cambiati usando la -funzione \func{utime}, il cui prototipo è: +\subsection{I bit \acr{suid} e \acr{sgid}} +\label{sec:file_suid_sgid} -\begin{prototype}{utime.h} -{int utime(const char * filename, struct utimbuf *times)} +Come si è accennato (in \secref{sec:file_perm_overview}) nei dodici bit del +campo \var{st\_mode} usati per il controllo di accesso oltre ai bit dei +permessi veri e propri, ci sono altri tre bit che vengono usati per indicare +alcune proprietà speciali dei file. Due di questi sono i bit detti +\acr{suid} (o \textit{set-user-ID bit}) e \acr{sgid} (o +\textit{set-group-ID bit}) che sono identificati dalle costanti +\macro{S\_ISUID} e \macro{S\_ISGID}. -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. +Come spiegato in dettaglio in \secref{sec:proc_exec}, quando si lancia un +programma il comportamento normale del kernel è quello di settare +l'\textit{effective user id} e l'\textit{effective group id} del nuovo +processo all'\acr{uid} e al \acr{gid} del processo corrente, che normalmente +corrispondono dell'utente con cui si è entrati nel sistema. -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} +Se però il file del programma\footnote{per motivi di sicurezza il kernel + ignora i bit \acr{suid} e \acr{sgid} per gli script eseguibili} (che +ovviamente deve essere eseguibile) ha il bit \acr{suid} settato, il kernel +assegnerà come \textit{effective user id} al nuovo processo l'\acr{uid} del +proprietario del file al posto dell'\acr{uid} del processo originario. Avere +il bit \acr{sgid} settato ha lo stesso effetto sull'\textit{effective group + id} del processo. + +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 dall'amministratore, +ma non è necessario chiamare l'amministratore per cambiare la propria +password. Infatti il comando \cmd{passwd} appartiene a root ma ha il bit +\acr{suid} settato per cui quando viene lanciato da un utente normale parte +con i privilegi di root. -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). +Chiaramente avere un processo che ha privilegi superiori a quelli che avrebbe +normalmente l'utente che lo ha lanciato comporta vari rischi, e questo tipo di +programmi devono essere scritti accuratamente per evitare che possano essere +usati per guadagnare privilegi non consentiti (torneremo sull'argomento in +\secref{sec:proc_perms}). -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. +La presenza dei bit \acr{suid} e \acr{sgid} su un file può essere +rilevata con il comando \cmd{ls -l}, in tal caso comparirà la lettera \cmd{s} +al posto della \cmd{x} in corrispondenza dei permessi di utente o gruppo. La +stessa lettera \cmd{s} può essere usata nel comando \cmd{chmod} per settare +questi bit. Infine questi bit possono essere controllati all'interno di +\var{st\_mode} con l'uso delle due costanti \macro{S\_ISUID} e +\macro{S\_IGID}, i cui valori sono riportati in +\tabref{tab:file_mode_flags}. +Gli stessi bit vengono ad assumere in significato completamente diverso per le +directory, normalmente infatti Linux usa la convenzione di SVR4 per indicare +con questi bit l'uso della semantica BSD nella creazione di nuovi file (si +veda \secref{sec:file_ownership} per una spiegazione dettagliata al +proposito). +Infine Linux utilizza il bit \acr{sgid} per una ulteriore estensione +mutuata da SVR4. Il caso in cui il file abbia il bit \acr{sgid} settato ma +non il corrispondente bit di esecuzione viene utilizzato per attivare per +quel file il \textit{mandatory locking} (argomento che affronteremo nei +dettagli in \secref{sec:file_mand_locking}). -\section{La manipolazione di file e directory} -Come già accennato in \secref{sec:file_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{Il bit \textsl{sticky}} +\label{sec:file_sticky} +L'ultimo dei bit rimanenti, identificato dalla costante \macro{S\_ISVTX}, è in +parte un rimasuglio delle origini dei sistemi unix. A quell'epoca infatti la +memoria virtuale e l'accesso ai files erano molto meno sofisticati e per +ottenere la massima velocità possibile per i programmi usati più comunemente +si poteva settare questo bit. -\subsection{Le funzioni \texttt{link} e \texttt{unlink}} -\label{sec:file_link} +L'effetto di questo bit era che il segmento di testo del programma (si veda +\secref{sec:proc_mem_layout} per i dettagli) veniva scritto nella swap la +prima volta che questo veniva lanciato, e vi permaneva fino al riavvio della +macchina (da questo il nome di \textsl{sticky bit}); essendo la swap un file +continuo indicizzato direttamente in questo modo si poteva risparmiare in +tempo di caricamento rispetto alla ricerca del file su disco. Lo +\textsl{sticky bit} è indicato usando la lettera \cmd{t} al posto della +\cmd{x} nei permessi per gli altri. -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. +Ovviamente per evitare che gli utenti potessero intasare la swap solo +l'amministratore era in grado di settare questo bit, che venne chiamato anche +con il nome di \textit{saved text bit}, da cui deriva quello della costante. +Le attuali implementazioni di memoria virtuale e filesystem rendono +sostanzialmente inutile questo procedimento. -Come spiegato in \secref{sec:file_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. +Benché ormai non venga più utilizzato per i file, lo \textsl{sticky bit} ha +assunto un uso corrente per le directory\footnote{lo \textsl{sticky bit} per + le directory è una estensione non definita nello standard POSIX, Linux però + la supporta, così come BSD e SVR4}, in questo caso se il bit è settato un +file potrà essere rimosso dalla directory soltanto se l'utente ha il permesso +di scrittura ed inoltre è vera una delle seguenti condizioni: +\begin{itemize} +\item l'utente è proprietario del file +\item l'utente è proprietario della directory +\item l'utente è l'amministratore +\end{itemize} +un classico esempio di directory che ha questo bit settato è \file{/tmp}, i +permessi infatti di solito sono settati come: +\begin{verbatim} +$ ls -ld /tmp +drwxrwxrwt 6 root root 1024 Aug 10 01:03 /tmp +\end{verbatim}%$ +in questo modo chiunque può leggere, scrivere ed eseguire i file temporanei +ivi memorizzati, sia crearne di nuovi, ma solo l'utente che ha creato un file +nella directory potrà cancellarlo o rinominarlo, così si può evitare che un +utente possa, più o meno consapevolmente, cancellare i file degli 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:file_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:file_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: +\subsection{La titolarità di nuovi file e directory} +\label{sec:file_ownership} -\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 - consentita 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} +Vedremo in \secref{sec:file_base_func} come creare nuovi file, ma se è +possibile specificare in sede di creazione quali permessi applicare ad un +file, non si può indicare a quale utente e gruppo esso deve appartenere. Lo +stesso problema di presenta per la creazione di nuove directory (procedimento +descritto in \secref{sec:file_dir_creat_rem}). -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). +Lo standard POSIX prescrive che l'\acr{uid} del nuovo file corrisponda +all'\textit{effective user id} del processo che lo crea; per il \acr{gid} +invece prevede due diverse possibilità: +\begin{itemize} +\item il \acr{gid} del file corrisponde all'\textit{effective group id} del + processo. +\item il \acr{gid} del file corrisponde al \acr{gid} della directory in cui + esso è creato. +\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 +\acr{gid} del processo, se però la directory in cui viene creato il file ha il +bit \acr{sgid} settato allora viene usata la seconda opzione. -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. +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 una maggiore +possibilità di scelta, ma per ottenere lo stesso risultato necessita che per +le nuove directory venga anche propagato anche il bit \acr{sgid}. Questo è +comunque il comportamento di default di \func{mkdir}, ed é in questo modo ad +esempio che Debian assicura che le sottodirectory create nelle home di un +utente restino sempre con il \acr{gid} del gruppo primario dello stesso. -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:file_remove} +\subsection{La funzione \func{access}} +\label{sec:file_access} -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:file_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}: +Come detto in \secref{sec:file_access_control} il controllo di accesso ad +un file viene fatto usando \textit{effective user id} e \textit{effective + group id} del processo, ma ci sono casi in cui si può voler effettuare il +controllo usando il \textit{real user id} e il \textit{real group id} (cioè +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)} -\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 verifica i permessi di accesso, indicati da \var{mode}, per il + file indicato da \var{pathname}. - 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{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{ENOSPC} Il device di destinazione non ha più spazio per la - nuova voce. - \end{errlist} + La funzione ritorna 0 se l'accesso è consentito, -1 altrimenti; in + quest'ultimo caso la variabile \var{errno} viene settata secondo i codici + di errore: \macro{EACCES}, \macro{EROFS}, \macro{EFAULT}, \macro{EINVAL}, + \macro{ENAMETOOLONG}, \macro{ENOENT}, \macro{ENOTDIR}, \macro{ELOOP}, + \macro{EIO}. \end{prototype} -\subsection{I link simbolici} -\label{sec:file_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. +I valori possibili per il parametro \var{mode} sono esprimibili come +combinazione delle costanti numeriche riportate in \ntab\ (attraverso un OR +binario). I primi tre valori implicano anche la verifica dell'esistenza del +file, se si vuole verificare solo quest'ultima si può usare \macro{F\_OK}, o +anche direttamente \func{stat}. In caso \var{pathname} si riferisca ad un link +simbolico il controllo è fatto sul file a cui esso fa riferimento. -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. +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 +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 + \begin{tabular}{|c|l|} + \hline + \textbf{\var{mode}} & \textbf{Significato} \\ + \hline + \hline + \macro{R\_OK} & verifica il permesso di lettura \\ + \macro{W\_OK} & verifica il permesso di scritture \\ + \macro{X\_OK} & verifica il permesso di esecuzione \\ + \macro{F\_OK} & verifica l'esistenza del file \\ + \hline + \end{tabular} + \caption{Valori possibile per il parametro \var{mode} della funzione + \func{access}} + \label{tab:file_access_mode_val} +\end{table} -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}. +Un esempio tipico per l'uso di questa funzione è quello di un processo che sta +eseguendo un programma coi privilegi di un altro utente (attraverso l'uso del +\acr{suid} bit) che vuole controllare se l'utente originale ha i permessi per +accedere ad un certo file. -\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 file (trattati in dettaglio in - \secref{sec:file_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: +\subsection{Le funzioni \func{chmod} e \func{fchmod}} +\label{sec:file_chmod} -\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. +Per cambiare i permessi di un file il sistema mette ad disposizione due +funzioni, che operano rispettivamente su un filename e su un file descriptor, +i loro prototipi sono: +\begin{functions} + \headdecl{sys/types.h} + \headdecl{sys/stat.h} + + \funcdecl{int chmod(const char *path, mode\_t mode)} Cambia i permessi del + file indicato da \var{path} al valore indicato da \var{mode}. - 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: + \funcdecl{int fchmod(int fd, mode\_t mode)} Analoga alla precedente, ma usa + il file descriptor \var{fd} per indicare il file. + + Le funzioni restituiscono zero in caso di successo e -1 per un errore, in + caso di errore \var{errno} può assumere i valori: \begin{errlist} - \item \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 \macro{EPERM} L'\textit{effective user id} non corrisponde a quello + del proprietario del file o non è zero. \end{errlist} -\end{prototype} + ed inoltre \macro{EROFS} e \macro{EIO}; \func{chmod} restituisce anche + \macro{EFAULT}, \macro{ENAMETOOLONG}, \macro{ENOENT}, \macro{ENOMEM}, + \macro{ENOTDIR}, \macro{EACCES}, \macro{ELOOP}; \func{fchmod} anche + \macro{EBADF}. +\end{functions} -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] +I valori possibili per \var{mode} sono indicati in \ntab. I valori possono +esser combinati con l'OR binario delle relative costanti simboliche, o +specificati direttamente, come per l'analogo comando di shell, con il valore +numerico (la shell lo vuole in ottale, dato che i bit dei permessi sono +divisibili in gruppi di tre). Ad esempio i permessi standard assegnati ai +nuovi file (lettura e scrittura per il proprietario, sola lettura per il +gruppo e gli altri) sono corrispondenti al valore ottale $0644$, un programma +invece avrebbe anche il bit di esecuzione attivo, con un valore di $0755$, se +si volesse attivare il bit \acr{suid} il valore da fornire sarebbe $4755$. + +\begin{table}[!htb] \centering \footnotesize - \begin{tabular}[c]{|l|c|c|} + \begin{tabular}[c]{|c|c|l|} + \hline + \textbf{\var{mode}} & \textbf{Valore} & \textbf{Significato} \\ + \hline + \hline + \macro{S\_ISUID} & 04000 & set user ID \\ + \macro{S\_ISGID} & 02000 & set group ID \\ + \macro{S\_ISVTX} & 01000 & sticky bit \\ + \hline + \macro{S\_IRWXU} & 00700 & l'utente ha tutti i permessi \\ + \macro{S\_IRUSR} & 00400 & l'utente ha il permesso di lettura \\ + \macro{S\_IWUSR} & 00200 & l'utente ha il permesso di scrittura \\ + \macro{S\_IXUSR} & 00100 & l'utente ha il permesso di esecuzione \\ + \hline + \macro{S\_IRWXG} & 00070 & il gruppo ha tutti i permessi \\ + \macro{S\_IRGRP} & 00040 & il gruppo ha il permesso di lettura \\ + \macro{S\_IWGRP} & 00020 & il gruppo ha il permesso di scrittura \\ + \macro{S\_IXGRP} & 00010 & il gruppo ha il permesso di esecuzione \\ + \hline + \macro{S\_IRWXO} & 00007 & gli altri hanno tutti i permessi \\ + \macro{S\_IROTH} & 00004 & gli altri hanno il permesso di lettura \\ + \macro{S\_IWOTH} & 00002 & gli altri hanno il permesso di scrittura \\ + \macro{S\_IXOTH} & 00001 & gli altri hanno il permesso di esecuzione \\ \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:file_symb_effect} + \caption{I valori delle costanti usate per indicare i permessi dei file.} + \label{tab:file_permission_const} \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 effettuata 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:file_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 effettuano lo scan 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: -\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}. +Il cambiamento dei permessi di un file attraverso queste funzioni ha comunque +alcune limitazioni, provviste per motivi di sicurezza. Questo significa che +anche se si è proprietari del file non tutte le operazioni sono permesse, in +particolare: +\begin{itemize} +\item siccome solo l'amministratore può settare lo \textit{sticky bit}; se + l'\textit{effective user id} del processo non è zero esso viene + automaticamente cancellato (senza notifica di errore) qualora sia stato + indicato in \var{mode}. +\item per via della semantica SVR4 nella creazione dei nuovi file, si può + avere il caso in cui il file creato da un processo è assegnato a un gruppo + per il quale il processo non ha privilegi. Per evitare che si possa + assegnare il bit \acr{sgid} ad un file appartenente a un gruppo per cui + non si hanno diritti, questo viene automaticamente cancellato (senza + notifica di errore) da \var{mode} qualora il gruppo del file non corrisponda + a quelli associati al processo (la cosa non avviene quando + l'\textit{effective user id} del processo è zero). +\end{itemize} +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 +processo che non appartenga all'amministratore scriva su un file. In questo +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{Le funzioni \texttt{mkdir} e \texttt{rmdir}} -\label{sec:file_dir_creat_rem} +\subsection{La funzione \func{umask}} +\label{sec:file_umask} -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}. +Oltre che dai valori indicati in sede di creazione, i permessi assegnati ai +nuovi file sono controllati anche da una maschera di bit settata con la +funzione \func{umask}, il cui prototipo è: +\begin{prototype}{stat.h} +{mode\_t umask(mode\_t mask)} -\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 - \var{dirname}, assegnandole i permessi indicati da \var{mode}. Il nome - può essere indicato con il pathname assoluto o relativo. + Setta la maschera dei permessi dei bit al valore specificato da \var{mask} + (di cui vengono presi solo i 9 bit meno significativi). - 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 file (trattati in dettaglio in - \secref{sec:file_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} + La funzione ritorna il precedente valore della maschera. È una delle poche + funzioni che non restituisce codici di errore. \end{prototype} - - -\subsection{Accesso alle directory} -\label{sec:file_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:file_vfs}) in una opportuna struttura -\texttt{struct dirent}. - -(NdA Il resto va scritto!!! É noioso e lo farò più avanti). +Questa maschera è una caratteristica di ogni processo e viene utilizzata per +impedire che alcuni permessi possano essere assegnati ai nuovi file in sede di +creazione, i bit indicati nella maschera vengono infatti esclusi quando un +nuovo file viene creato. +In genere questa maschera serve per impostare un default che escluda alcuni +permessi (usualmente quello di scrittura per il gruppo e gli altri, +corrispondente ad un valore di $022$). Essa è utile perché le routine +dell'interfaccia ANSI C degli stream non prevedono l'esistenza dei permessi, e +pertanto tutti i nuovi file vengono sempre creati con un default di $666$ +(cioè permessi di lettura e scrittura per tutti, si veda +\tabref{tab:file_permission_const} per un confronto); in questo modo è +possibile cancellare automaticamente i permessi non voluti, senza doverlo fare +esplicitamente. -\subsection{La directory di lavoro} -\label{sec:file_work_dir} +In genere il valore di \func{umask} viene stabilito una volta per tutte al +login a $022$, e di norma gli utenti non hanno motivi per modificarlo. Se però +si vuole che un processo possa creare un file che chiunque possa leggere +allora occorrerà cambiare il valore di \func{umask}. -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{Le funzioni \func{chown}, \func{fchown} e \func{lchown}} +\label{sec:file_chown} -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. +Come per i permessi, il sistema fornisce anche delle funzioni che permettano +di cambiare utente e gruppo cui il file appartiene; le funzioni in questione +sono tre e i loro prototipi sono i seguenti: +\begin{functions} + \headdecl{sys/types.h} + \headdecl{sys/stat.h} + + \funcdecl{int chown(const char *path, uid\_t owner, gid\_t group)} + \funcdecl{int fchown(int fd, uid\_t owner, gid\_t group)} + \funcdecl{int lchown(const char *path, uid\_t owner, gid\_t group)} -Le funzioni qui descritte servono esaminare e cambiare la directory di lavoro -corrente. + Le funzioni cambiano utente e gruppo di appartenenza di un file ai valori + specificati dalle variabili \var{owner} e \var{group}. -\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: + Le funzioni restituiscono zero in caso di successo e -1 per un errore, in + caso di errore \texttt{errno} viene settato ai valori: \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). + \item \macro{EPERM} L'\textit{effective user id} non corrisponde a quello + del proprietario del file o non è zero, o utente e gruppo non sono validi \end{errlist} -\end{prototype} + Oltre a questi entrambe restituiscono gli errori \macro{EROFS} e + \macro{EIO}; \func{chown} restituisce anche \macro{EFAULT}, + \macro{ENAMETOOLONG}, \macro{ENOENT}, \macro{ENOMEM}, \macro{ENOTDIR}, + \macro{EACCES}, \macro{ELOOP}; \func{fchown} anche \macro{EBADF}. +\end{functions} -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. +In Linux soltanto l'amministratore può cambiare il proprietario di un file, +seguendo la semantica di BSD che non consente agli utenti di assegnare i loro +file ad altri (per evitare eventuali aggiramenti delle quote). +L'amministratore può cambiare il gruppo di un file, il proprietario può +cambiare il gruppo dei file che gli appartengono solo se il nuovo gruppo è il +suo gruppo primario o uno dei gruppi a cui appartiene. -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. +La funzione \func{chown} segue i link simbolici, per operare direttamente su +in link simbolico si deve usare la funzione \func{lchown}\footnote{fino alla + versione 2.1.81 in Linux \func{chown} non seguiva i link simbolici, da + allora questo comportamento è stato assegnato alla funzione \func{lchown}, + introdotta per l'occasione, ed è stata creata una nuova system call per + \func{chown} che seguisse i link simbolici}. La funzione \func{fchown} opera +su un file aperto, essa è mutuata da BSD, ma non è nello standard POSIX. +Un'altra estensione rispetto allo standard POSIX è che specificando -1 come +valore per \var{owner} e \var{group} i valori restano immutati. - 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 file (trattati in dettaglio in - \secref{sec:file_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} +Quando queste funzioni sono chiamate con successo da un processo senza i +privilegi di root entrambi i bit \acr{suid} e \acr{sgid} vengono +cancellati. Questo non avviene per il bit \acr{sgid} nel caso in cui esso +sia usato (in assenza del corrispondente permesso di esecuzione) per indicare +che per il file è attivo il \textit{mandatory locking}. + +%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}).