session.tex

   1 \chapter{Sessioni di lavoro}
   2 \label{cha:session}
   3
   4 Unix nasce prima dell'esistenza dei moderni PC, quando i computer occupavano
   5 stanze intere e ci si poteva collegare solo attraverso dei terminali, ma fin
   6 dalle sue origini è sempre stato un sistema multitasking e multiutente,
   7 in grado di consentire l'utilizzo di un solo computer da parte di più persone.
   8
   9 Esamineremo in questo capitolo i concetti base del sistema delle sessioni di
  10 lavoro, vale a dire il metodo con cui il kernel gestisce l'accesso concorrente
  11 al sistema da parte di più utenti, permettendo loro di eseguire più programmi
  12 in contemporanea.
  13
  14
  15 \section{Il \textit{Job control}}
  16 \label{sec:sess_job_control}
  17
  18 Viene comunemente chiamato \textit{Job control} quell'insieme di funzionalità
  19 del sistema il cui scopo è quello di permettere ad un utente di poter
  20 sfruttare le capacità multitasking di un sistema Unix per eseguire in
  21 contemporanea più processi, pur potendo accedere, di solito, ad un solo
  22 terminale,\footnote{con X e con i terminali vituali tutto questo non è più
  23   vero, dato che si può accedere a molti terminali in contemporanea, ma il
  24   sistema è nato prima dell'esistenza di tutto ciò.} avendo cioè un solo punto
  25 in cui si può avere accesso all'input ed all'output degli stessi.
  26
  27
  28 \subsection{La struttura di base}
  29 \label{sec:sess_relation}
  30
  31 Per poter gestire il \textit{Job Control} il kernel associa a ciascun processo
  32 due ulteriori identificatori (oltre quelli visti in \secref{sec:proc_pid}):
  33 l'identificatore del cosiddetto \textit{process group} (o
  34 \textsl{ragguppamento di processi}), cui si fa di norma riferimento con la
  35 sigla \acr{pgid}, l'identificatore di sessione (il \textit{session id}) cui si
  36 fa riferimento con la sigla \acr{sid}).  In questo modo, sulla base dei valori
  37 dei rispettivi indicatori, i processi vengono organizzati in \textsl{sessioni}
  38 e \textsl{raggruppamenti}.
  39
  40 Entrambi gli identificatori vengono impostati alla creazione di ciascun
  41 processo allo stesso valore che hanno nel processo padre, un processo appena
  42 creato cioè appartiene sempre allo stesso raggruppamento e alla stessa
  43 sessione del padre. La differenza fra i due identificatori è che un processo
  44 può cambiare \acr{pgid} soltanto ad un valore che corrisponda al
  45 \textit{process group} di un altro processo della stessa sessione, oppure al
  46 suo stesso \acr{pid} (creando così un nuovo \textit{process group}). Se invece
  47 si modifica il \acr{sid} il processo viene automaticamente messo anche in un
  48 nuovo \textit{process group}, corrispondente al suo \acr{pid}.
  49
  50 Per capire meglio il significato di questi identificatori vediamone subito
  51 l'uso concreto nella gestione del \textit{job control} della linea di comando.
  52 Una volta che si è completata la procedura di login (che esamineremo in
  53 dettaglio in \secref{sec:sess_login}), si avrà a disposizione una shell,
  54 associata ad un terminale (detto \textsl{terminale di controllo}), dalla quale
  55 eseguire i comandi, una delle caratteristiche della shell è quella di
  56 consentire di inviare un comando in \textit{background}, cioè di farlo
  57 eseguire distaccandolo dal terminale, che potrà essere utilizzato da altri
  58 comandi. Così un solo un comando alla volta potrà leggere e scrivere sul
  59 terminale (quello che viene detto in \textit{foreground}).
  60
  61 Fra le funzionalità della shell c'è anche quella di consentire di concatenare
  62 più programmi in una sola riga di comando con le pipe, in tal caso verranno
  63 eseguiti più programmi, inoltre, anche quando si invoca un singolo programma,
  64 questo può sempre lanciare ulteriori sottoprocessi per eseguire dei compiti
  65 specifici. In tutti qesti casi la shell farà sì che tutti i processi che
  66 originano da un sola riga di comando vengano raggruppati in un unico
  67 \textit{process group}; questo perché i segnali inviati sul terminale con i
  68 comandi da tastiera (quelli illustrati in \secref{sec:sig_job_control})
  69 vengono inviati a tutti i processi che fan parte del raggruppamento di
  70 \textit{foreground}, cioè quelli che stanno corre
  71
  72
  73 Per consentire l'utilizzo contemporaneo dello stesso terminale la shell deve
  74 essere in grado di garantire che solo un comando alla volta possa accedervi;
  75
  76
  77
  78
  79
  80 Lo stato del sistema può essere verificato con il comando \cmd{ps -je f}
  81
  82
  83
  84 \subsection{Il login ed il terminale di controllo}
  85 \label{sec:sess_login}
  86
  87 L'organizzazione del sistema del \textit{Job Control} è strettamente connessa
  88 alle modalità con cui un utente accede al sistema, collegandosi ad esso con un
  89 terminale, che sia questo realmente tale, come un VT100 collegato ad una
  90 seriale o virtuale, come quelli associati a schermo e tastiera o ad una
  91 connessione di rete. Dato che i concetti base sono gli stessi, e dato che alla
  92 fine le differenze sono\footnote{in generale nel caso di login via rete o di
  93   terminali lanciati dall'interfaccia grafica cambia anche il processo da cui
  94   ha origine l'esecuzione della shell.} nel device cui il kernel associa i
  95 file standard di \secref{sec:file_std_descr}, tratteremo solo il caso in
  96 questo è il classico terminale.
  97
  98 Abbiamo già brevemente illustrato in \secref{sec:intro_kern_and_sys} le
  99 modalità con cui il sistema si avvia, e di come, a partire da \cmd{init},
 100 vengano lanciati tutti gli altri processi. Adesso vedremo in maniera più
 101 dettagliata le modalità con cui il sistema arriva a fornire ad un utente la
 102 shell che gli permette di lanciare i suoi comandi su un terminale.
 103
 104 Nella maggior parte delle distribuzioni di GNU/Linux\footnote{fa eccezione la
 105   distribuzione \textit{Slackware}, come alcune distribuzioni su dischetto, ed
 106   altre distribuzioni dedicate a compiti limitati e specifici.}  viene usata
 107 la procedura di avvio di System V; questa prevede che \cmd{init} legga dal
 108 file di configurazione \file{/etc/inittab} quali programmi devono essere
 109 lanciati, ed in quali modalità, a seconda del cosiddetto \textit{run level},
 110 anch'esso definito nello stesso file.
 111
 112 Tralasciando la descrizione del sistema dei run level, (per il quale si
 113 rimanda alla lettura delle pagine di manuale di \cmd{init} e di
 114 \file{inittab}) quello che comunque viene sempre fatto è di eseguire almeno
 115 una istanza di un programma che permetta l'accesso ad un terminale. Uno schema
 116 di massima della procedura è riportato in \secref{fig:sess_term_login}.
 117
 118 \begin{figure}[htb]
 119   \centering
 120   \includegraphics[width=15cm]{img/tty_login}
 121   \caption{Schema della procedura di login su un terminale.}
 122   \label{fig:sess_term_login}
 123 \end{figure}
 124
 125 Un terminale, che esso sia un terminale effettivo, attaccato ad una seriale o
 126 ad un altro tipo di porta di comunicazione, o una delle console virtuali
 127 associate allo schermo,  viene sempre visto attraverso attraverso un device
 128 driver che ne presenta un'interfaccia comune su un apposito file di
 129 dispositivo. Storicamente i primi terminali erano appunto terminali di
 130 telescriventi (\textit{teletype}), da cui deriva sia il nome dell'interfaccia,
 131 \textit{tty}, che quello dei relativi file di dispositivo, che sono sempre
 132 della forma \texttt{/dev/tty*}.\footnote{questo vale anche per i terminali
 133   associati alle connessioni di rete con \cmd{telnet} o \cmd{ssh}.}
 134
 135 Per controllare i terminali si usa di solito il programma \cmd{getty} (od una
 136 delle sue varianti), che permette di mettersi in ascolto sugli stessi. Alla
 137 radice della catena che porta ad una shell per i comandi perciò c'è sempre
 138 \cmd{init} che esegue prima una \func{fork} e poi una \func{exec} per lanciare
 139 una istanza di questo programma su un terminale, il tutto ripetuto per
 140 ciascuno dei terminali che si hanno a disposizione (o per un certo numero di
 141 essi, nel caso delle console virtuali), secondo quanto indicato
 142 dall'amministratore nel file di configurazione del programma,
 143 \file{/etc/inittab}.
 144
 145 Quando viene lanciato da \cmd{init} il programma parte con i privilegi di
 146 amministratore e con un ambiente vuoto; \cmd{getty} si cura di aprire il
 147 terminale in lettura sullo standard input ed in scrittura sullo standard
 148 output e sullo standard error, e di effettuare, qualora servano, ulteriori
 149 settaggi,\footnote{ad esempio, come qualcuno si sarà accorto scrivendo un nome
 150   di login in maiuscolo, può effettuare la conversione automatica dell'input
 151   in minuscolo, ponendosi in una modalità speciale che non distingue fra i due
 152   tipi di caratteri (a beneficio di alcuni vecchi terminali che non
 153   supportavano le minuscole).} ed infine il programma stamperà un messaggio di
 154 benvenuto per poi porsi in attesa dell'immissione del nome di un utente.
 155
 156 Una volta che si sia immesso il nome di login \cmd{getty} esegue direttamente
 157 il programma \cmd{login} con una \func{exevle}, passando come argomento la
 158 suddetta stringa ed un ambiente opportunamente costruito che contenga quanto
 159 necessario (ad esempio di solito viene opportunamente inizializzata la
 160 variabile di ambiente \texttt{TERM}) ad identificare il terminale su cui si
 161 sta operando, a beneficio dei programmi che verranno lanciati in seguito.
 162
 163 A sua volta \cmd{login}, che mantiene i privilegi di amministratore, usa il
 164 nome dell'utente per effettuare una ricerca nel database degli
 165 utenti,\footnote{in genere viene chiamata \func{getpwnam}, che abbiamo visto
 166   in \secref{sec:sys_user_group}, per leggere la password e gli altri dati dal
 167   database degli utenti.} e richiede una password. Se l'utente non esiste o se
 168 la password non corrisponde\footnote{il confronto non viene effettuato con un
 169   valore in chiaro; quanto immesso da terminale viene invece a sua volta
 170   criptato, ed è il risultato che viene confrontato con il valore che viene
 171   mantenuto nel database degli utenti.} la richiesta viene ripetuta un certo
 172 numero di volte dopo di che \cmd{login} esce ed \cmd{init} provvede a
 173 rilanciare un'altra istanza di \func{getty}.
 174
 175 Se invece la password corrisponde a questo punto \cmd{login} esegue
 176 \func{chdir} per settare la \textit{home directory} dell'utente, cambia i
 177 diritti di accesso al terminale (con \func{chown} e \func{chmod}) per
 178 assegnarne la titolarità all'utente ed al suo gruppo principale, assegnandogli
 179 al contempo i diritti di lettura e scrittura. Inoltre il programma provvede
 180 a costruire gli opportuni valori per le variabili di ambiente, come
 181 \texttt{HOME}, \texttt{SHELL}, ecc. Infine attraverso l'uso di \func{setuid},
 182 \func{setpid} e \func{initgroups} verrà cambiata l'identità del proprietario
 183 del processo, infatti, come spiegato in \secref{sec:proc_setuid}, avendo
 184 invocato tali funzioni con i privilegi di amministratore, tutti gli userid ed
 185 i groupid (reali, effettivi e salvati) saranno settati a quelli dell'utente.
 186
 187 A questo punto \cmd{login} provvederà (fatte salve eventuali altre azioni
 188 iniziali, come la stampa di messaggi di benvenuto o il controllo della posta)
 189 ad eseguire con un'altra \func{exec} la shell di login, che si troverà con un
 190 ambiente già pronto e con file standard di \secref{sec:file_std_descr}
 191 impostati sul terminale, pronta ad eseguire i comandi fino all'uscita. Dato
 192 che il processo genitore resta sempre \cmd{init} quest'ultimo provvederà,
 193 ricevendo un \macro{SIGCHLD} all'uscita della shell, a rilanciare \cmd{getty}
 194 per ripetere da capo tutto il procedimento.
 195
 196
 197
 198
 199 \subsection{I \textit{process group}}
 200 \label{sec:sess_proc_group}
 201
 202
 203
 204 \subsection{Le sessioni}
 205 \label{sec:sess_sessions}
 206
 207
 208
 209 \subsection{Il terminale di controllo}
 210 \label{sec:sess_ctrl_term}
 211
 212
 213
 214 \subsection{La shell e i programmi}
 215 \label{sec:sess_shell}
 216
 217
 218
 219 %%% Local Variables:
 220 %%% mode: latex
 221 %%% TeX-master: "gapil"
 222 %%% End: