Users, Groups & Root — Understanding Access Control

⚠️ Safety & Ethics

This post explains user, group, and root access management to help you learn and defend systems. Practice only on machines you own or have explicit permission to test. Misusing these skills is illegal and unethical.

🧭 Why users & groups matter

Linux security is built around who can do what. Users and groups define boundaries. Attackers probe these boundaries; defenders tighten them. To both exploit safely in labs and harden real systems, you must understand user and group mechanics thoroughly.

Users vs Root: The basics

Root is the superuser with unrestricted privileges (UID 0).
Regular users have limited privileges; they do not own the whole system.
Why root matters: Any process running as root can change system files, install services, and manipulate users — which is why gaining root is a common final goal in privesc labs.

Commands:

whoami      # shows current username

id          # shows UID, GID, and groups for current user

sudo -l     # shows which commands current user can run with sudo

User management commands (safe lab usage)

Command	Purpose
`useradd [username]`	Create a new user (use with care)
`adduser [username]`	Friendlier interactive add (Debian/Ubuntu)
`passwd [username]`	Set/change user’s password
`usermod -aG [group] [user]`	Add user to a group
`userdel [username]`	Remove a user (careful!)
`su - [username]`	Switch user (asks for target user’s password)
`sudo [command]`	Run a command as root (or another user)

Tip: Prefer adduser on Ubuntu/Debian for sane defaults.

Groups: organizing permissions

Groups let you assign permissions to multiple users at once. Useful examples:

www-data — webserver user/group
docker — users allowed to use Docker without sudo
adm / sys — admin-related groups for logs and monitoring

Check groups:

groups          # lists groups for current user

getent group [groupname]  # shows group members and GID

Add user to group:

sudo usermod -aG docker alice

Sudo: controlled root access

sudo lets authorized users run commands as root without sharing the root password.

Inspect sudo rights:

sudo -l

Sudoers file:

/etc/sudoers controls sudo permissions — edit safely with visudo.
Use visudo to avoid syntax errors that can lock out sudo.

Best practices:

Grant least privilege: only allow the specific commands a user needs.
Avoid NOPASSWD unless absolutely necessary.
Prefer group-based sudo rules (e.g., members of admin group).

Example sudoers entry:

%admin ALL=(ALL) /usr/bin/systemctl, /usr/bin/journalctl

This lets members of admin run only systemctl and journalctl as root.

Common misconfigurations and what attackers look for (lab-aware)

Users in risky groups: membership in docker, shadow, or sudo often grants escalatory paths.
Weak sudo rules: broad ALL or NOPASSWD entries.
Default passwords or unused accounts left enabled.
Improper file ownership: sensitive files readable by non-privileged users (e.g., /etc/shadow readable).
Sudo binaries that allow shell escapes (commands that let users spawn shells).

Again — learn these patterns to defend systems and to practice in isolated labs only.

Auditing user & group configuration (safe lab commands)

List all users:

cut -d: -f1 /etc/passwd

List all groups:

cut -d: -f1 /etc/group

Find users with UID 0 (other root-equivalents):

awk -F: '($3 == "0") {print $1}' /etc/passwd

Check sudoers files and included directories:

sudo cat /etc/sudoers
ls -la /etc/sudoers.d

Only run these on systems you manage or are authorized to test.

Defensive hardening checklist

Remove unnecessary users and disable unused accounts: usermod -L username
Lock default accounts and change default passwords
Restrict sudo to required commands and avoid NOPASSWD
Monitor group membership regularly (especially docker, adm, sudo)
Use sudo rather than sharing the root password
Use 2FA for privileged accounts where possible (SSH + key + 2FA)
Rotate credentials and use hashed/secrets management for services

Practical lab exercises (snapshot your VM first)

Create & manage users

1. sudo adduser testuser
2. Set password, add to a group, remove user.

Inspect sudo rights

1. Create a sudoers.d file via visudo -f /etc/sudoers.d/test that allows a specific harmless command (e.g., /bin/uptime) and test with sudo -l.

Simulate misconfiguration

1. Add a user to docker in a lab VM and research how Docker membership can be abused to escalate privileges (research only; do not attempt on production systems).

Find UID 0 duplicates

1. Run the UID check and, if you find extra UID 0 entries in your lab, investigate why they exist.

Tighten sudo

1. Replace a broad sudo rule with a narrow one, then test functionality.

🧠 How this connects to privilege escalation

Users, groups, and sudo rules are the map an attacker reads to choose an escalation path. By understanding membership, special privileges, and sudoers syntax, you will:

Recognize escalation opportunities in lab boxes
Build defensive checks to detect risky configurations
Harden systems so attackers have fewer low-cost paths to root

🎯 Coming Up Next

Part 6: Privilege Escalation Techniques on Linux Systems
We’ll dive into real privesc vectors (cron jobs, PATH issues, writable configs) and how to find them safely in labs — plus remediation strategies.

💬 Got Questions?

Drop them in the comments or join our community on Discord for exclusive hacking tips and resources.

Don’t worry — mastery comes with practice.
Just open your terminal and hack your brain into CLI mode daily.

Let’s keep building. 💻⚔️