%--------------------------------------------------------------------
\chapter{Se logger et se délogger}
%--------------------------------------------------------------------

        \begin{chapterquote}
        Ce chapitre a besoin d'une citation. Des suggestions ?\\
        \end{chapterquote}

        \noindent
Cette section décrit ce qui se passe lorsqu'un utilisateur se logge ou se délogge. Les différentes interactions entre
les processus d'arrière-plan, les fichiers de diagnostique, les fichiers de configuration, etc. sont décrites en 
détail.

\section{Logins via des terminaux}

	La figure~\ref{fig:terminal-logins} montre comment les logins se passent à partir des terminaux.
	\cmd{init} s'assure d'abord qu'il y a un programme 
	\cmd{getty} pour la connexion du terminal (ou de la console).
\cmd{getty} se met à l'écoute du terminal et attend qu'un utilisateur indique qu'il est pr\^et à se logger (ceci
signifie généralement que l'utilisateur doive taper quelque chose). Lorsqu'il a pris en compte un utilisateur,
\cmd{getty} produit un message d'accueil (stocké dans \fn{/etc/issue}), demande le nom de l'utilisateur, puis lance le
programme \cmd{login}.
	\cmd{login} prend le nom de l'utilisateur comme paramètre et demande à l'utilisateur son mot de passe. Si ceux-ci
correspondent, \cmd{login} lance le shell configuré pour l'utilisateur ; sinon, il s'arr\^ete et termine le
processus (parfois après avoir donné à l'utilisateur une autre chance d'entrer son nom d'utilisateur et un mot de 
passe).	\cmd{init} note que le processus est terminé et lance un nouveau \cmd{getty} pour le terminal.

\begin{figure}[htb]
\begin{center}
\includegraphics{logins/logins-via-terminals.ps}
\end{center}
\caption{Logins via des terminaux: les interactions de \cmd{init}, \cmd{getty},
	\cmd{login}, et le shell.}
