Coding for Hackers

Bash › Linux Fundamentals

Permissions, ownership, and the SUID trap

5 min read Intermediate 5 sections

Permissions decide what every file and program can do — and what you can do with them. Understanding them is prerequisite to the most common Linux privilege-escalation technique: finding a SUID binary that runs as root. This lesson decodes the permission system and shows why one misconfigured bit can hand you the whole box.

You'll learn to

  • Read the permission string on any file
  • Translate octal notation like 755 and 644
  • Understand why SUID binaries are a privesc path

Reading the permission string

ls -la /etc/shadow
# -rw-r----- 1 root shadow 1234 Jan 1 00:00 /etc/shadow

That -rw-r----- at the start packs in everything. The first character is the type (- file, d directory, l symlink). The next nine are three groups of three — read/write/execute for the owner, the group, and everyone else:

 -  rw-  r--  ---
 |   |    |    |
type owner group other

So /etc/shadow is readable and writable by its owner (root), readable by the shadow group, and nothing for everyone else — which is exactly why a normal user can’t read the password hashes.

Octal notation decoded

Permissions are often written as numbers like 755 or 644. Each digit is the sum of read (4), write (2), and execute (1):

7 = 4+2+1 = rwx (full)
6 = 4+2   = rw-
5 = 4+0+1 = r-x
4 = 4     = r--
0 =         ---

chmod 755 script.sh   # rwxr-xr-x: owner full, group + other read+execute
chmod 644 file.txt    # rw-r--r--: owner read+write, others read
chmod 600 id_rsa      # rw-------: owner only (correct for a private key)
chmod +x script.sh    # just add execute for everyone
chown root:root file  # change owner and group

The SUID trap

There’s a special permission bit — SUID — that changes everything for security. A binary with the SUID bit set runs with the privileges of its owner, not the user who runs it. If that owner is root, any user who runs it gets root-level power for the duration.

ls -la /usr/bin/passwd
# -rwsr-xr-x  ← the 's' where the owner's 'x' would be is the SUID bit

That s is the SUID bit. passwd legitimately needs it (it edits /etc/shadow), but when an admin sets it on the wrong binary, it becomes a privilege-escalation path.

# Find all SUID-root binaries — a top privesc check:
find / -perm -4000 -user root -type f 2>/dev/null

Checkpoint

A binary owned by root shows -rwsr-xr-x in its permissions. What does the 's' mean, and why is it a security concern?

Try it yourself

On a Linux system you control, run ls -la on a few files and practice reading the permission strings. Translate each into octal in your head. Then run find / -perm -4000 -type f 2>/dev/null to list the SUID binaries present, and note which look standard versus unusual.

Summary

A permission string is type plus three rwx triplets for owner, group, and other. Octal notation sums read (4), write (2), execute (1) — so 755 is rwxr-xr-x, 644 is rw-r—r—, 600 is owner-only. The SUID bit (shown as s) makes a binary run as its owner; SUID-root binaries are a primary privilege-escalation target, found with find / -perm -4000. Also watch for files you can read but shouldn’t, and root-run scripts you can write.

Key takeaways

  • Permission string = type + owner/group/other rwx triplets.
  • Octal: read 4, write 2, execute 1 — memorise 755, 644, 600.
  • SUID (s bit) runs a binary as its owner; SUID-root is a privesc path.
  • find / -perm -4000 -user root 2>/dev/null is a core enumeration command.

Quick quiz

Next module moves from the system into Bash scripting itself — variables, arrays, and the constructs that turn these commands into tools.

Was this lesson helpful?