User Administration

Mr. Bandel tells us all about users/groups, UIDs/GIDs, permissions and security. In short, how to successfully manage your users.

Once your system is installed and most of the services configured, it's time to add users. You may not have given this task much thought yet, but you should.

If you're like many Linux beginners, you may not understand the implications of giving someone access to your system. Perhaps, for some time, you've been using a Unix variant, in which the basic decisions have been handled for you. Indeed, some installation programs, such as Caldera's LISA (Linux Installation and System Administration), start the process for you by adding a user during the install process and then allow you to continue using it to add and delete users from the system. So what else is there to know?

For starters, adding users entails thinking about how you wish to administer the system overall. Security is directly affected by such things as groups and passwords. Their administration shouldn't be left to chance or the whims of the installation program—at least, not without exploring their impact.

/etc/passwd

When you add a user, however you do it (I'll mention some programs later), you add an entry to the /etc/passwd file. This file consists of seven colon-separated fields, specified all on one line:

col:JkH7XmXwH6e/E:100:100:Bandel:/home/col:/bin/bash

The fields are: user login name, password, UID, GID, comment (gecos) field, user's home directory and user's default shell.

If you decide to edit the /etc/passwd file manually, please be sure to make a backup copy first, so that if something goes wrong, you can start over. In general, I recommend using one of the programs specifically designed to edit the /etc/passwd file.

1. Login Name

The first field is fairly self-explanatory. The system matches this entry with the next field as the user's login name/password pair. Each name must be unique. This is the only field required to be unique; I will explain the implications of keeping certain other fields unique below. Beyond that, making the user name meaningful helps to quickly identify who sent a 10MB file to the printer when the boss needs a hard copy of his budget for a Board of Directors meeting in ten minutes. In most Unix variants, including Linux, the login name is limited to 8 characters.

2. Password

The second field is the password. This field can contain any of a number of things, but normally contains an encrypted password. The encrypted password must be 13 characters in length, composed of a two character seed plus the encrypted password. Other entries often seen in the password field include: “*”,“LOCKED” and “VOID”. If you see an “x” in this field, you'll want to read about shadow files below. These, or any other incorrect entries, effectively lock this user out. If you wish to lock a user out without losing the password they are using, you can insert an apostrophe as the first character. An apostrophe can never be used as part of the “scrambled eggs”, so apart from being illegal as part of a seed, you have also made the field size 14 characters. To allow the user access, just remove the apostrophe.

Also note that this field might be empty. Always check the /etc/passwd file to ensure that the second field is not empty. A field is defined as empty or NULL if the two colons delineating this field are next to each other with nothing in between, not even a space. If it is empty, no password is required to log in. The implications of this are obvious.

3. UID

The third field is the UID (user identification). Valid UID ranges are from 0 to 65534. A UID of 0 has a special significance to the system; it is the omnipotent “superuser”, a term derived from the su (substitute user) program normally used by a normal user to become root. When invoked without an argument (user name) or with only a hyphen (-), root is the default.

A UID of 65534 is commonly reserved for “nobody”, a user with no privileges as opposed to a non-privileged user. This UID is often used for individuals accessing your system via FTP or HTTP.

Custom dictates that the numbers 1 to 99 are reserved for system users, such as wheel, daemon, lp, operator, news, mail, etc. These numbers are more than sufficient for most system requirements. Also, you may want to reserve 100 to 999 for semi-privileged (for lack of a better term) users. These users are administrators who don't need total root powers, but who do some administration and thus need more privileges than those given to non-privileged users. Reserve 1000 to 9999 for local users and 10000 to 65534 for remote users (if any).

Reserving groups of numbers for particular users helps if you ever need to search through logs for suspicious user activity. Some distributions, like Caldera, start UIDs at 100, others, like Red Hat, at 500, and still others, like Debian, at 1000 for non-privileged users. Just decide on a scheme and stick to it. Since each distribution does its own thing, in order to mix distributions within an organization, you have to intervene manually if the systems are networked. This is particularly true if you want to use NIS or NFS to mount common directories (e.g., /var/spool/mail, /home).

Contrary to popular belief, the UID field does not have to be unique. In fact, one method that keeps “wanna-be” system crackers busy is to use the technique discussed above and put an apostrophe as the first character in the password field for root. Then create another entry, perhaps tuber, with a UID of 0. Some systems require the root entry to exist and be the first entry.

But beware: a non-unique field can cause problems. For example, if you are logged in as tuber (UID 0) and activate a password-protected screen lock, when you attempt to unlock it, you will find you've outsmarted yourself. The kernel knows you by your UID; it looks up UID 0 beginning with the top of the /etc/passwd file and finds it as the first entry corresponding to “root”--that's where it stops; it doesn't look any further. But root's password has been locked with an invalid entry. At this point, your choices are to telnet in and kill the screen-lock process or to reboot the machine. The other possibility for getting out is to use an unlocked virtual terminal if you have one running to which you can switch. (Sometimes, the “extra” virtual terminals come in handy.)

Before I leave UIDs, here are two more things to think about. First, if you have any “rhosts” files with references to other systems outside your own network, make sure your user names are unique not only in your system, but between systems. If you have a jonesd (for Donna Jones) and the other system has a jonesd (for Danny Jones), and they use rlogin to remotely log in to each other's systems, they'll have access to each other's files (as the other person). These files can cause many problems and probably should not be used.

The second thing is the find command, which is used extensively by systems-administration programs and can be used to find user's files for deletion or changing owners (chown) before (or after) the files become orphaned. Learn this command, and incorporate it into your tool box. See the side bar “A Few Words About the Find Command”.

A Few Words about the Find Command

______________________

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix