\subsection{I permessi per l'accesso ai file}
\label{sec:file_perm_overview}
-Il controllo di accesso ai file in unix segue un modello abbastanza semplice,
-ma adatto alla gran parte delle esigenze, in cui si dividono i permessi su tre
-livelli. Si tenga conto poi che quanto diremo è vero solo per filesystem di
-tipo unix, e non è detto che sia applicabile a un filesystem
+Il controllo di accesso ai file in unix segue un modello abbastanza semplice
+(ma adatto alla gran parte delle esigenze) in cui si dividono i permessi su
+tre livelli. Si tenga conto poi che quanto diremo è vero solo per filesystem
+di tipo unix, e non è detto che sia applicabile a un filesystem
qualunque\footnote{ed infatti non è vero per il filesystem vfat di Windows,
per il quale i permessi vengono assegnati in maniera fissa con un opzione in
fase di montaggio}. Esistono inoltre estensioni che permettono di
del processo.
Per una spiegazione dettagliata degli identificatori associati ai processi si
-veda \secref{sec:prochand_perms}; normalmente, a parte quanto vedremo in
+veda \secref{sec:proc_perms}; normalmente, a parte quanto vedremo in
\secref{sec:file_suid_sgid}, l'\textit{effective user id} e
l'\textit{effective group id} corrispondono a uid e gid dell'utente che ha
lanciato il processo, mentre i \textit{supplementary group id} sono quelli dei
\textit{set-group-ID bit}) che sono identificati dalle constanti
\macro{S\_ISUID} e \macro{S\_ISGID}.
-Come spiegato in dettaglio in \secref{sec:prochand_exec}, quando si lancia un
+Come spiegato in dettaglio in \secref{sec:proc_exec}, quando si lancia un
programma il comportamendo normale del kernel è quello di settare
l'\textit{effective user id} e l'\textit{effective group id} del nuovo
processo all'uid e al gid del processo corrente, che normalmente corrispondono
normalmente l'utente che lo ha lanciato comporta vari rischi, e questo tipo di
programmi devono essere scritti accuratamente per evitare che possano essere
usati per guadagnare privilegi non consentiti (torneremo sull'argomento in
-\secref{sec:prochand_perms}).
+\secref{sec:proc_perms}).
La presenza dei bit \acr{suid} e \acr{sgid} su un file può essere
rilevata con il comando \cmd{ls -l}, in tal caso comparirà la lettera \cmd{s}
group id} del processo, ma ci sono casi in cui si può voler effettuare il
controllo usando il \textit{real user id} e il \textit{real group id} (cioè
l'uid dell'utente che ha lanciato il programma, che, come accennato in
-\secref{sec:file_suid_sgid} e spiegato in \secref{sec:prochand_perms} non è
+\secref{sec:file_suid_sgid} e spiegato in \secref{sec:proc_perms} non è
detto sia uguale all'\textit{effective user id}). Per far questo si può usare
la funzione \func{access}, il cui prototipo è:
standard POSIX definisce un insieme di macro per verificare il tipo di files,
queste vengono usate anche da Linux che supporta pure le estensioni per link
simbolici e socket definite da BSD, l'elenco completo di tutte le macro
-definite in GNU/Linux è riportato in \ntab:
+definite in GNU/Linux è riportato in \ntab.
\begin{table}[htb]
\centering
\footnotesize
anche ad un file che non esiste; ad esempio possiamo creare un file temporaneo
nella nostra directory con un link del tipo:
\begin{verbatim}
-$ln -s /tmp/tmp_file temporaneo
+$ ln -s /tmp/tmp_file temporaneo
\end{verbatim}%$
ma anche se \file{/tmp/tmp\_file} non esiste. Aprendo in scrittura
\file{temporaneo} questo verrà scritto; ma se cercassimo di accederlo in sola
parlavamo in \secref{sec:file_vfs}) in una opportuna struttura
\texttt{struct dirent}.
+(NdA Il resto va scritto!!! É noioso e lo farò più avanti).
+
+
\subsection{La directory di lavoro}
\label{sec:file_work_dir}
fatta per compatibilità all'indietro con BSD, che non consente di specificare
la dimensione del buffer; esso deve essere allocato in precedenza ed avere una
dimensione superiore a \texttt{PATH\_MAX} (di solito 256 bytes, vedi
-\secref{sec:xxx_limits}; il problema è che in Linux non esiste una dimensione
+\secref{sec:xxx_limits}); il problema è che in Linux non esiste una dimensione
superiore per un pathname, per cui non è detto che il buffer sia sufficiente a
contenere il nome del file, e questa è la ragione principale per cui questa
funzione è deprecata.
projects / gapil.git / blobdiff