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

RHCSA Lab 26B: Multi-Role Staging

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:

• 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:
   • 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:
   • 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:
   • 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

Step 1: Initial System Configuration (Run as root)

Manual GID assignment for environment consistency:

groupadd -g 2000 administrators

Create the lead admin utilizing -u for specific UID, -g for primary group, and -G wheel for sudo access:

useradd -u 2000 -g administrators -G wheel adm_lead

Efficiently set the password for the lab user:

echo 'Rhcsa!2025' | passwd --stdin adm_lead

Create the junior admin and set their password:

useradd adm_jr
echo 'JuniorP@ss' | passwd --stdin adm_jr

Grant specific command access to satisfy Objective 9.4 without modifying the main sudoers file:

echo 'adm_jr ALL=(ALL) /bin/dnf, /bin/systemctl' > /etc/sudoers.d/junior_admin

Step 2: Project Provisioning (Run as adm_lead)

Switch to the lead account to begin delegated project tasks:

su - adm_lead

Create the developers group:

sudo groupadd -g 3000 developers

Create the service account. The -s /sbin/nologin flag prevents interactive login, and -M skips home directory creation:

sudo useradd -u 3000 -s /sbin/nologin -M helios_svc

Create the standard developer account and set the password:

sudo useradd -g developers anita
echo 'DevPass!23' | sudo passwd --stdin anita

Step 3: Directory Structure & Special Permissions

Build out the directory paths:

sudo mkdir -p /srv/helios/app/src
sudo mkdir -p /srv/helios/data/shared

Configure ownership and apply the SGID bit (2XXX) to ensure files created by 'anita' belong to the 'developers' group:

sudo chown root:developers /srv/helios/app/src
sudo chmod 2770 /srv/helios/app/src

Configure ownership and apply the Sticky Bit (1XXX) to protect files in the world-writable shared directory:

sudo chown root:developers /srv/helios/data/shared
sudo chmod 1777 /srv/helios/data/shared

Step 4: Verification Sequence

From the adm_lead shell, stage a test file:

sudo cp /etc/redhat-release /srv/helios/app/src/release_info.txt

Switch to the developer user:

sudo su - anita

Verify file creation and confirm the SGID bit worked (the group should appear as 'developers' in the output):

touch /srv/helios/app/src/test.py
ls -l /srv/helios/app/src/test.py

Check read and write permissions on the staged file. The write command will fail because the group lacks write permission on this specific file:

cat /srv/helios/app/src/release_info.txt
echo "test" >> /srv/helios/app/src/release_info.txt

Drop back to the lead admin shell to apply the fix:

exit

Update the permissions as the administrator:

sudo chmod g+w /srv/helios/app/src/release_info.txt

Switch back to the developer user and test again. It will now succeed:

sudo su - anita
echo "test" >> /srv/helios/app/src/release_info.txt

Step 5: Lab Finalization

Exit the active shells to return to the root prompt:

exit
exit

Run the grading script to verify all exam objectives were met:

./grade_ep0026.sh

Finally, run the cleanup script to reset the environment for your next practice run:

./cleanup_after_ep_0026.sh