How Linux Stores User Account Information

As you ve seen, the User Manager makes it really easy to create user accounts and groups, and to define group membership. Having seen it in action, it s a good time to see where account information is stored in the filesystem. By taking a quick look at these files, you ll get a better understanding of what you achieved in the preceding examples, and it will prepare you for using the command line tools that you ll see later in this chapter.

Linux stores its local user account information in the text configuration files shown in the following table.

Configuration File	Purpose
/etc/passwd	Contains a list of local users and their data
/etc/shadow	Contains encrypted passwords and bookkeeping information such as account expiry
/etc/group	Defines groups and associated accounts

Note	There is a fourth file, /etc/gshadow , that we will not cover extensively here. It stores encrypted group passwords. You can find out more by reading the HOWTO file on this subject, which (in the current release) can be found at /usr/share/doc/shadow- utils -*/HOWTO .

User Accounts and Their Properties

To examine in better detail the properties of a user account on your system, you can take a look at your /etc/passwd file (using a text editor such as gedit or a CLI command such as cat ). The /etc/passwd file is essentially the user account database in which Linux stores valid accounts and related information about these accounts.

The following example includes details of the accounts we just created using the User Manager. Your /etc/passwd file will be similar in structure to the file excerpt shown here, although the exact details may be a little different:

   root:x:0:0:Super User:/root:/bin/bash     halt:x:7:0:Stop the System:/sbin:/sbin/halt     eziodm:x:500:500:Pancrazio 'Ezio' de Mauro:/home/eziodm:/bin/bash     kapils:x:501:501:Kapil Sharma:/home/kapils:/bin/bash     deepakt:x:502:502:Deepak Thomas:/home/deepakt:/bin/bash

Each line of the /etc/passwd file is a single record in the user database and represents a single user. The administrator (root) account is usually the first user account defined in the file; it s followed by a number of system accounts , and finally the ordinary user accounts (such as the eziodm, kapils, and deepakt accounts here).

Each record is composed of a number of fields , which describe the properties of the user account. In this file, adjacent fields are separated by a colon (:). To get a better understanding of the purpose of each field, let s look, for example, at the third record (see Figure 7-10).

Figure 7-10

The first field contains the username (also known as the account name or login name ). When the user logs in, submitting a username, Linux looks up the specified username in this table. Usernames usually begin with an alphabetic character, and can be up to 32 characters long, although some older programs can accept only the first eight characters .

In fact, the eight-character limit for account names is a historic UNIX thing. Sticking to this maximum length is still considered the safest choice, especially when networking with older UNIX computers.

The second field contains a placeholder for the password . In older versions of Linux, this field used to contain an encrypted version of the password itself. For reasons of security, passwords are now stored in the /etc/shadow file (they re still stored in encrypted form); we ll return to this issue in the next section.
The third field contains the account s user identification number (UID) . The UID identifies the user account ”each UID is unique to exactly one account within the system. In Fedora Core, UIDs below 500 are reserved for system accounts. For example, the UID 0 (zero) is reserved for the super user, root. If the UID 0 is assigned to another account, it will grant administration rights to that account. Needless to say, that is a very dangerous thing to do.

The fourth field contains the group identification number (GID) of the account s primary group . A GID is unique to exactly one group within the system. An account belongs to at least one group (and it may belong to more than one), but the one specified here is the primary group with which the user is associated (and is usually the private group you created at the same time as the account).

Once again, the GID 0 (zero) should be reserved for root, even though it s not as dangerous as the UID zero.

Note

An account s UID and primary group GID are not necessarily the same values; the preceding example is slightly special. As mentioned, UIDs and GIDs below 500 are reserved for the system; and eziodm was the first non-system account created on this machine. So, when the system created this account, it set the UID to the first available UID value (which was 500), and it assigned the GID of the associated group to the first available GID value (which was also 500).

The fifth field is the description of the user account. In general, the description can be any string. For example, when the account is for a particular person, it usually makes sense to use that person s name for the account description (like the accounts for Ezio, Deepak, and Kapil); when the account is designed to fill a specific role, a description of the role is suitable (like the halt account).

