The program /etc/init finishes the task of starting up the computer system and lets users log in.

Some Unix systems can be booted in single-user mode . If Unix is booted in single-user mode, the init program forks and runs the standard Unix shell, /bin/sh, on the system console. This shell, run as superuser, gives the person sitting at the console total access to the system. It also allows nobody else access to the system; no network daemons are started unless root chooses to start them.

Some systems can be set up to require a password to boot in single-user mode, while others cannot. Many Unix systems will require a password if the console is not listed as a secure device in the /etc/ttys or /etc/securetty file. Some Sun Microsystems and Macintosh workstations will also accept a password specified using the ROM boot monitor under the Open Firmware standard, rather than reading from the file. This is a useful feature if the /etc/passwd file is deleted—the only way to rebuild it would be to bring the computer up in single-user mode.

Single-user mode is also a security hole because it allows unprivileged people to execute privileged commands simply by typing them on the system console. Computers that can be brought up in single-user mode should have their consoles in a place that is physically secure. This may be a challenge if the system is a workstation, and that is why the ROM password is useful.

Some Unix systems can also be booted in a maintenance mode . Maintenance mode is similar to single-user mode, except that the root password must first be typed on the system console.

In normal operation, /etc/init then executes the shell script /etc/rc. Depending on which version of Unix you are using, /etc/rc may execute a variety of other shell scripts whose names all begin with /etc/rc (common varieties include /etc/rc.network and /etc/rc.local) or which are located in the directory /etc/init.d or /etc/rc?.d. System V systems additionally use the file /etc/inittab to control what is done at various run levels. The /etc/rc script(s) set up the Unix system as a multiuser system, performing a variety of tasks, including:

When /etc/rc finishes executing, /etc/init forks a new process for every enabled terminal on the system. On older systems, this program is called /etc/getty. On newer systems, including SVR4, it is called /usr/lib/saf/ttymon. On systems that support virtual consoles, such as Linux, a version of getty (often called mingetty) will be run for each virtual console as well.

The getty or ttymon program is responsible for configuring the user terminal and displaying the initial prompt. A copy of the program is run for each port that is monitored. Whenever the process dies, init starts another one to take its place. If the init process dies, Unix halts or reboots (depending on the version of Unix installed).

The getty or ttymon program displays the word login: (or a similar prompt) on its assigned terminal and waits for a username to be typed. When it gets a username, getty/ttymon execs the program /bin/login, which asks for a password and validates it against the password stored in /etc/passwd. If the password does not match, the login program asks for a new username/password combination.

Some versions of Unix can be set up to require an additional password if you are trying to log into the computer over a modem. See the reference page for your login program for details.

If you do not log in within a short period of time (usually 60 seconds), or if you make too many incorrect attempts, login exits and init starts up a new getty/ttymon program on the terminal. On some systems equipped with modems, this causes the telephone to hang up. Again, this strategy is designed to deter an unauthorized user from breaking into a Unix system by making the task more difficult: after trying a few passwords, an attacker attempting to break into a Unix system is forced to redial the telephone.

If the username and password match, the login program performs some accounting and initialization tasks, then changes its real and effective UIDs be those of the username that has been supplied. login then execs your shell program. The process number of that shell is the same as the original getty. /etc/init receives a SIGCHLD signal when this process dies; /etc/init then starts a new getty or ttymon.

On Berkeley-derived systems, the file /etc/ttys or /etc/ttytab contains a line for each terminal that will have a getty/ttymon process enabled. It also contains information on terminal type, if known, and an indication of whether the line is “secure.” The root user cannot log into a terminal that is not secure; to become the superuser on one of these lines, you must first log in as yourself, then use the su command. Unless all your terminal lines are in protected areas, turning off “secure” on all lines is a good precaution.

Network logins are typically provided by the telnetd, rshd, or sshd programs. These programs listen for a network connection. (Systems that use the inetd Internet daemon split this functionality; the connection is accepted by inetd and then immediately passed to the telnetd or rshd daemon.) When the connection is accepted, they obtain the username and the password of the user and start the user’s shell.

As the last part of the login process, the Unix system starts up the user’s shell, as specified in the /etc/passwd file. The shell then reads a series of startup commands from a variety of different files, depending on which shell you are using and which flavor of Unix is running.

If the user’s shell is /bin/sh (the Bourne shell) or /bin/ksh (the Korn shell), the shell will execute all of the commands stored in a special file named .profile in your home directory. (On many systems, /bin/sh and /bin/ksh will also execute the commands stored in the system-wide /etc/profile or /usr/lib/profile files.)

If the user’s shell is /bin/csh (the C shell), Unix will execute all of the commands stored in the .cshrc file in your home directory. The C shell will then execute all of the commands stored in the .login file in the user’s home directory. When the user logs out, the commands in the .logout file will be executed.

Because these files are automatically run when the user logs in, they can present a security problem: if an intruder were to modify the files, the end result would be the same as if the intruder typed commands at your keyboard every time the user logged in! Thus, startup files need to be protected so that an intruder cannot write to the files or replace them with other files. Chapter 6 explains how to protect your files.

Once the shell is running, it takes input, parses it into words and arguments, and performs the fork/exec operations we described earlier. When you type an exit command, or type Ctrl-D to signify the end of input, the shell performs any final cleanup operations and exits. The underlying process terminates, and the init process may then fork a replacement process to listen for user input.