\label{fig:terminal-logins}
\end{figure}

	On notera que le seul nouveau processus est celui qui est créé par \cmd{init} (en utilisant l'appel
système \cmd{fork}) ; \cmd{getty} et \cmd{login} remplacent seulement le programme qui tourne dans le
processus (en utilisant l'appel système \cmd{exec}).

	Un autre programme est nécessaire pour prendre en compte un utilisateur dans le cas de lignes série car
il peut \^etre (et ça l'est en général) compliqué de s'apercevoir qu'un terminal devient actif. \cmd{getty} 
s'adapte aussi à la vitesse et autres réglages de la connexion, ce qui est important surtout pour les connexions
entrantes où ces paramètres peuvent changer d'appel en appel.

	Il existe plusieurs versions de \cmd{getty} et \cmd{init} en usage, chacunes avec leurs bons et mauvais 
aspects. Il est souhaitable de conna\^\i tre les versions de son système, ainsi que les autres versions (on peut
utiliser la << Linux Software Map >> pour les trouver). Si l'on n'a pas d'appels entrants, on n'a pas à se soucier
de \cmd{getty}, mais \cmd{init} reste important.

\section{Logins via le réseau}

Deux ordinateurs du m\^eme réseau sont généralement reliés par un simple c\^able physique. Quand ils communiquent
sur le réseau, les programmes de chaque ordinateur prenant part à la communication sont reliés par une
\defin{connexion virtuelle}, une sorte de c\^able imaginaire. Tant que les programmes à chaque bout de la connexion
sont concernés, ils ont le monopole sur leur propre c\^able. Cependant, comme ce c\^able n'est pas réel, seulement
imaginaire, les systèmes d'exploitation des deux ordinateurs peuvent avoir plusieurs connexions virtuelles partageant
le m\^eme c\^able physique. De cette façon, en utilisant un seul c\^able, plusieurs programmes peuvent communiquer
sans avoir à conna\^\i tre les autres communications ni à se soucier d'elles. Il est m\^eme possible d'avoir 
plusieurs ordinateurs sur le m\^eme c\^able ; les connexions virtuelles existent entre deux ordinateurs, et les
autres ignorent ces connexions auxquelles ils ne participent pas.

Ceci est une description compliquée et très abstraite de la réalité. Elle peut, cependant, \^etre assez bonne pour 
comprendre la raison importante pour laquelle les logins réseau sont différents des logins normaux. Les 
connexions virtuelles sont établies lorsque deux programmes sur des ordinateurs différents veulent communiquer.
Comme il est en principe possible de se logger de n'importe quel ordinateur du réseau sur un autre, il existe
un nombre énorme de communications virtuelles potentielles. Pour cette raison, il n'est pas pratique de lancer
un \cmd{getty} pour chaque login potentiel.

Il y a un seul processus \texttt{inetd} (correspondant à \cmd{getty}) qui gère \emph{tous} les logins réseau.
Lorsqu'il note l'arrivée d'un login réseau (i.e., il note qu'il obtient une nouvelle connexion virtuelle à 
un autre ordinateur), il lance un nouveau processus pour gérer cet unique login. Le processus original reste et 
continue à \^etre à l'écoute de nouveaux logins.

Pour compliquer encore un peu plus les choses, il y a plus d'un protocole de communication pour les logins
réseau. Les deux plus importants sont \cmd{telnet} et \cmd{rlogin}.  En plus des logins, on peut faire
beaucoup d'autres connexions virtuelles (pour FTP, Gopher, HTTP, et autres services réseau).
Il serait inefficace d'avoir un processus distinct attendant un type particulier de connexion ; au lieu de ça,
il n'y en a qu'un seul qui peut reconna\^\i tre le type de la connexion et qui peut lancer le type de programme
correct fournissant le service. Ce processus unique s'appelle \cmd{inetd} ; voir le
<< Guide de l'administrateur réseau sous Linux >> pour plus d'information.

\section{But de \cmd{login}}

Le programme  \cmd{login} s'occupe d'authentifier l'utilisateur (en s'assurant que le nom de l'utilisateur et le mot de
passe correspondent), et de mettre en place un environ\-ne\-ment initial pour celui-ci en positionnant les permissions pour
la ligne série et en lançant le shell.

Une partie de la configuration initiale consiste à afficher le contenu du fichier
\fn{/etc/motd} (raccourci signifiant << message of the day >>) et à vérifier le courrier électronique. Ces t\^aches 
peuvent \^etre désactivées en créant un fichier \fn{.hushlogin} dans le répertoire de l'utilisateur.

	Si le fichier \fn{/etc/nologin} existe, les logins sont désactivés. Ce fichier est géné\-ra\-le\-ment créé par 
	\cmd{shutdown} et consorts. \cmd{login} vérifie la présence de ce fichier et refusera d'accepter un login s'il
existe. S'il existe, \cmd{login} affiche son contenu sur le terminal avant de se terminer.

	\cmd{login} fait un rapport de toutes les tentatives de login qui ont échoué dans un fichier de diagnostique système 
	(via \cmd{syslog}).  Il rapporte aussi \emph{tous} les logins de \texttt{root}.
	Ces deux rapports peuvent \^etre utiles pour pister les intrus.

	Les personnes loggées sont listées dans \fn{/var/run/utmp}.
Ce fichier est valide jusqu'au redémarrage ou  l'arr\^et du système. Il liste chaque utilisateur et le terminal (ou
la connexion réseau) qu'il utilise, et d'autres informations utiles. Les commandes \cmd{who}, \cmd{w} et similaires 
consultent \fn{utmp} pour voir qui est loggé.

Tous les logins réussis sont enregistrés dans \fn{/var/log/wtmp}. Ce fichier grossit sans limite, il doit donc \^etre 
nettoyé régulièrement, par exemple en utilisant une t\^ache \cmd{cron} hebdomadaire.\footnote{Les bonnes distributions
Linux font cela.} La commande \cmd{last} parcourt \fn{wtmp}.

	\fn{utmp} et \fn{wtmp} sont dans un format binaire (voir la page \man{utmp} du manuel en ligne) ; il n'est
