Managing Users Part 1

This first part of chapter 5 “Module 5: Managing Users” covers understanding user properties and user databases. It also examines the technique of managing users for a single host. It starts by exploring the actual database files that contain information about users and moves on to the system tools available to manage the files automatically. (from the book Linux Administration, A Beginner’s Guide, third edition by Steven Graham and Steve Shah, McGraw-Hill/Osborne, ISBN:0072225629, 2002).

LinuxAdminUnder Linux, every file and program must be owned by a user. Each user has a unique identifier called a user ID (UID). Each user must also belong to at least one group, a collection of users established by the system administrator. Users may belong to multiple groups. Like users, groups also have unique identifiers called group IDs (GIDs).

The accessibility of a file or program is based on its UIDs and GIDs. A running program inherits the rights and permissions of the user who invokes it. (SetUID and SetGID, discussed in “Understand SetUID and SetGID Programs” later in this module, create an exception to this rule.) Each user’s rights can be defined in one of two ways: a normal user or the root user. Normal users can access only what they own or have been given permission to run; permission is granted because the user either belongs to the file’s group or because the file is accessible to all users. The root user is allowed to access all files and programs in the system, whether or not root owns them. The root user is often called a superuser.

If you are accustomed to Windows, you can draw parallels between that system’s user management and Linux’s user management. Linux UIDs are comparable to Windows SIDs (system IDs), for example. In contrast to Windows NT, you may find the Linux security model maddeningly simplistic: either you’re root or you’re not. Normal users cannot have root privileges in the same way normal users can be granted administrator access under NT. You’ll also notice the distinct absence of Access Control Lists (ACLs) in Linux. Which system is better? Depends on what you want and whom you ask.

In this module, we will examine the technique of managing users for a single host. Managing users over a network will be discussed in Module 19. Let’s begin by exploring the actual database files that contain information about users. From there we’ll examine the system tools available to manage the files automatically.

This chapter is from Linux Administration, A Beginner’s Guide, third edition, by Graham and Shah. (McGraw-Hill/Osborne, 2002, ISBN: 0072225629). Check it out at your favorite bookstore today. Buy this book now.

{mospagebreak title=Critical Skill 1 – Understand User Properites}

In Linux, everything has an owner attached to it. Given this, it is impossible for a Linux system to exist without users! At the very least, it needs one root user; however, most Linux distributions ship with several special users set up. These users work well as self-documentation tools since each user owns all of the files related to his or her username–for example, the user www is set up to own all files related to World Wide Web service. These users are configured in such a way that grants access only to a select few, so you do not have to worry about their abuse.

TIP: When possible, run applications without root privileges. (The Apache server, for example, knows how to give up root privileges before it starts accepting connections.) The benefit of doing this is that if an application is found to have a security problem, it cannot be exploited to gain system privileges.

A few things need to be set up for a user’s account to work correctly. In this section, we discuss those items and why they need to be there. The actual process of setting up accounts is discussed in “Utilize User Management Tools” later in the module.

Home Directories

Every user who actually logs in to the system needs a place for configuration files that are unique to the user. This place, called a home directory, allows each user to work in a customized environment without having to change the environment customized by another user—even if both users are logged in to the system at the same time. In this directory, users are allowed to keep not only their configuration files but their regular work files as well.

For the sake of consistency, most sites place home directories at /home and name each user’s directory by their login name. Thus, if your login name were sshah, your home directory would be /home/sshah. The exception to this is for system accounts, such as a root user’s account. Here, home directories are usually set to be either / or something specific to the need for that account (for example, the www account may want its home directory set to /usr/local/apache if the Apache Web server is installed). The home directory for root is traditionally / with most variants of UNIX. Many Linux installations use /root.

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 (discussed in “The /etc/passwd File” later in this module). You may see some sites use /u or break up the /home directory by department, thereby creating /home/engineering, /home/accounting, /home/admin, and so on, and then have users located under each department. (For example, Dr. Bosze from engineering would be /home/engineering/bosze.)


Every account should either have a password or be tagged as impossible to log in to. This is crucial to your system’s security—weak passwords are often the cause of a compromised system security.

