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 è: