X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=blobdiff_plain;f=filedir.tex;h=a268c1345473757abb27de5be1f291fd31ca6ec8;hb=fca834b08d79d8c024956a598d06ff36d8817d9f;hp=ce6f6c026af79c4dc806b80c9533c4a4f75ec23c;hpb=74b559a3958675adf01c9a906cdd485eaf399290;p=gapil.git diff --git a/filedir.tex b/filedir.tex index ce6f6c0..a268c13 100644 --- a/filedir.tex +++ b/filedir.tex @@ -163,10 +163,10 @@ Per cancellare una voce in una directory 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 @@ -269,7 +269,7 @@ necessario lo spostamento di un file fra directory diverse. Eventuali altri 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). @@ -280,7 +280,7 @@ essere una directory vuota, altrimenti si avranno gli errori \errcode{ENOTDIR} \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 @@ -527,9 +527,9 @@ standard (\file{.} e \file{..}), con il nome indicato dall'argomento 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 è: @@ -611,7 +611,7 @@ creare file regolari e fifo; l'argomento \param{mode} specifica il tipo di 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 dispositivo @@ -629,8 +629,8 @@ agli utenti normali. 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 @@ -1210,7 +1210,7 @@ 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 è \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}. @@ -1336,14 +1336,14 @@ gestione del controllo di accesso, trattate in in 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 file. 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} @@ -1398,8 +1398,9 @@ tab.~\ref{tab:intro_primitive_types}, e dichiarati in \file{sys/types.h}). 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, @@ -1493,9 +1494,10 @@ poi si effettua il confronto con la combinazione di tipi scelta. \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 @@ -1600,13 +1602,15 @@ infatti fa riferimento ad una modifica del contenuto di un file, mentre il 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 @@ -1708,10 +1712,6 @@ esiste. Per questo motivo quando si copia un file, a meno di preservare 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} @@ -1827,12 +1827,12 @@ rispettivamente al proprietario, al gruppo, a tutti gli altri. \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 @@ -1922,7 +1922,7 @@ 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 \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 @@ -1937,7 +1937,7 @@ effettivo e gli eventuali group-ID supplementari del processo.\footnote{in 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. @@ -1978,8 +1978,8 @@ processo appartiene ad un gruppo appropriato, in questo caso i permessi per tutti gli altri non vengono controllati. -\subsection{I bit \acr{suid} e \acr{sgid}} -\label{sec:file_suid_sgid} +\subsection{I bit dei permessi speciali} +\label{sec:file_special_perm} \itindbeg{suid~bit} \itindbeg{sgid~bit} @@ -2032,10 +2032,10 @@ riportati in tab.~\ref{tab:file_mode_flags}. Gli stessi bit vengono ad assumere in significato completamente diverso per le directory, normalmente infatti Linux usa la convenzione di SVr4 per indicare con questi bit l'uso della semantica BSD nella creazione di nuovi file (si -veda 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 \itindex{mandatory~locking} \textit{mandatory locking} @@ -2045,8 +2045,6 @@ sez.~\ref{sec:file_mand_locking}). \itindend{suid~bit} \itindend{sgid~bit} -\subsection{Il bit \textsl{sticky}} -\label{sec:file_sticky} \itindbeg{sticky~bit} @@ -2098,52 +2096,15 @@ consapevolmente, cancellare i file temporanei creati degli altri utenti. \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 è: @@ -2206,10 +2167,6 @@ 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. - -\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: @@ -2303,19 +2260,19 @@ in particolare accade che: \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 @@ -2324,9 +2281,6 @@ 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 @@ -2368,8 +2322,41 @@ voluti. Di norma questo valore viene impostato una volta per tutte al login a $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 @@ -2522,6 +2509,8 @@ non 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} @@ -2641,4 +2630,4 @@ programmi e librerie) di cui il server potrebbe avere bisogno. % 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 +% LocalWords: FTP Di