Describes what happens when a user logs on and logs off. More detailed description of the background process of various interactions, log files, configuration files, etc.
Login via terminal
First, Init confirms that a Getty program is provided to a terminal connection (or console). The Getty listening terminal waits for the user to tell it to log on (which usually means that the user must type something). When it notices a user, Getty outputs a welcome message (existing in/etc/issue), prompts the username, and finally runs the login program. Login takes the user name as a parameter and prompts the user for a password. If correct, login launches the shell set for this user, otherwise exits and terminates the process (possibly after giving the user a second chance to enter the username and password). Init notices that the process terminates and starts a new Getty for the terminal.
Note that the only new process is generated by Init (called by the fork system); Getty and login are only programs that run as an alternative to the process (using the exec system call).
For the attention of the user, the serial line requires a separate program because terminal activity can (and is) become complex. Getty also adapts to the speed of the connection and other settings, which is especially important for dial-up connections because the parameters of the connection and connection may be different.
Getty and Init have multiple versions in use, each with its own pros and cons. It's a good idea to learn about the versions of your system and other versions (you can use Linux Software map to find them.) If you don't dial in, you may not have to consider Getty, but Init is still important.
Log on over the network
2 computers in a network are usually connected by a physical cable. When they communicate through the network, the program in each computer that participates in communication communicates through virtual connection, that is, some fictitious cable. Virtual connection to each end of the program, exclusive of their (virtual) cable. However, since this cable is not true, it is fictitious, and the operating system of all computers can have more than one virtual connection on the same physical cable. This way, with only one cable, multiple programs can communicate with each other without having to consider other communications. Use the same cable to make multiple computers possible; a virtual connection exists between 2 computers, and other computers ignore connections they do not participate in.
That is a complex and abstract description of the truth. But it may be enough to understand the important reasons why a network login differs from a normal login. Virtual connections are established when 2 programs on different computers want to communicate. Because it is theoretically possible to log on to any computer from any computer on the network, there may be a significant number of potential virtual communications. Therefore, it is unrealistic to start a Getty for each potential login.
There is a process inetd (coordinated with Getty) to handle all network logins. When it finds an incoming network login (that is, it discovers a new virtual connection from another computer), it initiates a new process to process the login. The original process continues to listen for new logins.
More complicated, there are multiple communication protocols for network logins. The 2 most important protocols are Telnet and rlogin. In addition to logging in, there are many other virtual connections that may be established (for FTP, Gopher, HTTP, and other network services). It is not very efficient to provide a process for each type of connection to listen for, so only one listener is used to identify the type of connection, and the correct program can be started to provide the service. This listener is called inetd; see the Linux Network Administration Guide for more information.
What did login do?
Login program is responsible for authenticating the user (confirm username and password match), and establish serial line, launch shell, build user's initial environment.
The partial initialization settings are the contents of the output file/ETC/MOTD (Short message per day) and check the email. A file called. Hushlogin can be created in the user's home directory to be the failure described above.
If there is a file/etc/nologin, logon is not allowed. This document is generally produced by shutdown and its related things. Login checks this file and rejects the login if the file exists. If the file does exist, login will output its contents to the terminal before exiting.
Login attempts to register all failed logins in the system log file (via Syslog). It also registers all of the root logins. These are useful for tracking intruders.
The user currently logged on is listed in/var/run/utmp. This file does not work until the next time the system starts or shuts down. It was emptied when the system was just started. It lists the terminals (or network connections) used by each user and user, and some useful information. Who, W, and other similar commands view the utmp file to get who is logged in.
All successful logins are recorded in the/var/log/wtmp. This file will grow indefinitely, so there must be regular cleanup, such as a weekly cron task to clear it. The last command browses the wtmp file.
Utmp and wtmp are binary formats (see Utmp's man page); Unfortunately, no special programs are available to view them.
X and XDm
META:X implements logins via XDm; Also:xterm-ls
Access control
The user database is traditionally included in the/etc/passwd file. Some systems use shadow passwords to shadow passwords and move passwords to/etc/shadow. Many computers can share accounts using NIS or other methods that store user databases, and they may also automatically replicate the database from a central location to all other computers.
The user database contains not only passwords but also other information about the user, such as its real name, home directory, login shell, and so on. This other information needs to be public so that everyone can read it. The password is therefore encrypted and saved. This has the disadvantage, anyone obtains the encrypted password, may use the different encryption method to guess the password, but does not have to try to actually log on to the computer. Shadow password attempts to use the password to move to other files to avoid this situation, only root can read (password or encrypted). However, installing shadow passwords later onto a system that did not support them can be difficult.
Regardless of the password, it is important to confirm that all passwords in the system are good, that is, not easy to guess. Crack programs can be used to crack passwords, and any passwords that can be precisely found are not good passwords. The crack can also run for intruders and can be run by system administrators to avoid bad passwords. A good password can also be enforced by the passwd program, which is effective for CPU cycles because it takes a lot of computing to crack a password.
The user group database is stored in the/etc/group file, and the system with the shadow password is/etc/shadow.group.
Root is not normally logged on through more terminals or networks, only through terminals listed in the/etc/securetty file. This makes it necessary to physically access one of these terminals. It is also possible to log in with any support through any terminal, and then use the SU command to become root.
Shell Startup
When an interactive login shell is started, it automatically executes one or more predefined files. Different shells execute different files; More information is found in each shell's documentation.
Most shells run some global files first, such as the Bourne Shell (/bin/sh) and the/etc/profile it leads to execution, and they execute. Profile in the user's home directory. /etc/profile allows system administrators to establish a common user environment, especially path creation, to include a local command directory. In addition, profile allows the user to cover the environment according to their own tastes, if necessary, using the environment.