livelli. Si tenga conto poi che quanto diremo è vero solo per filesystem di
tipo unix, e non è detto che sia applicabile a un filesystem
qualunque\footnote{ed infatti non è vero per il filesystem vfat di Windows,
- per il quale vengono assegnati in maniera fissa con un opzione in fase di
- montaggio}. Esistono inoltre estensioni che permettono di implementare le
-ACL (\textit{Access Control List}) che sono un meccanismo di controllo di
-accesso molto più sofisticato.
+ 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 (\textsl{uid} e \textsl{gid}), e accessibili
-da programma tramite i campi \var{st\_uid} e \var{st\_gid} della struttura
-\var{stat} (si veda \secref{sec:filedir_stat}). Ad ogni file viene inoltre
-associato un insieme di permessi che sono divisi in tre classi, e cioè
-attribuiti rispettivamente all'utente proprietario del file, a un qualunque
-utente faccia parte del gruppo cui appartiene il file, e a tutti gli altri
-utenti.
-
-I permessi, così come vengono presi dai comandi e dalle routine di sistema
+identificatori di utenti e gruppi (\textsl{uid} e \textsl{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:filedir_stat}). Ad ogni file
+viene inoltre associato un insieme di permessi che sono divisi in tre classi,
+e cioè attribuiti rispettivamente all'utente proprietario del file, a un
+qualunque utente faccia parte del gruppo cui appartiene il file, e a tutti gli
+altri utenti.
+
+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 rispettivamente con le lettere \textsl{w}, \textit{r}
-\textsl{x} nei comandi di sistema) applicabili rispettivamente al
-proprietario, al gruppo, a tutti. I restanti tre bit (\textsl{suid},
-\textsl{sgid}, e \textsl{sticky}) sono usati per indicare alcune
-caratteristiche più complesse su cui torneremo in seguito (vedi
-\secref{sec:filedir_suid_sgid} e \secref{sec:filedir_sticky}).
-
-Anche i permessi sono tenuti per ciascun file (di qualunque tipo, quindi anche
-per le fifo, i socket e i file di dispositivo) nell'inode, in opportuni bit
-del campo \var{st\_mode} della struttura letta da \func{stat} (vedi
-\figref{fig:filedir_stat_struct}).
-
-
-In genere ci si riferisce a questi permessi usando le lettere \textsl{u} (per
-\textit{user}), \textsl{g} (per \textit{group}) e \textsl{o} (per
-\textit{other}), inoltre se si vuole indicare tutti questi gruppi insieme si
-usa la lettera \textsl{a} (per \textit{all}). Si tenga ben presente questa
-distinzione, dato che in certi casi, mutuando la terminologia in uso nel VMS,
-si parla dei permessi base come di permessi di owner, group ed all, le cui
-iniziali possono da luogo a confusione. Le costanti che permettono di accedere
-al valore numerico di questi bit sono riportate in \ntab.
+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 (\textsl{suid}, \textsl{sgid}, e
+\textsl{sticky}) sono usati per indicare alcune caratteristiche più complesse
+su cui torneremo in seguito (vedi \secref{sec:filedir_suid_sgid} e
+\secref{sec:filedir_sticky}).
+
+Anche i permessi, 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:filedir_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
vederlo con \cmd{ls} (per crearlo occorrerà anche il permesso di scrittura per
la directory).
-Il permesso di lettura per un file consente di aprirlo con le opzioni di sola
-lettura (\macro{O\_RDONLY}) o di lettura-scrittura (\macro{O\_RDWR}) e
-leggerne il contenuto. Il permesso di scrittura consente di aprire un file in
-sola scrittura (\macro{O\_WRONLY}) o lettura-scrittura (\macro{O\_RDWR}) e
-modificarne il contenuto, lo stesso permesso è necessario per poter troncare
-il file con l'opzione \macro{O\_TRUNC}.
+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 fisica del file), non è
necessario nessun tipo di permesso per il file stesso (infatti esso non viene
-toccato, viene solo modificato il contenute della directory).
+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), occorre il permesso di esecuzione per il medesimo, inoltre solo i file
-regolari possono essere eseguiti.
+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:filedir_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
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
+ 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
allora:
\begin{itemize}
\item se il bit dei permessi d'accesso del gruppo è settato, l'accesso è
- consentito, altrimenti l'accesso è negato
+ 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.
processo appartiene ad un gruppo appropriato, in questo caso i permessi per
tutti gli altri non vengono controllati.
+
\subsection{I bit \textsl{suid} e \textsl{sgid}}
\label{sec:filedir_suid_sgid}
Come si è accennato (in \secref{sec:filedir_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
-\textsl{suid} e \textsl{sgid}.
+alcune proprietà speciali dei file. Due di questi sono i bit detti
+\textsl{suid} (o \textit{set-user-ID bit}) e \textsl{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:prochand_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'uid e al gid del processo corrente, che corrispondono dell'utente
-con cui si è entrati nel sistema.
+processo all'uid e al gid del processo corrente, che normalmente corrispondono
+dell'utente con cui si è entrati nel sistema.
Se però il file del programma (che ovviamente deve essere eseguibile) ha il
-bit \textsl{suid} (o \textit{set-user-ID bit}) settato al posto dell'uid del
-processo originario il kernel assegnerà come \textit{effective user id} al
-nuovo processo l'uid del proprietario del file. Analogamente avere il bit
-\textsl{sgid} (o \textit{set-group-ID bit}) settato ha lo stesso effetto
-sull'\textit{effective group id}.
+bit \textsl{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 \textsl{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 è necessairo chiamare l'amministratore per
-cambiare la propria pasword. Infatti il comando \cmd{passwd} appartiene a root
+dall'amministratore, ma non è necessario chiamare l'amministratore per
+cambiare la propria password. Infatti il comando \cmd{passwd} appartiene a root
ma ha il suid bit settato per cui quando viene lanciato da un utente normale
parte con i privilegi di root.
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 (torneremo sull'argomento in
-\secref{sec:prochand_perms}).
-
-I due bit suid e sgid possono essere controllati all'interno di \var{st\_mode}
-con l'uso delle due costanti \macro{S\_ISUID} e \macro{S\_ISGID}, definite in
-\tabref{tab:filedir_file_mode_flags}. I file possono essere identificati con
-il comando \cmd{ls -l} in quanto presentano 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.
+\secref{sec:prochand_perms}) per evitare che possano essere usati per
+guadagnare privilegi non consentiti.
+
+La presenza dei bit \textsl{suid} e \textsl{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:filedir_file_mode_flags}.
Gli stessi bit vengono ad assumere in significato completamente diverso per le
-directory, in questo caso infatti linux usa la convezione di SVR4 per indicare
-con questi bit l'uso della semantica BSD nella creazione di nuovi file
-(si veda \secref{sec:filedir_ownership}).
+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:filedir_ownership} per una spiegazione dettagliata al
+proposito).
-Infine il caso in cui il file abbia il bit \textsl{sgid} settato ma non il
-corrispondente bit per l'esecuzione viene utilizzato per attivare per quel
-file il \textit{mandatory locking} (argomento affrontato nei dettagli in
-\secref{sec:xxx_mandatory_lock}).
+Infine Linux utilizza il bit \textsl{sgid} per una ulteriore estensione
+mutuata da SVR4. Il caso in cui il file abbia il bit \textsl{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}).
\subsection{Il bit \textsl{sticky}}
\label{sec:filedir_sticky}
-L'ultimo
+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.
+
+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.
+
+Ovviamente per evitare che gli utenti potessero intasare la swap solo
+l'amministratore era in grado di settare questo bit, che venne chiamato anche
+\textit{saved text bit}, da cui deriva il nome della costante. Le attuali
+implementazioni di memoria virtuale e filesystem rendono sostanzialmente
+inutile questo procedimento. Lo \textsl{sticky bit} è indicato attraverso la
+lettera \cmd{t} al posto della \cmd{x} nei permessi per gli 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} è 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}
+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, evitando così che utente
+possa, più o meno consapevolemnte, cancellare i file degli altri.
+
\subsection{La titolarità di nuovi file e directory}
\label{sec:filedir_ownership}
+Vedremo in \secref{sec:fileunix_base_func} quali sono le funzioni per creare
+nuovi file, ma se è possibile specificare in sede di creazione quali permessi
+applicare ad un nuovo 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:filedir_dir_creat_rem}).
+
+Lo standard POSIX prescrive che l'uid del nuovo file corrisponda
+all'\textit{effective user id} del processo che lo crea; per il gid invece
+prevede due diverse possibilità:
+\begin{itemize}
+\item il gid del file corrisponde all'\textit{effective group id} del processo
+\item il 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 gid
+del processo, se però la directory in cui viene creato il file ha il bit sgid
+settato allora viene usata la seconda opzione..
+
+Usare la semantica BSD ha il vantaggio che il 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 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 gid
+del gruppo primario dello stesso.
+
\subsection{La funzione \texttt{access}}
\label{sec:filedir_access}
+Come detto in \secref{sec:filedir_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:filedir_suid_sgid} e spiegato in \secref{sec:prochand_perms} non è
+detto sia uguale all'\textit{effective user id}). Per far questo si può usare
+la funzione \func{access}, il cui prototipo è:
-\subsection{La funzione \texttt{umask}}
-\label{sec:filedir_umask}
+\begin{prototype}{unistd.h}
+{int access(const char *pathname, int mode)}
+
+ La funzione verifica i permessi di accesso, indicati da \var{mode}, per il
+ file indicato da \var{pathname}.
+
+ La funzione ritorna 0 se l'accesso è consentito, -1 altrimenti; in
+ quest'utlimo 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},
+ \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.
+
+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
+ \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 \\
+ \hline
+ \end{tabular}
+ \caption{Valori possibile per il parametro \var{mode} della funzione
+ \func{access}}
+ \label{tab:filedir_access_mode_val}
+\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.
\subsection{Le funzioni \texttt{chmod} e \texttt{fchmod}}
\label{sec:filedir_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{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}.
+
+ \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 \texttt{errno} viene settato ai valori:
+ \begin{errlist}
+ \item \macro{EPERM} L'\textit{effective user id} non corrisponde a quello
+ del proprietario del file o non è zero.
+ \end{errlist}
+ Oltre a questi entrambe restituiscono gli errori \macro{EROFS} e
+ \macro{EIO}; \func{chmod} restituisce anche \macro{EFAULT},
+ \macro{ENAMETOOLONG}, \macro{ENOENT}, \macro{ENOMEM}, \macro{ENOTDIR},
+ \macro{EACCES}, \macro{ELOOP}; \func{chmod} 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:filedir_permission_const}
+\end{table}
+
+
+
+\subsection{La funzione \texttt{umask}}
+\label{sec:filedir_umask}
+
+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}. 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 gruppo e altri, corrispondente ad
+un valore di 022). Essa è utile perché le routine l'interfaccia degli stream
+non prevede l'esistenza dei processi, e pertanto i nuovi file vengono sempre
+creati con i permessi fissati su 066.
+
+
+
\subsection{Le funzioni \texttt{chown}, \texttt{fchown} e \texttt{lchown}}
\label{sec:filedir_chown}
\begin{errlist}
\item \texttt{EACCESS} non c'è il permesso di accedere al file.
\item \texttt{ENOTDIR} una componente del pathname non è una directory.
- \item \texttt{EMLOOP} ci sono troppi link simbolici nel pathname.
- \item \texttt{EFAULT} i puntatori usati sono fuori dallo spazio di indirizzi
- del processo.
\item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a
completare l'operazione.
\item \texttt{ENAMETOOLONG} il filename è troppo lungo.
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}
(e che grub vedrebbe come radice), con lo stesso path con cui verrebbero
visti dal sistema operativo.}.
-Questo può causare problemi per tutti quei programmi che effettuassero uno
-scan di una directory senza tener conto dei link simbolici, in quel caso
-infatti il loop nella directory
+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
\begin{prototype}{sys/stat.h}
{int mkdir (const char * dirname, mode\_t mode)}
Questa funzione crea una nuova directory vuota con il nome indicato da
- \texttt{dirname}, assegnandole i permessi indicati da \texttt{mode}. Il nome
+ \var{dirname}, assegnandole i permessi indicati da \var{mode}. Il nome
può essere indicato con il pathname assoluto o relativo.
La funzione restituisce zero in caso di successo e -1 per un errore, in caso
projects / gapil.git / blobdiff