Библиотека сайта rus-linux.net
7.2. Design
7.2.1. The login process
The From-Powerup-To-BASH-Prompt-HOWTO does a good job of outlining the steps in the login process. Basically it works like this.
The init daemon starts a getty process on the terminal.
The getty program displays the contents of
/etc/issueand prompts for a user name.When the user name is entered, control is handed off to the login program.
The login program asks for a password and verifies the credentials using
/etc/passwd,/etc/groupand possibly/etc/shadow.If everything is okay the user's shell is started.
7.2.2. Obtaining source code
The getty and login programs were already installed as part of the util-linux package so there is no need to download any new source code.
7.2.3. Creating support files
7.2.3.1. Device nodes
Details about virtual console device files can be found in the
Linux kernel source code file called devices.txt
in the Documentation directory. We will need to
create tty1 through tty6 for
each of the virtual consoles as well as tty0 and
tty to represent the current virtual
console.
7.2.3.2. /etc/issue
The /etc/issue file is pretty easy to
construct. It can contain any text we want displayed on the screen
prior to the login prompt. It could be something friendly like
"Welcome to Pocket Linux", something menacing like "Authorized users
only!" or something informational like "Connected to tty1 at 9600bps".
The agetty(8) manpage explains how to display information like tty
line and baud rate using escape codes.
7.2.3.3. /etc/passwd
The format of /etc/passwd can be obtained
by reading the passwd(5) manpage. We can easily create a user account
by adding a line like "root::0:0:superuser:/root:/bin/sh" to the
file.
Maintaining passwords will be somewhat challenging because of
the system being loaded into ramdisk. Any changes to
/etc/passwd will be lost when the system is
shutdown. So to make things easy, we will create all users with null
passwords.
7.2.3.4. /etc/group
The structure of /etc/group is available
from the group(5) manpage. A line of "root::0:root" would define a
group called "root" with no password, a group id of zero and the user
root assigned to it as the only member.
7.2.3.5. Conventions
User and group names and id's are generally not chosen at
random. Most Linux systems have very similar looking
/etc/passwd and /etc/group
files. Definitions for commonly used user id and group id assignments
may be found in one of several places:
The
/etc/passwdand/etc/groupfiles on any popular GNU/Linux distribution.The Debian Policy Manual -- available online at http://www.debian.org/doc/debian-policy.
The Linux Standard Base specification -- downloadable in many formats from http://www.linuxbase.org/spec/index.shtml.
Essential System Administration, 3rd Edition by Aeleen Frisch -- available at libraries, bookstores or directly from O'Reilly Publishing at http://www.oreilly.com/.
7.2.4. Dependencies
Running ldd on the login
program from util-linux will reveal that it is linked to the libraries
libcrypt.so.1, libc.so.6 and
ld-linux.so.2. In addition to these libraries there
is another, unseen dependency on libnss_files.so.2
and the configuration file
/etc/nsswitch.conf.
The name service switch library
libnss_files.so.2 and
nsswitch.conf are required for
libc.so.6, and consequently the
login program, to access the
/etc/passwd file. Without libnss and its
configuration file, all logins will mysteriously fail. More information
about glibc's use of the name service switch libraries can be found at
http://www.gnu.org/software/libc/manual/html_node/Name-Service-Switch.html.
7.2.5. Assigning ownership and permissions
Previously, with the single user system, there was no need to worry about permissions when installing directories, files and device nodes. The shell was effectively operating as root, so everything was accessible. Things become more complex with the addition of multiple user capability. Now we need to make sure that every user has access to what they need and at the same time gets blocked from what they do not need.
A good guideline for assigning ownership and permissions would be
to give the minimum level of access required. Take the
/bin directory as an example. The Filesystem
Hierarchy (FHS) document says, "/bin contains
commands that may be used by both the system administrator and by
users". From that statement we can infer that /bin
should have read and execute permission for everyone. On the other hand,
the /boot directory contains files for the boot
loader. Chances are good that regular users will not need to access
anything in the /boot directory. So the minimum
level of access would be read permission for the root user and other
administrators who are members of the root group. Normal users would
have no permissions assigned on the /boot
directory.
Most of the time we can assign similar permissions to all the commands in a directory, but there are some programs that prove to be exceptions to the rule. The su command is a good example. Other commands in the /bin directory have a minimum requirement of read and execute, but the su command needs to be setuid root in order to run correctly. Since it is a setuid binary, it might not be a good idea to allow just anyone to run it. Ownership of 0:0 (root user, root group) and permissions of rwsr-x--- (octal 4750) would be a good fit for su.
The same logic can be applied to other directories and files in the root filesystem using the following steps:
Assign ownership to the root user and root group.
Set the most restrictive permissions possible.
Adjust ownership and permissions on an "as needed" basis.