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 (affronteremo in
dettaglio l'argomento dei permessi di file e directory in
-sez.~\ref{sec:file_access_control}). Se inoltre lo \textit{sticky} bit (vedi
-sez.~\ref{sec:file_sticky}) è impostato occorrerà anche essere proprietari del
-file o proprietari della directory (o root, per cui nessuna delle restrizioni
-è applicata).
+sez.~\ref{sec:file_access_control}). Se inoltre lo
+\itindex{sticky~bit}\textit{sticky bit} (vedi sez.~\ref{sec:file_sticky}) è
+impostato occorrerà anche essere proprietari del file o proprietari della
+directory (o root, per cui nessuna delle restrizioni è applicata).
Una delle caratteristiche di queste funzioni è che la creazione/rimozione del
nome dalla directory e l'incremento/decremento del numero di riferimenti
un'ulteriore condizione,\footnote{come vedremo in
cap.~\ref{cha:file_unix_interface} il kernel mantiene anche una tabella dei
file aperti nei vari processi, che a sua volta contiene i riferimenti agli
- inode ad essi relativi. Prima di procedere alla cancellazione dello spazio
- occupato su disco dal contenuto di un file il kernel controlla anche questa
- tabella, per verificare che anche in essa non ci sia più nessun riferimento
- all'inode in questione.} e cioè che non ci siano processi che abbiano il
-suddetto file aperto).
+ \index{inode} inode ad essi relativi. Prima di procedere alla cancellazione
+ dello spazio occupato su disco dal contenuto di un file il kernel controlla
+ anche questa tabella, per verificare che anche in essa non ci sia più nessun
+ riferimento all'inode in questione.} e cioè che non ci siano processi che
+abbiano il suddetto 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
\label{sec:file_symlink}
Come abbiamo visto in sez.~\ref{sec:file_link} la funzione \func{link} crea
-riferimenti agli inode\index{inode}, pertanto può funzionare soltanto per file
+riferimenti agli \index{inode}inode, 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.
\label{sec:file_dir_creat_rem}
Benché in sostanza le directory non siano altro che dei file contenenti
-elenchi di nomi ed inode, non è possibile trattarle come file ordinari e
-devono essere create direttamente dal kernel attraverso una opportuna system
-call.\footnote{questo permette anche, attraverso l'uso del VFS, l'utilizzo di
- diversi formati per la gestione dei suddetti elenchi.} La funzione usata
-per creare una directory è \funcd{mkdir}, ed il suo prototipo è:
+elenchi di nomi ed \index{inode}inode, non è possibile trattarle come file
+ordinari e devono essere create direttamente dal kernel attraverso una
+opportuna system call.\footnote{questo permette anche, attraverso l'uso del
+ VFS, l'utilizzo di diversi formati per la gestione dei suddetti elenchi.}
+La funzione usata per creare una directory è \funcd{mkdir}, ed il suo
+prototipo è:
\begin{functions}
\headdecl{sys/stat.h}
\headdecl{sys/types.h}
errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
\item[\errcode{EPERM}] Il filesystem non supporta la cancellazione di
- directory, oppure la directory che contiene \param{dirname} ha lo sticky
- bit impostato e l'user-ID effettivo del processo non corrisponde al
- proprietario della directory.
+ directory, oppure la directory che contiene \param{dirname} ha lo
+ \itindex{sticky~bit} \textit{sticky bit} impostato e l'user-ID effettivo
+ del processo non corrisponde al proprietario della directory.
\item[\errcode{EACCES}] 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
\label{sec:file_dir_read}
Benché le directory alla fine non siano altro che dei file che contengono
-delle liste di nomi ed inode, per il ruolo che rivestono nella struttura del
-sistema, non possono essere trattate come dei normali file di dati. Ad
-esempio, onde evitare inconsistenze all'interno del filesystem, solo il kernel
-può scrivere il contenuto di una directory, e non può essere un processo a
-inserirvi direttamente delle voci con le usuali funzioni di scrittura.
+delle liste di nomi ed \index{inode}inode, per il ruolo che rivestono nella
+struttura del sistema, non possono essere trattate come dei normali file di
+dati. Ad esempio, onde evitare inconsistenze all'interno del filesystem, solo
+il kernel può scrivere il contenuto di una directory, e non può essere un
+processo a inserirvi direttamente delle voci con le usuali funzioni di
+scrittura.
Ma se la scrittura e l'aggiornamento dei dati delle directory è compito del
kernel, sono molte le situazioni in cui i processi necessitano di poterne
ma solo un limite \const{NAME\_MAX}; in SVr4 la lunghezza del campo è
definita come \code{NAME\_MAX+1} che di norma porta al valore di 256 byte
usato anche in Linux.} ed il campo \var{d\_ino}, che contiene il numero di
-inode cui il file è associato (di solito corrisponde al campo \var{st\_ino} di
-\struct{stat}).
+\index{inode}inode cui il file è associato (di solito corrisponde al campo
+\var{st\_ino} di \struct{stat}).
\begin{figure}[!htb]
\footnotesize \centering
la prima valida delle seguenti:
\begin{itemize*}
\item La variabile di ambiente \const{TMPNAME} (non ha effetto se non è
- definita o se il programma chiamante è \acr{suid} o \acr{sgid}, vedi
- sez.~\ref{sec:file_suid_sgid}).
+ definita o se il programma chiamante è \itindex{suid~bit} \acr{suid} o
+ \itindex{sgid~bit} \acr{sgid}, vedi sez.~\ref{sec:file_suid_sgid}).
\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}.
caso si possono usare le vecchie funzioni \funcd{mktemp} e \func{mkstemp} che
modificano una stringa di input che serve da modello e che deve essere
conclusa da 6 caratteri \code{X} che verranno sostituiti da un codice
-unico. La prima delle due è analoga a \funcd{tmpnam} e genera un nome casuale,
+unico. La prima delle due è analoga a \func{tmpnam} e genera un nome casuale,
il suo prototipo è:
\begin{prototype}{stlib.h}{char *mktemp(char *template)}
Genera un filename univoco sostituendo le \code{XXXXXX} finali di
\const{S\_IFCHR} & 0020000 & dispositivo a caratteri \\
\const{S\_IFIFO} & 0010000 & fifo \\
\hline
- \const{S\_ISUID} & 0004000 & set UID bit \\
- \const{S\_ISGID} & 0002000 & set GID bit \\
- \const{S\_ISVTX} & 0001000 & sticky bit \\
+ \const{S\_ISUID} & 0004000 & set UID bit \itindex{suid~bit} \\
+ \const{S\_ISGID} & 0002000 & set GID bit \itindex{sgid~bit} \\
+ \const{S\_ISVTX} & 0001000 & sticky bit \itindex{sticky~bit}\\
\hline
% \const{S\_IRWXU} & 00700 & bitmask per i permessi del proprietario \\
\const{S\_IRUSR} & 00400 & il proprietario ha permesso di lettura \\
\label{fig:file_perm_bit}
\end{figure}
-I restanti tre bit (noti come \acr{suid}, \acr{sgid}, e \textsl{sticky}) sono
-usati per indicare alcune caratteristiche più complesse del meccanismo del
-controllo di accesso su cui torneremo in seguito (in
+I restanti tre bit (noti come \itindex{suid~bit}\textit{suid bit},
+\itindex{sgid~bit}\textit{sgid bit}, e \itindex{sticky~bit} \textit{sticky
+ bit}) sono usati per indicare alcune caratteristiche più complesse del
+meccanismo del controllo di accesso su cui torneremo in seguito (in
sez.~\ref{sec:file_suid_sgid} e sez.~\ref{sec:file_sticky}); lo schema di
allocazione dei bit è riportato in fig.~\ref{fig:file_perm_bit}.
simbolico tutti i permessi come concessi; utente e gruppo a cui esso
appartiene vengono pure 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} impostato (si veda
-sez.~\ref{sec:file_sticky}).
+in una directory con lo \itindex{sticky~bit} \textit{sticky bit} impostato (si
+veda sez.~\ref{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
\subsection{I bit \acr{suid} e \acr{sgid}}
\label{sec:file_suid_sgid}
+\itindbeg{suid~bit}
+\itindbeg{sgid~bit}
+
Come si è accennato (in sez.~\ref{sec:file_perm_overview}) nei dodici bit del
campo \var{st\_mode} di \struct{stat} che vengono usati per il controllo di
accesso oltre ai bit dei permessi veri e propri, ci sono altri tre bit che
per quel file il \textit{mandatory locking} (affronteremo questo argomento in
dettaglio più avanti, in sez.~\ref{sec:file_mand_locking}).
+\itindend{suid~bit}
+\itindend{sgid~bit}
\subsection{Il bit \textsl{sticky}}
\label{sec:file_sticky}
+\itindbeg{sticky~bit}
+
L'ultimo dei bit rimanenti, identificato dalla costante \const{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 impostare questo bit.
-L'effetto di questo bit era che il segmento di testo del programma (si veda
-sez.~\ref{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 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 \cmd{t} al
-posto della \cmd{x} nei permessi per gli altri.
+L'effetto di questo bit era che il \index{segmento!testo} segmento di testo
+del programma (si veda sez.~\ref{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 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.
Ovviamente per evitare che gli utenti potessero intasare la swap solo
l'amministratore era in grado di impostare questo bit, che venne chiamato
costante. Le attuali implementazioni di memoria virtuale e filesystem rendono
sostanzialmente inutile questo procedimento.
-Benché ormai non venga più utilizzato per i file, lo \textsl{sticky bit} ha
-invece assunto un uso importante per le directory;\footnote{lo \textsl{sticky
+Benché ormai non venga più utilizzato per i file, lo \textit{sticky bit} ha
+invece assunto un uso importante per le directory;\footnote{lo \textit{sticky
bit} per le directory è un'estensione non definita nello standard POSIX,
Linux però la supporta, così come BSD e SVr4.} in questo caso se tale bit è
impostato un file potrà essere rimosso dalla directory soltanto se l'utente ha
$ ls -ld /tmp
drwxrwxrwt 6 root root 1024 Aug 10 01:03 /tmp
\end{verbatim}%$
-quindi con lo \textsl{sticky bit} bit impostato. In questo modo qualunque
+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
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{La titolarità di nuovi file e directory}
\label{sec:file_ownership}
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 \acr{suid} bit) che vuole controllare se l'utente originale ha i
-permessi per accedere ad un certo file.
+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.
\subsection{Le funzioni \func{chmod} e \func{fchmod}}
\textbf{\param{mode}} & \textbf{Valore} & \textbf{Significato} \\
\hline
\hline
- \const{S\_ISUID} & 04000 & set user ID \\
- \const{S\_ISGID} & 02000 & set group ID \\
- \const{S\_ISVTX} & 01000 & sticky bit \\
+ \const{S\_ISUID} & 04000 & set user ID \itindex{suid~bit} \\
+ \const{S\_ISGID} & 02000 & set group ID \itindex{sgid~bit}\\
+ \const{S\_ISVTX} & 01000 & sticky bit \itindex{sticky~bit}\\
\hline
\const{S\_IRWXU} & 00700 & l'utente ha tutti i permessi \\
\const{S\_IRUSR} & 00400 & l'utente ha il permesso di lettura \\
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$.
+bit \itindex{suid~bit} \acr{suid} il valore da fornire sarebbe $4755$.
Il cambiamento dei permessi di un file eseguito attraverso queste funzioni ha
comunque alcune limitazioni, previste per motivi di sicurezza. L'uso delle
non tutti i valori possibili di \param{mode} sono permessi o hanno effetto;
in particolare accade che:
\begin{enumerate}
-\item siccome solo l'amministratore può impostare lo \textit{sticky bit}, se
- l'user-ID effettivo del processo non è zero esso viene automaticamente
- cancellato (senza notifica di errore) qualora sia stato indicato in
- \param{mode}.
+\item siccome solo l'amministratore può impostare lo \itindex{sticky~bit}
+ \textit{sticky bit}, se l'user-ID effettivo del processo non è zero esso
+ viene automaticamente cancellato (senza notifica di errore) qualora sia
+ stato indicato in \param{mode}.
\item per quanto detto in sez.~\ref{sec:file_ownership} riguardo la 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 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'user-ID effettivo del processo è zero).
+ che si possa assegnare il bit \itindex{sgid~bit} \acr{sgid} ad un file
+ appartenente a 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'user-ID effettivo del processo è zero).
\end{enumerate}
-Per alcuni filesystem\footnote{il filesystem \acr{ext2} supporta questa
- caratteristica, che è mutuata da BSD.} è inoltre prevista una ulteriore
-misura di sicurezza, volta a scongiurare l'abuso dei bit \acr{suid} e
-\acr{sgid}; essa consiste nel cancellare automaticamente questi bit dai
-permessi di un file qualora un processo che non appartenga all'amministratore
-effettui una scrittura. In questo modo anche se un utente malizioso scopre un
-file \acr{suid} su cui può scrivere, un'eventuale modifica comporterà la
-perdita di questo privilegio.
+Per alcuni filesystem\footnote{i filesystem più comuni (\textsl{ext2},
+ \textsl{ext3}, \textsl{reiser}) supportano questa caratteristica, che è
+ mutuata da BSD.} è inoltre prevista una ulteriore misura di sicurezza, volta
+a scongiurare l'abuso dei \itindex{suid~bit} bit \acr{suid} e \acr{sgid}; essa
+consiste nel cancellare automaticamente questi bit dai permessi di un file
+qualora un processo che non appartenga all'amministratore\footnote{per la
+ precisione un processo che non dispone della capability
+ \const{CAP\_FSETID}.} effettui una scrittura. In questo modo anche se un
+utente malizioso scopre un file \acr{suid} su cui può scrivere, un'eventuale
+modifica comporterà la perdita di questo privilegio.
\subsection{La funzione \func{umask}}
\label{sec:file_umask}
\errval{EACCES}, \errval{ELOOP}; \func{fchown} anche \errval{EBADF}.}
\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.
+In Linux soltanto l'amministratore (in sostanza un processo con la
+\itindex{capabilities} capability \const{CAP\_CHOWN}) 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 di cui fa parte.
La funzione \func{chown} segue i link simbolici, per operare direttamente su
un link simbolico si deve usare la funzione \func{lchown}.\footnote{fino alla
valore per \param{owner} e \param{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 sez.~\ref{sec:file_perms}), le date (vedi
-%sez.~\ref{sec:file_times}).
+privilegi di root entrambi i bit \itindex{suid~bit} \acr{suid} e
+\itindex{sgid~bit} \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}.
\subsection{Un quadro d'insieme sui permessi}
\label{tab:file_fileperm_bits}
\end{table}
-Per compattezza, nella tabella si sono specificati i bit di \acr{suid},
-\acr{sgid} e \acr{sticky} con la notazione illustrata anche in
-fig.~\ref{fig:file_perm_bit}.
+Per compattezza, nella tabella si sono specificati i bit di \itindex{suid~bit}
+\textit{suid}, \itindex{sgid~bit} \textit{sgid} e \textit{sticky}
+\itindex{sticky~bit} con la notazione illustrata anche in
+fig.~\ref{fig:file_perm_bit}.
In tab.~\ref{tab:file_dirperm_bits} si sono invece riassunti gli effetti dei
vari bit dei permessi per una directory; anche in questo caso si sono
-specificati i bit di \acr{suid}, \acr{sgid} e \acr{sticky} con la notazione
-compatta illustrata in fig.~\ref{fig:file_perm_bit}.
+specificati i bit di \itindex{suid~bit} \textit{suid}, \itindex{sgid~bit}
+\textit{sgid} e \textit{sticky} \itindex{sticky~bit} con la notazione compatta
+illustrata in fig.~\ref{fig:file_perm_bit}.
\begin{table}[!htb]
\centering
projects / gapil.git / blobdiff