Red Hat Certified System Administrator (RHCSA) #11 Users/Groups: UID/GID, sudo, ACL, password policy

If #10 Basic networking had you pinning down persistent connections with nmcli, now it’s time to control who uses the system and how. In RHCSA, users and groups, sudo, ACLs, and password policy are areas where the task count is high and the grading points are clear, so they’re a reliable way to bank points. This post organizes the commands that show up verbatim on the exam — from useradd to setfacl — by typing them out for yourself.

The three files where account information lives #

Before working with users, you need to know where account information is stored and in what format. There are three core files.

A line in /etc/passwd is seven colon-separated fields.

alice:x:1001:1001:Alice Kim:/home/alice:/bin/bash

From left to right: username, password placeholder (x means the actual hash is in shadow), UID, primary GID, GECOS (description), home directory, login shell.

/etc/shadow is also colon-separated and holds the password hash and expiry-related fields.

alice:$6$xyz...:19500:0:90:7:::

The order is: username, hash, last change date (days since 1970-01-01), minimum days, maximum days, warning days. Only root can read this file.

/etc/group holds the group name, password placeholder, GID, and the list of supplementary group members.

developers:x:2000:alice,bob

It’s safer to handle these three files with commands like useradd, usermod, passwd, and chage than to edit them directly. If you must edit them directly, use vipw (passwd) and vigr (group), which run an integrity check.

Creating and modifying users #

Creating a user with useradd #

The simplest user creation looks like this. The home directory and primary group are created automatically.

useradd alice
passwd alice

In RHCSA, creation with specific options shows up more often than plain creation. The frequently used options are as follows.

An example that assigns UID, primary group, supplementary groups, and shell all at once looks like this.

useradd -u 1500 -g developers -G wheel,docker -s /bin/bash -c "Alice Kim" alice

This command creates alice with UID 1500, primary group developers, supplementary groups wheel and docker, and login shell bash. The primary and supplementary groups must already exist, so if they don’t, you have to create them with groupadd first.

A service account that blocks login is often given /sbin/nologin as its shell.

useradd -s /sbin/nologin -M appsvc

Modifying an existing user with usermod #

To change attributes of a user that already exists, use usermod. The option names are mostly the same as useradd.

# change the login shell
usermod -s /bin/bash alice

# replace the supplementary groups with just developers
usermod -G developers alice

# add docker to the supplementary groups (using -G without -a wipes the existing supplementary groups)
usermod -aG docker alice

# change the UID
usermod -u 1600 alice

The -a (append) in -aG is the crux. If you use -G without -a, the existing supplementary groups are replaced wholesale and lost, so when adding a supplementary group, always include -aG.

Deleting a user with userdel #

To also remove the home directory and mail spool when deleting a user, add -r.

# delete the account only (the home directory remains)
userdel alice

# delete the home directory and mail spool too
userdel -r alice

In RHCSA, a question that says “delete the user and their home directory” costs you points if you omit -r, so be careful.

Managing passwords with passwd #

This command handles password setting and locking.

# set a password (interactive)
passwd alice

# set a password from standard input (for scripts)
echo 'NewP@ss123' | passwd --stdin alice

# lock and unlock the account
passwd -l alice
passwd -u alice

--stdin only works on the RHEL family, so when typing directly in the exam environment, interactive passwd is safer.

Group management #

Primary and supplementary groups #

Linux groups come in two kinds. The primary group is the group assigned when a user creates a new file, and a user has exactly one. A supplementary group is a group you belong to for extra permissions, and you can have several.

Check current membership with the id command.

id alice
# uid=1500(alice) gid=2000(developers) groups=2000(developers),10(wheel),990(docker)

gid= is the primary group, and what’s listed under groups= is the full set of groups you belong to.

Creating a group with groupadd #

# create a group
groupadd developers

# create with a specified GID
groupadd -g 2000 developers

# create as a system group
groupadd -r appgroup

Adding users to a group is done with usermod, which we saw earlier. To make several users supplementary members of one group, apply usermod -aG to each user.

usermod -aG developers alice
usermod -aG developers bob

You can also handle group members directly with gpasswd.

# add a user to a group
gpasswd -a carol developers

# remove a user from a group
gpasswd -d carol developers

Granting sudo rights #

How sudo works #

sudo is the tool that allows a regular user to run commands that require root rights. Who can do what is defined in the /etc/sudoers file and the /etc/sudoers.d/ directory.

Don’t edit /etc/sudoers directly — always open it with visudo. visudo checks the syntax on save, preventing the accident where a typo breaks sudo itself.

visudo

The %wheel group #

On RHEL, by default a user in the wheel group can run any command with sudo. The following line is in /etc/sudoers.

%wheel  ALL=(ALL)       ALL

% denotes a group. So a question that says “give this user full sudo rights” is done by making the user a supplementary member of the wheel group.

usermod -aG wheel alice

Defining rights with a drop-in file #

Rather than editing /etc/sudoers directly, placing a file under /etc/sudoers.d/ is the recommended approach. Files in this directory are also created with visudo for the syntax check.

visudo -f /etc/sudoers.d/developers

You write the rule on a single line inside the file. For example, a rule that gives the developers group full sudo rights looks like this.

%developers  ALL=(ALL)  ALL

To allow only a specific command for a specific user, list the command path like this.

alice  ALL=(ALL)  /usr/bin/systemctl, /usr/sbin/lvextend

NOPASSWD #

To skip the password prompt when running sudo, add NOPASSWD:.

%developers  ALL=(ALL)  NOPASSWD: ALL

You can also allow only a specific command without a password.

