Learning AlmaLinux - Users, Permissions & Sudo

#Introduction

In the previous episode, Episode 5, we covered AppStream modules and how to manage software versions. Now we move to the topic that determines who can access what on the system: users, permissions, and sudo. This isn't just technical — poor user and access policies are the leading cause of security incidents on Linux servers.

This episode breaks down three layers: identity (users and groups), administration (sudo), and file control (classic permissions, ACLs, and special bits). Together they form the security foundation you'll pair with SELinux starting in episode 13.

#Users & Groups

#Creating and Managing Users

The basic user management commands on AlmaLinux:

sudo useradd -m -c "DevOps Engineer" -s /bin/bash devops
sudo passwd devops

The useradd -m -s /bin/bash pattern is the standard: create a home directory and set the login shell. Without the -m flag, the user gets no home directory — something that often causes problems when the user first logs in.

#Identity Files

User identities are stored in simple text files you can read directly:

• /etc/passwd — the list of users with their UID, GID, home, and shell.
• /etc/shadow — password hashes and their expiration policy (readable only by root).
• /etc/group — the list of groups and their members.

cat /etc/passwd
getent passwd devops

The format of each /etc/passwd line: name:x:UID:GID:comment:home:shell. The x column indicates the actual password is stored in /etc/shadow — never write plaintext passwords here.

#Default umask

umask determines the default permissions for new files and directories. The standard value 022 means new files are created with 644 (rw-r--r--) and directories with 755 (rwxr-xr-x). Check your umask value:

umask

For stricter environments, 077 makes new files accessible only by their owner — a decision many use on servers storing sensitive data.

#Sudo & Administration

#The Least Privilege Principle

The golden rule of Linux administration: don't log in as root for daily work. Root has absolute power, and a single typo can destroy the system. Instead, use a regular user and escalate commands one at a time with sudo.

#The wheel Group

On AlmaLinux, users in the wheel group automatically get full sudo rights. Add a user to this group to give them administrative access:

sudo usermod -aG wheel devops

#visudo and /etc/sudoers

The sudo configuration lives in /etc/sudoers — and this file must be edited with visudo, not a regular editor. visudo validates the syntax before saving, so a typo won't permanently lock out sudo access. Additional configuration is usually placed in /etc/sudoers.d/.

# file /etc/sudoers.d/devops
devops ALL=(ALL) ALL
devops ALL=(ALL) NOPASSWD: /usr/bin/systemctl, /usr/bin/dnf5

The line devops ALL=(ALL) ALL grants full permission after a password prompt. The NOPASSWD: line allows specific commands without a password — handy for automation, but it must be limited to safe commands only.

sudo visudo -f /etc/sudoers.d/devops

#Adding Custom Roles

For granular needs, you can define aliases and restrictions:

Cmnd_Alias SERVICES = /usr/bin/systemctl restart *, /usr/bin/systemctl status *
%webteam ALL=(ALL) NOPASSWD: SERVICES

This rule gives members of the webteam group the right to restart services without a password, without granting access to any other commands — a real-world example of least privilege in an organization.

#File Security: Permissions, ACLs, and Special Bits

#chmod, chown, chgrp

Classic Linux permissions: three rwx triplets for owner (u), group (g), and others (o).

sudo chown devops:webteam /srv/www
chmod 750 /srv/www

chmod 750 means full owner access, group read+execute, others no access. chown devops:webteam sets the owner and group at once.

#ACLs (Access Control Lists)

Classic permissions only know one owner and one group. ACLs go beyond that — you can grant specific users or groups specific access:

setfacl -m u:auditor:r /var/log/messages
getfacl /var/log/messages

setfacl -m u:auditor:r gives the auditor user read access to a specific file without changing its owner. getfacl displays the currently active ACL list.

#SUID, SGID, and the Sticky Bit

Three special bits you must understand:

• SUID (Set User ID) — an executed file runs with the identity of its owner, not the executor. Classic example: /usr/bin/passwd. Marked with s in the owner column.
• SGID — on directories, new files inherit the directory's group; on files, the program runs with the owner's group. Marked with s in the group column.
• Sticky bit — on directories like /tmp, only the file's owner may delete or rename it. Marked with t.

chmod +t /shared/uploads
chmod g+s /shared/team
ls -ld /tmp /shared/uploads

#Common Pitfalls

1. Logging in as root for daily work. A dangerous habit that removes audit trails and adds risk. Use sudo.
2. Editing /etc/sudoers without visudo. A single syntax error can lock out all sudo access.
3. Ignoring umask. Unintentionally wide-open new files are a doorway to data breaches.
4. Using chmod 777. Almost never needed; use ACLs or groups for selective access.
5. Forgetting the -a flag in usermod -G. Without -a, the user is removed from all their old groups.

#Conclusion

In this episode 6 you've mastered user, permission, and sudo management on AlmaLinux: creating users and groups, reading the identity files, understanding umask, configuring sudo with visudo and the wheel group, and ACLs plus the SUID, SGID, and sticky special bits.

Key takeaways:

• Use useradd/usermod/userdel to manage identities, and passwd for passwords.
• Identities live in /etc/passwd, hashes in /etc/shadow, groups in /etc/group.
• The main principle: least privilege — don't be root, use sudo through the wheel group.
• Edit sudoers with visudo; use /etc/sudoers.d/ and NOPASSWD carefully.
• ACLs give per-user control; SUID/SGID/sticky are special bits that must be managed consciously.

With a tidy access foundation, you're ready to manage services. In the next episode, Episode 7, we'll cover Systemd, Services & Journald — how systemd runs and supervises services, boot targets, writing unit files, managing resources with cgroups, and reading logs with journalctl. See you there!