I don't care to belong to a club
that accepts people like me as a member.
(Groucho Marx)
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.
Logins via terminals shows how logins happen via
terminals. First, init makes sure there is
a getty program for the terminal connection
(or console). 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, getty outputs a welcome message
(stored in /etc/issue), and prompts for
the username, and finally runs the login
program. login gets the username as a
parameter, and prompts the user for the password. If these
match, 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). init notices that
the process terminated, and starts a new getty
for the terminal.
Logins via terminals: the interaction of
<command>init</command>,
<command>getty</command>, <command>login</command>, and the
shell. Note that the only new process is the
one created by init (using the
fork system call); getty
and login only replace the program running in
the process (using the exec 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.
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 getty
and 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-ins,
you probably don't have to worry about getty,
but init is still important. Logins via the networkTwo 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 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 getty
for each potential login. There is a single process inetd (corresponding to
getty) that handles 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 telnet and
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
inetd;
see the Linux Network Administrators' Guide
for more information. What <command>login</command> doesThe 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 /etc/motd (short for message of the
day) and checking for electronic mail. These can be disabled
by creating a file called .hushlogin in
the user's home directory. If the file /etc/nologin
exists, logins are disabled. That file is typically
created by shutdown and relatives.
login checks for this file, and will
refuse to accept a login if it exists. If it does exist,
login outputs its contents to the terminal
before it quits. login logs all failed login attempts in
a system log file (via syslog). It also logs
all logins by root. Both of these can be useful when tracking
down intruders. Currently logged in people are listed in
/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 who, w,
and other similar commands look in utmp
to see who are logged in. All successful logins are recorded into
/var/log/wtmp. This file will grow without
limit, so it must be cleaned regularly, for example by having
a weekly cron job to clear it.
The last command browses
wtmp. Both utmp and
wtmp are in a binary format (see the
utmp manual page); it is unfortunately not
convenient to examine them without special programs. X and xdm XXX X implements logins via xdm; also: xterm -ls TO BE ADDEDAccess control The user database is traditionally contained in the
/etc/passwd file. Some systems use
shadow passwords, and have moved the
passwords to /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 cryptographic 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 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
guessed. The crack program can be used
to crack passwords; any password it can find is by definition
not a good one. While crack can be run
by intruders, it can also be run by the system administrator
to avoid bad passwords. Good passwords can also be enforced
by the passwd 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
/etc/group; for systems with shadow
passwords, there can be a /etc/shadow.group.
root usually can't login via most terminals
or the network, only via terminals listed in the
/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 su command to become root. 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 (/bin/sh) and its derivatives
execute /etc/profile; in addition,
they execute .profile in the user's
home directory. /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, .profile allows the user to customize
the environment to his own tastes by overriding, if necessary,
the default environment.