5.1 Lesson 1

The User and Group Identifiers (UIDs/GIDs) are the basic, enumerated references to accounts. Early implementations were limited 16-bit (values 0 to 65535) integers, but 21st century systems support 64-bit UIDs and GIDs. Users and groups are enumerated independently, so the same ID can stand for both a user and group.

Every user has not only an UID, but also a primary GID. The primary GID for a user can be unique to that user alone, and may end up not being used by any other users. However, this group could also be a group shared by numerous users. In addition to these primary groups, each user can be member of other groups, too.

By default on Linux systems, every user is assigned to a group with the same name as their username, and same GID as his UID. E.g., create a new user named newuser and, by default, its default group is newuser as well.

On Linux the superuser account is root, which always has UID 0. The superuser is sometimes called the system administrator, and has unlimited access and control over the system, including other users.

The default group for the superuser has the GID 0 and is also named root. The home directory for the superuser is a dedicated, top level directory, /root, only accessible by the root user himself.

All accounts other than root are technically regular user accounts, but on a Linux system the colloquial term user account often means a “regular” (unprivileged) user account. They typically have the following properties, with select exceptions:

If a user account does not have a valid shell in their attributes, the user will not be able to open an interactive shell. Usually /sbin/nologin is used as an invalid shell. This may be purposeful, if the user will only be authenticated for services other than console or SSH access, e.g., Secure FTP (sftp) access only.

System accounts are typically pre-created at system installation time. These are for facilities, programs and services that will not run as the superuser. In an ideal world, these would all be operating system facilities.

The system accounts vary, but their attributes include:

Most system accounts on Linux will never login, and do not need a defined shell in their attributes. Many processes owned and executed by system accounts are forked into their own environment by the system management, running with the specified, system account. These accounts usually have limited or, more often than not, no privileges.

In general, the system accounts should not have a valid login shell. The opposite would be a security issue in most cases.

Service accounts are typically created when services are installed and configured. Similar to system accounts, these are for facilities, programs and services that will not run as the superuser.

In much documentation, system and service accounts are similar, and interchanged often. This includes the location of home directories typically being outside of /home, if defined at all (service accounts are often more likely to have one, compared to system accounts), and no valid login shell. Although there is no strict definition, the primary difference between system and service accounts breaks down to UID/GID.

Some Linux distributions still have pre-reserved service accounts under UID <100, and those could be considered a system account as well, even though they are not created at system installation. E.g., on Fedora-based (including Red Hat) Linux distributions, the user for the Apache Web server has UID (and GID) 48, clearly a system account, despite having a home directory (usually at /usr/share/httpd or /var/www/html/).

Some accounts have a login shell, while others do not for security purposes as they do not require interactive access. The default login shell on most Linux distributions is the Bourne Again Shell, or bash, but other shells may be available, like the C Shell (csh), Korn shell (ksh) or Z shell (zsh), to name a few.

A user can change his login shell using the chsh command. By default the command runs in interactive mode, and displays a prompt asking which shell should be used. The answer should be the full path to the shell binary, like below:

You can also run the command in non-interactive mode, with the -s parameter followed by the path to the binary, like so:

Most accounts have a defined home directory. On Linux, this is usually the only location where that user account has guaranteed write access, with some exceptions (e.g., temporary file system areas). However, some accounts are purposely setup to not have any write access to even their own home directory, for security purposes.

The file /etc/passwd is commonly referred to as the “password file”. Each line contains multiple fields always delimited by a colon (:). Despite the name, the actual one-way password hash is nowadays not stored in this file.

The typical syntax for a line on this file is:

Where:

For example, the following line describes the user emma:

The /etc/group file contains fields always delimited by a colon (:), storing basic information about the groups on the system. It is sometimes called the “group file”. The syntax for each line is:

Where:

The example below shows a line containing information about the students group:

The user does not need to be listed in the members field when the group is the primary group for a user. If a user is listed, then it is redundant — i.e., there is no change in functionality, listed or not.

The following table lists the attributes stored in the file /etc/shadow, commonly referred to as the “shadow file”. The file contains fields always delimited by a colon (:). Although the file has many fields, most are beyond the scope of this lesson, other than the first two.

The basic syntax for a line on this file is:

Where:

In the example below you can see a sample entry from the /etc/shadow file. Note that some values, like INACTIVE and EXPDATE are undefined.

The “epoch” of a POSIX system is midnight (0000), Universal Coordinate Time (UTC), on Thursday, January 1st, 1970. Most POSIX dates and times are in either seconds since “epoch”, or in the case of the file /etc/shadow, days since “epoch”.

Although different authentication solutions exist, the elementary method of password storage is the one-way hash function. This is done so the password is never stored in clear-text on a system, as the hashing function is not reversible. You can turn a password into a hash, but (ideally) it is not possible to turn a hash back into a password.

At most, a brute force method is required to hash all combinations of a password, until one matches. To mitigate the issue of a password hash being cracked on one system, Linux systems use a random “salt” on each password hash for a user. So the hash for a user password on one Linux system will usually not be the same as on another Linux system, even if the password is the same.

In the file /etc/shadow, the password may take several forms. These forms typically include the following:

The hash function, hash salt and hash string are preceded and delimited by a dollar symbol ($). The hash salt length must be between eight and sixteen (8-16) characters. Examples of the three most common are as follows:

From the standpoint of the LPI Linux Essentials objectives and exam, just understand the password hash for a local user is only stored in the file /etc/shadow which only select, authentication services can read, or the superuser can modify via other commands.