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:
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
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
$ 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.
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. ]