%% filedir.tex
%%
-%% Copyright (C) 2000-2005 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2006 Simone Piccardi. Permission is granted to
%% copy, distribute and/or modify this document under the terms of the GNU Free
%% Documentation License, Version 1.1 or any later version published by the
%% Free Software Foundation; with the Invariant Sections being "Un preambolo",
La funzione cancella il nome specificato da \param{pathname} nella relativa
directory e decrementa il numero di riferimenti nel relativo
inode\index{inode}. Nel caso di link simbolico cancella il link simbolico; nel
-caso di socket\index{socket}, fifo o file di
-dispositivo\index{file!di~dispositivo} rimuove il nome, ma come per i file i
-processi che hanno aperto uno di questi oggetti possono continuare ad
-utilizzarlo.
+caso di socket, fifo o file di dispositivo\index{file!di~dispositivo} rimuove
+il nome, ma come per i file i processi che hanno aperto uno di questi oggetti
+possono continuare ad utilizzarlo.
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 (affronteremo in
dettaglio l'argomento dei permessi di file e directory in
-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).
+sez.~\ref{sec:file_access_control}). Se inoltre lo \itindex{sticky~bit}
+\textit{sticky bit} (vedi sez.~\ref{sec:file_special_perm}) è 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
link diretti allo stesso file non vengono influenzati.
Il comportamento della funzione è diverso a seconda che si voglia rinominare
-un file o una directory; se ci riferisce a un file allora \param{newpath}, se
+un file o una directory; se ci riferisce ad un file allora \param{newpath}, se
esiste, non deve essere una directory (altrimenti si ha l'errore
\errcode{EISDIR}). Nel caso \param{newpath} indichi un file esistente questo
viene cancellato e rimpiazzato (atomicamente).
\param{newpath} non può contenere \param{oldpath} altrimenti si avrà un errore
\errcode{EINVAL}.
-Se \param{oldpath} si riferisce a un link simbolico questo sarà rinominato; se
+Se \param{oldpath} si riferisce ad un link simbolico questo sarà rinominato; se
\param{newpath} è un link simbolico verrà cancellato come qualunque altro
file. Infine qualora \param{oldpath} e \param{newpath} siano due nomi dello
stesso file lo standard POSIX prevede che la funzione non dia errore, e non
I permessi di accesso alla directory (vedi sez.~\ref{sec:file_access_control})
sono specificati da \param{mode}, i cui possibili valori sono riportati in
tab.~\ref{tab:file_permission_const}; questi sono modificati dalla maschera di
-creazione dei file (si veda sez.~\ref{sec:file_umask}). La titolarità della
-nuova directory è impostata secondo quanto riportato in
-sez.~\ref{sec:file_ownership}.
+creazione dei file (si veda sez.~\ref{sec:file_perm_management}). La
+titolarità della nuova directory è impostata secondo quanto riportato in
+sez.~\ref{sec:file_ownership_management}.
La funzione per la cancellazione di una directory è \funcd{rmdir}, il suo
prototipo è:
Finora abbiamo parlato esclusivamente di file, directory e link simbolici; in
sez.~\ref{sec:file_file_types} abbiamo visto però che il sistema prevede pure
degli altri tipi di file speciali, come i file di dispositivo
-\index{file!di~dispositivo} e le fifo (i socket\index{socket} sono un caso a
-parte, che vedremo in cap.~\ref{cha:socket_intro}).
+\index{file!di~dispositivo} e le fifo (i socket sono un caso a parte, che
+tratteremo in cap.~\ref{cha:socket_intro}).
La manipolazione delle caratteristiche di questi file e la loro cancellazione
può essere effettuata con le stesse funzioni che operano sui file regolari; ma
file che si vuole creare ed i relativi permessi, secondo i valori riportati in
tab.~\ref{tab:file_mode_flags}, che vanno combinati con un OR binario. I
permessi sono comunque modificati nella maniera usuale dal valore di
-\var{umask} (si veda sez.~\ref{sec:file_umask}).
+\var{umask} (si veda sez.~\ref{sec:file_perm_management}).
Per il tipo di file può essere specificato solo uno fra: \const{S\_IFREG} per
-un file regolare (che sarà creato vuoto), \const{S\_IFBLK} per un device a
-blocchi, \const{S\_IFCHR} per un device a caratteri e \const{S\_IFIFO} per una
-fifo. Un valore diverso comporterà l'errore \errcode{EINVAL}. Qualora si sia
-specificato in \param{mode} un file di dispositivo, il valore di \param{dev}
-viene usato per indicare a quale dispositivo si fa riferimento.
+un file regolare (che sarà creato vuoto), \const{S\_IFBLK} per un dispositivo
+a blocchi, \const{S\_IFCHR} per un dispositivo a caratteri e \const{S\_IFIFO}
+per una fifo. Un valore diverso comporterà l'errore \errcode{EINVAL}. Qualora
+si sia specificato in \param{mode} un file di dispositivo, il valore di
+\param{dev} viene usato per indicare a quale dispositivo si fa riferimento.
Solo l'amministratore può creare un file di dispositivo o un file regolare
usando questa funzione; ma in Linux\footnote{la funzione non è prevista dallo
I nuovi inode\index{inode} creati con \func{mknod} apparterranno al
proprietario e al gruppo del processo che li ha creati, a meno che non si sia
attivato il bit \acr{sgid} per la directory o sia stata attivata la semantica
-BSD per il filesystem (si veda sez.~\ref{sec:file_ownership}) in cui si va a
-creare l'inode\index{inode}.
+BSD per il filesystem (si veda sez.~\ref{sec:file_ownership_management}) in
+cui si va a creare l'inode\index{inode}.
Per creare una fifo (un file speciale, su cui torneremo in dettaglio in
sez.~\ref{sec:ipc_named_pipe}) lo standard POSIX specifica l'uso della funzione
Al solito, per la presenza fra gli argomenti di due puntatori a funzione, il
prototipo non è molto comprensibile; queste funzioni però sono quelle che
-controllano rispettivamente la selezione di una voce (\param{select}) e
-l'ordinamento di tutte le voci selezionate (\param{compar}).
+controllano rispettivamente la selezione di una voce (quella passata con
+l'argomento \param{select}) e l'ordinamento di tutte le voci selezionate
+(quella specificata dell'argomento \param{compar}).
La funzione legge tutte le voci della directory indicata dall'argomento
-\param{dir}, passando ciascuna di esse come argomento alla funzione di
-\param{select}; se questa ritorna un valore diverso da zero la voce viene
-inserita in una struttura allocata dinamicamente con \func{malloc}, qualora si
-specifichi un valore \val{NULL} per \func{select} vengono selezionate tutte le
-voci. Tutte le voci selezionate vengono poi inserite un una lista (anch'essa
-allocata con \func{malloc}, che viene riordinata tramite \func{qsort} usando
-la funzione \param{compar} come criterio di ordinamento; alla fine l'indirizzo
-della lista ordinata è restituito nell'argomento \param{namelist}.
-
-Per l'ordinamento sono disponibili anche due funzioni predefinite,
+\param{dir}, passando ciascuna di esse (una struttura \struct{dirent}) come
+argomento della funzione di selezione specificata da \param{select}; se questa
+ritorna un valore diverso da zero la voce viene inserita in un vettore che
+viene allocato dinamicamente con \func{malloc}. Qualora si specifichi un
+valore \val{NULL} per \func{select} vengono selezionate tutte le voci.
+
+Le voci selezionate possono essere riordinate tramite \func{qsort}, le modalità
+del riordinamento possono essere personalizzate usando la funzione
+\param{compar} come criterio di ordinamento di\func{qsort}, la funzione prende
+come argomenti le due strutture \struct{dirent} da confrontare restituendo un
+valore positivo, nullo o negativo per indicarne l'ordinamento; alla fine
+l'indirizzo della lista delle strutture \struct{dirent} così ordinate viene
+restituito nell'argomento \param{namelist}.
+
+Per l'ordinamento (vale a dire come valori possibili per l'argomento
+\param{compar}) sono disponibili anche due funzioni predefinite,
\funcd{alphasort} e \funcd{versionsort}, i cui prototipi sono:
\begin{functions}
\headdecl{dirent.h}
\begin{itemize*}
\item La variabile di ambiente \const{TMPNAME} (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_suid_sgid}).
+ \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}.
condition}\itindex{race~condition} non si pongono.
-\section{La manipolazione delle caratteristiche dei files}
+\section{La manipolazione delle caratteristiche dei file}
\label{sec:file_infos}
Come spiegato in sez.~\ref{sec:file_filesystem} tutte le informazioni generali
sez.~\ref{sec:file_access_control}).
-\subsection{Le funzioni \func{stat}, \func{fstat} e \func{lstat}}
+\subsection{La lettura delle caratteristiche dei file}
\label{sec:file_stat}
La lettura delle informazioni relative ai file è fatta attraverso la famiglia
delle funzioni \func{stat} (\funcd{stat}, \funcd{fstat} e \funcd{lstat});
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:
+e mostrare tutti i dati relativi ad un file. I prototipi di queste funzioni
+sono i seguenti:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/stat.h}
\funcdecl{int lstat(const char *file\_name, struct stat *buf)} Identica a
\func{stat} eccetto che se il \param{file\_name} è un link simbolico vengono
- lette le informazioni relativae ad esso e non al file a cui fa riferimento.
+ lette le informazioni relative ad esso e non al file a cui fa riferimento.
\funcdecl{int fstat(int filedes, struct stat *buf)} Identica a \func{stat}
eccetto che si usa con un file aperto, specificato tramite il suo file
Come riportato in tab.~\ref{tab:file_file_types} in Linux oltre ai file e alle
directory esistono altri oggetti che possono stare su un filesystem. Il tipo
-di file è ritornato dalla \func{stat} come maschera binaria nel campo
-\var{st\_mode} (che contiene anche le informazioni relative ai permessi).
+di file è ritornato dalla funzione \func{stat} come maschera binaria nel campo
+\var{st\_mode} (che contiene anche le informazioni relative ai permessi) di
+una struttura \struct{stat}.
Dato che il valore numerico può variare a seconda delle implementazioni, lo
standard POSIX definisce un insieme di macro per verificare il tipo di file,
queste vengono usate anche da Linux che supporta pure le estensioni allo
-standard per i link simbolici e i socket\index{socket} definite da BSD;
-l'elenco completo delle macro con cui è possibile estrarre l'informazione da
-\var{st\_mode} è riportato in tab.~\ref{tab:file_type_macro}.
+standard per i link simbolici e i socket definite da BSD; l'elenco completo
+delle macro con cui è possibile estrarre l'informazione da \var{st\_mode} è
+riportato in tab.~\ref{tab:file_type_macro}.
\begin{table}[htb]
\centering
\footnotesize
\macro{S\_ISBLK(m)} & dispositivo a blocchi\\
\macro{S\_ISFIFO(m)} & fifo \\
\macro{S\_ISLNK(m)} & link simbolico \\
- \macro{S\_ISSOCK(m)} & socket\index{socket} \\
+ \macro{S\_ISSOCK(m)} & socket \\
\hline
\end{tabular}
\caption{Macro per i tipi di file (definite in \texttt{sys/stat.h}).}
\hline
\hline
\const{S\_IFMT} & 0170000 & maschera per i bit del tipo di file \\
- \const{S\_IFSOCK} & 0140000 & socket\index{socket} \\
+ \const{S\_IFSOCK} & 0140000 & socket \\
\const{S\_IFLNK} & 0120000 & link simbolico \\
\const{S\_IFREG} & 0100000 & file regolare \\
\const{S\_IFBLK} & 0060000 & dispositivo a blocchi \\
\subsection{Le dimensioni dei file}
\label{sec:file_file_size}
-Il campo \var{st\_size} contiene la dimensione del file in byte (se si tratta
-di un file regolare, nel caso di un link simbolico la dimensione è quella del
-\itindex{pathname}\textit{pathname} che contiene, per le fifo è sempre nullo).
+Il campo \var{st\_size} di una struttura \struct{stat} contiene la dimensione
+del file in byte, se si tratta di un file regolare. Nel caso di un link
+simbolico la dimensione è quella del \itindex{pathname} \textit{pathname} che
+il link stesso contiene; per le fifo questo campo è sempre nullo.
Il campo \var{st\_blocks} definisce la lunghezza del file in blocchi di 512
byte. Il campo \var{st\_blksize} infine definisce la dimensione preferita per
\func{ftruncate} si hanno i valori:
\begin{errlist}
\item[\errcode{EBADF}] \param{fd} non è un file descriptor.
- \item[\errcode{EINVAL}] \param{fd} è un riferimento ad un
- socket\index{socket}, non a un file o non è aperto in scrittura.
+ \item[\errcode{EINVAL}] \param{fd} è un riferimento ad un socket, non a un
+ file o non è aperto in scrittura.
\end{errlist}
per \func{truncate} si hanno:
\begin{errlist}
secondo ad una modifica dell'inode\index{inode}; siccome esistono molte
operazioni (come la funzione \func{link} e molte altre che vedremo in seguito)
che modificano solo le informazioni contenute nell'inode\index{inode} senza
-toccare il file, diventa necessario l'utilizzo di un altro tempo.
+toccare il contenuto del file, diventa necessario l'utilizzo di un altro
+tempo.
-Il sistema non tiene conto dell'ultimo accesso all'inode\index{inode},
+Il sistema non tiene conto dell'ultimo accesso \index{inode} all'inode,
pertanto funzioni come \func{access} o \func{stat} non hanno alcuna influenza
sui tre tempi. Il 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 programma \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
esplicitamente i tempi (ad esempio con l'opzione \cmd{-p} di \cmd{cp}) esso
avrà sempre il tempo corrente come data di ultima modifica.
-
-\subsection{La funzione \func{utime}}
-\label{sec:file_utime}
-
I tempi di ultimo accesso e modifica possono essere cambiati usando la
funzione \funcd{utime}, il cui prototipo è:
\begin{prototype}{utime.h}
\label{fig:file_perm_bit}
\end{figure}
-I restanti tre bit (noti come \itindex{suid~bit}\textit{suid bit},
-\itindex{sgid~bit}\textit{sgid bit}, e \itindex{sticky~bit} \textit{sticky
+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}.
+sez.~\ref{sec:file_special_perm}); lo schema di allocazione dei bit è
+riportato in fig.~\ref{fig:file_perm_bit}.
Anche i permessi, come tutte le altre informazioni pertinenti al file, sono
memorizzati nell'inode\index{inode}; in particolare essi sono contenuti in
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 \itindex{sticky~bit} \textit{sticky bit} impostato (si
-veda sez.~\ref{sec:file_sticky}).
+veda sez.~\ref{sec:file_special_perm}).
La procedura con cui il kernel stabilisce se un processo possiede un certo
permesso (di lettura, scrittura o esecuzione) si basa sul confronto fra
Per una spiegazione dettagliata degli identificatori associati ai processi si
veda sez.~\ref{sec:proc_perms}; normalmente, a parte quanto vedremo in
-sez.~\ref{sec:file_suid_sgid}, l'user-ID effettivo e il group-ID effettivo
+sez.~\ref{sec:file_special_perm}, l'user-ID effettivo e il group-ID effettivo
corrispondono ai valori dell'\acr{uid} e del \acr{gid} dell'utente che ha
lanciato il processo, mentre i group-ID supplementari sono quelli dei gruppi
cui l'utente appartiene.
tutti gli altri non vengono controllati.
-\subsection{I bit \acr{suid} e \acr{sgid}}
-\label{sec:file_suid_sgid}
+\subsection{I bit dei permessi speciali}
+\label{sec:file_special_perm}
\itindbeg{suid~bit}
\itindbeg{sgid~bit}
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 sez.~\ref{sec:file_ownership} per una spiegazione dettagliata al
-proposito).
+veda sez.~\ref{sec:file_ownership_management} per una spiegazione dettagliata
+al proposito).
-Infine Linux utilizza il bit \acr{sgid} per una ulteriore estensione mutuata
+Infine Linux utilizza il bit \acr{sgid} per un'ulteriore estensione mutuata
da SVr4. Il caso in cui un file ha il bit \acr{sgid} impostato senza che lo
sia anche il corrispondente bit di esecuzione viene utilizzato per attivare
-per quel file il \textit{mandatory locking} (affronteremo questo argomento in
-dettaglio più avanti, in sez.~\ref{sec:file_mand_locking}).
+per quel file il \itindex{mandatory~locking} \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
+memoria virtuale e l'accesso ai file erano molto meno sofisticati e per
ottenere la massima velocità possibile per i programmi usati più comunemente
si poteva impostare questo bit.
\itindend{sticky~bit}
-
-\subsection{La titolarità di nuovi file e directory}
-\label{sec:file_ownership}
-
-Vedremo in sez.~\ref{sec:file_base_func} con quali funzioni si possono creare
-nuovi file, in tale occasione vedremo che è possibile specificare in sede di
-creazione quali permessi applicare ad un file, però non si può indicare a
-quale utente e gruppo esso deve appartenere. Lo stesso problema si presenta
-per la creazione di nuove directory (procedimento descritto in
-sez.~\ref{sec:file_dir_creat_rem}).
-
-Lo standard POSIX prescrive che l'\acr{uid} del nuovo file corrisponda
-all'user-ID effettivo del processo che lo crea; per il \acr{gid} invece prevede
-due diverse possibilità:
-\begin{itemize*}
-\item il \acr{gid} del file corrisponde al group-ID effettivo 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} impostato allora viene usata la seconda opzione.
-
-Usare la semantica BSD ha il vantaggio che il \acr{gid} viene sempre
-automaticamente propagato, restando coerente a quello della directory di
-partenza, in tutte le sotto-directory.
-
-La semantica SVr4 offre la possibilità di scegliere, ma per ottenere lo stesso
-risultato di coerenza che si ha con BSD necessita che per le nuove directory
-venga anche propagato anche il bit \acr{sgid}. Questo è il comportamento
-predefinito del comando \cmd{mkdir}, ed è in questo modo ad esempio che Debian
-assicura che le sotto-directory create nella home di un utente restino sempre
-con il \acr{gid} del gruppo primario dello stesso.
-
-
-\subsection{La funzione \func{access}}
-\label{sec:file_access}
+\subsection{Le funzioni per la gestione dei permessi dei file}
+\label{sec:file_perm_management}
Come visto in sez.~\ref{sec:file_access_control} il controllo di accesso ad un
file viene fatto utilizzando l'user-ID ed il group-ID effettivo del processo;
ci sono casi però in cui si può voler effettuare il controllo con l'user-ID
reale ed il group-ID reale, vale a dire usando i valori di \acr{uid} e
\acr{gid} relativi all'utente che ha lanciato il programma, e che, come
-accennato in sez.~\ref{sec:file_suid_sgid} e spiegato in dettaglio in
+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 è:
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}}
-\label{sec:file_chmod}
-
Per cambiare i permessi di un file il sistema mette ad disposizione due
funzioni \funcd{chmod} e \funcd{fchmod}, che operano rispettivamente su un
filename e su un file descriptor, i loro prototipi sono:
\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 \itindex{sgid~bit} \acr{sgid} ad un file
- appartenente a un gruppo per cui non si hanno diritti, questo viene
+\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'user-ID effettivo del processo è zero).
\end{enumerate}
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
+ \textsl{ext3}, \textsl{reiserfs}) supportano questa caratteristica, che è
+ mutuata da BSD.} è inoltre prevista un'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
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}
-
Le funzioni \func{chmod} e \func{fchmod} ci permettono di modificare i
permessi di un file, resta però il problema di quali sono i permessi assegnati
quando il file viene creato. Le funzioni dell'interfaccia nativa di Unix, come
$022$, e gli utenti non hanno motivi per modificarlo.
-\subsection{Le funzioni \func{chown}, \func{fchown} e \func{lchown}}
-\label{sec:file_chown}
+
+\subsection{La gestione della titolarità dei file}
+\label{sec:file_ownership_management}
+
+Vedremo in sez.~\ref{sec:file_base_func} con quali funzioni si possono creare
+nuovi file, in tale occasione vedremo che è possibile specificare in sede di
+creazione quali permessi applicare ad un file, però non si può indicare a
+quale utente e gruppo esso deve appartenere. Lo stesso problema si presenta
+per la creazione di nuove directory (procedimento descritto in
+sez.~\ref{sec:file_dir_creat_rem}).
+
+Lo standard POSIX prescrive che l'\acr{uid} del nuovo file corrisponda
+all'user-ID effettivo del processo che lo crea; per il \acr{gid} invece prevede
+due diverse possibilità:
+\begin{itemize*}
+\item il \acr{gid} del file corrisponde al group-ID effettivo 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} impostato allora viene usata la seconda opzione.
+
+Usare la semantica BSD ha il vantaggio che il \acr{gid} viene sempre
+automaticamente propagato, restando coerente a quello della directory di
+partenza, in tutte le sotto-directory.
+
+La semantica SVr4 offre la possibilità di scegliere, ma per ottenere lo stesso
+risultato di coerenza che si ha con BSD necessita che per le nuove directory
+venga anche propagato anche il bit \acr{sgid}. Questo è il comportamento
+predefinito del comando \cmd{mkdir}, ed è in questo modo ad esempio che Debian
+assicura che le sotto-directory create nella home di un utente restino sempre
+con il \acr{gid} del gruppo primario dello stesso.
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
\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}.
+\itindex{mandatory~locking} \textit{mandatory locking}.
\subsection{Un quadro d'insieme sui permessi}
\hline
1&-&-&-&-&-&-&-&-&-&-&-&Se eseguito ha i permessi del proprietario\\
-&1&-&-&-&1&-&-&-&-&-&-&Se eseguito ha i permessi del gruppo proprietario\\
- -&1&-&-&-&0&-&-&-&-&-&-&Il \textit{mandatory locking} è abilitato\\
+ -&1&-&-&-&0&-&-&-&-&-&-&Il \itindex{mandatory~locking}
+ \textit{mandatory locking} è abilitato\\
-&-&1&-&-&-&-&-&-&-&-&-&Non utilizzato\\
-&-&-&1&-&-&-&-&-&-&-&-&Permesso di lettura per il proprietario\\
-&-&-&-&1&-&-&-&-&-&-&-&Permesso di scrittura per il proprietario\\
riferimento soltanto alla combinazione di bit per i quali il valore è
riportato esplicitamente.
+% TODO intrudurre nuova sezione sulle funzionalità di sicurezza avanzate, con
+% dentro chroot, gli attributi estesi, ecc.
\subsection{La funzione \func{chroot}}
\label{sec:file_chroot}
%%% mode: latex
%%% TeX-master: "gapil"
%%% End:
+
+% LocalWords: sez like filesystem unlink MacOS Windows VMS inode kernel unistd
+% LocalWords: un'etichetta int const char oldpath newpath errno EXDEV EPERM st
+% LocalWords: EEXIST EMLINK EACCES ENAMETOOLONG ENOTDIR EFAULT ENOMEM EROFS ls
+% LocalWords: ELOOP ENOSPC EIO pathname nlink stat vfat fsck EISDIR ENOENT cap
+% LocalWords: POSIX socket fifo sticky root nell'inode system call count crash
+% LocalWords: all'inode descriptor remove rename rmdir stdio glibc libc NFS DT
+% LocalWords: ENOTEMPTY EBUSY mount point EINVAL soft symbolic tab symlink fig
+% LocalWords: dangling access chdir chmod chown creat exec lchown lstat mkdir
+% LocalWords: mkfifo mknod opendir pathconf readlink truncate path buff size
+% LocalWords: grub bootloader grep linux MAXSYMLINKS cat VFS sys dirname fcntl
+% LocalWords: dev l'inode umask IFREG IFBLK IFCHR IFIFO SVr sgid BSD SVID NULL
+% LocalWords: stream dirent EMFILE ENFILE dirfd SOURCE fchdir readdir struct
+% LocalWords: EBADF namlen HAVE thread entry result value argument fileno ino
+% LocalWords: name TYPE OFF RECLEN UNKNOWN REG SOCK CHR BLK type IFTODT DTTOIF
+% LocalWords: DTYPE off reclen seekdir telldir void rewinddir closedir select
+% LocalWords: namelist compar malloc qsort alphasort versionsort strcoll myls
+% LocalWords: strcmp DirScan direntry while current working home shell pwd get
+% LocalWords: dell'inode getcwd ERANGE getwd change fd race condition tmpnam
+% LocalWords: string tmpdir TMP tempnam pfx TMPNAME suid tmp EXCL tmpfile pid
+% LocalWords: EINTR mktemp mkstemp stlib template filename XXXXXX OpenBSD buf
+% LocalWords: mkdtemp fstat filedes nell'header padding ISREG ISDIR ISCHR IFMT
+% LocalWords: ISBLK ISFIFO ISLNK ISSOCK IFSOCK IFLNK IFDIR ISUID UID ISGID GID
+% LocalWords: ISVTX IRUSR IWUSR IXUSR IRGRP IWGRP IXGRP IROTH IWOTH IXOTH du
+% LocalWords: blocks blksize holes lseek TRUNC ftruncate length lenght ETXTBSY
+% LocalWords: hole atime read utime mtime write ctime modification leafnode cp
+% LocalWords: make fchmod fchown utimbuf times actime modtime Mac owner uid fs
+% LocalWords: gid Control List patch mandatory control execute group other all
+% LocalWords: dell' effective passwd IGID locking swap saved text IRWXU IRWXG
+% LocalWords: IRWXO ext reiser capability FSETID mask capabilities chroot jail
+% LocalWords: FTP Di
projects / gapil.git / blobdiff