X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=prochand.tex;h=ef6c064a0552dcbfa657378321a7ce663b38fbfb;hp=2578683223646554cb6bc54923d57855dcc7e59e;hb=682ed599d14547e67301b35fba26c3a1cf9a39f7;hpb=f83c16427a6e33346a4713d30800c0fda95a63dd diff --git a/prochand.tex b/prochand.tex index 2578683..ef6c064 100644 --- a/prochand.tex +++ b/prochand.tex @@ -207,10 +207,17 @@ Tutti i processi figli dello stesso processo padre sono detti \textit{sibling}, questa è una delle relazioni usate nel \textsl{controllo di sessione}, in cui si raggruppano i processi creati su uno stesso terminale, o relativi allo stesso login. Torneremo su questo argomento in dettaglio in -\secref{cap:session}, dove esamineremo i vari identificativi associati ad un -processo e le varie relazioni fra processi utilizzate per definire una +\secref{cap:session}, dove esamineremo gli altri identificativi associati ad +un processo e le varie relazioni fra processi utilizzate per definire una sessione. +Oltre al \acr{pid} e al \acr{ppid}, e a quelli usati per il controllo di +sessione, ad ogni processo sono associati altri identificatori, usati per il +controllo di accesso, che servono per determinare se il processo può o meno +eseguire le operazioni richieste, a seconda dei privilegi e dell'identità di +chi lo ha posto in esecuzione; su questi torneremo in dettaglii più avanti in +\secref{sec:proc_perm}. + \subsection{La funzione \func{fork}} \label{sec:proc_fork} @@ -522,16 +529,17 @@ sequenza impredicibile. Le modalit Oltre ai file aperti i processi figli ereditano dal padre una serie di altre proprietà comuni; in dettaglio avremo che dopo l'esecuzione di una \func{fork} padre e figlio avranno in comune: -\begin{itemize} +\begin{itemize*} \item i file aperti (e gli eventuali flag di \textit{close-on-exec} se settati). \item gli identificatori per il controllo di accesso: il \textit{real user id}, il \textit{real group id}, l'\textit{effective user id}, l'\textit{effective group id} e i \textit{supplementary group id} (vedi - \secref{tab:proc_uid_gid}). + \secref{sec:proc_user_group}). \item gli identificatori per il controllo di sessione: il \textit{process - group id} e il \textit{session id} e il terminale di controllo. -\item i flag \acr{suid} e \acr{sgid} (vedi \secref{sec:file_suid_sgid}). + group id} e il \textit{session id} e il terminale di controllo (vedi + \secref{sec:sess_xxx} e \secref{sec:sess_xxx}). +\item i flag di \acr{suid} e \acr{sgid} (vedi \secref{sec:file_suid_sgid}). \item la directory di lavoro e la directory radice (vedi \secref{sec:file_work_dir}). \item la maschera dei permessi di creazione (vedi \secref{sec:file_umask}). @@ -539,9 +547,9 @@ padre e figlio avranno in comune: \item i segmenti di memoria condivisa agganciati al processo. \item i limiti sulle risorse \item le variabili di ambiente (vedi \secref{sec:proc_environ}). -\end{itemize} +\end{itemize*} le differenze invece sono: -\begin{itemize} +\begin{itemize*} \item il valore di ritorno di \func{fork}. \item il \textit{process id}. \item il \textit{parent process id} (quello del figlio viene settato al @@ -550,7 +558,7 @@ le differenze invece sono: \var{tms\_cutime}, \var{tms\_uetime}) che nel figlio sono posti a zero. \item i \textit{file lock}, che non vengono ereditati dal figlio. \item gli allarmi pendenti, che per il figlio vengono cancellati. -\end{itemize} +\end{itemize*} \subsection{La funzione \func{vfork}} @@ -603,7 +611,7 @@ Qualunque sia la modalit comunque una serie di operazioni: chiude tutti i file aperti, rilascia la memoria che stava usando, e così via; l'elenco completo delle operazioni eseguite alla chiusura di un processo è il seguente: -\begin{itemize} +\begin{itemize*} \item tutti i descrittori dei file sono chiusi. \item viene memorizzato lo stato di terminazione del processo. \item ad ogni processo figlio viene assegnato un nuovo padre. @@ -614,7 +622,7 @@ eseguite alla chiusura di un processo \item se la conclusione di un processo rende orfano un \textit{process group} ciascun membro del gruppo viene bloccato, e poi gli vengono inviati in successione i segnali \macro{SIGHUP} e \macro{SIGCONT}. -\end{itemize} +\end{itemize*} ma al di la di queste operazioni è necessario poter disporre di un meccanismo ulteriore che consenta di sapere come questa terminazione è avvenuta; dato che in un sistema unix-like tutto viene gestito attraverso i processi il @@ -978,6 +986,7 @@ versione 4.3 Reno di BSD, attualmente (con il kernel 2.4.x) i soli campi che sono mantenuti sono: \var{ru\_utime}, \var{ru\_stime}, \var{ru\_minflt}, \var{ru\_majflt}, e \var{ru\_nswap}. + \subsection{Le funzioni \texttt{exec}} \label{sec:proc_exec} @@ -1122,7 +1131,6 @@ indicato dal parametro \var{path}, che viene interpretato come il \label{fig:proc_exec_relat} \end{figure} - La terza differenza è come viene passata la lista delle variabili di ambiente. Con lo mnemonico \func{e} vengono indicate quelle funzioni che necessitano di un vettore di parametri \var{envp[]} analogo a quello usato per gli argomenti @@ -1133,7 +1141,7 @@ processo di partenza per costruire l'ambiente. Oltre a mantenere lo stesso \acr{pid}, il nuovo programma fatto partire da \func{exec} assume anche una serie di altre proprietà del processo chiamante; la lista completa è la seguente: -\begin{itemize} +\begin{itemize*} \item il \textit{process ID} (\acr{pid}) ed il \textit{parent process ID} (\acr{ppid}). \item il \textit{real user ID} ed il \textit{real group ID} (vedi @@ -1153,7 +1161,7 @@ la lista completa \item i limiti sulle risorse (vedi \secref{sec:limits_xxx}).. \item i valori delle variabili \var{tms\_utime}, \var{tms\_stime}, \var{tms\_cutime}, \var{tms\_ustime} (vedi \secref{sec:xxx_xxx}).. -\end{itemize} +\end{itemize*} Oltre a questo i segnali che sono stati settati per essere ignorati nel processo chiamante mantengono lo stesso settaggio pure nuovo programma, tutti @@ -1197,9 +1205,9 @@ chiamato come se si fosse eseguito il comando \cmd{interpreter [arg] filename}. Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è -basato il controllo dei processi in unix: con \func{fork} si crea un nuovo +basata la gestione dei processi in unix: con \func{fork} si crea un nuovo processo, con \func{exec} si avvia un nuovo programma, con \func{exit} e -\func{wait} si effettua e si gestisce la conclusione dei programmi. Tutte le +\func{wait} si effettua e verifica la conclusione dei programmi. Tutte le altre funzioni sono ausiliarie e servono la lettura e il settaggio dei vari parametri connessi ai processi. @@ -1209,112 +1217,275 @@ parametri connessi ai processi. \label{sec:proc_perms} In questa sezione esamineremo le problematiche relative al controllo di -accesso dal punto di vista del processi; gli identificativi usati, come questi -possono essere modificati nella creazione e nel lancio di nuovi processi, le -varie funzioni per la loro manipolazione diretta e tutte le problematiche -connesse alla gestione accorta dei privilegi. +accesso dal punto di vista del processi; vedremo quali sono gli identificatori +usati, come questi possono essere modificati nella creazione e nel lancio di +nuovi processi, e le varie funzioni per la loro manipolazione diretta e tutte +le problematiche connesse alla gestione accorta dei privilegi. \subsection{Utente e gruppo di un processo} \label{sec:proc_user_group} Come accennato in \secref{sec:intro_multiuser} il modello base\footnote{in - realtà esistono estensioni di questo modello, che lo rendono più flessibile - e controllabile, come le \textit{capabilities}, le ACL per i file o il - modello a ``... NdT riprendere i dati'' di SELinux} di sicurezza di un + realtà già esistono estensioni di questo modello base, che lo rendono più + flessibile e controllabile, come le \textit{capabilities}, le ACL per i file + o il \textit{Mandatory Access Control} di SELinux} di sicurezza di un sistema unix-like è fondato sui concetti di utente e gruppo, e sulla -separazione fra l'amministratore, che non è sottoposto a restrizioni, e il -resto degli utenti, per i quali vengono effettuati i vari controlli di -accesso. - -%Benché il sistema sia piuttosto semplice il sistema permette una -%notevole fles - -Abbiamo già visto come il sistema associ ad ogni utente e gruppo due -identificatori, lo \acr{uid} e il \acr{gid}, che li contraddistinguono e che -sono questi quelli che vengono controllati dal kernel nella gestione di -permessi e protezioni; in \secref{sec:file_access_control} si è visto come -essi vengano utilizzati per il controllo di accesso ai file, vedremo ora come -come sono usati nella gestione dei privilegi di accesso dei processi. - -In \secref{sec:file_perm_overview} abbiamo visto come ogni file appartenga ad -un utente e ad un gruppo, e che il controllo di accesso viene eseguito sulla -base del - - -Ad ogni processo è associato un certo numero di identificatori, il cui elenco -è riportato \ntab, in genere questi derivano direttamente dall'utente che ha -lanciato il processo (attraverso i valori di \acr{uid} e \acr{gid}), e vengono -usati sia per il controllo di accesso ai file che per la gestione dei -privilegi associati ai processi stessi. +separazione fra l'amministratore (\textsl{root}, detto spesso anche +\textit{superuser}) che non è sottoposto a restrizioni, ed il resto degli +utenti, per i quali invece vengono effettuati i vari controlli di accesso. + +%Benché il sistema sia piuttosto semplice (è basato su un solo livello di +% separazione) il sistema permette una +%notevole flessibilità, + +Abbiamo già accennato come il sistema associ ad ogni utente e gruppo due +identificatori univoci, lo \acr{uid} e il \acr{gid}; questi servono al kernel +per identificare uno specifico utente o un gruppo di utenti, per poi poter +controllare che essi siano autorizzati a compiere le operazioni richieste. Ad +esempio in \secref{sec:file_access_control} vedremo come ad ogni file vengano +associati un utente ed un gruppo (i suoi \textsl{proprietari}, indicati +appunto tramite un \acr{uid} ed un \acr{gid}) che vengono controllati dal +kernel nella gestione dei permessi di accesso. + +Dato che tutte le operazioni del sistema vengono compiute dai processi, è +evidente che per poter implementare un controllo sulle operazioni occorre +anche poter identificare chi è che ha lanciato un certo processo, e pertanto +anche a ciascuno di essi è associato un utente e a un gruppo. + +Un semplice controllo di una corrispondenza fra identificativi però non +garantisce però sufficiente flessibilità per tutti quei casi in cui è +necessario poter disporre di privilegi diversi, o dover impersonare un altro +utente per un limitato insieme di operazioni. Per questo motivo in generale +tutti gli unix prevedono che i processi abbiano almeno due gruppi di +identificatori, chiamati rispettivamente \textit{real} ed \textit{effective}. + + \begin{table}[htb] \footnotesize \centering - \begin{tabular}[c]{|c|l|p{8cm}|} + \begin{tabular}[c]{|c|l|p{6.5cm}|} \hline - \textbf{Sigla} & \textbf{Significato} & \textbf{Utilizzo} \\ + \textbf{Suffisso} & \textbf{Significato} & \textbf{Utilizzo} \\ \hline \hline - \acr{ruid} & \textit{real user id} & indica l'utente reale che ha lanciato + \acr{uid} & \textit{real user id} & indica l'utente che ha lanciato il programma\\ - \acr{rgid} & \textit{real group id} & indica il gruppo reale dell'utente + \acr{gid} & \textit{real group id} & indica il gruppo dell'utente che ha lanciato il programma \\ - \acr{euid} & \textit{effective user id} & indica l'utente effettivo usato - dal programma \\ - \acr{egid} & \textit{effective group id} & indica il gruppo effettivo usato - dal programma \\ - & \textit{supplementary group id} & indica i gruppi cui + \acr{euid} & \textit{effective user id} & indica l'utente usato + dal programma nel controllo di accesso \\ + \acr{egid} & \textit{effective group id} & indica il gruppo + usato dal programma nel controllo di accesso \\ + -- & \textit{supplementary group id} & indica i gruppi cui l'utente appartiene \\ - \acr{suid} & \textit{saved user id} & indica l'utente \\ - \acr{sgid} & \textit{saved group id} & indica il gruppo \\ + -- & \textit{saved user id} & copia dell'\acr{euid} iniziale\\ + -- & \textit{saved group id} & copia dell'\acr{egid} iniziale \\ \acr{fsuid} & \textit{filesystem user id} & indica l'utente effettivo per il filesystem \\ \acr{fsgid} & \textit{filesystem group id} & indica il gruppo effettivo per il filesystem \\ \hline \end{tabular} - \caption{Identificatori di utente e gruppo associati a ciascun processo.} + \caption{Identificatori di utente e gruppo associati a ciascun processo con + indicazione dei suffissi usate dalle varie funzioni di manipolazione.} \label{tab:proc_uid_gid} \end{table} -Il \textit{real user id} e il \textit{real group id} indicano l'utente che ha -lanciato il processo, e vengono settati al login al valore standard di -\acr{uid} e \acr{gid} dell'utente letti direttamente da \file{/etc/passwd}. - -Esso servono ad identificare l'utente che ha lanciato il processo e non -vengono mai cambiati nella creazione di nuovi processi restando sempre gli -stessi per tutti i processi avviati in una sessione. In realtà vedremo che è -possibile possibile modificarli (in \secref{sec:proc_setuid}), ma solo ad un -processo che abbia i privilegi di amministratore; questa possibilità è usata -ad esempio da \cmd{login} che una volta completata la procedura di -autenticazione lancia una shell per la quale setta questi identificatori ai -valori corrispondenti all'utente che entra nel sistema. - -L'\textit{effective user id}, l'\textit{effective group id} e gli eventuali -\textit{supplementary group id} sono invece gli identificatori usati per il -controllo di accesso ai file (secondo quanto descritto in dettaglio in -\secref{sec:file_perm_overview}). Normalmente essi sono uguali al \textit{real - user id} e al \textit{real group id}, a meno che il file posto in esecuzione -non abbia o il bit \acr{suid} o il bit \acr{sgid} settato, in questo caso alla -la funzione \func{exec} (vedi \secref{}) li setta rispettivamente ai valori -dell'\acr{uid} e del \acr{gid} cui appartiene il file. +Al primo gruppo appartengono il \textit{real user ID} e il \textit{real group + ID}: questi vengono settati al login ai valori corrispondenti all'utente con +cui si accede al sistema (e relativo gruppo di default). Servono per +l'identificazione dell'utente e normalmente non vengono mai cambiati. In +realtà vedremo (in \secref{sec:proc_setuid}) che è possibile modificarli, ma +solo ad un processo che abbia i privilegi di amministratore; questa +possibilità è usata ad esempio da \cmd{login} che una volta completata la +procedura di autenticazione lancia una shell per la quale setta questi +identificatori ai valori corrispondenti all'utente che entra nel sistema. + +Al secondo gruppo appartengono l'\textit{effective user ID} e +l'\textit{effective group ID} (a cui si aggiungono gli eventuali +\textit{supplementary group id} dei gruppi dei quale l'utente fa parte). +Questi sono invece gli identificatori usati nella verifiche dei permessi del +processo e per il controllo di accesso ai file (argomento affrontato in +dettaglio in \secref{sec:file_perm_overview}). + +Questi identificatori normalmente sono identici ai corrispondenti del gruppo +\textsl{reale} tranne nel caso in cui, come visto in \secref{sec:proc_exec}, +il programma che si è posto in esecuzione abbia i bit \acr{suid} o \acr{sgid} +settati (il significato di questi bit è affrontato in dettaglio in +\secref{sec:file_suid_sgid}). In questo caso essi saranno settati all'utente e +al gruppo proprietari del file; questo consente, per programmi in cui ci sia +necessità, di dare a qualunquee utente normale privilegi o permessi di +un'altro (o dell'amministratore). + +Come nel caso del \acr{pid} e del \acr{ppid} tutti questi identificatori +possono essere letti dal processo attraverso delle opportune funzioni, i cui +prototipi sono i seguenti: + +\begin{functions} +\headdecl{unistd.h} +\headdecl{sys/types.h} +\funcdecl{uid\_t getuid(void)} restituisce il \textit{real user ID} del +processo corrente. +\funcdecl{uid\_t geteuid(void)} restituisce l'\textit{effective user ID} del +processo corrente. +\funcdecl{gid\_t getgid(void)} restituisce il \textit{real group ID} del +processo corrente. +\funcdecl{gid\_t getegid(void)} restituisce l'\textit{effective group ID} del +processo corrente. + +Queste funzioni non riportano condizioni di errore. +\end{functions} + +In generale l'uso di privilegi superiori deve essere limitato il più +possibile, per evitare abusi e problemi di sicurezza, per questo occorre anche +un meccanismo che consenta ad un programma di rilasciare gli eventuali +maggiori privilegi necessari, una volta che si siano effettuate le operazioni +per i quali erano richiesti, e a poterli eventualmente recuperare in caso +servano di nuovo. + +Questo in Linux viene fatto usando altri due gruppi di identificatori, il +\textit{saved} ed il \textit{filesystem}, analoghi ai precedenti. Il primo +gruppo è lo stesso usato in SVr4, e previsto dallo standard POSIX quando è +definita la costante \macro{\_POSIX\_SAVED\_IDS}, il secondo gruppo è +specifico di Linux e viene usato per migliorare la sicurezza con NFS. Il \textit{saved user id} e il \textit{saved group id} sono copie dell'\textit{effective user id} e dell'\textit{effective group id} del processo padre, e vengono settati dalla funzione \func{exec} all'avvio del -processo, prima che \textit{effective user id} e \textit{effective group id} -vengano modificati per tener conto di eventuali \acr{suid} o \acr{sgid}, essi -quindi consentono di tenere traccia di quale fossero l'utente originale. +processo, come copie dell'\textit{effective user id} e dell'\textit{effective + group id} dopo che questo sono stati settati tenendo conto di eventuali +\acr{suid} o \acr{sgid}. Essi quindi consentono di tenere traccia di quale +fossero utente e gruppo effettivi all'inizio dell'esecuzione di un nuovo +programma. + +Il \textit{filesystem user id} e il \textit{filesystem group id} sono una +estensione introdotta in Linux per rendere più sicuro l'uso di NFS (torneremo +sull'argomento in \secref{sec:proc_setfsuid}). Essi sono una replica dei +corrispondenti \textit{effective id}, ai quali si sostituiscono per tutte le +operazioni di verifica dei permessi relativi ai file (trattate in +\secref{sec:file_perm_overview}). Ogni cambiamento effettuato sugli +\textit{effective id} viene automaticamente riportato su di essi, per cui in +condizioni normali se ne può tranquillamente ignorare l'esistenza, in quanto +saranno del tutto equivalenti ai precedenti. + +Uno specchietto riassuntivo, contenente l'elenco completo degli identificatori +di utente e gruppo associati dal kernel ad ogni processo, è riportato in +\tabref{tab:proc_uid_gid}. + + +\subsection{Le funzioni \func{setuid} e \func{setgid}} +\label{sec:proc_setuid} +Le due funzioni che venfono usate per cambiare identità (cioè utente e gruppo +di appartenenza) ad un processo sono rispettivamente \func{setuid} e +\func{setgid}; come accennato in \secref{sec:proc_user_group} in Linux esse +seguono la sematica POSIX che prevede l'esistenza di \textit{saved user id} e +\textit{saved group id}; i loro prototipi sono: -\subsection{Le funzioni \texttt{setuid} e \texttt{setgid}} -\label{sec:proc_setuid} +\begin{functions} +\headdecl{unistd.h} +\headdecl{sys/types.h} +\funcdecl{int setuid(uid\_t uid)} setta l' \textit{user ID} del processo +corrente. + +\funcdecl{int setgid(gid\_t gid)} setta il \textit{group ID} del processo +corrente. + +Le funzioni restituiscono 0 in caso di successo e -1 in caso di fallimento: +l'unico errore possibile è \macro{EPERM}. +\end{functions} -\subsection{Le funzioni \texttt{seteuid} e \texttt{setegid}} +Il funzionamento di queste due funzioni è analogo, per cui considereremo solo +la prima; la seconda si comporta esattamente allo stesso modo facendo +riferimento al \textit{group id} invece che all'\textit{user id}. + + +L'effetto della chiamata è diverso a seconda dei privilegi del processo; se +l'\textit{effective user id} è zero (cioè è quello dell'amministratore di +sistema) allora tutti gli identificatatori (\textit{real}, \textit{effective} +e \textit{saved}) vengono settati al valore specificato da \var{uid}, +altrimenti viene settato solo l'\textit{effective user id}, e soltanto se il +valore specificato corrisponde o al \textit{real user id} o al \textit{saved + user id}. Negli altri casi segnalato un errore (con \macro{EPERM}). + +Come accennato l'uso principale di queste funzioni è quello di poter +consentire ad un programma con i bit \acr{suid} o \acr{sgid} settati, di +riportare l'\textit{effective user id} a quello dell'utente che ha lanciato il +programma, per effettuare il lavoro che non necessita di privilegi aggiuntivi, +ed eventualmente tornare indietro. + +Occorre però tenere conto che tutto questo non è possibile nel caso di root, +in tal caso infatti l'esecuzione una \func{setuid} con un \textit{effective + user id} uguale a zero comporta il cambiamento di tutti gli identificatori +associati al processo rendendo impossibile riguadagnare i privilegi di +amministratore. Questo è l'uso che ne fa \cmd{login} una volta che crea una +nuova shell per l'utente, ma se si vuole cambiare soltanto l'\textit{effective + user id} occorre ricorrere ad altre funzioni (si veda ad esempio +\secref{sec:proc_seteuid}). + +Come esempio per chiarire dell'uso di queste funzioni prediamo quello con cui +viene gestito l'accesso al file \file{/var/log/utmp}. In questo file viene +registrato chi sta usando il sistema al momento corrente; chiaramente non può +essere lasciato aperto in scrittura a qualunque utente, che protrebbe +falsificare la registrazione. Per questo motivo questo file (e l'analogo +\file{/var/log/wtmp} su cui vengono registrati login e logout) appartengono ad +un gruppo dedicato (\acr{utmp}) ed i programmi che devono accedervi (ad +esempio tutti i programmi di terminale in X, o il programma \cmd{screen} +che crea terminali multipli su una console) appartengono a questo gruppo ed +hanno il bit \acr{sgid} settato. + +Quando uno di questi programmi (ad esempio \cmd{xterm}) viene lanciato la +situazione degli identificatori è la seguente: +\begin{eqnarray*} + \label{eq:1} + \textit{real group id} &=& \textrm{\acr{gid} (del chiamante)} \\ + \textit{effective group id} &=& \textrm{\acr{utmp}} \\ + \textit{saved group id} &=& \textrm{\acr{utmp}} +\end{eqnarray*} +in questo modo, dato che l'\textit{effective group id} è quello giusto, il +programma può accedere a \file{/var/log/utmp} in scrittura ed aggiornarlo, a +questo punto il programma può eseguire una \func{setgid(getgid())} per settare +l'\textit{effective group id} a quello dell'utente (ed usando il \textit{real + group id} la funzione avrà successo), in questo modo non sarà possibile +lanciare dal terminale programmi che modificano detto file, in tal caso +infatti la situazione degli identificatori sarebbe: +\begin{eqnarray*} + \label{eq:2} + \textit{real group id} &=& \textrm{\acr{gid} (invariato)} \\ + \textit{effective group id} &=& \textrm{\acr{gid}} \\ + \textit{saved group id} &=& \textrm{\acr{utmp} (invariato)} +\end{eqnarray*} +e ogni processo lanciato dal terminale avrebbe comunque \acr{gid} come +\textit{effective group id}. All'uscita dal terminale, per poter di nuovo +aggiornare lo stato di \file{/var/log/utmp} il programma eseguirà una +\func{setgid(utmp)} (dove \var{utmp} è il valore numerico associato al gruppo +\acr{utmp}, ottenuto ad esempio con una \func{getegid}), dato che in questo +caso il valore richiesto corrisponde al \textit{saved group id} la funzione +avrà successo e riporterà la situazione a: +\begin{eqnarray*} + \label{eq:3} + \textit{real group id} &=& \textrm{\acr{gid} (invariato)} \\ + \textit{effective group id} &=& \textrm{\acr{utmp}} \\ + \textit{saved group id} &=& \textrm{\acr{utmp} (invariato)} +\end{eqnarray*} +consentendo l'accesso a \file{/var/log/utmp}. + + +\subsection{Le funzioni \func{seteuid} e \func{setegid}} \label{sec:proc_seteuid} +\subsection{Le funzioni \func{setreuid} e \func{setresuid}} +\label{sec:proc_setreuid} + + +\subsection{Le funzioni \func{setfsuid} e \func{setfsgid}} +\label{sec:proc_setfsuid} + + + \subsection{Le \textit{race condition}} \label{sec:proc_race_cond} @@ -1325,5 +1496,3 @@ l'ordine di esecuzione di un processo, senza appositi meccanismi di sincronizzazione, non è assolutamente prevedibile, queste situazioni sono fonti di errori molto subdoli, che possono verificarsi solo in condizioni particolari e quindi difficilmente riproducibili. - -