Learn Rocky Linux - User, Group & Privilege Management

#Introduction

In the previous episode 5, you understood where software packages come from. Now we shift to a topic that's equally important: who can access the system and what they're allowed to do. Every process on Rocky Linux runs on behalf of a user, and every user has access rights to files, commands, and services.

This knowledge is the heart of system security. You can't secure a server without understanding users, groups, sudo, and permissions. Think of the operating system as an office building: users are its occupants, groups are teams, sudo is the access key to doors, and permissions are the rules for who may enter which room. This episode will give you the full set of keys and rules.

#Users and Groups

#Creating and Managing Users

User operations start with simple commands:

useradd -m -s /bin/bash arman
passwd arman

usermod -aG wheel arman
userdel -r arman

useradd -m -s /bin/bash arman creates user arman with a home directory and Bash shell. usermod -aG wheel arman adds the user to the wheel group — we'll discuss what that means shortly. userdel -r arman deletes the user along with their home directory.

#Groups

Groups group users together to share file access. Their operations are symmetric with users:

groupadd developers
usermod -aG developers arman
groupdel developers

A user can be a member of several groups at once, and each file has one owning group.

#The Passwd, Shadow, and Group Files

Behind the commands above lie three text files that form the identity database:

cat /etc/passwd

cat /etc/shadow
cat /etc/group

• /etc/passwd — one line per user: name, UID, GID, comment, home, and shell. Readable by everyone.
• /etc/shadow — password hashes and expiry policy. Readable only by root.
• /etc/group — group definitions and memberships.

This is why passwords are stored in /etc/shadow and not in /etc/passwd: a leaked hash stays safer than one that's easily accessible.

#Sudo and Administration

#The Sudo Concept

The most important principle in Linux administration: don't work as root all the time. Root has unlimited power, and a single typo as root can destroy the system. The solution is sudo — running specific commands with root privileges, only when needed.

On Rocky Linux, membership in the wheel group grants full sudo access:

sudo dnf5 install vim

This command installs vim with root privileges, while you stay logged in as a regular user.

#The Sudoers File

Sudo rules are stored in /etc/sudoers and the /etc/sudoers.d/ directory. This file should be edited with visudo, which validates syntax before saving:

visudo

grep wheel /etc/sudoers

The line %wheel ALL=(ALL) ALL means all wheel members may run all commands as any user.

#NOPASSWD and Least Privilege

For certain scenarios — such as automated scripts — you can allow specific commands without prompting for a password:

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

echo 'arman ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart httpd' \
  > /etc/sudoers.d/arman-restart-httpd
chmod 440 /etc/sudoers.d/arman-restart-httpd

Note the least privilege principle: user arman may only restart httpd without a password, not run every command. Granting minimal but sufficient access is a habit that will protect you in production.

#Access Control

#File Permissions and umask

Every file has three sets of permissions — for owner, group, and others — each with read (4), write (2), and execute (1) permissions:

ls -l /etc/passwd

chmod 640 /etc/passwd

The umask value determines the default permissions for new files. A 022 umask produces 644 files and 755 directories:

umask

#ACLs for Finer Control

Traditional permissions are limited to three categories. ACLs (Access Control Lists) allow granting specific permissions to additional users or groups:

setfacl -m u:joko:rw /var/www/index.html
getfacl /var/www/index.html

setfacl -m u:joko:rw gives user joko read-write access to the file without adding him to the owning group. getfacl shows all permissions including ACLs.

#Capabilities

Capabilities break root privileges into small units. Instead of granting the full power of root, you can grant one specific capability — for example, the ability to bind to low ports:

setcap cap_net_bind_service=+ep /usr/bin/node
getcap /usr/bin/node

With setcap cap_net_bind_service=+ep, Node.js can serve on port 80 without running as root — a much safer practice.

#SUID, SGID, and Sticky Bit

Three final special permissions change file behavior:

• SUID (4) — an executed file runs with the identity of its owner, not the executor. Classic example: /usr/bin/passwd runs as root.
• SGID (2) — on directories, new files inherit the directory's group; on files, they run with the group's identity.
• Sticky bit (1) — on directories like /tmp, only the file owner can delete its contents.

ls -l /usr/bin/passwd
ls -ld /tmp

chmod +t /var/shared
chmod g+s /var/shared

On passwd, the letter s in the owner position indicates SUID is active. The combination of SUID and SGID is a powerful yet dangerous feature — always audit SUID files periodically, because a flaw in a SUID file is an attacker's favorite path to privilege escalation.

#Closing

In this episode 6, you mastered identity and access rights management on Rocky Linux: creating and maintaining users and groups with useradd, usermod, and userdel; the passwd, shadow, and group file structure; sudo and sudoers configuration with the least privilege principle; and advanced access control with permissions, umask, ACLs, capabilities, and SUID/SGID/sticky bit.

Key takeaways:

• Use a regular user and sudo via the wheel group; don't work as root continuously.
• Password hashes live in /etc/shadow; the passwd and group files are just metadata.
• Edit sudoers with visudo and limit NOPASSWD to specific commands.
• ACLs provide control beyond the three traditional permission categories.
• Capabilities replace the need for full root for a single specific capability.
• Audit SUID files periodically to close privilege escalation paths.

In the next episode 7, we will discuss systemd and service management — how to manage services with systemctl, understand targets, create your own service unit files, override configurations, and read logs with journalctl. Now you know who manages the system; next up is understanding who runs it!