From: Simone Piccardi Date: Wed, 17 Oct 2001 21:56:13 +0000 (+0000) Subject: Aggiunte su euid e soci X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=01d60178a9cce9ad5ff205b5906668364980faeb;p=gapil.git Aggiunte su euid e soci --- diff --git a/prochand.tex b/prochand.tex index 813e55e..07ebb35 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} @@ -528,10 +535,11 @@ padre e figlio avranno in comune: \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}). @@ -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 @@ -1243,34 +1251,41 @@ 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 ha lanciato un certo processo, che pertanto è -associato anch'esso ad un utente e a un gruppo. Un semplice controllo di una -corrispondenza fra identificativi però non garantisce 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. +anche poter identificare chi 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 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 +Per questo motivo in generale tutti i processi hanno almeno due gruppi di +identificatori, chiamati rispettivamente \textsl{reale} e \textsl{effettivo}. +Al primo gruppo appartengono il \textit{real user ID} e il \textit{real group + ID}, che vengono settati al login ai valori corrispondenti all'utente con +cui si accede al sistema (e relativo gruppo di default), questi normalmente +non vengono mai cambiati. -questo può essere fatto -in vari modi (ad +Al secondo gruppo appartengono l'\textit{effective user ID} e +l'\textit{effective group ID} che sono gli identificatori usati nella +verifiche dei permessi, (ad esempio, come vedremo in +\secref{sec:file_perm_overview} vengono usati nel controllo di accesso ai +file). -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; 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 di uno di questi identificatori, l'\textit{effective uid} +Questi normalmente sono identici ai corrispondenti del gruppo reale tranne nel +caso in cui (come abbiamo accennato in \secref{sec:proc_exec}) il programma +che si è posto in esecuzione abbia i bit \acr{suid} o \acr{sgid} settati (su +questo torneremo in maggior dettagli in \secref{sec:file_suid_sgid}) nel qual +caso essi saranno settati all'utente e al gruppo proprietari del file. -, e vengono -usati sia per il controllo di accesso ai file che per la gestione dei -privilegi associati ai processi stessi. -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 +Oltre a questi Linux, seguendo +Linux inoltre, per poter rilasciare eventuali privilegi addizionali avuti con +l'esecuzione di un programma + \begin{table}[htb] \footnotesize @@ -1350,5 +1365,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. - -