Users & Permissions

Every user account has a numeric User ID (UID) — the kernel and filesystem only ever deal in UIDs, not usernames; the username is a convenience layer resolved via `/etc/passwd`. UID 0 is always root, the superuser with unrestricted access. Regular user UIDs conventionally start at 1000 on most modern distributions, with UIDs below that reserved for system accounts and services that need their own identity but aren't meant for interactive login.

`/etc/passwd` lists every user account: username, UID, primary GID, a description field, home directory, and login shell — despite the name, it hasn't stored actual passwords in decades; that field is now always an `x`, a placeholder pointing to `/etc/shadow`. `/etc/shadow` holds the actual (hashed, never plaintext) passwords and password-aging policy, and is readable only by root — this separation exists specifically so that `/etc/passwd`, which many tools need to read to resolve usernames, doesn't need to expose password hashes to do so.

`/etc/group` lists every group, its GID, and its member usernames. Every user has exactly one primary group (assigned at creation, usually matching their username by default) but can belong to any number of supplementary groups, which is how you grant access to shared resources (a "developers" group with write access to a shared directory) without changing anyone's primary identity.

`su` switches you to another user (commonly root) for the rest of the session, requiring that user's own password. `sudo` runs a single command as another user (by default root), requiring your own password, and logs what was run — a meaningful audit trail that "log in as root directly" doesn't give you. Modern practice strongly favors `sudo` over routine root logins: it preserves accountability (which admin ran what, and when), and lets you grant a specific person access to specific commands without handing over full root.

`/etc/sudoers` controls who can run what as whom, and must never be edited directly with a normal text editor — a syntax error in this file can lock every administrator out of `sudo` simultaneously, including yourself. `visudo` opens the file for editing through a wrapper that validates syntax before saving, refusing to write a broken file. This single habit (always `visudo`, never `vim /etc/sudoers` directly) prevents a specific, well-known class of self-inflicted outage.

The real power of `sudoers` is scoping access narrowly instead of granting blanket root: a line like `alice ALL=(ALL) /usr/bin/systemctl restart nginx` lets alice restart exactly that one service with sudo, and nothing else — no file access, no other commands, no full root shell. This is the least-privilege principle applied directly to system administration: grant exactly the access a role needs, not a convenient superset "to save time".

Every file has three permission sets — for its owner, its group, and everyone else ("others") — and three permission types within each: read (r), write (w), and execute (x). Run `ls -l` and the first ten characters of each line encode this: the first character is the file type (`-` for a regular file, `d` for a directory, `l` for a symlink), then three groups of three characters for owner/group/others permissions. `-rwxr-xr--` means: a regular file, owner can read/write/execute, group can read/execute, others can only read.

For directories specifically, permissions mean something slightly different than for files: read lets you list the directory's contents, write lets you create/delete/rename entries inside it, and execute lets you actually enter it (`cd` into it) or access files inside it by path — a directory with read but not execute permission will let you see filenames via `ls` but not open any of them, which surprises people the first time they hit it.

Numerically, each permission has a value — read=4, write=2, execute=1 — and you sum them per group: `rwx` = 4+2+1 = 7, `r-x` = 4+1 = 5, `r--` = 4. So `chmod 755 file` sets owner to rwx (7), group to r-x (5), others to r-x (5) — the standard permission for an executable script or directory others need to traverse. `chmod 644` (rw-r--r--) is the standard for a regular, non-executable file. `chmod 600` (rw-------) means only the owner can read or write it at all — the correct permission for anything containing a secret, like an SSH private key.

SUID (Set User ID), when set on an executable file, makes it run with the permissions of the file's owner rather than the user who launched it — this is how `passwd` lets a regular, unprivileged user update their own password even though `/etc/shadow` is only writable by root: the `passwd` binary itself runs as root momentarily via SUID, does the specific privileged write it needs to do, and exits.

SGID (Set Group ID) has two distinct effects depending on what it's applied to: on an executable, it runs with the file's group permissions instead of the invoking user's group. On a directory, it makes new files and subdirectories created inside automatically inherit that directory's group, instead of the creating user's primary group — genuinely useful for shared team directories where you want every new file to automatically belong to the team's group.

The sticky bit, applied to a directory, restricts deletion: even if multiple users have write access to that directory, each user can only delete or rename files they personally own within it. `/tmp` is the canonical example — everyone needs to write temporary files there, but you don't want any user able to delete another user's temp files.