The original philosophy behind passwords is actually quite interesting, especially since we still rely on a significant part of it today. The idea is simple: instead of relying on protected files to keep passwords a secret, the system would encrypt the password using an AT&T-developed (and National Security Agency–approved) algorithm called Data Encryption Standard (DES) and leave the encrypted value publicly viewable. What originally made this secure was that the encryption algorithm was computationally difficult to break. The best most folks could do is a brute force dictionary attack where automated systems would iterate through a large dictionary and rely on the nature of users to pick English words for their passwords. Many people tried to break DES itself, but since it was an open algorithm that anyone could study, it was made much more bulletproof before it was actually deployed.

When users entered their passwords at a login prompt, the password they entered would be encrypted. The encrypted value would then be compared against the user’s password entry. If the two encrypted values matched, the user was allowed to enter the system. The actual algorithm for performing the encryption was computationally cheap enough that a single encryption wouldn’t take too long. However, the tens of thousands of encryptions that would be needed for a dictionary attack would take prohibitively long. Along with the encrypted passwords, the password file could then also keep information about the user’s home directory, UID, shell, real name, and so on without having to worry about system security being compromised if any application run by any user would be allowed to read it.

But then a problem occurred: Moore’s Law on processor speed doubling every 18 months held true, and home computers were becoming fast enough that programs were able to perform a brute force dictionary attack within days rather than weeks or months. Dictionaries got bigger and the software got smarter. The nature of passwords needed to be reevaluated.

Shadow passwords were one solution. In the shadow password scheme, the encrypted password entries were removed from the password file and placed in a separate file called shadow. The regular password file would continue to be readable by all users on the system, and the actual encrypted password entries would be readable only by the root user. (The login prompt is run with root permissions.) Why not just make the regular password file readable by root only? Well, it isn’t that simple. By having the password file open for so many years, the rest of the system software that grew up around it relied on the fact that the password file was always readable by all users. Changing this would simply cause software to fail.

Another solution has been to improve the algorithm used to perform the encryption of passwords. Some distributions of Linux have followed the path of the FreeBSD operating system and used the MD5 scheme. This has increased the complexity of being able to crack passwords, which, when used in conjunction with shadow passwords, works quite well. (Of course, this is assuming you make your users choose good passwords!)

TIP:  Choosing good passwords is always a chore. Your users will inevitably ask, “What then, O Almighty System Administrator, makes a good password?” Here’s your answer: a non-language word (not English, not Spanish, not German, not human-language word), preferably with mixed case, numbers, and punctuation—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 viewed place. So better make it memorable! I prefer the technique of choosing a phrase and then picking the first letter of every word in the phrase. Thus, the phrase “coffee is VERY GOOD for you and me” becomes ciVG4yam. The phrase is memorable even if the resulting password isn’t.

This chapter is from Linux Administration, A Beginner’s Guide, third edition, by Graham and Shah. (McGraw-Hill/Osborne, 2002, ISBN: 0072225629). Check it out at your favorite bookstore today. Buy this book now.

{mospagebreak title=Shells, Startup Scripts and Mail}

When users log in to the system, they expect an environment that can help them be productive. This first program that users encounter is called a shell. If you’re used to the Windows side of the world, you might equate this to, Program Manager, or Windows Explorer (not to be confused with Internet Explorer, which is a Web browser).

Under UNIX, most shells are text based. The shell we discuss in further detail in Module 6 is the default shell for the root user, 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 beer—what’s right for you isn’t right for everyone, but, still, everyone tends to get defensive about his or her choice!

What makes UNIX so interesting is that you do not have to stick with the list of shells provided 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.

Startup Scripts

Under DOS, you are used to having the autoexec.bat and config.sys files run automatically when you start up the system. Since DOS is a single-user system, the two programs not only perform system functions such as loading device drivers, but they also set up your working environment.

UNIX, on the other hand, is a multiuser environment. Each user is allowed to have their 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 configuration file comes in the form of shell script—a series of commands executed by the shell that starts when a user logs in. In the case of BASH, it’s the file .bashrc. (Yes, there is a period in front of the filename—filenames preceded by periods, also called dot files, are hidden from normal directory listings unless the user uses a special option to list them.) You can think of shell scripts in the same light as batch files, except shell scripts can be much more capable. The .bashrc script in particular is similar in nature to that of autoexec.bat.

