The /etc/passwd Linux File - Full description

/etc/passwd Linux File Manual

The /etc/passwd file stores the user’s login, encrypted password entry, UID, default GID, name (sometimes called GECOS), home directory, and login shell. Each line in the file represents information about a user. The lines are made up of various standard fields, with each field delimited by a colon. A sample entry from a passwd file with its various fields is illustrated in Figure 1. The fields of the /etc/passwd file are discussed in detail in the sections that follow.



Fields of the /etc/passwd file

Figure 1   Fields of the /etc/passwd file

Username Field

This field is also referred to as the login field or the account field. It stores the name of the user on the system. The username must be a unique string and uniquely identifies a user to the system. Different sites use different conventions for generating human user login names.

A common method is to use the first letter of the user’s first name and append the user’s last name. This usually works, because the chances are relatively slim that an organization would have several users with the same first and last names. For example, for a user whose first name is “Ying” and whose last name is “Yang,” a username of “yyang” can be assigned. Of course, several variations of this method are also used.

Password Field

This field contains the user’s encrypted password. On most modern Linux systems, this field contains a letter x to indicate that shadow passwords are being used on the system (discussed further on, in this chapter). Because security is important, every regular user or human account on the system should have a good and secure password.

Passwords and Encryption

Most GNU/Linux distributions use modern encryption algorithms (such as Blowfish, SHA-512, and so on) to encrypt and store passwords on the system. Overall, the stronger and better encryption algorithms have increased the complexity and difficulty involved in cracking passwords. Of course, all of this only works assuming that your end users choose good passwords to begin with!

The process works as follows: When users enter their passwords at a login prompt, the password they enter is encrypted. The encrypted value is then compared against the user’s password/shadow entry. If the two encrypted values match, the user is allowed to log into the system.

 

TIP  

Choosing good passwords is always a chore. Your users will inevitably ask, “What then, O’ Mighty System Administrator, makes a good password?” Here’s a good answer: a nonlanguage word (not English, not Spanish, not Yoruba; in fact, not a human-language word), preferably with mixed case, numbers, punctuation, and high entropy—in other words, a string that looks like line noise.

Well, this is all nice and wonderful, but if a password is too hard to remember, most people will quickly defeat its purpose by writing it down and keeping it in an easily accessible location. So better make it memorable! A good technique might be to choose a phrase and then pick the first letter of every word in the phrase. Thus, the phrase “coffee is VERY GOOD for you and me” becomes ciVG4y&m. The phrase is memorable, even if the resulting password isn’t! The shadow password configuration file, /etc/login.defs, can used to configure and enforce various password parameters.

User ID Field (UID)

This field stores a unique number that the operating system and other applications use to identify the user and determine access privileges. It is the numerical equivalent of the Username field. The UID should be unique for every user.

The UID zero (0) is extra special and usually reserved for the root user. Any user who has a UID of 0 has root (administrative) access and thus has the full run (control) of the system. It is considered bad practice to allow any other users or usernames to have a UID of 0.

Different Linux distributions sometimes adopt specific UID numbering schemes. For example, newer Fedora and Red Hat Enterprise Linux (RHEL), openSUSE and Ubuntu distros reserve the UID 65534 for the user “nobody”.

Group ID Field (GID)

The next field in the /etc/passwd file is the group ID entry. It is the numerical equivalent of the primary group to which the user belongs. This field also plays an important role in determining user access privileges. It should be noted that in addition to a primary group, a user can belong to other groups as well (more on this later in the section “The /etc/group File”).

GECOS

This field can store various pieces of information for a user. It can act as a placeholder for the user description, full name (first and last name), telephone number, and so on. This field is optional and as a result can be left blank. It is also possible to store multiple entries in this field by simply separating the different entries with a comma.

NOTE  

Of historical note, GECOS is an acronym for General Electric Comprehensive Operating System (now referred to as GECOS) and is a carryover from the early days of computing.

Directory

