Linux File Permissions

Linux is a multi-user operating system: many accounts, plus background services, can share one machine. Every file and directory carries a set of permissions that decide who is allowed to read it, change it, or run it. These permissions are the first and most fundamental layer of access control on a Linux host. In cybersecurity this matters enormously. A huge share of real Linux incidents — data exposure, tampering, and privilege escalation — trace back to a permission that was set too loosely: a config file the whole system could read, a private SSH key readable by everyone, or a script directory anyone could write to and replace. Learning to read and set permissions correctly is a core defensive skill, not a formality.

Every file and directory has three permission bits — r (read), w (write), and x (execute) — and those three bits are defined separately for three classes of user: the owner, the file's group, and others (everyone else). That gives nine bits in total: rwx for owner, rwx for group, rwx for other. The catch students always trip on: r, w, and x mean different things on a directory than on a file.

The ls -l command prints a long listing. Its first field is a 10-character permission string. The first character is the file type; the next nine are the three rwx triplets for owner, group, and other. A dash (-) in any slot means that permission is absent.

After the permission string, the remaining fields are: link count, owner, group, size in bytes, last-modified date, and finally the name. Owner and group are exactly the two names that the owner and group triplets apply to.

The chmod (change mode) command sets permissions. Its symbolic form is built from three parts: who (u owner, g group, o other, a all), an operator (+ add, - remove, = set exactly), and the permissions (r, w, x). + and - are relative — they add or remove a bit and leave the rest alone. = is absolute — it sets that class to exactly what you list and clears anything else.

The octal form describes all nine bits with three digits — one per class, in the order owner / group / other. Each digit (0-7) is the sum of the permissions you want, where read = 4, write = 2, execute = 1. Add them up per class and you get the digit.

Permissions decide what each class may do; ownership decides who those classes are. chown changes a file's owner (and optionally its group), and chgrp changes just the group. Changing the owner normally requires root (via sudo), because otherwise anyone could hand off files to escape accountability. A regular user may change a file's group to any group they belong to.

Permissions are the frontline access control on a Linux host, and a single over-permissive file can quietly undo every other protection. A few lessons that come up again and again in the field: Secrets stay at 600. OpenSSH will refuse to use a private key such as ~/.ssh/id_rsa if group or other can read it, printing a "permissions are too open" error and failing the connection. The same 600 rule applies to API keys and credential files. World-writable is dangerous. If a script or its directory is writable by other, any account on the box can replace that script with malicious code that later runs with the owner's privileges. This is a classic path to privilege escalation. setuid programs are high-value targets. A setuid-root binary runs with root's power no matter who launches it, so a bug in one can hand an attacker full control. Defenders inventory them with find / -perm -4000 -type f 2>/dev/null and keep the list short.

Work through these on a Linux shell (a VM or a class sandbox) to make the rwx model stick: 1. Run touch practice.txt (touch makes an empty file) then ls -l practice.txt. Read off the rwx string and convert it to octal. What did your umask give the file, and does it match the 644 default? 2. Run chmod 640 practice.txt. Before you run ls -l again, write down the exact rwx string you expect (owner, group, other), then check yourself. 3. Run mkdir vault (mkdir makes a new folder) and chmod 700 vault. In one sentence, explain why a private directory needs 700 and not 600 — which permission lets the owner actually enter it, and what breaks without it?

Using ls-l-listing.txt, work out each answer by reading the permission string yourself (or check it with grep): 1. Exactly one file in the listing has the setuid bit set (an s in the owner's execute slot, position 4 of the permission string). Which file is it? 2. Exactly one file has the setgid bit set instead (an s in the group's execute slot, position 7). Which file is it? 3. Convert shared-notes.txt's permission string to a three-digit octal mode. 4. Of id_rsa, config.yaml, and shared-notes.txt, only one is at mode 600 or stricter — the only one OpenSSH would actually accept as a private key without refusing it as "too open." Which file is it?