Most Linux/Unix software likes to store information in directories or files that begin with a . in your home directory. Some examples are .netscape and .kde. Also, there are several files that contain customizable options for some of your favorite applications:

  •  .emacs The configuration file for emacs; venture into this when you would like to start learning Lisp.
  • .bashrc/.profile Configuration files for BASH.
  • .tcshrc/.login Configuration files for tcsh.
  • .xinitrc This script overrides the default script that gets called when you log in to the X Window System.
  • .Xdefaults This file contains defaults that you can specify for X Window System applications.

To see all of the files in your home directory, simply type ls -al.

When you create a user’s account, you should provide a default set of dot files to get the user started. If you use the tools that come with Linux, you don’t need to worry about creating these files—the tools automatically do this for you. However, there is nothing stopping you from customizing these files to make them site specific. For example, if you have a special application that requires an environment variable to be set, you can add that to the dot files that are copied to the new user’s home directories.


Creating a new user means not only creating the user’s home directory and setting up the environment, it also means making it possible for the user to send and receive e-mail. Setting up a mailbox under Linux is quite easy, and if you use the tools that come with Linux to create the account, you don’t even have to do this yourself!

Mailboxes are kept in the /var/spool/mail directory. Each user has a mailbox that is based on their login name. Thus, if a user’s login is jyom, their mailbox will be /var/spool/mail/jyom. All mailboxes should be owned by their respective owners with the permissions set so that others cannot read its contents. (See the chown, chmod, and chgrp commands in Module 6 for details on how to do this.)

An empty mailbox is a zero-length file. To create a zero-length file anywhere in the system, you simply use the touch command, like so:

[root@ford /root]# touch myfile

This will create a new file called myfile in the current directory.

This chapter is from Linux Administration, A Beginner’s Guide, third edition, by Graham and Shah. (McGraw-Hill/Osborne, 2002, ISBN: 0072225629). Check it out at your favorite bookstore today. Buy this book now.

{mospagebreak title=Critical Skill 2 – Understand the User Databases}

If you’re already used to Windows 2000 user management, you’re familiar with the Active Directory tool that takes care of the nitty-gritty details of the user database. This tool is convenient, but it makes developing your own administrative tools trickier, since the only other way to read or manipulate user information is through a series of LDAP calls.

In contrast, Linux takes the path of traditional UNIX and keeps all user information in straight text files. This is beneficial for the simple reason that it allows you to make changes to user information without the need of any other tool but a text editor such as pico. In many instances, larger sites take advantage of these text files by developing their own user administration tools so that they can not only create new accounts but also automatically make additions to the corporate phone book, Web pages, and so on.

However, users and groups working with UNIX style for the first time may prefer to stick with the basic user management tools that come with the Linux distribution. We’ll discuss those tools in “Utilize User Management Tools” later in this module. For now, let’s examine how Linux’s text files are structured.

The /etc/passwd File

The /etc/passwd file stores the user’s login, encrypted password entry, UID, default GID, name (sometimes called GECOS), home directory, and login shell. The file keeps one user per line, and each entry for the user is delimited by a colon. For example:

sshah:boQavhhaCKaXg:100:102:Steve Shah:/home/sshah:/bin/tcsh

NOTE : Although modern distributions of Linux allow for logins to be longer than eight characters, it is generally considered a bad idea to do so. This is because some tools don’t work quite right with longer logins, and some versions of UNIX get quite finicky with them.

Earlier in this module, we discussed the details of the password entry. In the code listing above, you can actually see what a DES-encrypted password looks like (the information following the first column). Many sites disable accounts by altering the encrypted password entry so that when the disabled account’s user enters their password, it won’t match the value in the password file. The guaranteed method of altering passwords for this reason is to insert an asterisk (*) into the entry. The above entry, for example, could be altered to boQavhhaCKaXg*.

