Redhat Linux 9: tìm hiểu cấu trúc /etc/passwd và /etc/shadown

Link playlist
Red Hat Enterprise Linux Administration
https://www.youtube.com/playlist?list=PLIpLw6v7Z1qnIUiJipjgYEHwxF16TZbCN

2023 11 05 13 16 18
Creating and Managing User Accounts
Now that you know how to perform tasks as either an
administrative user or a nonadministrative user, it is time to
learn how to manage user accounts on Linux. In this section,
you learn what is involved.
System Accounts and Normal Accounts
A typical Linux environment has two kinds of user accounts.
There are normal user accounts for the people who need to
work on a server and who need limited access to the resources
on that server. These user accounts typically have a password
that is used for authenticating the user to the system. There are
also system accounts that are used by the services the server is
offering. Both types of user accounts share common properties,
which are kept in the files /etc/passwd and /etc/shadow.
Note
On many Linux servers, hardly any user accounts
are used by people. Many Linux servers are
installed to run a specific service, and if people
interact with that service, they will authenticate
within the service.
As you can see in Example 6-2, to define a user account,
different fields are used in /etc/passwd. The fields are separated
from each other by a colon. The following is a summary of these
fields, followed by a short description of their purpose.
Username: This is a unique name for the user. Usernames
are important to match a user to their password, which is
stored separately in /etc/shadow (see next bullet). On Linux,
there can be no spaces in the username, and in general it’s a
good idea to specify usernames in all lowercase letters.
Password: In the old days, the second field of /etc/passwd
was used to store the hashed password of the user. Because
the /etc/passwd file is readable by all users, this poses a
security threat, and for that reason on current Linux systems
the hashed passwords are stored in /etc/shadow (discussed in
the next section).
UID: Each user has a unique user ID (UID). This is a numeric
ID. It is the UID that really determines what a user can do.
When permissions are set for a user, the UID (and not the
username) is stored in the file metadata. UID 0 is reserved for
root, the unrestricted user account. The lower UIDs (typically
up to 999) are used for system accounts, and the higher UIDs
(from 1000 on by default) are reserved for people who need
to connect a directory to the server. The range of UIDs that
are used to create regular user accounts is set in
/etc/login.defs.
GID: On Linux, each user is a member of at least one group.
This group is referred to as the primary group, and this group
plays a central role in permissions management, as discussed
later in this chapter. Users can be a member of additional
groups, which are administered in the file /etc/group.
Comment field: The Comment field, as you can guess, is used
to add comments for user accounts. This field is optional, but
it can be used to describe what a user account is created for.
Some utilities, such as the obsolete finger utility, can be used
to get information from this field. The field is also referred to
as the GECOS field, which stands for General Electric
Comprehensive Operating System and had a specific purpose
for identifying jobs in the early 1970s when General Electric
was still an important manufacturer of servers.
Directory: This is the initial directory where the user is
placed after logging in, also referred to as the home directory.
If the user account is used by a person, this is where the
person would store their personal files and programs. For a
system user account, this is the environment where the
service can store files it needs while operating.
Shell: This is the program that is started after the user has
successfully connected to a server. For most users this will be
/bin/bash, the default Linux shell. For system user accounts,
it will typically be a shell like /sbin/nologin. The
/sbin/nologin command is a specific command that silently
denies access to users (to ensure that if by accident an
intruder logs in to the server, the intruder cannot get any
shell access). Optionally, you can create an /etc/nologin.txt
file, in which case only root will be able to log in but other
users will see the contents of this file when their logins are
denied.
A part of the user properties is stored in /etc/passwd, which was
just discussed. Another part of the configuration of user
properties is stored in the /etc/shadow file. The settings in this
file are used to set properties of the password. Only the user
root and processes running as root have access to /etc/shadow.