Computer & OS Fundamentals · beginner · ~11 min
Read Unix permission bits and explain owner/group/other and the root exception.
Unix files sit in one tree under /, each with owner/group/other read-write-execute bits (e.g. 750). setuid/setgid change a program's effective user; root (UID 0) bypasses all checks.
Permissions are the access-control model you audit constantly: world-writable files, setuid binaries, and over-privileged services are bread-and-butter findings and privilege-escalation paths.
Tree under /. Absolute vs relative paths. rwx triads. owner/group/other, octal 0–7. Directory x. Permission to enter. setuid/setgid. Run as owner/group. Root. UID 0 bypasses checks — the privilege-escalation goal.
Almost everything on a Unix system is a file, and access to each file is governed by permissions.
Files live in a single hierarchy rooted at /. Directories are files that list other files. Paths are absolute (/etc/passwd) or relative (../notes.txt).
Each file has an owner, a group, and three permission triads — owner / group / other — each with read (r), write (w), execute (x):
-rwxr-x--- owner=rwx group=r-x other=---
As octal: rwx=7, r-x=5, ---=0 → 750. Execute on a directory means "may enter it".
setuid / setgid make a program run as its owner/group rather than the caller — powerful and a classic privilege-escalation vector when misused. The sticky bit on a shared directory (like /tmp) stops users deleting each other's files.
The root user (UID 0) bypasses permission checks. That's why gaining root is the goal of Linux privilege escalation — and why services should drop privileges and never run as root unnecessarily.
Unix access control is owner/group/other rwx bits, with setuid/setgid and the sticky bit as special cases and root bypassing everything. Mis-set permissions and setuid binaries are recurring audit findings.