TIP: When disabling accounts in this manner, you may find it helpful not only to add an asterisk character, but also to add a string to indicate why the account was disabled in the first place. For example, if you catch a user downloading pirated software, you could disable his account by changing the encrypted entry to boQavhhaCKaXg*caught pirating.

The UID must be unique for every user, with the exception of the UID 0 (zero). Any user who has a UID of 0 has root (administrative) access and thus has full run of the system. Usually, the only user who has this specific UID has the login root. It is considered bad practice to allow any other users or usernames to have a UID of 0. This is notably different from the Windows NT and 2000 models, in which any number of users can have administrative privileges.

NOTE: Some distributions of Linux reserve the UID -1 (or 65535) for the user nobody.

The user’s name can be any freeform text entry. Although it is possible for nonprintable characters to exist in this string, it is considered bad practice to use them. Also, the user’s name may not span multiple lines.

NOTE: Although the entire line for a user’s password entry may not span multiple lines, it may be longer than 80 characters.

The user’s home directory appears as discussed earlier in this module. Ditto for the last entry, the user’s shell. A complete password file for a system, then, might look like this:

ftp:*:14:50:FTP User:/home/ftp:
pop:*:15:15:APOP Admin:/tmp:/bin/tcsh
sshah:Kss9Ere9b1Ejs:500:500:Steve Shah:/home/sshah:/bin/tcsh
hdc:bfCAblvZBIbFM:501:501:H. D. Core:/home/hdc:/bin/bash
jyom:*:502:502:Mr. Yom:/home/jyom:/bin/bash

This chapter is from Linux Administration, A Beginner’s Guide, third edition, by Graham and Shah. (McGraw-Hill/Osborne, 2002, ISBN: 0072225629). Check it out at your favorite bookstore today. Buy this book now.

{mospagebreak title=The /etc/shadow File and The /etc/group File}

The speed of home computers began making dictionary attacks against password lists easier for hackers to accomplish. This led to the separation of the encrypted passwords from the /etc/passwd file. The /etc/passwd file would remain readable by all users, but the passwords kept in the /etc/shadow file would be readable only by those programs with root privileges, such as the login program.

In addition to the encrypted password field, the /etc/shadow file contains information about password expiration and whether the account is disabled. The format of each line in the /etc/shadow file contains the following:

  • Login name
  • Encrypted password
  • Days since January 1, 1970, that the password has been changed
  • Days before the password may be changed
  • Days after which the password must be changed
  • Days before the password is about to expire that the user is warned
  • Days after the password is expired that the account is disabled
  • Days since January 1, 1970, that the account has been disabled
  • Reserved field

Each user has a one-line entry with a colon delimiter. Here’s an example:


Entries with a -1 imply infinity. In the case where a -1 appears in the field indicating the number of days before a password expires, you are effectively tagging a user as never having to change their password.

The /etc/group File

As you know, each user belongs to at least one group, that being their default group. Users may then be assigned to additional groups if needed. The /etc/passwd file contains each user’s default GID. This GID is mapped to the group’s name and other members of the group in the /etc/group file. The format of each line in the /etc/group file is

  • Group name
  • Encrypted password for the group
  • GID number
  • Comma-separated list of member users

Again, each field is separated by a colon. An entry looks similar to this:


Also like the /etc/passwd file, the group file must be world-readable so that applications can test for associations between users and groups. Group names should not exceed eight characters, and the GID should be unique for each group. Finally, the comma-separated list of users is used only for users for whom particular groups are not their default group.

If you want to include a group that does not have a password, you can set the entry like this:


If you want a group to exist, but you don’t want to allow anyone to change their working group to this group (good for applications that need their own group but no valid reason exists for a user to be working inside that group), use an asterisk in the password field. For example:


Progress Check

1. What file does BASH use to read a user’s settings?
2. Is the password stored in clear text in /etc/passwd?

Answer 1. ~/.bashrc
Answer 2. No, it is stored encrypted in either DES or MD5.

This chapter is from Linux Administration, A Beginner’s Guide, third edition, by Graham and Shah. (McGraw-Hill/Osborne, 2002, ISBN: 0072225629). Check it out at your favorite bookstore today. Buy this book now.

Google+ Comments

Google+ Comments