RHCSA (026B): Season 2 - Scenario 1 of 25: Multi-Role Staging Environment Provisioning

Executive Summary

This RHCSA practice scenario details the complete provisioning of a secure, multi-role staging environment for a new application. The exercise is a comprehensive test of core system administration skills, starting with the creation of specific user and group accounts with designated IDs.

A key focus is on privilege management, demonstrating how to safely delegate limited administrative rights to a junior administrator using a dedicated sudoers file, while granting full sudo access to a lead administrator. The scenario reinforces security best practices by requiring a transition from the root account to a named administrative user for the bulk of the configuration.

Finally, the article covers the creation of a complex directory structure with advanced permissions. This includes the practical application of special permissions like the SGID bit to ensure correct group ownership in a collaborative developer directory and the sticky bit to protect files in a shared data directory. The solution provides a complete, step-by-step command guide followed by a thorough verification process to confirm that all configurations are correct and functional.

Keywords: RHCSA, Linux, System Administration, Privilege Management, User Management, Group Management, sudo, sudoers, File Permissions, Special Permissions, SGID, Sticky Bit, Security Best Practices, Server Provisioning, Multi-role Environment, Red Hat

The Problem

Mission

Your organization is deploying a new staging environment for a critical application named "Helios". You have been tasked with provisioning the user accounts, groups, and directory structures according to strict security and operational requirements. All configurations must be precise.

RHCSA Objectives covered in this article/video:

• 1.1: Issue commands with correct syntax, including less common options.
• 1.5: Log in and switch between multiple user contexts to perform tasks and verify permissions.
• 1.7: Create and edit system configuration files (e.g., /etc/sudoers.d/).
• 1.8: Create a complex, multi-level directory structure and manipulate files within it.
• 1.10: Implement a multi-tiered permission scheme using standard (rwx), group ownership, and special permissions (SGID, Sticky Bit).
• 9.1: Create user accounts with specific UIDs, non-standard shells, and supplementary group memberships.
• 9.3: Create local groups with specific GIDs.
• 9.4: Configure fine-grained superuser access without modifying the default sudoers file.

Your Task

You will begin as the root user. Your first actions are to create a dedicated administrative account for yourself and then a limited-privilege administrator. After that, you must exclusively use your new admin account (adm_lead) for all subsequent tasks.

Requirements

1. Initial Root Tasks:
   • Create a local group named administrators with a Group ID (GID) of 2000.
   • Create your primary administrative user account named adm_lead. This user must have a UID of 2000, a primary group of administrators, be a member of the wheel group, and have the password Rhcsa!2025.
   • Create a junior administrator user account named adm_jr with the password JuniorP@ss.
2. Configure Delegated Privileges:
   • As root, create a new file at /etc/sudoers.d/junior_admin to grant the user adm_jr the ability to run /bin/dnf and /bin/systemctl with superuser privileges, and nothing else.
   • Log out of the root session. You must now log in as adm_lead and use sudo for all subsequent tasks.
3. Provision Project Groups and Users (as adm_lead):
   • Create a local group named developers with a GID of 3000.
   • Create a service account named helios_svc with a UID of 3000, a shell of /sbin/nologin, and no home directory.
   • Create a developer user named anita with a primary group of developers and the password DevPass!23.
4. Create Directory Structure and Permissions (as adm_lead):
   • Create the directory structures: /srv/helios/app/src and /srv/helios/data/shared.
   • For /srv/helios/app/src, set ownership to root:developers. Permissions must allow the owner full control, group members read/write/access, and automatically set group ownership of new files to developers (SGID). Others must have no access.
   • For /srv/helios/data/shared, set ownership to root:developers. Permissions must allow all users to read/write/access, but only allow users to delete files they own (Sticky Bit).
5. Final Verification (as adm_lead):
   • Copy /etc/redhat-release to /srv/helios/app/src/release_info.txt.
   • Switch to the anita user.
   • As anita, verify you can create a new file in /srv/helios/app/src.
   • As anita, confirm the new file's group is developers.
   • As anita, verify you can read release_info.txt and can also write to it after a permission change is applied by adm_lead.

Note

All users, groups, files, and permissions must be correctly configured and persist after a system reboot.

The Solution

Part 1: Run as the root user

# Create the 'administrators' group with GID 2000
groupadd -g 2000 administrators

# Create 'adm_lead' user (UID 2000, primary group 'administrators', supplementary 'wheel')
useradd -u 2000 -g administrators -G wheel adm_lead

# Set password for 'adm_lead'
echo 'Rhcsa!2025' | passwd --stdin adm_lead

# Create 'adm_jr' user and set password
useradd adm_jr
echo 'JuniorP@ss' | passwd --stdin adm_jr

# Create a sudoers file to grant specific privileges to 'adm_jr'
echo 'adm_jr ALL=(ALL) /bin/dnf, /bin/systemctl' > /etc/sudoers.d/junior_admin

# Log out of the root session
exit

Part 2: Run as the adm_lead user

# NOTE: You must now log in as 'adm_lead'. All commands require 'sudo'.

# Create the 'developers' group with GID 3000
sudo groupadd -g 3000 developers

# Create the 'helios_svc' service account (UID 3000, nologin shell, no home dir)
sudo useradd -u 3000 -s /sbin/nologin -M helios_svc

# Create developer 'anita' with primary group 'developers' and set password
sudo useradd -g developers anita
echo 'DevPass!23' | sudo passwd --stdin anita

# Create the directory structures
sudo mkdir -p /srv/helios/app/src
sudo mkdir -p /srv/helios/data/shared

# Configure /srv/helios/app/src (ownership and SGID)
sudo chown root:developers /srv/helios/app/src
sudo chmod 2770 /srv/helios/app/src

# Configure /srv/helios/data/shared (ownership and Sticky Bit)
sudo chown root:developers /srv/helios/data/shared
sudo chmod 1777 /srv/helios/data/shared

Part 3: Verification (as adm_lead and anita)

Step A: Initial Check (as adm_lead, then anita)

# From the 'adm_lead' shell, copy a file into the project directory
sudo cp /etc/redhat-release /srv/helios/app/src/release_info.txt

# Switch to the 'anita' user
sudo su - anita

# --- Now running as 'anita' ---

# Verify ability to create a file (should succeed)
touch /srv/helios/app/src/test.py

# Verify the SGID bit is working (group must be 'developers')
ls -l /srv/helios/app/src/test.py

# Verify read access to the file copied by root (should succeed)
cat /srv/helios/app/src/release_info.txt

# Verify write access (should FAIL with 'Permission denied')
echo "test" >> /srv/helios/app/src/release_info.txt

# Return to 'adm_lead' shell
exit

Step B: Apply Fix and Re-verify (as adm_lead, then anita)

# --- Back in the 'adm_lead' shell ---

# Fix the permissions on the file copied by root
sudo chown :developers /srv/helios/app/src/release_info.txt
sudo chmod g+w /srv/helios/app/src/release_info.txt

# Switch back to the 'anita' user
sudo su - anita

# --- Now running as 'anita' again ---

# Re-verify write access to the file (should SUCCEED now)
echo "test" >> /srv/helios/app/src/release_info.txt

# Confirm content was added
cat /srv/helios/app/src/release_info.txt

# Exit the 'anita' shell
exit