File Permissions & Ownership

• Keeps secrets secret: a 600-mode file is readable only by its owner, so credentials, keys and configs never leak to other users on the same host.
• Root is one typo away from disaster: chmod -R 777 /etc can cripple a server, so disciplined permissions are a survival skill, not a nicety.
• Shared infrastructure works without root: directories owned by a shared group let whole teams read and write the same code safely.
• Containers and CI/CD bake permissions into images: deployments fail at startup when the runtime user cannot read config or write logs.
• Interview fundamentals: permission checks, setuid binaries and umask are core Linux internals every SRE is expected to explain cold.

Each file is a cabinet. The owner holds a personal key (user bits), the owner's group shares a team key (group bits), and everyone else can only read the label (other bits). Root is the building super who opens any cabinet regardless. Linux decides which key applies by checking the caller's identity once, from most specific to least.

• Every file is described by an inode that stores a numeric user id (uid), a numeric group id (gid) and a mode — a 16-bit number whose lower nine bits are the read/write/execute triples for user, group and other.
• The kernel resolves access on every system call: if the caller's uid matches the file owner, the user triple applies; otherwise if the uid is in the file's group, the group triple applies; otherwise the other triple applies — exactly one triple is ever consulted.
• Octal is a compact encoding: each triple is a 3-bit number where read = 4, write = 2, execute = 1, so chmod 755 means owner 7 (rwx), group 5 (r-x), other 5 (r-x). The three digits are additive, never decimal.
• The special bits live above the nine: setuid = 4000, setgid = 2000, sticky = 1000. chmod 4755 sets setuid, which makes an executable run with the file owner's privileges — this is why unprivileged users can change their password via /usr/bin/passwd.
• On directories the bits mean something extra: write lets you add or delete entries, execute lets you traverse into the directory, setgid makes new entries inherit the directory's group, and the sticky bit means only the owner (or root) can delete entries inside.

• Web servers run as a dedicated user (www-data) that can only read the web root — a compromised app process cannot rewrite its own code or configs.
• Setuid helpers are everywhere: /usr/bin/passwd, sudo and ping carry setuid root so unprivileged users can perform specific privileged operations without full root.
• Shared CI artifacts use setgid directories so every pipeline job writes into the same group without per-user chown dances.
• The sticky bit on /tmp and /run lets everyone create files but only their owner (or root) delete them, stopping denial-of-service via deletion of other users' sockets.
• Container images set read-only mounts and per-user ownership so a compromised container process cannot modify host-visible data.

• Apply least privilege: start at 600 or 700 and widen only as far as the app genuinely needs.
• Share with groups, never 777: chgrp a directory to the team group and chmod g+rwX instead of world-writable.
• Verify with stat -c '%a %U:%G %n' rather than eyeballing ls -l.
• Reserve setuid for packaged, reviewed binaries — never write your own setuid shell scripts.
• Keep secrets at 600 and owned by a dedicated service account, never world-readable.
• Audit for dangerous modes regularly: find / -type f -perm -0002 lists every world-writable file.

• Reaching for chmod 777 'to make it work' — it works until the host is compromised, then it is a gift to every user.
• Running chmod -R 777 on a whole tree, silently opening logs, sockets and configs you never thought about.
• Forgetting that directory write permission controls creating and deleting entries: a 777 directory means anyone can delete files they don't own unless the sticky bit is set.
• Assuming octal is decimal: 700 grants full access to the owner only, while 777 grants it to everyone.
• Changing ownership to a name when the kernel checks numbers — a typo'd uid can quietly hand files to the wrong account.

• ls -ld shows the directory's own mode; ls -l on the parent tells you whether you can actually create files inside it.
• stat -c '%a %u %g' prints mode, uid and gid numerically — compare those against id to catch mismatch.
• namei -l /path/to/file walks every path component and prints its permissions, revealing which ancestor blocks you.
• Test as the real user: sudo -u alice cat /srv/app.conf instead of reasoning about the model in your head.
• Watch for a trailing + in ls -l: that signals extended ACLs layered on top of the classic bits (getfacl shows them).