session.tex

   1 \chapter{Sessioni di lavoro e terminali}
   2 \label{cha:session}
   3
   4 Esamineremo in questo capitolo i concetti base del sistema delle sessioni di
   5 lavoro, vale a dire il metodo con cui il kernel gestisce l'accesso concorrente
   6 al sistema da parte di più utenti, permettendo loro di eseguire più programmi
   7 in contemporanea.  Nella seconda parte del capitolo tratteremo poi il
   8 funzionamento dell'I/O su terminale, e delle varie peculiarità che esso viene
   9 ad assumere a causa del suo stretto legame con le modalità di accesso al
  10 sistema da parte degli utenti.
  11
  12
  13 \section{Il \textit{job control}}
  14 \label{sec:sess_job_control}
  15
  16 Viene comunemente chiamato \textit{job control} quell'insieme di funzionalità
  17 il cui scopo è quello di permettere ad un utente di poter sfruttare le
  18 capacità multitasking di un sistema Unix per eseguire in contemporanea più
  19 processi, pur potendo accedere, di solito, ad un solo terminale,\footnote{con
  20   X e con i terminali virtuali tutto questo non è più vero, dato che si può
  21   accedere a molti terminali in contemporanea, ma il sistema è nato prima
  22   dell'esistenza di tutto ciò.} avendo cioè un solo punto in cui si può avere
  23 accesso all'input ed all'output degli stessi.
  24
  25
  26 \subsection{Una panoramica introduttiva}
  27 \label{sec:sess_job_control_overview}
  28
  29 Il \textit{job control} è una caratteristica opzionale, introdotta in BSD
  30 negli anni '80, e successivamente standardizzata da POSIX.1; la sua
  31 disponibilità nel sistema è verificabile attraverso il controllo della macro
  32 \macro{\_POSIX\_JOB\_CONTROL}. In generale il \textit{job control} richiede il
  33 supporto sia da parte della shell (quasi tutte ormai lo fanno), che da parte
  34 del kernel; in particolare il kernel deve assicurare sia la presenza di un
  35 driver per i terminali abilitato al \textit{job control} che quella dei
  36 relativi segnali illustrati in \secref{sec:sig_job_control}.
  37
  38 In un sistema che supporta il \textit{job control} una volta completato il
  39 login (che esamineremo in dettaglio in \secref{sec:sess_login}), l'utente avrà
  40 a disposizione una shell dalla quale eseguire i comandi e potrà iniziare
  41 quella che viene chiamata una \textsl{sessione}, che riunisce (vedi
  42 \secref{sec:sess_proc_group}) tutti i processi eseguiti all'interno dello
  43 stesso login.
  44
  45 Siccome la shell è collegata ad un solo terminale (il \textsl{terminale di
  46   controllo}, vedi \secref{sec:sess_control_term}) solo un comando alla volta,
  47 quello che viene detto in \textit{foreground}, potrà scrivere e leggere dal
  48 terminale. La shell però può eseguire anche più comandi in contemporanea,
  49 mandandoli in \textit{background} (si fa aggiungendo una \cmd{\&} alla fine
  50 del comando), nel qual caso essi saranno eseguiti senza essere collegati al
  51 terminale.
  52
  53 Si noti come si sia parlato di comandi e non di programmi o processi; fra le
  54 funzionalità della shell infatti c'è anche quella di consentire di concatenare
  55 più programmi in una sola riga di comando con le pipe, ed in tal caso verranno
  56 eseguiti più programmi, inoltre, anche quando si invoca un singolo programma,
  57 questo potrà sempre lanciare altri processi per eseguire dei compiti
  58 specifici.
  59
  60 Per questo l'esecuzione di un comando può originare più di un processo; quindi
  61 nella gestione del job control non si può far riferimento ai singoli processi,
  62 per questo il kernel prevede la possibilità di raggruppare più processi in un
  63 \textit{process group} (detto anche \textsl{raggruppamento}, vedi
  64 \secref{sec:sess_proc_group}) e la shell farà sì che tutti i processi che
  65 originano da una riga di comando appartengano allo stesso \textit{process
  66   group}, in modo che le varie funzioni di controllo, ed i segnali inviati dal
  67 terminale, possano fare riferimento ad esso.
  68
  69 In generale allora all'interno di una sessione avremo un eventuale (possono
  70 non esserci comandi in \textit{foreground}) \textit{process group} in
  71 \textit{foreground}, che riunisce i processi che possono accedere al
  72 terminale, e più \textit{process group} in \textit{background}, che non
  73 possono accedervi. Il job control prevede che quando un processo appartenente
  74 ad un raggruppamento in \textit{background} cerca di accedere al terminale
  75 questo invii a tutti i processi del raggruppamento un segnale di
  76 \macro{SIGTTIN} o di \macro{SIGTTOU}, a seconda che l'accesso sia
  77 rispettivamente in lettura o scrittura, bloccando (secondo il comportamento
  78 di default esposto in \secref{sec:sig_job_control}) i processi.
  79
  80 Un comportamento analogo sia ha anche per i segnali generati dai comandi di
  81 tastiera inviati dal terminale con \cmd{C-z}, \cmd{C-c}, \cmd{C-y} e
  82 \verb|C-\|; questi generano rispettivamente i segnali \macro{SIGTSTP},
  83 \macro{SIGINT}, \macro{SIGQUIT} e \macro{SIGTERM}, che vengono inviati a tutti
  84 i processi del raggruppamento in \textit{foreground}. In particolare il primo
  85 di essi, \macro{SIGTSTP}, interrompe l'esecuzione del comando, che può poi
  86 essere mandato in \textit{background} con il comando \cmd{bg}. Il comando
  87 \cmd{fg} consente invece di mettere in \textit{foreground} un comando
  88 precedentemente lanciato in \textit{background}.
  89
  90 Di norma la shell si cura anche di notificare all'utente (di solito prima
  91 della stampa a video del prompt) lo stato dei vari processi, essa infatti usa
  92 le caratteristiche della funzione \func{waitpid} (si riveda quanto detto in
  93 \secref{sec:proc_wait}) per verificare quali gruppi di processi sono bloccati
  94 e quali sono terminati.
  95
  96
  97 \subsection{I \textit{process group} e le \textsl{sessioni}}
  98 \label{sec:sess_proc_group}
  99
 100 Come accennato in \secref{sec:sess_job_control_overview} nel job control i
 101 processi vengono raggruppati in \textit{process group} e \textit{sessioni};
 102 per far questo vengono utilizzati due ulteriori identificatori (oltre quelli
 103 visti in \secref{sec:proc_pid}) che il kernel associa a ciascun processo:
 104 l'identificatore del \textit{process group} e l'identificatore della
 105 \textsl{sessione}, che vengono indicati rispettivamente con le sigle
 106 \acr{pgid} e \acr{sid}, e sono mantenuti in variabili di tipo \type{pid\_t}.
 107
 108 Un \textit{process group} è pertanto definito da tutti i processi che hanno lo
 109 stesso \acr{pgid}; è possibile leggere il valore di questo identificatore con
 110 le funzioni \func{getpgid} e \func{getpgrp},\footnote{\func{getpgrp} è
 111   definita nello standard POSIX.1, mentre \func{getpgid} è richiesta da SVr4.}
 112 i cui prototipi sono:
 113 \begin{functions}
 114   \headdecl{unistd.h}
 115
 116   \funcdecl{pid\_t getpgid(pid\_t pid)}
 117   Legge il \acr{pgid} del processo \param{pid}.
 118
 119   \funcdecl{pid\_t getpgrp(void)}
 120   Legge il \acr{pgid} del processo corrente.
 121
 122   \bodydesc{Le funzioni restituiscono il \acr{pgid} del processo,
 123     \func{getpgrp} ha sempre successo, mentre \func{getpgid} restituisce -1
 124     ponendo \var{errno} a \macro{ESRCH} se il processo selezionato non esiste.}
 125 \end{functions}
 126
 127 La funzione \func{getpgid} permette di specificare il \acr{pid} del processo
 128 di cui si vuole sapere il \acr{pgid}; un valore nullo per \param{pid}
 129 restituisce il \acr{pgid} del processo corrente; \func{getpgrp} è di norma
 130 equivalente a \code{getpgid(0)}.
 131
 132 In maniera analoga l'identificatore della sessione può essere letto dalla
 133 funzione \func{getsid}, che però nelle \acr{glibc}\footnote{la system call è
 134   stata introdotta in Linux a partire dalla versione 1.3.44, il supporto nelle
 135   librerie del C è iniziato dalla versione 5.2.19.} è accessibile solo
 136 definendo \macro{\_XOPEN\_SOURCE} e \macro{\_XOPEN\_SOURCE\_EXTENDED}; il suo
 137 prototipo è:
 138 \begin{prototype}{unistd.h}{pid\_t getsid(pid\_t pid)}
 139   Legge l'identificatore di sessione del processo \param{pid}.
 140
 141   \bodydesc{La funzione restituisce l'identificatore (un numero positivo) in
 142   caso di successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà
 143   i valori:
 144     \begin{errlist}
 145     \item[\macro{ESRCH}] Il processo selezionato non esiste.
 146     \item[\macro{EPERM}] Il processo selezionato non fa parte della stessa
 147     sessione del processo corrente.
 148     \end{errlist}
 149   }
 150 \end{prototype}
 151
 152 Entrambi gli identificatori vengono inizializzati alla creazione di ciascun
 153 processo con lo stesso valore che hanno nel processo padre, per cui un
 154 processo appena creato appartiene sempre allo stesso raggruppamento e alla
 155 stessa sessione del padre.
 156
 157 Ciascun gruppo di processi ha sempre un processo principale, il cosiddetto
 158 \textit{process leader}, che è identificato dall'avere un \acr{pgid} uguale al
 159 suo \acr{pid}, in genere questo è il primo processo del gruppo, che si
 160 incarica di lanciare tutti gli altri. Un nuovo gruppo si crea con la funzione
 161 \func{setpgrp},\footnote{questa è la definizione di POSIX.1, BSD definisce una
 162   funzione con lo stesso nome, che però è identica a \func{setpgid}; nelle
 163   \acr{glibc} viene sempre usata sempre questa definizione, a meno di non
 164   richiedere esplicitamente la compatibilità all'indietro con BSD, definendo
 165   la macro \macro{\_BSD\_SOURCE}.} il cui prototipo è:
 166 \begin{prototype}{unistd.h}{int setpgrp(void)}
 167   Modifica il \acr{pgid} al valore del \acr{pid} del processo corrente.
 168
 169   \bodydesc{La funzione restituisce il valore del nuovo \textit{process
 170       group}.}
 171 \end{prototype}
 172
 173 La funzione, assegnando al \acr{pgid} il valore del \acr{pid} processo
 174 corrente, rende questo \textit{process leader} di un nuovo gruppo, tutti i
 175 successivi processi da esso creati apparterranno (a meno di non cambiare di
 176 nuovo il \acr{pgid}) al nuovo gruppo. È possibile invece spostare un processo
 177 da un gruppo ad un altro con la funzione \func{setpgid}, il cui prototipo è:
 178 \begin{prototype}{unistd.h}{int setpgid(pid\_t pid, pid\_t pgid)}
 179   Assegna al \acr{pgid} del processo \param{pid} il valore \param{pgid}.
 180
 181   \bodydesc{La funzione ritorna il valore del nuovo \textit{process group}, e
 182   -1 in caso di errore, nel qual caso \var{errno} assumerà i valori:
 183     \begin{errlist}
 184     \item[\macro{ESRCH}] Il processo selezionato non esiste.
 185     \item[\macro{EPERM}] Il processo selezionato non fa parte della stessa
 186     sessione del processo corrente.
 187     \end{errlist}
 188  }
 189 \end{prototype}
 190
 191
 192
 193
 194
 195 La differenza fra i due identificatori è che un processo
 196 può cambiare \acr{pgid} soltanto ad un valore che corrisponda al
 197 \textit{process group} di un altro processo della stessa sessione, oppure al
 198 suo stesso \acr{pid} (creando così un nuovo \textit{process group}). Se invece
 199 si modifica il \acr{sid} il processo viene automaticamente messo anche in un
 200 nuovo \textit{process group}, corrispondente al suo \acr{pid}.
 201
 202
 203
 204
 205
 206 \subsection{Il terminale di controllo}
 207 \label{sec:sess_ctrl_term}
 208
 209 Come accennato in \secref{sec:sess_job_control_overview} ad ogni sessione di
 210 lavoro è associato un terminale di controllo.
 211
 212
 213
 214 \subsection{La procedura di login}
 215 \label{sec:sess_login}
 216
 217 L'organizzazione del sistema del job control è strettamente connessa alle
 218 modalità con cui un utente accede al sistema, collegandosi ad esso con un
 219 terminale, che sia questo realmente tale, come un VT100 collegato ad una
 220 seriale o virtuale, come quelli associati a schermo e tastiera o ad una
 221 connessione di rete. Dato che i concetti base sono gli stessi, e dato che alla
 222 fine le differenze sono\footnote{in generale nel caso di login via rete o di
 223   terminali lanciati dall'interfaccia grafica cambia anche il processo da cui
 224   ha origine l'esecuzione della shell.} nel device cui il kernel associa i
 225 file standard di \secref{sec:file_std_descr}, tratteremo solo il caso in
 226 questo è il classico terminale.
 227
 228 Abbiamo già brevemente illustrato in \secref{sec:intro_kern_and_sys} le
 229 modalità con cui il sistema si avvia, e di come, a partire da \cmd{init},
 230 vengano lanciati tutti gli altri processi. Adesso vedremo in maniera più
 231 dettagliata le modalità con cui il sistema arriva a fornire ad un utente la
 232 shell che gli permette di lanciare i suoi comandi su un terminale.
 233
 234 Nella maggior parte delle distribuzioni di GNU/Linux\footnote{fa eccezione la
 235   distribuzione \textit{Slackware}, come alcune distribuzioni su dischetto, ed
 236   altre distribuzioni dedicate a compiti limitati e specifici.}  viene usata
 237 la procedura di avvio di System V; questa prevede che \cmd{init} legga dal
 238 file di configurazione \file{/etc/inittab} quali programmi devono essere
 239 lanciati, ed in quali modalità, a seconda del cosiddetto \textit{run level},
 240 anch'esso definito nello stesso file.
 241
 242 Tralasciando la descrizione del sistema dei run level, (per il quale si
 243 rimanda alla lettura delle pagine di manuale di \cmd{init} e di
 244 \file{inittab}) quello che comunque viene sempre fatto è di eseguire almeno
 245 una istanza di un programma che permetta l'accesso ad un terminale. Uno schema
 246 di massima della procedura è riportato in \secref{fig:sess_term_login}.
 247
 248 \begin{figure}[htb]
 249   \centering
 250   \includegraphics[width=15cm]{img/tty_login}
 251   \caption{Schema della procedura di login su un terminale.}
 252   \label{fig:sess_term_login}
 253 \end{figure}
 254
 255 Un terminale, che esso sia un terminale effettivo, attaccato ad una seriale o
 256 ad un altro tipo di porta di comunicazione, o una delle console virtuali
 257 associate allo schermo,  viene sempre visto attraverso attraverso un device
 258 driver che ne presenta un'interfaccia comune su un apposito file di
 259 dispositivo. Storicamente i primi terminali erano appunto terminali di
 260 telescriventi (\textit{teletype}), da cui deriva sia il nome dell'interfaccia,
 261 \textit{tty}, che quello dei relativi file di dispositivo, che sono sempre
 262 della forma \texttt{/dev/tty*}.\footnote{questo vale anche per i terminali
 263   associati alle connessioni di rete con \cmd{telnet} o \cmd{ssh}.}
 264
 265 Per controllare i terminali si usa di solito il programma \cmd{getty} (od una
 266 delle sue varianti), che permette di mettersi in ascolto sugli stessi. Alla
 267 radice della catena che porta ad una shell per i comandi perciò c'è sempre
 268 \cmd{init} che esegue prima una \func{fork} e poi una \func{exec} per lanciare
 269 una istanza di questo programma su un terminale, il tutto ripetuto per
 270 ciascuno dei terminali che si hanno a disposizione (o per un certo numero di
 271 essi, nel caso delle console virtuali), secondo quanto indicato
 272 dall'amministratore nel file di configurazione del programma,
 273 \file{/etc/inittab}.
 274
 275 Quando viene lanciato da \cmd{init} il programma parte con i privilegi di
 276 amministratore e con un ambiente vuoto; \cmd{getty} si cura di aprire il
 277 terminale in lettura sullo standard input ed in scrittura sullo standard
 278 output e sullo standard error, e di effettuare, qualora servano, ulteriori
 279 settaggi,\footnote{ad esempio, come qualcuno si sarà accorto scrivendo un nome
 280   di login in maiuscolo, può effettuare la conversione automatica dell'input
 281   in minuscolo, ponendosi in una modalità speciale che non distingue fra i due
 282   tipi di caratteri (a beneficio di alcuni vecchi terminali che non
 283   supportavano le minuscole).} ed infine il programma stamperà un messaggio di
 284 benvenuto per poi porsi in attesa dell'immissione del nome di un utente.
 285
 286 Una volta che si sia immesso il nome di login \cmd{getty} esegue direttamente
 287 il programma \cmd{login} con una \func{exevle}, passando come argomento la
 288 suddetta stringa ed un ambiente opportunamente costruito che contenga quanto
 289 necessario (ad esempio di solito viene opportunamente inizializzata la
 290 variabile di ambiente \texttt{TERM}) ad identificare il terminale su cui si
 291 sta operando, a beneficio dei programmi che verranno lanciati in seguito.
 292
 293 A sua volta \cmd{login}, che mantiene i privilegi di amministratore, usa il
 294 nome dell'utente per effettuare una ricerca nel database degli
 295 utenti,\footnote{in genere viene chiamata \func{getpwnam}, che abbiamo visto
 296   in \secref{sec:sys_user_group}, per leggere la password e gli altri dati dal
 297   database degli utenti.} e richiede una password. Se l'utente non esiste o se
 298 la password non corrisponde\footnote{il confronto non viene effettuato con un
 299   valore in chiaro; quanto immesso da terminale viene invece a sua volta
 300   criptato, ed è il risultato che viene confrontato con il valore che viene
 301   mantenuto nel database degli utenti.} la richiesta viene ripetuta un certo
 302 numero di volte dopo di che \cmd{login} esce ed \cmd{init} provvede a
 303 rilanciare un'altra istanza di \func{getty}.
 304
 305 Se invece la password corrisponde a questo punto \cmd{login} esegue
 306 \func{chdir} per settare la \textit{home directory} dell'utente, cambia i
 307 diritti di accesso al terminale (con \func{chown} e \func{chmod}) per
 308 assegnarne la titolarità all'utente ed al suo gruppo principale, assegnandogli
 309 al contempo i diritti di lettura e scrittura. Inoltre il programma provvede
 310 a costruire gli opportuni valori per le variabili di ambiente, come
 311 \texttt{HOME}, \texttt{SHELL}, ecc. Infine attraverso l'uso di \func{setuid},
 312 \func{setpid} e \func{initgroups} verrà cambiata l'identità del proprietario
 313 del processo, infatti, come spiegato in \secref{sec:proc_setuid}, avendo
 314 invocato tali funzioni con i privilegi di amministratore, tutti gli userid ed
 315 i groupid (reali, effettivi e salvati) saranno settati a quelli dell'utente.
 316
 317 A questo punto \cmd{login} provvederà (fatte salve eventuali altre azioni
 318 iniziali, come la stampa di messaggi di benvenuto o il controllo della posta)
 319 ad eseguire con un'altra \func{exec} la shell di login, che si troverà con un
 320 ambiente già pronto e con file standard di \secref{sec:file_std_descr}
 321 impostati sul terminale, pronta ad eseguire i comandi fino all'uscita. Dato
 322 che il processo genitore resta sempre \cmd{init} quest'ultimo provvederà,
 323 ricevendo un \macro{SIGCHLD} all'uscita della shell, a rilanciare \cmd{getty}
 324 per ripetere da capo tutto il procedimento.
 325
 326
 327
 328
 329 Lo stato del sistema può essere verificato con il comando \cmd{ps -je f}
 330
 331
 332
 333
 334
 335
 336 \section{L'I/O su terminale}
 337 \label{sec:sess_terminal_io}
 338
 339 Esamineremo in questa sezione le peculiarità dell'I/O su terminale, tenendo
 340 conto delle
 341
 342
 343 %%% Local Variables:
 344 %%% mode: latex
 345 %%% TeX-master: "gapil"
 346 %%% End: