%--------------------------------------------------------------------
\chapter{Login e logout}
\label{ch:logins}
%--------------------------------------------------------------------

        \begin{chapterquote}
	Questo capitolo ha bisogno di una citazione. Suggerimenti? \\
        \end{chapterquote}

        \noindent
	Questa sezione descrive cosa succede quando un utente si collega o fa logout. Vengono descritte in dettaglio le varie interazioni di processi in background, file di log, file di configurazione e così via.

\section{Login via terminale}

	La figura~\ref{fig:terminal-logins} mostra come avvengono i login via terminale. Per prima cosa, \cmd{init} si assicura che ci sia un programma di \cmd{getty} per la connessione da terminale (o da console). \cmd{getty} ascolta al terminale ed aspetta che l'utente sia pronto a fare il login (di solito comporta che l'utente digiti qualcosa). Quando nota un utente, \cmd{getty} dà in output un messaggio di saluto (che si trova in \fn{/etc/issue}), chiede il nome dell'utente, e alla fine fa partire il programma \cmd{login}. \cmd{login} prende come parametro il nome dell'utente, e chiede la password. Se corrispondono, \cmd{login} avvia la shell configurata per l'utente, altrimenti esce semplicemente e termina il processo (probabilmente dopo aver dato all'utente un'altra possibilità di inserire il nome e la password). \cmd{init} nota che il processo è stato terminato, e avvia una nuova \cmd{getty} per quel terminale.


\begin{figure}[htb]
\begin{center}
\includegraphics{logins/logins-via-terminals.ps}
\end{center}
\caption{Login via terminale: l'interazione di \cmd{init}, \cmd{getty},
	\cmd{login}, e la shell.}
