projects
/
gapil.git
/ commitdiff
commit
grep
author
committer
pickaxe
?
search:
re
summary
|
shortlog
|
log
|
commit
| commitdiff |
tree
raw
|
patch
|
inline
| side by side (parent:
7462afa
)
Aggiunte su euid e soci
author
Simone Piccardi
<piccardi@gnulinux.it>
Wed, 17 Oct 2001 21:56:13 +0000
(21:56 +0000)
committer
Simone Piccardi
<piccardi@gnulinux.it>
Wed, 17 Oct 2001 21:56:13 +0000
(21:56 +0000)
prochand.tex
patch
|
blob
|
history
diff --git
a/prochand.tex
b/prochand.tex
index 813e55e0f52428e0a6a799be431b1f133022be2b..07ebb358579f5375876cce2416e9ea9a80554bfc 100644
(file)
--- 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
\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.
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}
\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
\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
\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}).
\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}.
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}
\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}
\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
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
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 h
a
-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 programm
a
+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
\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.
sincronizzazione, non è assolutamente prevedibile, queste situazioni sono
fonti di errori molto subdoli, che possono verificarsi solo in condizioni
particolari e quindi difficilmente riproducibili.
-
-