% "@(#)sag:$Id$"        
%--------------------------------------------------------------------
\chapter{Logging In And Out}
%--------------------------------------------------------------------

        \begin{raggedleft}
        \it
        This chapter needs a quote.  Suggestions, anyone?  \\
        \end{raggedleft}
        \vspace{2em}

        \noindent
	This section describes what happens when a user logs in or out.
	The various interactions of background processes, log files,
	configuration files, and so on are described in some detail.

\section{Logins via terminals}

	Figure~\ref{fig:terminal-logins} shows how logins happen
	via terminals.  First, \cmd{init} makes sure there is a
	\cmd{getty} program for the terminal connection (or
	console).  \cmd{getty} listens at the terminal and waits for
	the user to notify that he is ready to login in (this usually
	means that the user must type something).  When it notices a
	user, \cmd{getty} outputs
	a welcome message (stored in \fn{/etc/issue}), and prompts for
	the username, and finally runs the \cmd{login} program.
	\cmd{login} gets the username as a parameter, and prompts the
	user for the password.  If these match, \cmd{login}
	starts the shell configured for the user; else it just exits
	and terminates the process (perhaps after giving the user
	another chance at entering the username and password).
	\cmd{init} notices that the
	process terminated, and starts a new \cmd{getty} for the
	terminal.

\begin{figure}[htb]
\begin{center}
\leavevmode \epsffile{logins-via-terminals.ps}
\end{center}
\caption{Logins via terminals: the interaction of \cmd{init}, \cmd{getty},
	\cmd{login}, and the shell (here, \cmd{/bin/sh}).}
\label{fig:terminal-logins}
\end{figure}

	Note that the only process new process is created by \cmd{init}
	(using the \cmd{fork(2)} system call);
	\cmd{getty} and \cmd{login} only replace the program running
	in the process (using the \cmd{exec(3)} system call).

	A separate program for noticing the user is needed for serial
	lines, since it can be (and traditionally was) complicated to
	notice when a terminal becomes active.  \cmd{getty} also adapts
	to the speed and other settings of the connection, which is
	important especially for dial-in connections, where these
	parameters may change from call to call.

	There are several versions of \cmd{getty} and \cmd{init}
	in use, all with their good and bad points.  It is a good idea
	to learn about the versions on your system, and also about the
	other versions (you could use the Linux Software Map to search
	them).  If you don't have dial-in's, you probably don't have to
	worry about \cmd{getty}, but \cmd{init} is still important.

\section{Logins via the network}

	Two computers in the same network are usually linked via a single
	physical cable.  When they communicate over the network, the programs
	in each computer that take part in the communication are linked
	via a \defin{virtual connection}, a sort of imaginary cable.
	As far as the programs at either end of the virtual connection
	are concerned, they have a monopoly on their own cable.  However,	
	since the cable is not real, only imaginary, the operating systems
	of both computers can have several virtual connections share
	the same physical cable.  This way, using just a single cable,
	several programs can communicate without having to know of or
	care about the other communications.  It is even possible to
	have several computers use the same cable; the virtual
	connections exist between two computers, and the other computers
	ignore those connections that they don't take part in.

	That's a complicated and over-abstracted description of the
	reality.  It might, however, be good enough to understand
	the important reason why network logins are somewhat different
	from normal logins.  The virtual connections are established
	when there are two programs on different computers that
	wish to communicate.  Since it is in principle possible to
	login from any computer in a network to any other computer,
	there is a huge number of potential virtual communications.
	Because of this, it is not practical to start a \cmd{getty}
	for each potential login.

	There is a single process corresponding
	to \cmd{getty} that handles \emph{all} network logins.
	When it notices an incoming network login (i.e., it notices
	that it gets a new virtual connection to some other computer),
	it starts a new process to handle that single login.  The
	original process remains and continues to listen for new
	logins.

	To make things a bit more complicated, there is more than
	one communication protocol for network logins.  The two
	most important ones are \cmd{telnet} and \cmd{rlogin}.  In
	addition to logins, there are many other virtual connections
	that may be made (for FTP, Gopher, HTTP, and other network services).
	It would be ineffective to have a separate process listening 
	for a particular type of connection, so instead there is only
	one listener that can recognize the type of the connection and
	can start the correct type of program to provide the service.
	This single listener is called \cmd{inetd}; see the
	``Linux Network Administrators' Guide'' for more information.