This is usually the user’s home directory, but it can also be any arbitrary location on the system. Each user who actually logs into the system needs a place for configuration files that are unique to that user. Along with configuration files, the directory (often referred to as the home directory) also stores the user’s personal data such as documents, code, music, photos, and so on.

The home directory allows each user to work in an environment that he or she has specifically customized—without having to worry about the personal preferences and customizations of other users.

Startup Scripts

Startup scripts are not quite a part of the information stored in the users’ database in Linux, but they nonetheless play an important role in determining and controlling a user’s environment. In particular, the startup scripts in GNU/Linux are usually stored under the user’s home directory, and hence the need to mention them while we’re still on the subject of the directory (home directory) field in the /etc/passwd file.

Each user is allowed to have his or her own configuration files; thus, the system appears to be customized for each particular user (even if other people are logged in at the same time). The customization of each individual user environment is done through the use of shell scripts, initialization files, run control files, and the like. These files can contain a series of commands to be executed by the shell that starts when a user logs in. In the case of the Bash shell, for example, one of its startup files is the .bashrc file. (Yes, there is a period in front of the filename—filenames preceded by periods, also called dot files, are hidden from normal directory listings.) The .bashrc script is similar in nature to the autoexec.bat batch file in the Windows world.

Various Linux software packages use application-specific and customizable options in directories or files that begin with a dot (.) in each user’s home directory. Some examples are .mozilla, .kde, .local, .ssh, and .ansible.cfg. Here are some common dot files that may be present in each user’s home directory:

  • .bashrc and .profileConfiguration files for the Bash shell.
  • .tcshrc and .loginConfiguration files for tcsh.
  • .xinitrcThis script overrides the default script that gets called when you log into the X Window System.
  • .XdefaultsThis file contains defaults that you can specify for X Window System applications.

When you create a user’s account, a set of default dot files are also created for the user; this is mostly for convenience, to help get the user started. The user management tools discussed later in this chapter help you do this automatically. The default or template files that are used to initially populate new user home directories are stored under the /etc/skel directory.

For the sake of consistency, most sites place home directories at /home and name each user’s directory by that user’s login name. Thus, for example, if your login name were “yyang,” your home directory would be /home/yyang. The exception to this is for some special system accounts, such as a root user’s account or a system service. The superuser’s (root’s) home directory in Linux is usually set to /root. An example of a special system service account that might need a specific working directory could be a web server whose web pages are served from the /var/www/ directory.

In Linux, the decision to place home directories under /home is strictly arbitrary, but it does make organizational sense. The system really doesn’t care where we place home directories, so long as the location for each user is specified in the password file.

Shell

When users log into the system, they expect an environment that can help them be productive. When logged in at the command line, the first program that users encounter is called a shell. If you’re used to the Windows side of the world, you might equate this with command.com (cmd), Program Manager, PowerShell, or Windows Explorer.

Under GNU/Linux, most shells are text-based. A popular default user shell in Linux is the Bourne Again Shell, or Bash for short. Linux comes with several shells from which to choose—you can see most of them listed in the /etc/shells file. Deciding which shell is right for you is kind of like choosing a favorite tea or beer—what’s right for you isn’t right for everyone, but still, everyone tends to get defensive about their choice!

Interestingly enough, you are not limited only to the list of shells declared in /etc/shells. In the strictest of definitions, the password entry for each user doesn’t list what shell to run so much as it lists what program to run first for the user. Of course, most users prefer that the first program run be a shell, such as Bash.

 

 

Вас заинтересует / Intresting for you:

Understanding Linux security: ...
Understanding Linux security: ... 349 views Zero Cool Sat, 17 Jul 2021, 06:52:25
Deploying Linux Servers in the...
Deploying Linux Servers in the... 949 views Mike Thu, 11 Feb 2021, 20:02:23
Choosing the right Linux distr...
Choosing the right Linux distr... 239 views Zero Cool Wed, 14 Jul 2021, 19:26:27
Understanding the differences ...
Understanding the differences ... 977 views Mike Sun, 07 Feb 2021, 18:50:31