From d3cbe0a3984b7189d086ccb631d5b3b1955e223c Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Tue, 24 Sep 2002 22:24:40 +0000 Subject: [PATCH 1/1] Risistemata introduzione e login --- prochand.tex | 46 ++++++++------ session.tex | 171 +++++++++++++++++++++++++-------------------------- 2 files changed, 109 insertions(+), 108 deletions(-) diff --git a/prochand.tex b/prochand.tex index 5186e41..ef75e52 100644 --- a/prochand.tex +++ b/prochand.tex @@ -767,15 +767,15 @@ informazioni riguardo ai processi che sta terminando. Questo viene fatto mantenendo attiva la voce nella tabella dei processi, e memorizzando alcuni dati essenziali, come il \acr{pid}, i tempi di CPU usati -dal processo (vedi \secref{sec:sys_unix_time}) e lo stato di -terminazione\footnote{NdA verificare esattamente cosa c'è!}, mentre la memoria -in uso ed i file aperti vengono rilasciati immediatamente. I processi che sono -terminati, ma il cui stato di terminazione non è stato ancora ricevuto dal -padre sono chiamati \textit{zombie}, essi restano presenti nella tabella dei -processi ed in genere possono essere identificati dall'output di \cmd{ps} per -la presenza di una \texttt{Z} nella colonna che ne indica lo stato. Quando il -padre effettuerà la lettura dello stato di uscita anche questa informazione, -non più necessaria, verrà scartata e la terminazione potrà dirsi completamente +dal processo (vedi \secref{sec:sys_unix_time}) e lo stato di terminazione, +mentre la memoria in uso ed i file aperti vengono rilasciati immediatamente. I +processi che sono terminati, ma il cui stato di terminazione non è stato +ancora ricevuto dal padre sono chiamati \textit{zombie}, essi restano presenti +nella tabella dei processi ed in genere possono essere identificati +dall'output di \cmd{ps} per la presenza di una \texttt{Z} nella colonna che ne +indica lo stato (vedi \tabref{tab:proc_proc_states}). Quando il padre +effettuerà la lettura dello stato di uscita anche questa informazione, non più +necessaria, verrà scartata e la terminazione potrà dirsi completamente conclusa. Possiamo utilizzare il nostro programma di prova per analizzare anche questa @@ -925,14 +925,16 @@ specchietto riportato in \tabref{tab:proc_waidpid_pid}: Il comportamento di \func{waitpid} può inoltre essere modificato passando delle opportune opzioni tramite l'argomento \param{option}. I valori possibili sono il già citato \macro{WNOHANG}, che previene il blocco della funzione -quando il processo figlio non è terminato, e \macro{WUNTRACED} (usata per il -controllo di sessione, trattato in \secref{sec:sess_job_control}) che fa -ritornare la funzione anche per i processi figli che sono bloccati ed il cui -stato non è stato ancora riportato al padre. Il valore dell'opzione deve -essere specificato come maschera binaria ottenuta con l'OR delle suddette -costanti con zero. In Linux sono previste altre opzioni non standard relative -al comportamento con i thread, che saranno trattate in -\secref{sec:thread_xxx}. +quando il processo figlio non è terminato, e \macro{WUNTRACED}. Quest'ultimo +viene generalmente usato per il controllo di sessione, (trattato in +\secref{sec:sess_job_control}) in quanto permette di identificare i processi +bloccati. La funzione infatti in tal caso ritorna, restituendone il \acr{pid}, +se c'è un processo figlio che è entrato in stato di sleep (vedi +\tabref{tab:proc_proc_states}) di cui non si è ancora letto lo stato (con +questa stessa opzione). Il valore dell'opzione deve essere specificato come +maschera binaria ottenuta con l'OR delle suddette costanti con zero. In Linux +sono previste altre opzioni non standard relative al comportamento con i +thread, che saranno trattate in \secref{sec:thread_xxx}. La terminazione di un processo figlio è chiaramente un evento asincrono rispetto all'esecuzione di un programma e può avvenire in un qualunque @@ -1186,7 +1188,7 @@ indicato dal parametro \var{path}, che viene interpretato come il \begin{figure}[htb] \centering - \includegraphics[width=13cm]{img/exec_rel} + \includegraphics[width=15cm]{img/exec_rel} \caption{La interrelazione fra le sei funzioni della famiglia \func{exec}.} \label{fig:proc_exec_relat} \end{figure} @@ -1289,8 +1291,12 @@ problematiche connesse ad una gestione accorta dei privilegi. Come accennato in \secref{sec:intro_multiuser} il modello base\footnote{in 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 + o il \textit{Mandatory Access Control} di SELinux; inoltre basandosi sul + lavoro effettuato con SELinux, a partire dal kernel 2.5.x, è iniziato lo + sviluppo di una infrastruttura di sicurezza, il \textit{Linux Security + Modules}, ol LSM, in grado di fornire diversi agganci a livello del kernel + per modularizzare tutti i possibili controlli di accesso.} di sicurezza di +un sistema unix-like è fondato sui concetti di utente e gruppo, e sulla 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. diff --git a/session.tex b/session.tex index 2f73d61..67e5129 100644 --- a/session.tex +++ b/session.tex @@ -62,12 +62,12 @@ nella gestione del job control non si pu Per questo il kernel prevede la possibilità di raggruppare più processi in un \textit{process group} (detto anche \textsl{raggruppamento di processi}, vedi \secref{sec:sess_proc_group}) e la shell farà sì che tutti i processi che -originano da una riga di comando appartengano allo stesso \textit{process - group}, in modo che le varie funzioni di controllo, ed i segnali inviati dal -terminale, possano fare riferimento ad esso. +originano da una riga di comando appartengano allo stesso raggruppamento, in +modo che le varie funzioni di controllo, ed i segnali inviati dal terminale, +possano fare riferimento ad esso. -In generale allora all'interno di una sessione avremo un eventuale (possono -non esserci) \textit{process group} in \textit{foreground}, che riunisce i +In generale allora all'interno di una sessione avremo un eventuale (può non +esserci) \textit{process group} in \textit{foreground}, che riunisce i processi che possono accedere al terminale, e più \textit{process group} in \textit{background}, che non possono accedervi. Il job control prevede che quando un processo appartenente ad un raggruppamento in \textit{background} @@ -78,15 +78,18 @@ Un comportamento analogo si ha anche per i segnali generati dai comandi di tastiera inviati dal terminale che vengono inviati a tutti i processi del raggruppamento in \textit{foreground}. In particolare \cmd{C-z} interrompe l'esecuzione del comando, che può poi essere mandato in \textit{background} -con il comando \cmd{bg}. Il comando \cmd{fg} consente invece di mettere in -\textit{foreground} un comando precedentemente lanciato in -\textit{background}. +con il comando \cmd{bg}.\footnote{si tenga presente che \cmd{bg} e \cmd{fg} + sono parole chiave che indicano comandi interni alla shell, e nel caso non + comportano l'esecuzione di un programma esterno.} Il comando \cmd{fg} +consente invece di mettere in \textit{foreground} un comando precedentemente +lanciato in \textit{background}. Di norma la shell si cura anche di notificare all'utente (di solito prima -della stampa a video del prompt) lo stato dei vari processi, essa infatti usa -le caratteristiche della funzione \func{waitpid} (si riveda quanto detto in -\secref{sec:proc_wait}) per verificare quali gruppi di processi sono bloccati -e quali sono terminati. +della stampa a video del prompt) lo stato dei vari processi; essa infatti sarà +in grado, grazie all'uso di \func{waitpid}, di rilevare sia i processi che +sono terminati, sia i raggruppamenti che sono bloccati (in questo caso usando +l'opzione \macro{WUNTRACED}, secondo quanto illustrato in +\secref{sec:proc_wait}). \subsection{I \textit{process group} e le \textsl{sessioni}} @@ -158,16 +161,16 @@ stessa sessione del padre. Vedremo poi come sia possibile creare pi \textit{process group} all'interno della stessa sessione, e spostare i processi dall'uno all'altro, ma sempre all'interno di una stessa sessione. -Ciascun gruppo di processi ha sempre un processo principale, il cosiddetto -\textit{process group leader}, che è identificato dall'avere un \acr{pgid} -uguale al suo \acr{pid}, in genere questo è il primo processo del gruppo, che -si incarica di lanciare tutti gli altri. Un nuovo gruppo si crea con la -funzione \func{setpgrp},\footnote{questa è la definizione di POSIX.1, BSD - definisce una funzione con lo stesso nome, che però è identica a - \func{setpgid}; nelle \acr{glibc} viene sempre usata sempre questa - definizione, a meno di non richiedere esplicitamente la compatibilità - all'indietro con BSD, definendo la macro \macro{\_BSD\_SOURCE}.} il cui -prototipo è: +Ciascun raggruppamento di processi ha sempre un processo principale, il +cosiddetto \textit{process group leader}, che è identificato dall'avere un +\acr{pgid} uguale al suo \acr{pid}, in genere questo è il primo processo del +raggruppamento, che si incarica di lanciare tutti gli altri. Un nuovo +raggruppamento si crea con la funzione \func{setpgrp},\footnote{questa è la + definizione di POSIX.1, BSD definisce una funzione con lo stesso nome, che + però è identica a \func{setpgid}; nelle \acr{glibc} viene sempre usata + sempre questa definizione, a meno di non richiedere esplicitamente la + compatibilità all'indietro con BSD, definendo la macro + \macro{\_BSD\_SOURCE}.} il cui prototipo è: \begin{prototype}{unistd.h}{int setpgrp(void)} Modifica il \acr{pgid} al valore del \acr{pid} del processo corrente. @@ -176,10 +179,11 @@ prototipo \end{prototype} La funzione, assegnando al \acr{pgid} il valore del \acr{pid} processo -corrente, rende questo \textit{process leader} di un nuovo gruppo, tutti i -successivi processi da esso creati apparterranno (a meno di non cambiare di -nuovo il \acr{pgid}) al nuovo gruppo. È possibile invece spostare un processo -da un gruppo ad un altro con la funzione \func{setpgid}, il cui prototipo è: +corrente, rende questo \textit{group leader} di un nuovo raggruppamento, tutti +i successivi processi da esso creati apparterranno (a meno di non cambiare di +nuovo il \acr{pgid}) al nuovo raggruppamento. È possibile invece spostare un +processo da un raggruppamento ad un altro con la funzione \func{setpgid}, il +cui prototipo è: \begin{prototype}{unistd.h}{int setpgid(pid\_t pid, pid\_t pgid)} Assegna al \acr{pgid} del processo \param{pid} il valore \param{pgid}. @@ -199,11 +203,12 @@ cambiamento pu \textit{process group} che è nella stessa sessione del processo chiamante. Inoltre la funzione può essere usata soltanto sul processo corrente o su uno dei suoi figli, ed in quest'ultimo caso ha successo soltanto se questo non ha -ancora eseguito una \func{exec}. Specificando un valore nullo per \param{pid} -si indica il processo corrente, mentre specificando un valore nullo per -\param{pgid} si imposta il \textit{process group} al valore del \acr{pid} del -processo selezionato; pertanto \func{setpgrp} è equivalente a \code{setpgid(0, - 0)}. +ancora eseguito una \func{exec}.\footnote{questa caratteristica è implementata + dal kernel che mantiene allo scopo un altro campo, \var{did\_exec}, in + \var{task\_struct}.} Specificando un valore nullo per \param{pid} si indica +il processo corrente, mentre specificando un valore nullo per \param{pgid} si +imposta il \textit{process group} al valore del \acr{pid} del processo +selezionato; pertanto \func{setpgrp} è equivalente a \code{setpgid(0, 0)}. Di norma questa funzione viene usata dalla shell quando si usano delle pipeline, per mettere nello stesso process group tutti i programmi lanciati su @@ -281,7 +286,7 @@ Alla creazione di una nuova sessione con \func{setsid} ogni associazione con il precedente terminale di controllo viene cancellata, ed il processo che è divenuto un nuovo leader di sessione dovrà riottenere\footnote{solo quando ciò è necessario, cosa che, come vedremo in \secref{sec:sess_daemon}, non è - sempre vera}, un terminale di controllo. In generale questo viene fatto + sempre vera.}, un terminale di controllo. In generale questo viene fatto automaticamente dal sistema\footnote{a meno di non avere richiesto esplicitamente che questo non diventi un terminale di controllo con il flag \macro{O\_NOCTTY} (vedi \secref{sec:file_open}). In questo Linux segue la @@ -294,10 +299,10 @@ sessione. In genere (a meno di redirezioni) nelle sessioni di lavoro questo terminale è associato ai file standard (di input, output ed error) dei processi nella -sessione, ma solo quelli che fanno parte del cosiddetto gruppo di +sessione, ma solo quelli che fanno parte del cosiddetto ragruppamento di \textit{foreground}, possono leggere e scrivere in certo istante. Per -impostare il gruppo di \textit{foreground} di un terminale si usa la funzione -\func{tcsetpgrp}, il cui prototipo è: +impostare il raggruppamento di \textit{foreground} di un terminale si usa la +funzione \func{tcsetpgrp}, il cui prototipo è: \begin{functions} \headdecl{unistd.h} \headdecl{termios.h} @@ -322,13 +327,13 @@ impostare il gruppo di \textit{foreground} di un terminale si usa la funzione un processo nella stessa sessione e con lo stesso terminale di controllo. Come accennato in \secref{sec:sess_job_control_overview}, tutti i processi (e -relativi gruppi) che non fanno parte del gruppo di \textit{foreground} sono -detti in \textit{background}; se uno si essi cerca di accedere al terminale di -controllo provocherà l'invio da parte del kernel di uno dei due segnali -\macro{SIGTTIN} o \macro{SIGTTOU} (a seconda che l'accesso sia stato in -lettura o scrittura) a tutto il suo \textit{process group}; dato che il +relativi raggruppamenti) che non fanno parte del gruppo di \textit{foreground} +sono detti in \textit{background}; se uno si essi cerca di accedere al +terminale di controllo provocherà l'invio da parte del kernel di uno dei due +segnali \macro{SIGTTIN} o \macro{SIGTTOU} (a seconda che l'accesso sia stato +in lettura o scrittura) a tutto il suo \textit{process group}; dato che il comportamento di default di questi segnali (si riveda quanto esposto in -\secref{sec:sig_job_control}) è di bloccare il processo, di norma questo +\secref{sec:sig_job_control}) è di fermare il processo, di norma questo comporta che tutti i membri del gruppo verranno fermati, ma non si avranno condizioni di errore.\footnote{la shell in genere notifica comunque un avvertimento, avvertendo la presenza di processi bloccati grazie all'uso di @@ -359,18 +364,18 @@ ma solo dal terminale cui fa riferimento; il kernel inoltre permette a ciascun processo di accedere direttamente al suo terminale di controllo attraverso il file speciale \file{/dev/tty}, che per ogni processo è un sinonimo per il proprio terminale di controllo. Questo consente anche a processi che possono -aver rediretto l'output di accedere al terminale, pur non disponendo più del -file descriptor originario; un caso tipico è il programma \cmd{crypt} che -accetta la redirezione sullo standard input di un file da decrittare, ma deve -poi leggere la password dal terminale. +aver rediretto l'output di accedere al terminale di controllo, pur non +disponendo più del file descriptor originario; un caso tipico è il programma +\cmd{crypt} che accetta la redirezione sullo standard input di un file da +decrittare, ma deve poi leggere la password dal terminale. Un'altra caratteristica del terminale di controllo usata nel job control è che utilizzando su di esso le combinazioni di tasti speciali (\cmd{C-z}, -\cmd{C-c}, \cmd{C-y} e \verb|C-\|) si farà si che il kernel invii i +\cmd{C-c}, \cmd{C-y} e \verb|C-\|) si farà sì che il kernel invii i corrispondenti segnali (rispettivamente \macro{SIGTSTP}, \macro{SIGINT}, \macro{SIGQUIT} e \macro{SIGTERM}, trattati in \secref{sec:sig_job_control}) a -tutti i processi del gruppo di \textit{foreground}; in questo modo la shell -può gestire il blocco e l'interruzione dei vari comandi. +tutti i processi del raggruppamento di \textit{foreground}; in questo modo la +shell può gestire il blocco e l'interruzione dei vari comandi. Per completare la trattazione delle caratteristiche del job control legate al terminale di controllo, occorre prendere in considerazione i vari casi legati @@ -391,10 +396,10 @@ riutilizzato per qualche altra sessione. Lo standard POSIX.1 prevede che quando il processo di controllo termina, che ciò avvenga o meno per un \textit{hungup} del terminale (ad esempio si potrebbe terminare direttamente la shell con \cmd{kill}) venga inviato un -segnale di \macro{SIGHUP} ai processi del gruppo di foreground. In questo modo -essi potranno essere avvisati che non esiste più un processo in grado di -gestire il terminale (di norma tutto ciò comporta la terminazione anche di -questi ultimi). +segnale di \macro{SIGHUP} ai processi del raggruppamento di foreground. In +questo modo essi potranno essere avvisati che non esiste più un processo in +grado di gestire il terminale (di norma tutto ciò comporta la terminazione +anche di questi ultimi). Restano però gli eventuali processi in background, che non ricevono il segnale; in effetti se il terminale non dovesse più servire essi potrebbero @@ -406,10 +411,11 @@ controllo dello stesso. Questa è la situazione in cui si ha quello che viene chiamato un \textit{orphaned process group}. Lo standard POSIX.1 lo definisce come un \textit{process group} i cui processi hanno come padri esclusivamente o altri -processi nel gruppo, o processi fuori della sessione. Lo standard prevede -inoltre che se la terminazione di un processo fa sì che un raggruppamento di -processi diventi orfano e se i suoi membri sono bloccati, ad essi vengano -inviati in sequenza i segnali di \macro{SIGHUP} e \macro{SIGCONT}. +processi nel raggruppamento, o processi fuori della sessione. Lo standard +prevede inoltre che se la terminazione di un processo fa sì che un +raggruppamento di processi diventi orfano e se i suoi membri sono bloccati, ad +essi vengano inviati in sequenza i segnali di \macro{SIGHUP} e +\macro{SIGCONT}. La definizione può sembrare complicata, e a prima vista non è chiaro cosa tutto ciò abbia a che fare con il problema della terminazione del processo di @@ -422,21 +428,20 @@ non viene emesso nessun segnale perch solo i raggruppamenti che diventano orfani in seguito alla terminazione di un processo.\footnote{l'emissione dei segnali infatti avviene solo nella fase di uscita del processo, come una delle operazioni legate all'esecuzione di - \func{_exit}, secondo quanto illustrato in \secref{sec:proc_termination}.} + \func{\_exit}, secondo quanto illustrato in \secref{sec:proc_termination}.} -Il leader di sessione provvederà a creare nuovi raggruppamenti di processi che -a questo punto non sono orfani in quanto esso resta padre per almeno uno dei -processi del gruppo (gli altri possono derivare dal primo). Alla terminazione -del leader di sessione però avremo che, come visto in +Il leader di sessione provvederà a creare nuovi raggruppamenti che a questo +punto non sono orfani in quanto esso resta padre per almeno uno dei processi +del gruppo (gli altri possono derivare dal primo). Alla terminazione del +leader di sessione però avremo che, come visto in \secref{sec:proc_termination}, tutti i suoi figli vengono adottati da \cmd{init}, che è fuori dalla sessione. Questo renderà orfani tutti i process group creati direttamente dal leader di sessione (a meno di non aver spostato con \func{setpgid} un processo da un gruppo ad un altro, cosa che di norma non -viene fatta) i quali riceveranno, nel caso siano bloccati, i due segnali: -\macro{SIGCONT} ne farà proseguire l'esecuzione, e, essendo stato nel +viene fatta) i quali riceveranno, nel caso siano bloccati, i due segnali; +\macro{SIGCONT} ne farà proseguire l'esecuzione, ed essendo stato nel frattempo inviato anche \macro{SIGHUP}, se non c'è un gestore per -quest'ultimo, essi saranno terminati. - +quest'ultimo, i processi bloccati verranno automaticamente terminati. @@ -547,27 +552,14 @@ salvati) saranno settati a quelli dell'utente. A questo punto \cmd{login} provvederà (fatte salve eventuali altre azioni iniziali, come la stampa di messaggi di benvenuto o il controllo della posta) -ad eseguire con un'altra \func{exec} la shell di login, che si troverà con un -ambiente già pronto e con file standard di \secref{sec:file_std_descr} -impostati sul terminale, pronta ad eseguire i comandi fino all'uscita. Dato -che il processo genitore resta sempre \cmd{init} quest'ultimo provvederà, -ricevendo un \macro{SIGCHLD} all'uscita della shell, a rilanciare \cmd{getty} -per ripetere da capo tutto il procedimento. - - -In generale quando con il contollo di sessione è la shell che assume il ruolo -di processo di controllo, seleziona il gruppo di \textit{foregroud} e gestisce -l'assegnazione dei process group ai programmi eseguiti sulla stessa riga di -comando. - -Qualora un processo venga bloccato nella gestione della sessione, sia -implicitamente, perché cerca di eseguire dell'I/O sul terminale mentre è in -background, sia esplicitamente con l'uso di \cmd{C-z}, la shell è in grado di -rilevare l'evento grazie all'uso di \func{waitpid} con l'opzione -\macro{WUNTRACED}. In questo modo la shell può notificare (di solito prima -della stampa del prompt, lo stato dei vari processi. - - +ad eseguire con un'altra \func{exec} la shell, che si troverà con un ambiente +già pronto con i file standard di \secref{sec:file_std_descr} impostati sul +terminale, e pronta, nel ruolo di leader di sessione e processo di controllo +per il terminale, a gestire l'esecuzione dei comandi come illustrato in +\secref{sec:sess_job_control_overview}. Dato che il processo padre resta +sempre \cmd{init} quest'ultimo potrà provvedere, ricevendo un \macro{SIGCHLD} +all'uscita della shell, a rilanciare \cmd{getty} sul terminale per ripetere da +capo tutto il procedimento. @@ -593,8 +585,11 @@ servizio).\footnote{NdT. ricontrollare, i miei ricordi di filosofia sono \section{L'I/O su terminale} \label{sec:sess_terminal_io} -Esamineremo in questa sezione le peculiarità dell'I/O su terminale, tenendo -conto delle +Esamineremo in questa sezione le peculiarità dell'I/O eseguito sui terminali, +tenendo conto delle differenze che quest'ultimi presentano rispetto ai normali +file su disco. + + %%% Local Variables: -- 2.30.2