Later in the chapter, you ll see how the User Information dialog box allows users to enter a name and contact information associated to their account. When they do so, the information is stored in this field, in comma-separated format.

The sixth field contains the account s home directory . This is most commonly used for personal accounts, and provides users with a directory within which they can store their own personal files. By default, a user s home directory is created under the /home directory (for example, eziodm s home directory is /home/eziodm ), but in fact, it is possible to place a user s home directory anywhere on the system.

Note

There is one notable exception: the root account s home directory is always /root (or even / itself in old systems). This design is to ensure that the directory will be available for use even if /home is not available after booting (for example, if the /home filesystem lies on a separate partition to the rest of the filesystem, and a disk error prevents Linux from mounting it).

For an account that is associated with a function or a software program, rather than a user, the notion of using the home directory field to store personal files is somewhat lost. In this scenario, the home directory field is sometimes used to specify the directory in which the software is located, or it may point to a general location place such as the /bin directory.

The seventh and final field contains the login shell associated with the account. You saw in Chapter 6 that the shell is in charge of executing user commands. The system runs the login shell whenever you log in using text mode, or open a terminal window using graphical mode. A list of valid shells is typically kept in /etc/shells (although any program can be used as a login shell). There are programs that check the contents of /etc/shells to find out whether a user account is an ordinary account (with a shell listed in /etc/shells ) or a special account. One special account is the halt user: if you log in using the halt account and you supply the correct password, the system will initiate the shutdown sequence to switch the computer off.

You can get more information with the man 5 passwd and man 5 shells commands from your terminal window or console screen.

User Account Passwords

As it happens, any user has read access to the /etc/passwd file ”indeed, this access is handy if, for example, you need to match an account name to its UID. But as previously mentioned, older versions of Linux stored account passwords in encrypted format in the second field of the /etc/passwd file. A consequence of this was that it was easy for users to access the encrypted versions of the passwords of other users.

Initially, this was not considered a security issue because the passwords were encrypted. However, the storage of encrypted passwords in /etc/passwd is no longer considered safe; as we explain in the next subsections, techniques now exist that make it much easier to guess a user s password given its encrypted form and knowledge of the encryption algorithm.

To plug this security hole, Fedora Core stores encrypted passwords in a different file ” /etc/shadow . This file is accessible to root only. While non-root users can still read from /etc/passwd , they do not have permission to read from /etc/shadow , and thus do not have access to encrypted passwords.

Password Encryption

While the account passwords are now stored safely in the restricted access /etc/shadow file, Linux still takes the precaution of storing them in encrypted format.

If you use root privileges to examine the contents of the /etc/shadow file, you ll see each encrypted password stored as an incomprehensible string of characters, like this:

   $mWzQxFuT$EWnSiX5hmxiERbUpfwR5V0

Fedora Core never stores passwords in the clear text form in which the user enters them. Rather, it always encrypts them before storing them or working with them, in such a way that it is not easily possible (or even feasible ) to decipher the encrypted version and find out the original password.

In fact, once the password has been encrypted and stored in /etc/shadow , there will never be the need to decrypt it again. This is a key point: when a user logs in, the operating system verifies her identity by encrypting the submitted password and comparing it with the encrypted string contained in the /etc/shadow . If the two strings match, access is granted. It is this process that enables Linux to avoid ever having to decrypt passwords.

A Technique for Guessing Passwords

Unfortunately, the fact that a password is encrypted before storage is not enough to guarantee that it can t be discovered by other means. While it s very difficult to use decryption techniques to discover the original passwords, it is quite possible to use a brute force method to find out weak passwords. The power of modern computer hardware makes it possible to take large numbers of common passwords, encrypt them using the same algorithm used by the operating system, and check if the encrypted version is the same as the one stored in the password file.