\section{What \cmd{login} does}

	The \cmd{login} program takes care of authenticating the user
	(making sure that the username and password match), and of
	setting up an initial environment for the user by setting
	permissions for the serial line and starting the shell.

	Part of the initial setup is outputting the contents of the
	file \fn{/etc/motd} (short for message of the day) and checking
	for electronic mail.  These can be disabled by creating a file
	called \fn{.hushlogin} in the user's home directory.

	If the file \fn{/etc/nologin} exists, logins are
	disabled.  That file is typically created by \cmd{shutdown(8)}
	and relatives.  \cmd{login} checks for this file, and will
	refuse to accept a login if it exists.  If it does exist,
	\cmd{login} outputs it contents to the terminal before it quits.

	\cmd{login} logs all failed login attempts in a system log file
	(via \cmd{syslog}).  It also logs \emph{all} logins by \texttt{root}.
	Both of these can be useful when tracking down intruders.

	Currently logged in people are listed in \fn{/var/run/utmp}.
	This file is valid only until the system is next rebooted or shut
	down; it is cleared when the system is booted.	It lists each
	user and the terminal (or network connection) he is using, along
	with some other useful information.  The \cmd{who}, \cmd{w}, and
	other similar commands look in \fn{utmp} to see who are logged in.

	All successful logins are recorded into \fn{/var/log/wtmp}.
	This file will grow without limit, so it must be cleaned
	regularly, for example by having a weekly \cmd{cron} job
	to clear it.\footnote{Good Linux distributions do this out
	of the box.}  The \cmd{last} command browses \fn{wtmp}.

	Both \fn{utmp} and \fn{wtmp} are in a binary format (see the
	\man{utmp(5)} manual page); it is unfortunately not convenient
	to examine them without special programs.

\section{X and xdm}

	\meta X implements logins via xdm; also: xterm -ls

\section{Access control}

	The user database is traditionally contained in the
	\fn{/etc/passwd} file.  Some systems use \defin{shadow passwords},
	and have moved the passwords to \cmd{/etc/shadow}.
	Sites with many computers that share the accounts use
	NIS or some other method to store the user database; they might
	also automatically copy the database from one central location
	to all other computers.

	The user database contains not only the passwords, but also
	some additional information about the users, such as their
	real names, home directories, and login shells.  This other
	information needs to be public, so that anyone can read it.
	Therefore the password is stored encrypted.  This does have
	the drawback that anyone with access to the encrypted password
	can use various cryptographical methods to guess it, without
	trying to actually log into the computer.  Shadow passwords
	try to avoid this by moving the password into another file,
	which only \texttt{root} can read (the password is still
	stored encrypted).  However, installing shadow passwords later
	onto a system that did not support them can be difficult.

	With or without passwords, it is important to make sure that
	all passwords in a system are good, i.e., not easily guessable.
	The \cmd{crack} program can be used to crack passwords; any
	password it can find is by definition not a good one.  While
	\cmd{crack} can be run be intruders, it can also be run by
	the system adminstrator to avoid bad passwords.  Good passwords
	can also be enforced by the \cmd{passwd(1)} program; this is
	in fact more effective in CPU cycles, since cracking passwords
	requires quite a lot of computation.

	The user group database is kept in \fn{/etc/group}; for systems
	with shadow passwords, there can be a \fn{/etc/shadow.group}.

	\texttt{root} usually can't login via most terminals or the
	network, only via terminals listed in the \cmd{/etc/securetty}
	file.  This makes it necessary to get physical access to
	one of these terminals.  It is, however, possible to log in
	via any terminal as any other user, and use the \cmd{su} command
	to become \texttt{root}.

\section{Shell startup}

	When an interactive login shell starts, it automatically executes
	one or more pre-defined files.  Different shells execute different
	files; see the documentation of each shell for further information.

	Most shells first run some global file, for example, the Bourne
	shell (\cmd{/bin/sh}) and its derivatives execute \fn{/etc/profile};
	in addition, they execute \fn{\~/.profile}.  \fn{/etc/profile}
	allows the system administrator to have set up a common user
	environment, especially by setting the PATH to include local
	command directories in addition to the normal ones.  On the other
	hand, \fn{\~/.profile} allows the user to customize the environment
	to his own tastes by overriding, if necessary, the default
	environment.
