Users, Permissions, and Why Root Is Dangerous

In the previous post, you learned the commands. Now let’s understand the system that controls who can use them and what they can do.

Permissions are at the core of every privilege escalation technique, every access control vulnerability, and every secure system design. If you don’t understand how permissions work, you won’t understand how they break.

Users: Not All Accounts Are Equal

Every Linux system has multiple users. Even if you’re the only person using the machine, there are dozens of user accounts running behind the scenes.

cat /etc/passwd

This file lists every user on the system. Each line follows this format:

username:x:UID:GID:comment:home_directory:shell

Example:

root:x:0:0:root:/root:/bin/bash
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
user:x:1000:1000:Regular User:/home/user:/bin/bash

User Types

Type	UID Range	Purpose
root	0	Superuser - can do anything
System accounts	1-999	Services (web server, database, mail)
Regular users	1000+	Actual humans

root (UID 0) is God on a Linux system. Root can read any file, kill any process, change any setting, and delete anything. There are no restrictions.

System accounts (like www-data, mysql, nobody) run services. They typically have limited permissions and no login shell (/usr/sbin/nologin). If someone exploits your web server, they get www-data access - not root. This is intentional.

Regular users are human accounts with their own home directories and limited access.

Why This Matters

The entire goal of privilege escalation is moving from a low-privilege user (like www-data) to root. Understanding user types tells you:

• What you can access with your current privileges
• What you can’t access and need to escalate to reach
• Which accounts are interesting targets

Groups: Organizing Access

Users belong to groups. Groups let you give the same permissions to multiple users at once.

# See your groups
groups

# See all groups on the system
cat /etc/group

# See groups for a specific user
id username

Example output of id:

uid=1000(user) gid=1000(user) groups=1000(user),27(sudo),33(www-data)

This user belongs to three groups:

• user (their primary group)
• sudo (can use sudo - this is significant)
• www-data (can access web server files)

Important Groups

Group	Significance
sudo / wheel	Members can use sudo to run commands as root
adm	Can read log files in /var/log
www-data	Web server group
docker	Can run Docker containers (effectively root access)
shadow	Can read /etc/shadow (password hashes)

Security note: Being in the docker group is essentially the same as being root. You can mount the entire file system inside a container and access everything. This is a well-known privilege escalation vector.

File Permissions: The rwx System

Every file and directory in Linux has three sets of permissions for three categories of users.

ls -la

-rw-r--r-- 1 user user  4096 Jan 30 10:00 document.txt
drwxr-xr-x 2 user user  4096 Jan 30 10:00 projects
-rwxr-x--- 1 root root  8192 Jan 30 10:00 admin-tool

Let’s decode -rw-r--r--:

 -    rw-    r--    r--
 │     │      │      │
 │     │      │      └── Others: read only
 │     │      └── Group: read only
 │     └── Owner: read + write
 └── File type (- = file, d = directory)

The Three Permissions

Symbol	Permission	On Files	On Directories
r	Read	View file contents	List directory contents
w	Write	Modify file contents	Create/delete files in directory
x	Execute	Run as a program	Enter the directory (cd)

The Three Categories

Category	Meaning
Owner (u)	The user who owns the file
Group (g)	Members of the file’s group
Others (o)	Everyone else

Numeric Permissions

Permissions can be expressed as numbers:

Number	Permission
0	--- (none)
1	—x (execute)
2	-w- (write)
4	r— (read)
5	r-x (read + execute)
6	rw- (read + write)
7	rwx (read + write + execute)

So chmod 755 file means:

• Owner: 7 (rwx)
• Group: 5 (r-x)
• Others: 5 (r-x)

And chmod 600 file means:

• Owner: 6 (rw-)
• Group: 0 (---)
• Others: 0 (---)

Common Permission Sets

Numeric	Symbolic	Use Case
644	rw-r—r—	Normal files
755	rwxr-xr-x	Scripts and programs
600	rw-------	SSH private keys, sensitive configs
700	rwx------	Private directories
777	rwxrwxrwx	Never do this - everyone can do everything

Security rule: If you see chmod 777, something is wrong. It means any user on the system can read, modify, and execute that file. It’s the “I don’t understand permissions so I’ll just open everything” approach.

Special Permissions: SUID, SGID, and Sticky Bit

Beyond rwx, there are three special permission bits that are critical for security.

SUID (Set User ID)

When a file has SUID set, it runs as the file’s owner instead of the user who executes it.

ls -la /usr/bin/passwd

-rwsr-xr-x 1 root root 68208 Jan 30 10:00 /usr/bin/passwd

Notice the s where x would normally be in the owner section. This means when any user runs passwd, it executes as root. That’s why normal users can change their own password - the passwd program needs root access to write to /etc/shadow.

Why this matters for security: If you find a SUID binary with a vulnerability, you can use it to execute commands as root. This is one of the most common privilege escalation methods.

