Linux sysadmin basics: User account management with UIDs and GIDs

Like many sysadmin tasks and duties, user account management isn't just one thing, nor does it exist in a vacuum. User account management is an ongoing job aspect and there are many facets to it: account creation, account removal, permissions manipulation, expiring accounts, establishing password standards, enforcing security, enforcing password changes, and manipulating UIDs and GIDs to keep a system organized and supportable. Part one focused on useful commands. This current article deals with managing user IDs (UIDs) and group IDs (GIDs). 

Introduction to UIDs and GIDs

By default, Linux systems automatically assign UIDs and GIDs to new user accounts in numerical order starting at 1000. In other words, if you create a new user account during installation, it will have UID = 1000 and GID = 1000, as shown below:

khess:x:1000:1000:Ken Hess:/home/khess:/bin/bash

The theory behind this arbitrary assignment is that anything below 1000 is reserved for system accounts, services, and other special accounts, and regular user UIDs and GIDs stay above 1000. This theory is based on the assumption that 999 account numbers minus a few pre-assigned ones will be more than enough to satisfy most systems for many years. As a Linux administrator for more than 20 years, I've never personally run out of those first 999 system account numbers.

The root account has the awesome privilege of having UID = 0 and GID = 0. These numbers are what give the root account its overwhelming power. If you don't believe me, rename the root account to goonygoogoo, or whatever you choose, and then create a new user account named root, allowing the system to assign the next available UID and GID to it. This account has no more power than any other user account on the system. It's not the name, but the UID and the GID that give the administration account its power. To further test this assertion, assign a test user account with 0 for the UID and GID, and that user is now root, regardless of the account name.

As you can see from the list below, user accounts are (as stated earlier) assigned UID and GID in numerical order from 1000. The UID and GID always match to keep things organized:

khess:x:1000:1000:Ken Hess:/home/khess:/bin/bash
msmith:x:1001:1001::/home/msmith:/bin/bash
mjones:x:1003:1003:Mary Jones:/home/mjones:/bin/bash
jjones:x:1004:1004:John Jones:/home/jjones:/bin/bash
djones:x:1005:1005:Don Jones:/home/djones:/bin/bash

There's no magic in this setup. The system does it. I don't have to worry about it.

But what if your policies are different concerning user and group information? It's possible that your company wants UIDs and GIDs assigned based on employee ID or some other unique identifier (Hopefully not Social Security Number, although I have seen this number used in practice.) Or, what if you want to assign specific GIDs based on roles rather than adding users to a GID in /etc/group? Well, it's easy enough to do any of this with the useradd command from my previous article on this topic, which covered user account management basics.

The following is the user list from /etc/group:

khess:x:1000:
msmith:x:1001:
mjones:x:1003:
jjones:x:1004:
djones:x:1005:

Customizing UIDs and GIDs

Traditionally, administrators wanting to add a user to non-primary groups do so at account creation, using the useradd tool with the -G switch. Be sure to list all secondary groups after the -G switch, separated by commas with no spaces. The following command allows the system to pick the UID and primary GID from the next available number but adds user jdoe to the sysadmin and helpdesk groups:

$ sudo useradd -G sysadmin,helpdesk jdoe

If you want to specify the primary group with the -g switch, the group must already exist. For example, if you enter the following command:

$ sudo useradd -u 10600 -g 10600 -G sysadmin,helpdesk jdoe

You will get the error "useradd: group '10600' does not exist," and the system won't create the account. If you must specify the group, then add the group first:

$ groupadd 10600

$ sudo useradd -u 10600 -g 10600 -G sysadmin,helpdesk jdoe

Managing group permissions

When users create files, the user owner gets read (r) and write (w) permissions, the group gets read permission, and others get read permission (rw-r--r--), or in numeric terms, 644. The execute (x) permission is not given by default. So, as a system administrator, if a group member requests execute permission be placed on a file or group of files, then grant execute permission for the group only:

$ sudo chmod g+x coolscript.sh

The user can change the permission themselves if they are the user owner but often will not do so for fear of doing it incorrectly. Only the user owner or the root user can change permissions on a file even if the group has write permission to the file. Write permission means that a group member can edit or delete the file.

Be sure that shared group directories have write access (permission) for the group, and that the files that need to be modified by group members also have write access. Some of you who have more advanced permissions knowledge are probably asking why I don't mention the chattr (change attributes) command, and it's a valid question. The chattr command is out of scope for this article but will be covered in a later article that focuses solely on chattr and its many options.

Wrapping up

This article provides brief coverage of the UID and GID attributes and how to manipulate those if you need to do so. I also covered a bit about group permissions. In a future article, I'll cover the chattr command that gives you options to prevent accidental deletion by group members. If you want to read ahead, do so with caution. The chattr command can be frustrating for new administrators who aren't familiar with its syntax and option consequences.

[Want to try out Red Hat Enterprise Linux? Download it now for free. ]