This technique is often called a dictionary attack because the attacker can take large numbers of candidate passwords from a dictionary. A surprising number of passwords can be cracked in this way ”indeed, Chapter 10 takes a look at a program called crack, which uses this technique to crack passwords.

The existence of such techniques is the motivating factor behind the decision to place passwords in /etc/shadow , rather than /etc/passwd . Thus, users are prevented from stealing encrypted passwords and then trying to break the weak ones via a dictionary attack.

Note

Further discussion of cryptographic techniques is outside the scope of this chapter. However, cryptography is a fascinating science. If you re interested, you could start experimenting with the GNU Privacy Guard (GnuPG) ”install the gnupg package on your system, and then have a look at the gpg command. The gpg manual page will certainly be useful, providing information and lists of other documents.

A Sample /etc/shadow File

Examine the following few lines from a sample /etc/shadow file. This example contains the entries for the accounts added via the User Manager earlier in this chapter. Once again, your /etc/shadow will probably differ from this, although its structure will be similar:

   root:$ekA$Kv55YOaIHDcPlI1q6igoQ0:11961:0:99999:7:::     halt:*:11961:0:99999:7:::     eziodm:$W/RgbXrI$OP9t9IyVmQyvPfxNLUFwQ1:12100:0:99999:7:::     kapils:!!Q7Ci4g$CqbN8rdCBw4GmxDlouQ2q/:12100:0:99999:7:::     deepakt:$sUejrHGF$I3cSo2TRmKIbN55wfLgfB1:12100:0:99999:7:::

Just like /etc/passwd , each line (or record ) represents a user, and adjacent fields are separated by a colon. Again, to understand the purpose of the fields in this file, let s look at the third line (see Figure 7-11).

Figure 7-11

The first field contains the account name. It must match the name found in /etc/passwd .
The second field contains the encrypted password. An asterisk ( * ) here indicates that the account is disabled (that is, the user cannot log in), while a !! sequence here (followed by the original encrypted password) indicates that the account is temporarily locked.
The third field indicates the date when the password was last changed. It is expressed as the number of days elapsed since January 1, 1970. It is very typical, in systems of UNIX descent, to count the number of days or seconds since this date, also known as the epoch . In the example, you can see that eziodm s password was last changed 12,100 days after January 1, 1970.
The fourth field contains a count of the number of days before the password may next be changed. The value zero or an empty field (as in the preceding examples) means that it can be changed anytime .
The fifth field contains a count of the number of days after which the password must be changed. This default value means that the password can stay in its place for almost 274 years , which is probably long enough.
The sixth field specifies the number of days users will be warned that their password is about to expire.
The seventh field specifies after how many days the account is disabled if its owner does not change the password when requested to.
The eighth field is the date when the account will be unconditionally disabled, expressed in days since January 1, 1970.
Finally, at the end of the line is an empty field, reserved for future use.

To get more information about /etc/shadow , you can consult its manual page by typing man 5 shadow at your shell prompt.

Groups

A user can belong to many groups, but as you ve seen, /etc/passwd allows membership of only one group (the primary group ). Membership of additional groups must be specified in the /etc/groups file. This file is very similar in structure to the two you ve already seen. The following example shows the groups created earlier in this chapter:

   root:x:0:root     bin:x:1:root,bin,daemon     daemon:x:2:root,bin,daemon     eziodm:x:500:     kapils:x:501:     deepakt:x:502:     authors:x:503:eziodm,kapils,deepakt

The structure is quite simple. Let s study the second line of this file to understand the fields (see Figure 7-12).

Figure 7-12

The first field contains the group name.
The second field contains a placeholder for an optional group password . The password, if present, is stored in /etc/gshadow . Group passwords are rarely used so they aren t discussed here.
The third field contains the group identification number (GID). As previously mentioned, every group on the system must have its own unique GID. Recall that /etc/passwd refers to primary groups by number, not by name; so when it s necessary, this field is used to match a group number with its corresponding group name.
The last field contains the list of user accounts that belong to this group.

For more information about /etc/group , you can type man 5 group at your shell prompt.