# Find all SUID files on the system
find / -perm -4000 2>/dev/null

Any unexpected SUID binary is worth investigating. Check GTFOBins to see if a SUID binary can be exploited.

SGID (Set Group ID)

Same concept as SUID, but for the group. The file runs with the file’s group permissions.

# Find SGID files
find / -perm -2000 2>/dev/null

Sticky Bit

On a directory, the sticky bit means only the file owner (or root) can delete files, even if others have write access.

ls -la /tmp

drwxrwxrwt 10 root root 4096 Jan 30 10:00 tmp

The t at the end is the sticky bit. /tmp is world-writable, but users can only delete their own files. Without the sticky bit, anyone could delete anyone’s files in /tmp.

Sudo: Controlled Root Access

sudo lets specific users run specific commands as root (or another user) without knowing the root password.

How Sudo Works

The sudo configuration lives in /etc/sudoers:

sudo cat /etc/sudoers

Example rules:

# User "user" can run anything as root
user    ALL=(ALL:ALL) ALL

# User "backup" can only run tar as root
backup  ALL=(root) /usr/bin/tar

# User "dev" can run commands without a password
dev     ALL=(ALL) NOPASSWD: ALL

Checking Your Sudo Rights

sudo -l

This is critical in pentesting. It shows exactly what you can run with elevated privileges:

User www-data may run the following commands on this host:
    (root) NOPASSWD: /usr/bin/vim

If you can run vim as root, you can escape to a root shell from within vim. Same goes for find, less, python, awk, and many other programs. GTFOBins lists these.

Common Sudo Misconfigurations

Misconfiguration	Risk
NOPASSWD: ALL	Any command as root without a password
(ALL) /usr/bin/vim	Vim has shell escape - instant root
(ALL) /usr/bin/python3	Python can spawn a root shell
(ALL) /usr/bin/find	Find can execute commands
(ALL) /usr/bin/env	Can run any command via env

Each of these is a direct path to root.

The Shadow File

User passwords aren’t stored in /etc/passwd (despite the name). They’re in /etc/shadow, which only root can read.

sudo cat /etc/shadow

root:$6$randomsalt$hashedpassword:19000:0:99999:7:::
user:$6$anothersalt$anotherhash:19000:0:99999:7:::
www-data:*:19000:0:99999:7:::

The $6$ prefix indicates SHA-512 hashing. The * means no password (account can’t log in with a password).

Why this matters: If you can read /etc/shadow during a pentest, you can attempt offline password cracking with tools like hashcat or john. The hashes, combined with weak passwords, often yield results.

How Permissions Get Exploited

Here’s how this knowledge connects to real attacks:

Scenario 1: World-Readable Sensitive File

ls -la /var/www/config/database.yml
-rw-r--r-- 1 root root 256 Jan 30 10:00 database.yml

This config file is readable by everyone (r-- for others). If it contains database credentials, any user on the system can read them. Should be 600.

Scenario 2: SUID Binary Exploitation

find / -perm -4000 2>/dev/null
# Finds: /usr/local/bin/custom-backup (owned by root, SUID set)

A custom backup tool running as root. If it has a command injection vulnerability, you can execute arbitrary commands as root.

Scenario 3: Sudo Misconfiguration

sudo -l
# Output: (root) NOPASSWD: /usr/bin/less /var/log/syslog

Seems harmless - just reading a log file. But less has a shell escape: type !sh inside less and you get a root shell.

Scenario 4: Writable Cron Job

ls -la /etc/cron.d/backup
-rwxrwxrwx 1 root root 64 Jan 30 10:00 backup

A cron job owned by root that runs periodically, but it’s writable by everyone. Replace its contents with a reverse shell and wait for it to execute as root.

Try It Yourself

Safe exercises on your own system:

# 1. Check your user info
id
whoami

# 2. See your groups
groups

# 3. Check your sudo rights
sudo -l

# 4. Find SUID files
find / -perm -4000 2>/dev/null

# 5. Check permissions on sensitive files
ls -la /etc/shadow
ls -la /etc/passwd
ls -la ~/.ssh/

# 6. Create a file and experiment with permissions
touch test.txt
ls -la test.txt
chmod 777 test.txt
ls -la test.txt
chmod 600 test.txt
ls -la test.txt
rm test.txt

What’s Next

You now understand how Linux controls access. In the next post, we’ll cover the Windows side - the registry, services, event logs, and how Windows handles permissions differently. Many organizations run both, and attackers target whichever is weaker.

References

• Linux File Permissions Explained
• GTFOBins - Unix binaries that can be exploited for privilege escalation
• OverTheWire Bandit - Learn permissions through challenges

---

Permissions aren’t just access control theory. They’re the difference between “I’m stuck as www-data” and “I’m root.” Learn to read them. Learn to break them.