Molti problemi di sicurezza derivano proprio da una creazione non accorta di
file temporanei che lascia aperta questa \itindex{race~condition} \textit{race
condition}. Un attaccante allora potrà sfruttarla con quello che viene
-chiamato ``\textit{symlink attack}'' dove nell'intervallo fra la generazione
-di un nome e l'accesso allo stesso, viene creato un collegamento simbolico con
-quel nome verso un file diverso, ottenendo, se il programma sotto attacco ne
-ha la capacità, un accesso privilegiato.
+chiamato \itindex{symlink~attack} ``\textit{symlink attack}'' dove
+nell'intervallo fra la generazione di un nome e l'accesso allo stesso, viene
+creato un collegamento simbolico con quel nome verso un file diverso,
+ottenendo, se il programma sotto attacco ne ha la capacità, un accesso
+privilegiato.
La \acr{glibc} provvede varie funzioni per generare nomi di file temporanei,
di cui si abbia certezza di unicità al momento della generazione; storicamente
\end{funcproto}
La funzione restituisce il puntatore ad una stringa contente un nome di file
-valido e non esistente al momento dell'invocazione; se si è passato come
+valido e non esistente al momento dell'invocazione. Se si è passato come
argomento \param{string} un puntatore non nullo ad un buffer di caratteri
questo deve essere di dimensione \const{L\_tmpnam} ed il nome generato vi
-verrà copiato automaticamente; altrimenti il nome sarà generato in un buffer
+verrà copiato automaticamente, altrimenti il nome sarà generato in un buffer
statico interno che verrà sovrascritto ad una chiamata successiva. Successive
invocazioni della funzione continueranno a restituire nomi unici fino ad un
massimo di \const{TMP\_MAX} volte, limite oltre il quale il comportamento è
nome provvisorio. La funzione assegna come directory per il file temporaneo,
verificando che esista e sia accessibile, la prima valida fra le seguenti:
\begin{itemize*}
-\item La variabile di ambiente \envvar{TMPDIR} (non ha effetto se non è
+\item la variabile di ambiente \envvar{TMPDIR} (non ha effetto se non è
definita o se il programma chiamante è \itindex{suid~bit} \acr{suid} o
- \itindex{sgid~bit} \acr{sgid}, vedi sez.~\ref{sec:file_special_perm}).
-\item il valore dell'argomento \param{dir} (se diverso da \val{NULL}).
-\item Il valore della costante \const{P\_tmpdir}.
+ \itindex{sgid~bit} \acr{sgid}, vedi sez.~\ref{sec:file_special_perm}),
+\item il valore dell'argomento \param{dir} (se diverso da \val{NULL}),
+\item il valore della costante \const{P\_tmpdir},
\item la directory \file{/tmp}.
\end{itemize*}
motivo quando si usa il nome ottenuto da una di queste funzioni occorre sempre
assicurarsi che non si stia usando un collegamento simbolico e aprire il nuovo
file in modalità di esclusione (cioè con l'opzione \const{O\_EXCL} per i file
-descriptor o con il flag \code{x} per gli \textit{stream}) che fa fallire
-l'apertura in caso il file sia già esistente. Essendo disponibili alternative
-migliori l'uso di queste funzioni è deprecato.
+descriptor o con il flag ``\texttt{x}'' per gli \textit{stream}) che fa
+fallire l'apertura in caso il file sia già esistente. Essendo disponibili
+alternative migliori l'uso di queste funzioni è deprecato.
Per evitare di dovere effettuare a mano tutti questi controlli, lo standard
POSIX definisce la funzione \funcd{tmpfile}, che permette di ottenere in
caso si possono usare le vecchie funzioni \funcd{mktemp} e \func{mkstemp} che
modificano una stringa di input che serve da modello e che deve essere
conclusa da 6 caratteri ``\texttt{X}'' che verranno sostituiti da un codice
-unico. La prima delle due è analoga a \func{tmpnam} e genera un nome casuale,
-il suo prototipo è:
+unico. La prima delle due è analoga a \func{tmpnam} e genera soltanto un nome
+casuale, il suo prototipo è:
\begin{funcproto}{
\fhead{stlib.h}
La funzione genera una directory il cui nome è ottenuto sostituendo le
\code{XXXXXX} finali di \param{template} con permessi \code{0700} (al solito
-si veda cap.~\ref{cha:file_unix_interface} per i dettagli); dato che la
+si veda cap.~\ref{cha:file_unix_interface} per i dettagli). Dato che la
creazione della directory è sempre esclusiva i precedenti problemi di
\itindex{race~condition} \textit{race condition} non si pongono.
costanti numeriche riportate in tab.~\ref{tab:file_mode_flags}, che
definiscono le maschere che consentono di selezionare non solo i dati relativi
al tipo di file, ma anche le informazioni relative ai permessi su cui
-torneremo in sez.~\ref{sec:file_access_control} ed identificare i rispettivi
+torneremo in sez.~\ref{sec:file_access_control}, ed identificare i rispettivi
valori.
Le costanti che servono per la identificazione del tipo di file sono riportate
una struttura \struct{stat} contiene la dimensione del file in byte. Questo
però è vero solo se si tratta di un file regolare, mentre nel caso di un
collegamento simbolico la dimensione è quella del \textit{pathname} che il
-collegamento stesso contiene mentre per le fifo ed i file di dispositivo
+collegamento stesso contiene, infine per le fifo ed i file di dispositivo
questo campo è sempre nullo.
Il campo \var{st\_blocks} invece definisce la lunghezza del file in blocchi di
-512 byte. La differenze con \var{st\_size} è che in questo caso si fa
+512 byte. La differenza con \var{st\_size} è che in questo caso si fa
riferimento alla quantità di spazio disco allocata per il file, e non alla
dimensione dello stesso che si otterrebbe leggendolo sequenzialmente.
rendere evidente che vi è stato un accesso dopo una modifica e che il file
viene comunque osservato regolarmente, conservando tutte le informazioni
veramente utili senza dover consumare risorse in scritture continue per
-mantenere costantemente aggiornata una informazione che questo punto non ha
+mantenere costantemente aggiornata una informazione che a questo punto non ha
più nessuna rilevanza pratica.\footnote{qualora ce ne fosse la necessità è
comunque possibile, tramite l'opzione di montaggio \texttt{strictatime},
richiedere in ogni caso il comportamento tradizionale.}
\end{errlist}}
\end{funcproto}
-Le due funzioni anno lo stesso comportamento di \texttt{utimes} e richiedono
+Le due funzioni hanno lo stesso comportamento di \texttt{utimes} e richiedono
gli stessi privilegi per poter operare, la differenza è che con \func{futimes}
si può indicare il file su cui operare se questo è già aperto facendo
-riferimento al suo file descriptor mentre con \func{lutimes} nel caso in
+riferimento al suo file descriptor, mentre con \func{lutimes} nel caso in
cui \param{filename} sia un collegamento simbolico saranno modificati i suoi
tempi invece di quelli del file a cui esso punta.
Torneremo su questa sintassi e sulla sua motivazione in
sez.~\ref{sec:file_openat}, quando tratteremo tutte le altre funzioni (le
-cosiddette funzioni \textit{at}) che la utilizzano; essa prevede comunque
-anche la presenza dell'argomento \param{flags} con cui attivare flag di
-controllo che modificano il comportamento della funzione, nel caso specifico
-l'unico valore consentito è \const{AT\_SYMLINK\_NOFOLLOW} che indica alla
-funzione di non dereferenziare i collegamenti simbolici, cosa che le permette
-di riprodurre le funzionalità di \func{lutimes}.
+cosiddette \itindex{at-functions} \textit{at-functions}) che la utilizzano;
+essa prevede comunque anche la presenza dell'argomento \param{flags} con cui
+attivare flag di controllo che modificano il comportamento della funzione, nel
+caso specifico l'unico valore consentito è \const{AT\_SYMLINK\_NOFOLLOW} che
+indica alla funzione di non dereferenziare i collegamenti simbolici, cosa che
+le permette di riprodurre le funzionalità di \func{lutimes}.
tipo Unix, ad esempio non è vero per il filesystem VFAT di Windows, che non
fornisce nessun supporto per l'accesso multiutente, e per il quale queste
proprietà vengono assegnate in maniera fissa con opportune opzioni di
- montaggio.} Anche questi sono mantenuti \index{itinode} sull'\textit{inode}
+ montaggio.} Anche questi sono mantenuti \itindex{inode} sull'\textit{inode}
insieme alle altre proprietà e sono accessibili da programma tramite la
funzione \func{stat} (trattata in sez.~\ref{sec:file_stat}), che restituisce
l'utente proprietario nel campo \var{st\_uid} ed il gruppo proprietario nel
meccanismo del controllo di accesso su cui torneremo in seguito (in
sez.~\ref{sec:file_special_perm}), lo schema di allocazione dei bit è
riportato in fig.~\ref{fig:file_perm_bit}. Come tutte le altre proprietà di
-una file anche i permessi sono memorizzati \itindex{inode}
-nell'\textit{inode}, e come accennato in sez.~\ref{sec:file_types} essi sono
-contenuti in una parte del campo \var{st\_mode} della struttura \struct{stat}
-(si veda di nuovo fig.~\ref{fig:file_stat_struct}).
+un file anche i permessi sono memorizzati \itindex{inode} nell'\textit{inode},
+e come accennato in sez.~\ref{sec:file_types} essi sono vengono restituiti in
+una parte del campo \var{st\_mode} della struttura \struct{stat} (si veda di
+nuovo fig.~\ref{fig:file_stat_struct}).
In genere ci si riferisce ai tre livelli dei privilegi usando le lettere
\texttt{u} (per \textit{user}), \texttt{g} (per \textit{group}) e \texttt{o}
\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}, già viste in
-tab.~\ref{tab:file_mode_flags}, sono riportate per chiarezza in
-tab.~\ref{tab:file_bit_perm}.
+tab.~\ref{tab:file_mode_flags}, sono riportate per chiarezza una seconda volta
+in tab.~\ref{tab:file_bit_perm}.
\begin{table}[htb]
\centering
(si veda quanto riportato in tab.~\ref{tab:file_open_flags}) di sola lettura o
di lettura/scrittura e leggerne il contenuto. Avere il permesso di scrittura
consente di aprire un file in sola scrittura o lettura/scrittura e modificarne
-il contenuto, lo stesso permesso è necessario per poter troncare il file.
+il contenuto, lo stesso permesso è necessario per poter troncare il file o per
+aggiornare il suo tempo di ultima modifica al tempo corrente, ma non per
+modificare arbitrariamente quest'ultimo, operazione per la quale, come per
+buona parte delle modifiche effettuate sui metadati del file, occorre esserne
+i proprietari.
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
+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). Per la cancellazione non è necessario nessun tipo di permesso per il
file stesso dato che, come illustrato in sez.~\ref{sec:link_symlink_rename}
-esso non viene toccato, nella cancellazione viene solo modificato il contenuto
-della directory, rimuovendo la voce che ad esso fa riferimento.
-
-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,
-oltre al permesso di lettura per accedere al contenuto, avere anche il
-permesso di esecuzione. Inoltre solo i file regolari possono essere eseguiti.
+esso non viene toccato, nella cancellazione infatti viene solo modificato il
+contenuto della directory, rimuovendo la voce che ad esso fa riferimento. Lo
+stesso vale per poter rinominare o spostare il file in altra directory, in
+entrambi i casi occorrerà il permesso di scrittura sulle directory che si
+vanno a modificare.
+
+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
+oltre al permesso di lettura per accedere al contenuto avere anche il permesso
+di esecuzione. Inoltre solo i file regolari possono essere eseguiti. Per i
+file di dispositivo i permessi validi sono solo quelli di lettura e scrittura,
+che corrispondono al poter eseguire dette operazioni sulla periferica
+sottostante.
I permessi per un collegamento simbolico sono ignorati, contano quelli del
file a cui fa riferimento; per questo in genere il comando \cmd{ls} riporta
-per un collegamento simbolico tutti i permessi come concessi; utente e gruppo
+per un collegamento simbolico tutti i permessi come concessi. Utente e gruppo
a cui esso appartiene vengono pure ignorati quando il collegamento viene
risolto, vengono controllati solo quando viene richiesta la rimozione del
collegamento e quest'ultimo è in una directory con lo \itindex{sticky~bit}
di accesso sono i seguenti:
\begin{enumerate*}
\item Se l'\ids{UID} effettivo 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.
+ all'amministratore) l'accesso è sempre garantito senza nessun controllo. Per
+ questo motivo l'amministratore ha piena libertà di accesso a tutti i file.
\item Se l'\ids{UID} effettivo del processo è uguale all'\ids{UID} del
proprietario del file (nel qual caso si dice che il processo è proprietario
del file) allora:
\item altrimenti l'accesso è negato.
\end{itemize*}
\item Se il \ids{GID} effettivo del processo o uno dei \ids{GID} supplementari
- dei processi corrispondono al \ids{GID} del file allora:
+ del processo corrispondono al \ids{GID} del file allora:
\begin{itemize*}
\item se il bit dei permessi d'accesso del gruppo è impostato, l'accesso è
consentito;
\end{enumerate*}
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.
+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.
+
+Questo significa che se si è proprietari di un file ma non si ha il permesso
+di scrittura, non vi si potrà scrivere anche se questo fosse scrivibile per
+tutti gli altri. Permessi di questo tipo sono ovviamente poco ortodossi, e
+comunque, come vedremo in sez.~\ref{sec:file_perm_management}, il proprietario
+di un file può sempre modificarne i permessi, e riassegnarsi un eventuale
+permesso di scrittura mancante.
+
+\itindbeg{file~attributes}
-\itindbeg{file~attributes}
A questi che sono i permessi ordinari si aggiungono, per i filesystem che
supportano questa estensione, due permessi speciali mantenuti nei cosiddetti
\textit{file attributes}, che si possono leggere ed impostare con i comandi
-\cmd{lsattr} e \cmd{chattr}.\footnote{per l'utilizzo di questo comando e le
- spiegazioni riguardo gli altri \textit{file attributes} si rimanda alla
- sezione 1.4.4 di \cite{AGL}.}
+\cmd{lsattr} e \cmd{chattr}.\footnote{per l'utilizzo di questi comandi e per
+ le spiegazioni riguardo tutti gli altri \textit{file attributes} si rimanda
+ alla sezione 1.4.4 di \cite{AGL}.}
Il primo è il cosiddetto attributo di immutabilità (\textit{immutable},
identificato dalla lettera \texttt{i}) che impedisce ogni modifica al file,
\textit{inode} compreso. Questo significa non solo che non se ne può cambiare
-il contenuto, ma neanche nessuno dei metadati, ed in particolare non si può
-cancellare, rinominare, modificare nei permessi o nei tempi, o creare
-\textit{hard link} verso di esso.
+il contenuto, ma neanche nessuna delle sue proprietà, ed in particolare non si
+può modificare nei permessi o nei tempi o nel proprietario ed inoltre, visto
+che non se può modificare il \textit{link count}, non si può neanche
+cancellare, rinominare, o creare \textit{hard link} verso di esso.
Il secondo è il cosiddetto attributo di \textit{append-only}, (identificato
-dalla lettera \texttt{a}) che consente soltanto la scrittura del file in coda
-al file. Il file cioè può essere soltanto esteso, ma i suoi metadati, a parte
-i tempi che può però possono essere impostati al valore corrente, non possono
-essere modificati, quindi di nuovo non si potrà cancellare, rinominare, o
-modificare nei permessi.
-
-Entrambi questi attributi attivano queste proprietà a livello di filesytem,
+dalla lettera \texttt{a}) che consente soltanto la scrittura in coda al
+file. Il file cioè può essere soltanto esteso nel contenuto, ma i suoi
+metadati, a parte i tempi che però possono essere impostati al valore
+corrente, non possono essere modificati in alcun modo, quindi di nuovo non si
+potrà cancellare, rinominare, o modificare nei permessi o nelle altre
+proprietà.
+
+Entrambi questi attributi attivano queste restrizioni a livello di filesytem,
per cui a differenza dei permessi ordinari esse varranno per qualunque utente
compreso l'amministratore. L'amministratore è l'unico che può attivare o
disattivare questi attributi,\footnote{più precisamente un processo con la
\itindex{capabilities} capacità \const{CAP\_LINUX\_IMMUTABLE}.} e potendo
rimuoverli è comunque capace di tornare in grado di eseguire qualunque
-operazione.
+operazione su un file immutabile o \textit{append-only}.
+
\itindbeg{file~attributes}
corrispondenti del gruppo \textit{real} del processo corrente, che normalmente
corrispondono a quelli dell'utente con cui si è entrati nel sistema.
-Se però il file del programma (che ovviamente deve essere
-eseguibile\footnote{per motivi di sicurezza il kernel ignora i bit \acr{suid}
- e \acr{sgid} per gli script eseguibili.}) ha il bit \acr{suid} impostato, il
-kernel assegnerà come \ids{UID} effettivo al nuovo processo l'\ids{UID} del
-proprietario del file al posto dell'\ids{UID} del processo originario. Avere
-il bit \acr{sgid} impostato ha lo stesso effetto sul \ids{GID} effettivo del
-processo.
+Se però il file del programma, che ovviamente deve essere
+eseguibile,\footnote{anzi più precisamente un binario eseguibile: per motivi
+ di sicurezza il kernel ignora i bit \acr{suid} e \acr{sgid} per gli script
+ eseguibili.} ha il bit \acr{suid} impostato, il kernel assegnerà come
+\ids{UID} effettivo al nuovo processo l'\ids{UID} del proprietario del file al
+posto dell'\ids{UID} del processo originario. Avere il bit \acr{sgid}
+impostato ha lo stesso effetto sul \ids{GID} effettivo del processo. É
+comunque possibile riconoscere questa situazione perché il cambiamento viene
+effettuato solo sugli identificativi del gruppo \textit{effective}, mentre
+quelli dei gruppi \textit{real} e \textit{saved} restano quelli dell'utente
+che ha eseguito il programma.
I bit \acr{suid} e \acr{sgid} vengono usati per permettere agli utenti normali
-di usare programmi che richiedono privilegi speciali; l'esempio classico è il
+di usare programmi che richiedono 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} impostato
-per cui quando viene lanciato da un utente normale parte con i privilegi di
-root.
+il comando \cmd{passwd} appartiene in genere all'utente \textit{root} ma ha il
+bit \acr{suid} impostato, per cui quando viene lanciato da un utente normale
+ottiene comunque 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
dettaglio in sez.~\ref{sec:proc_perms}).
La presenza dei bit \acr{suid} e \acr{sgid} su un file può essere rilevata con
-il comando \cmd{ls -l}, che visualizza una 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 impostare questi bit.
-Infine questi bit possono essere controllati all'interno di \var{st\_mode} con
-l'uso delle due costanti \const{S\_ISUID} e \const{S\_IGID}, i cui valori sono
-riportati in tab.~\ref{tab:file_mode_flags}.
-
-Gli stessi bit vengono ad assumere in significato completamente diverso per le
+il comando \cmd{ls -l}, che visualizza una 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 impostare
+questi bit. Infine questi bit possono essere controllati all'interno di
+\var{st\_mode} con l'uso delle due costanti \const{S\_ISUID} e
+\const{S\_IGID}, i cui valori sono riportati in
+tab.~\ref{tab:file_mode_flags}.
+
+Gli stessi bit vengono ad assumere un 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 sez.~\ref{sec:file_ownership_management} per una spiegazione dettagliata
essendo la swap un file continuo o una partizione indicizzata direttamente si
poteva risparmiare in tempo di caricamento rispetto alla ricerca attraverso la
struttura del filesystem. Lo \textsl{sticky bit} è indicato usando la lettera
-\texttt{t} al posto della \texttt{x} nei permessi per gli altri.
+``\texttt{t}'' al posto della ``\texttt{x}'' nei permessi per gli altri.
Ovviamente per evitare che gli utenti potessero intasare la swap solo
l'amministratore era in grado di impostare questo bit, che venne chiamato
il permesso di scrittura su di essa 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
+\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 impostato è \file{/tmp}, i
-permessi infatti di solito sono i seguenti:
-\begin{verbatim}
+
+Un classico esempio di directory che ha questo bit impostato è \file{/tmp}, i
+cui permessi infatti di solito sono i seguenti:
+\begin{Command}
$ ls -ld /tmp
+\end{Command}
+\begin{Terminal}
drwxrwxrwt 6 root root 1024 Aug 10 01:03 /tmp
-\end{verbatim}%$
+\end{Terminal}
+%$
quindi con lo \textit{sticky bit} bit impostato. In questo modo qualunque
-utente nel sistema può creare dei file in questa directory (che, come
-suggerisce il nome, è normalmente utilizzata per la creazione di file
-temporanei), ma solo l'utente che ha creato un certo file potrà cancellarlo o
+utente nel sistema può creare dei file in questa directory, che come
+suggerisce il nome è normalmente utilizzata per la creazione di file
+temporanei, ma solo l'utente che ha creato un certo file potrà cancellarlo o
rinominarlo. In questo modo si evita che un utente possa, più o meno
consapevolmente, cancellare i file temporanei creati degli altri utenti.
\itindend{sticky~bit}
+
+
\subsection{Le funzioni per la gestione dei permessi dei file}
\label{sec:file_perm_management}
accennato in sez.~\ref{sec:file_special_perm} e spiegato in dettaglio in
sez.~\ref{sec:proc_perms}, non è detto siano uguali a quelli effettivi.
-Per far questo si può usare la funzione \funcd{access}, il cui prototipo è:
+Per far questo si può usare la funzione di sistema \funcd{access}, il cui
+prototipo è:
\begin{funcproto}{
\fhead{unistd.h}
{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
caso \var{errno} assumerà uno dei valori:
- \begin{errlist}
- \item[\errcode{EINVAL}] il valore di \param{mode} non è valido.
+ \begin{errlist}
\item[\errcode{EACCES}] l'accesso al file non è consentito, o non si ha il
permesso di attraversare una delle directory di \param{pathname}.
+ \item[\errcode{EINVAL}] il valore di \param{mode} non è valido.
\item[\errcode{EROFS}] si è richiesto l'accesso in scrittura per un file su
un filesystem montato in sola lettura.
+ \item[\errcode{ETXTBSY}] si è richiesto l'accesso in scrittura per un
+ eseguibile binario correntemente in esecuzione.
\end{errlist}
- ed inoltre \errval{EFAULT}, \errval{ENAMETOOLONG}, \errval{ENOENT},
- \errval{ENOTDIR}, \errval{ELOOP}, \errval{EIO}
- nel loro significato generico.}
+ ed inoltre \errval{EFAULT}, \errval{EIO}, \errval{ELOOP},
+ \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOTDIR} nel loro
+ significato generico.}
\end{funcproto}
La funzione verifica i permessi di accesso, indicati da \param{mode}, per il
riferisca ad un collegamento simbolico, questo viene seguito ed il controllo è
fatto sul file a cui esso fa riferimento.
-La funzione controlla solo i bit dei permessi di accesso, si ricordi che il
-fatto che una directory abbia permesso di scrittura non significa che ci si
-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.
+La funzione controlla solo i bit dei permessi di accesso per \param{pathname},
+ma occorre poter risolvere quest'ultimo, e se non c'è il permesso di
+esecuzione per una qualunque delle sue componenti la funzione fallirà
+indipendentemente dai permessi del file. Si tenga presente poi che il fatto
+che una directory abbia permesso di scrittura non significa che vi si possa
+scrivere come fosse un file, e che se un file ha il permesso di esecuzione non
+è detto che sia eseguibile. La funzione ha successo solo se tutti i permessi
+controllati sono disponibili.
+
\begin{table}[htb]
\centering
\footnotesize
\const{F\_OK} & Verifica l'esistenza del file. \\
\hline
\end{tabular}
- \caption{Valori possibile per l'argomento \param{mode} della funzione
+ \caption{Valori possibili per l'argomento \param{mode} della funzione
\func{access}.}
\label{tab:file_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 (ad esempio attraverso
l'uso del \itindex{suid~bit} \textit{suid bit}) che vuole controllare se
-l'utente originale ha i permessi per accedere ad un certo file.
-
-Del tutto analoghe a \func{access} sono le due funzioni \funcd{euidaccess} e
-\funcd{eaccess} che ripetono lo stesso controllo usando però gli
+l'utente originale ha i permessi per accedere ad un certo file, ma eseguire
+questo controllo prima di aprire il file espone al rischio di una
+\itindex{race~condition} \textit{race condition} che apre ad un possibile
+\itindex{symlink~attack} \textit{symlink attack} fra il controllo e l'apertura
+del file. In questo caso è sempre opportuno usare invece la funzione
+\func{faccessat} che tratteremo insieme alle altre \itindex{at-functions}
+\textit{at-functions} in sez.~\ref{sec:file_openat}.
+
+Del tutto analoghe a \func{access} sono le due funzioni \funcm{euidaccess} e
+\funcm{eaccess} che ripetono lo stesso controllo usando però gli
identificatori del gruppo effettivo, verificando quindi le effettive capacità
di accesso ad un file. Le funzioni hanno entrambe lo stesso
-prototipo\footnote{in realtà \func{eaccess} è solo un sinonimo di
- \func{euidaccess} fornita per compatibilità con l'uso di questo nome in
+prototipo\footnote{in realtà \funcm{eaccess} è solo un sinonimo di
+ \funcm{euidaccess} fornita per compatibilità con l'uso di questo nome in
altri sistemi.} che è del tutto identico a quello di \func{access}. Prendono
anche gli stessi valori e restituiscono gli stessi risultati e gli stessi
codici di errore.
caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EPERM}] l'\ids{UID} effettivo non corrisponde a quello del
- proprietario del file o non è zero.
+ proprietario del file o non si hanno i privilegi di amministratore.
\item[\errcode{EROFS}] il file è su un filesystem in sola lettura.
\end{errlist}
- ed inoltre per entrambe \errval{EIO}, per \func{chmod} \errval{EFAULT},
- \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM}, \errval{ENOTDIR},
- \errval{EACCES}, \errval{ELOOP}, per \func{fchmod} \errval{EBADF}
- nel loro significato generico.}
+ ed inoltre per entrambe \errval{EIO}, per \func{chmod} \errval{EACCES},
+ \errval{EFAULT}, \errval{ELOOP}, \errval{ENAMETOOLONG}, \errval{ENOENT},
+ \errval{ENOMEM}, \errval{ENOTDIR}, per \func{fchmod} \errval{EBADF} nel loro
+ significato generico.}
\end{funcproto}
\end{table}
Le costanti con cui specificare i singoli bit di \param{mode} sono riportate
-in tab.~\ref{tab:file_permission_const}. Il valore di \param{mode} può essere
-ottenuto combinando fra loro con un OR binario le costanti simboliche relative
-ai vari bit, o specificato direttamente, come per l'omonimo comando di shell,
-con un valore numerico (la shell lo vuole in ottale, dato che i bit dei
-permessi sono divisibili in gruppi di tre), che si può calcolare direttamente
-usando lo schema si utilizzo dei bit illustrato in
+in tab.~\ref{tab:file_permission_const}, e corrispondono agli stessi valori
+usati per \var{st\_mode} in tab.~\ref{tab:file_mode_flags}. Il valore
+di \param{mode} può essere ottenuto combinando fra loro con un OR binario le
+costanti simboliche relative ai vari bit, o specificato direttamente, come per
+l'omonimo comando di shell, con un valore numerico (la shell lo vuole in
+ottale, dato che i bit dei permessi sono divisibili in gruppi di tre), che si
+può calcolare direttamente usando lo schema di utilizzo dei bit illustrato in
fig.~\ref{fig:file_perm_bit}.
Ad esempio i permessi standard assegnati ai nuovi file (lettura e scrittura
limitazioni ulteriori. Per questo motivo, anche se si è proprietari del file,
non tutti i valori possibili di \param{mode} sono permessi o hanno effetto;
in particolare accade che:
-\begin{enumerate}
+\begin{enumerate*}
\item siccome solo l'amministratore può impostare lo \itindex{sticky~bit}
\textit{sticky bit}, se l'\ids{UID} effettivo del processo non è zero esso
- viene automaticamente cancellato (senza notifica di errore) qualora sia
+ viene automaticamente cancellato, senza notifica di errore, qualora sia
stato indicato in \param{mode}.
\item per quanto detto in sez.~\ref{sec:file_ownership_management} riguardo la
creazione dei nuovi file, si può avere il caso in cui il file creato da un
processo è assegnato ad un gruppo per il quale il processo non ha privilegi.
Per evitare che si possa assegnare il bit \itindex{sgid~bit} \acr{sgid} ad
un file appartenente ad un gruppo per cui non si hanno diritti, questo viene
- automaticamente cancellato da \param{mode} (senza notifica di errore)
- qualora il gruppo del file non corrisponda a quelli associati al processo
- (la cosa non avviene quando l'\ids{UID} effettivo del processo è zero).
-\end{enumerate}
+ automaticamente cancellato da \param{mode}, senza notifica di errore,
+ qualora il gruppo del file non corrisponda a quelli associati al processo;
+ la cosa non avviene quando l'\ids{UID} effettivo del processo è zero.
+\end{enumerate*}
Per alcuni filesystem\footnote{i filesystem più comuni (\textsl{ext2},
\textsl{ext3}, \textsl{ext4}, \textsl{ReiserFS}) supportano questa
creazione che lo consentono, i permessi contenuti nella \textit{umask}
verranno tolti.}
-La funzione che permette di impostare il valore di questa maschera di
-controllo è \funcd{umask}, ed il suo prototipo è:
+La funzione di sistema che permette di impostare il valore di questa maschera
+di controllo è \funcd{umask}, ed il suo prototipo è:
\begin{funcproto}{
\fhead{stat.h}
previste condizioni di errore.}
\end{funcproto}
-La funzione imposta maschera dei permessi dei bit al valore specificato
-da \param{mask} (di cui vengono presi solo i 9 bit meno significativi). In
+La funzione imposta la maschera dei permessi dei bit al valore specificato
+da \param{mask}, di cui vengono presi solo i 9 bit meno significativi. In
genere si usa questa maschera per impostare un valore predefinito che escluda
-preventivamente alcuni permessi (usualmente quello di scrittura per il gruppo
-e gli altri, corrispondente ad un valore per \param{mask} pari a $022$). In
-questo modo è possibile cancellare automaticamente i permessi non voluti. Di
-norma questo valore viene impostato una volta per tutte al login a $022$, e
-gli utenti non hanno motivi per modificarlo.
+preventivamente alcuni permessi, il caso più comune è eliminare il permesso di
+scrittura per il gruppo e gli altri, corrispondente ad un valore
+per \param{mask} pari a $022$. In questo modo è possibile cancellare
+automaticamente i permessi non voluti. Di norma questo valore viene impostato
+una volta per tutte al login (a $022$ se non indicato altrimenti), e gli
+utenti non hanno motivi per modificarlo.
\itindend{umask}
all'\ids{UID} effettivo del processo che lo crea; per il \ids{GID} invece
prevede due diverse possibilità:
\begin{itemize*}
-\item il \ids{GID} del file corrisponde al \ids{GID} effettivo del processo.
-\item il \ids{GID} del file corrisponde al \ids{GID} della directory in cui
- esso è creato.
+\item che il \ids{GID} del file corrisponda al \ids{GID} effettivo del
+ processo.
+\item che il \ids{GID} del file corrisponda al \ids{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
% LocalWords: subtree SILENT log unbindable BUSY EAGAIN EXPIRE DETACH NOFOLLOW
% LocalWords: lazy encfs sshfs setfsent getfsent getfsfile getfsspec endfsent
% LocalWords: setmntent getmntent addmntent endmntent hasmntopt such offsetof
-% LocalWords: member scan attack EOVERFLOW BITS blkcnt rdev
+% LocalWords: member scan attack EOVERFLOW BITS blkcnt rdev FDCWD functions
%%% Local Variables:
%%% mode: latex
projects / gapil.git / commitdiff