alice  ALL=(ALL)  NOPASSWD: /usr/bin/systemctl restart httpd

In RHCSA, variations like “let them use sudo without a password” or “allow only a specific command via sudo” show up, so learn NOPASSWD together with command-path specification.

ACL: fine-grained per-file permissions #

The limits of standard permissions #

Traditional rwx permissions can only grant rights to three subjects: owner, group, and others. A requirement like “let only one specific user read this file, not the whole group” can’t be solved with standard permissions. This is where the ACL (Access Control List) comes in.

Checking the current ACL with getfacl #

getfacl /data/report.txt

In the output, user::, group::, and other:: are the standard permissions, while a named entry like user:alice: is a permission added via ACL.

Granting an ACL with setfacl #

Use -m (modify) to add or change a permission.

# grant read/write to user alice
setfacl -m u:alice:rw /data/report.txt

# grant read/execute to group developers
setfacl -m g:developers:rx /data/report.txt

Use -x (remove) to remove a specific ACL entry.

setfacl -x u:alice /data/report.txt

To apply recursively to every file under a directory, add -R.

setfacl -R -m g:developers:rwx /data/project

To clear all ACLs, use -b (remove all).

setfacl -b /data/report.txt

Understanding the mask #

A file with an ACL gets a mask:: entry. The mask is the upper bound of the permissions allowed for named user/group entries and the group. That is, even with user:alice:rwx, if the mask is r--, alice’s effective permission is read only. The #effective: comment in the getfacl output tells you the effective permission. The mask is usually adjusted automatically by setfacl, but you can also set it directly.

setfacl -m m:rx /data/report.txt

default ACL #

If you set a default ACL on a directory, files and subdirectories newly created inside that directory inherit those permissions. Add the d: prefix.

setfacl -m d:g:developers:rwx /data/project

This way, files created under /data/project from now on are born with an rwx ACL for the developers group. It doesn’t affect existing files, so to handle existing files at the same time, also set a regular ACL with -R.

setfacl -R -m g:developers:rwx -m d:g:developers:rwx /data/project

Password expiry policy #

Viewing and changing per-account policy with chage #

chage (change age) handles per-user password expiry policy. Check the current policy with -l.

chage -l alice

The frequently used options are as follows.

For example, making a password change every 90 days and setting an account expiry date looks like this.

# maximum password use of 90 days
chage -M 90 alice

# set the account expiry date to 2026-12-31
chage -E 2026-12-31 alice

# force a password change at next login
chage -d 0 alice

To clear account expiry, set -E -1.

chage -E -1 alice

/etc/login.defs: defaults for new users #

chage is a command you apply to a user that already exists, while the default policy for users you’ll create going forward is set in /etc/login.defs. The main items are as follows.

PASS_MAX_DAYS   90
PASS_MIN_DAYS   0
PASS_WARN_AGE   7
UID_MIN         1000

Changing these values applies them to users created with useradd afterward. They don’t apply to existing users, though, so adjust accounts that already exist separately with chage.

Locking an account #

Apart from password policy, there are times you need to block an account temporarily. usermod’s -L (lock) puts a ! in front of the password hash to block password login, and -U (unlock) reverses it.

# lock the account
usermod -L alice

# unlock
usermod -U alice

passwd -l and usermod -L have the same effect. To fully block login itself, also use the method of changing the shell to /sbin/nologin.

usermod -s /sbin/nologin alice

Exam points #

• Adding a supplementary group is usermod -aG. Omit -a and the existing supplementary groups vanish wholesale. When adding, always attach append.
• To also delete the home when deleting a user, use userdel -r. Omit -r and the home directory remains, costing you points.
• Full sudo rights are the wheel group. A question that says “give this user sudo” is often done with usermod -aG wheel.
• Edit sudoers only with visudo. Create drop-ins with visudo -f /etc/sudoers.d/filename so they go through the syntax check.
• ACL is setfacl -m u:name:perm, checked with getfacl. If you need directory inheritance, use a d: default ACL; if existing files too, add -R.
• The mask is the upper bound of effective permission. If you set an ACL but the permission doesn’t take, check getfacl’s #effective: and the mask.
• Expiry policy is chage, new defaults are /etc/login.defs. Remember that the two apply to different targets.

After finishing a task, get into the habit of verifying the resulting state directly with id, getfacl, chage -l, and sudo -l -U user. RHCSA’s grading script inspects the resulting state, so rather than stopping after typing the command, verifying that the intended state was actually reached is what earns points.

Wrap-up #

What this post locked in:

• Account information is stored in the three files /etc/passwd, shadow, and group, and handled safely with useradd, usermod, passwd, and chage.
• User creation is useradd -u/-g/-G/-s/-d, modification is usermod, adding a supplementary group is -aG, and deletion is userdel -r.
• Groups are created with groupadd, and supplementary group membership is managed with usermod or gpasswd.
• sudo means editing /etc/sudoers or /etc/sudoers.d/ with visudo. The wheel group, NOPASSWD, and per-command allows are the regular variations.
• ACL is getfacl/setfacl -m/-x/-R, covering the mask and default ACL (d:) as well.
• Password policy is chage -l/-M/-m/-E, new defaults are /etc/login.defs, and account locking is usermod -L.

Next: firewalld and SSH keys #

With users and rights pinned down, it’s time to guard the system’s outer boundary. In #12 firewalld and SSH key authentication, we’ll organize — by typing it out for ourselves — how to open ports and services as persistent rules with firewall-cmd, the zone concept, and how to set up passwordless key authentication with ssh-keygen and ssh-copy-id.