\label{fig:terminal-logins}
\end{figure}

	Notare che il solo processo nuovo è quello creato da \cmd{init} (usando la chiamata di sistema \cmd{fork}); \cmd{getty} e \cmd{login} sostituiscono solo il programma che gira nel processo (usando la chiamata di sistema \cmd{exec}).

	Per le linee seriali è necessario un programma separato per notare l'utente, dato che può essere (ed era tradizionalmente) complicato notare quando un terminale diventa attivo. \cmd{getty} si adatta anche alla velocità e ad altre impostazioni della connessione, quando questi parametri cambiano da chiamata a chiamata.

	Ci sono diverse versioni di \cmd{getty} e \cmd{init}, tutte con i loro aspetti positivi e negativi. \`E una buona idea studiare tutte le versioni disponibili sul vostro sistema, e anche le altre (potete usare la Linux Software Map per cercarle). Se non avete accessi in entrata via linea seriale probabilmente non avete bisogno di preoccuparvi delle \cmd{getty}, ma \cmd{init} è sempre importante.


\section{Login via rete}

	Due computer della stessa rete di solito sono collegati da un singolo cavo fisico. Quando comunicano in rete, i programmi in ciascun computer che prendono parte alla comunicazione sono collegati attraverso una \defin{connessione virtuale}, una specie di cavo immaginario. Per quanto riguarda i programmi ai lati della connessione, hanno un monopolio del proprio cavo; comunque, dato che il cavo non è reale, solo immaginario, i sistemi operativi di entrambi i computer hanno diverse connessioni virtuali che condividono lo stesso cavo fisico. In questo modo, usando un solo cavo fisico, diversi programmi possono comunicare tra di loro senza dover conoscere o doversi preoccupare delle altre comunicazioni. \`E anche possibile avere diversi computer che usano lo stesso cavo; le connessioni virtuali esistono tra due computer, e gli altri ignorano le connessioni di cui non fanno parte.


	Questo è un modo complicato e troppo astratto per descrivere la situazione; può però essere abbastanza buono per capirle la ragione importante per cui i login via rete sono in qualche modo diversi da quelli normali. Le connessioni virtuali vengono stabilite quando due programmi su computer diversi vogliono comunicare. Dato che in principio è possibile fare login su un qualsiasi computer della rete da un qualsiasi altro, c'è un numero enorme di comunicazioni virtuali potenziali; quindi non è pratico inizializzare una \cmd{getty} per ogni login potenziale.

	C'è un singolo processo di inetd (che corrisponde alle \cmd{getty}) che gestisce \emph{tutti} i login di rete. Quando nota un login di rete in arrivo (cioè nota che viene aperta una connessione virtuale da un altro computer), inizia un nuovo processo per gestirlo singolarmente. Il processo originale resta e continua ad aspettare altri login.

	Per complicare un po' le cose, c'è più di un protocollo di comunicazione per i login di rete; i due più importanti sono \cmd{telnet} e \cmd{rlogin}. Oltre ai login, ci sono molte altre connessioni virtuali possibili (per FTP, Gopher, HTTP ed altri servizi di rete). Sarebbe poco efficace avere un processo separato che aspetti un tipo particolare di connessione, quindi ce n'è uno solo che può riconoscere tutti i tipi di connessione e far partire il programma giusto per il servizio richiesto. Questo programma si chiama \cmd{inetd}: consultate la ``Linux Network Administration Guide'' per altre informazioni.

\section{Che cosa fa \cmd{login}}

	\cmd{login} si occupa di autenticare l'utente (cioè di assicurarsi che il nome dell'utente e la password combacino), di configurare un ambiente iniziale impostando i permessi per la linea seriale e di inizializzare la shell.

	Parte della configurazione iniziale consiste nel mandare in output il contenuto del file \fn{/etc/motd} (per ``message of the day'', cioè ``messaggio del giorno'') e controllare la posta elettronica. Queste fasi possono essere disabilitate creando il file \fn{.hushlogin} nella home directory dell'utente.

	Se esiste il file \fn{/etc/nologin}, i login sono disabilitati. Un file del genere viene di solito creato da \cmd{shutdown} e da comandi simili. \cmd{login} controlla la presenza di questo file, e se esiste non accetterà i login. Se esiste, \cmd{login} manderà in output il suo contenuto al terminale prima di uscire.

	\cmd{login} tiene un log di tutti i tentativi di login falliti in un file di log di sistema (usando \cmd{syslog}). Tiene anche un log di \emph{tutti} i login di \texttt{root}; entrambi possono essere utili per rintracciare gli intrusi.

	Gli utenti collegati al momento sono elencati in \fn{/var/run/utmp}; questo file è valido solo fino al prossimo reboot o shutdown del sistema, ed elenca ogni utente ed il terminale (o la connessione di rete) che sta usando, oltre ad altre informazioni utili. I comandi \cmd{who}, \cmd{w} e simili usano \fn{utmp} per vedere chi è collegato.

	Tutti i login che hanno avuto successo sono registrati in \fn{/var/log/wtmp}. Questo file crescerà senza limite, quindi deve essere ripulito regolarmente, ad esempio usando un job di \cmd{cron} settimanale.\footnote{Le buone distribuzioni di Linux lo fanno senza dover configurare niente.} Il comando \cmd{last} legge \fn{wtmp}.

	Sia \fn{utmp} che \fn{wtmp} sono in formato binario (consultate la pagina man di \cmd{utmp}); non conviene esaminarli senza usare programmi speciali.


\section{X e xdm}

	\meta X implementa i login via xdm; e anche: xterm -ls

\section{Il controllo degli accessi}

	Tradizionalmente il database degli utenti è tenuto nel file \fn{/etc/passwd}. Alcuni sistemi usano le \defin{shadow password}, ed hanno spostato le password in \fn{/etc/shadow}. I siti con molti computer che condividono gli account usano il NIS o altri metodi per immagazzinare i database degli utenti: possono anche copiare automaticamente il database da una posizione centrale in tutti gli altri computer.

	Il database degli utenti non contiene solo le password, ma anche altre informazioni sugli utenti, come il loro vero nome, le home directory e le shell di login. Queste informazioni devono essere pubbliche, in modo che chiunque possa leggerle, quindi le password sono criptate. Questo metodo ha il lato negativo che chiunque con accesso alle password criptate può usare un qualche metodo di decrittazione per leggerle, senza dover collegarsi al computer. Le shadow password tentano di evitare questa possibilità spostando le password in un altro file, leggibile solo da \texttt{root} (le password sono comunque criptate). Comunque, installare le shadow password su un sistema che non le supporta fin dall'inizio può essere difficoltoso.

	Con o senza le shadow password, è importante assicurarsi che tutte le password del sistema siano valide, cioè non facilmente indovinabili. Per craccare le password si può usare il programma \cmd{crack}: qualsiasi password che riesce a craccare per definizione non è valida. \cmd{crack} viene usato dagli intrusi, ma anche dai sistemisti che vogliono evitare password facili da indovinare. Si possono avere password valide anche usando il programma \cmd{passwd}; è più efficace in termini di cicli di CPU, dato che craccare le password è un lavoro che richiede molto calcolo.

Il database dei gruppi degli utenti viene tenuto in \fn{/etc/group}; per i sistemi con le shadow password può anche esistere il file \fn{/etc/shadow.group}.

	\texttt{root} di solito non si può collegare dalla maggior parte dei terminali di rete, ma solo da quelli elencari nel file \cmd{/etc/securetty}; ciò rende necessario avere accesso fisico ad uno di questi terminali. \`E comunque possibile collegarsi ad un qualsiasi terminale come utente normale ed usare il comando \cmd{su} per diventare \texttt{root}.

\section{L'avvio della shell}

	Quando parte una shell di login interattiva, esegue automaticamente uno o più file predefiniti. Shell diverse eseguono file diversi; consultate la documentazione di ciascuna shell per altre informazioni.

	La maggior parte delle shell eseguono prima un file globale, ad esempio la Bourne shell (\cmd{/bin/sh} e i suoi derivati eseguono \fn{/etc/profile}, poi eseguono \fn{.profile} nella home directory dell'utente. \fn{/etc/profile} permette all'amministratore di sistema di impostare un ambiente comune per gli utenti, specialmente per quanto riguarda il PATH per includere le directory di comandi locali oltre a quelle normali. D'altra parte, \fn{.profile} permette agli utenti di personalizzare il proprio ambiente superando, se necessario, quello di default.