malheureusement pas pratique de les examiner sans programmes spéciaux.

\section{X et xdm}

	\meta X implante les logins via xdm ; voir aussi xterm -ls

\section{Contr\^ole d'accès}

La base de données utilisateurs est traditionnellement contenue dans le fichier
	\fn{/etc/passwd}.  Certains systèmes utilisent des \defin{shadow passwords},
	et ont déplacé les mots de passe dans \cmd{/etc/shadow}.
	Les sites ayant plusieurs ordinateurs partageant les m\^emes comptes utilisent NIS ou une autre méthode pour 
stocker la base de données utilisateurs ; ils peuvent aussi copier automatiquement la base de données d'un emplacement
central sur tous les autres ordinateurs.

La base de données utilisateurs ne contient pas seulement les mots de passe mais aussi d'autres informations sur les
utilisateurs, comme leur vrai nom, leur répertoire de base, et leur shell de login. Ces dernières informations doivent
\^etre publiques pour que tout le monde puisse les lire. Par conséquent, le mot de passe est stocké de façon cryptée.
Ceci a le désavantage que tous ceux qui ont accès au mot de passe crypté peuvent utiliser diverses méthodes 
cryptographiques pour le trouver. Les shadow passwords essayent d'éviter cela en déplaçant les mots de passe dans un
autre fichier que seul \texttt{root} peut lire (le mot de passe est encore stocké crypté). Cependant, installer des
shadow passwords sur un système qui ne les possédait pas peut s'avérer difficile.

Il est important de s'assurer que tous les mots de passe sur un système soient corrects, i.e. difficilement trouvables.
Le programme \cmd{crack} peut \^etre utilisé pour casser les mots de passe ; tout mot de passe qu'il peut trouver
est, par définition, incorrect. Bien que \cmd{crack} puisse \^etre lancé par des intrus, il peut aussi \^etre lancé par
l'administrateur système pour éviter les mauvais mots de passe. Le programme \cmd{passwd} peut aussi s'assurer de
la validité des mots de passe ; c'est, en fait, plus efficace en termes de cycles CPU car le << craquage >> des mots de
passe requiert beaucoup de calculs.

La base de donnée des groupes d'utilisateurs est contenue dans \fn{/etc/group} ; pour les systèmes avec
shadow passwords, il peut y avoir un fichier \fn{/etc/shadow.group}.

	\texttt{root} ne peut généralement pas se logger à partir de tous les terminaux ou via le réseau, mais
seulement à partir des terminaux listés dans le fichier	\cmd{/etc/securetty}. Ceci oblige à avoir un accès physique 
à l'un de ces terminaux. Il est, cependant, possible de se logger via n'importe quel terminal en tant qu'autre 
utilisateur, puis d'utiliser la commande \cmd{su} pour devenir \texttt{root}.

\section{Démarrage du shell}

Lorsqu'un shell de login interactif démarre, il exécute automatiquement un ou plusieurs fichiers pré-définis. Les différents
shells exécutent des fichiers différents ; voir la documentation de chaque shell pour plus d'informations.

La plupart des shells lancent d'abord un fichier global, par exemple, le Bourne shell 
(\cmd{/bin/sh}) et ses dérivés exécutent \fn{/etc/profile} ; de plus, ils exécutent
\fn{.profile} dans le répertoire de l'utilisateur.
\fn{/etc/profile} permet à l'adminstrateur système d'avoir un environnement commun à tous les utilisateurs, notamment
en faisant en sorte que PATH inclue les répertoires des commandes locales en plus des commandes normales. D'un autre c\^oté, 
\fn{.profile} permet à l'utilisateur de personnaliser son environnement selon ses propres go\^uts en surchargeant, 
si nécessaire, l'environnement par défaut.
