In the previous lesson you read app.log and shipments.csv without trouble, but sooner or later you will run into a Permission denied when trying to write to /var/log/veloz or when running your first script from ~/veloz-ops/bin. Permissions are not an administrative obstacle: they are the mechanism that stops a bug in veloz-api from deleting the business data, or any user on the system from reading the payment gateway credentials. In this lesson you will learn to read them, to modify them with judgment, and to leave ~/veloz-ops and /srv/veloz/data properly protected.

1. The user / group / others model
2. Reading the output of ls -l field by field
3. What x means on a file and what it means on a directory
4. Symbolic chmod
5. Octal chmod
6. Ownership: chown, chgrp, id and groups
7. umask: the default permissions
8. Special bits: sticky, setgid and setuid
9. sudo and the principle of least privilege
10. Hands-on case: securing the Veloz Envíos toolkit and data

Every file and every directory in Linux has one owner (a user) and one group. From there, permissions are defined for three classes of subject:

And for each class there are three permissions:

The evaluation rule is important and surprises a lot of people: the system checks only the first class that matches. If you are the owner, the u permissions apply and the g and o ones are never looked at, even if they were more permissive. A file with permissions ----rwxrwx is unreadable for its owner and accessible to everyone else.

The fields, in order, are: type and permissions (-rw-r-----), number of hard links (1, a topic for 05-01), owner (veloz), group (veloz), size in bytes (21504), last modification date and name. The interesting part is the first ten characters:

• Type -: regular file. It would be d for a directory and l for a symbolic link.
• u = rw-: the user veloz can read and write, but not execute.
• g = r--: the members of the veloz group can only read.
• o = ---: the rest of the system cannot even open it.

That is exactly the design we want for business data: the application writes, the operations team reads, nobody else sees anything.

This distinction is the number one source of confusion with permissions.

On a file, x means "the system may attempt to run it as a program". Without x, a perfectly written script fails with bash: ./daily-report.sh: Permission denied.

On a directory, x means something completely different: permission to traverse it. Without x on a directory you cannot cd into it, nor reach anything inside it, not even files you do have read permission on.

From that, three combinations follow that are worth being clear about:

The --x combination is the one websites use for configuration directories: you can get in if you know the path, but you cannot browse. And the most useful practical consequence: if a read permission on a file does not work, check the x on every directory along the path. It only has to be missing on one for the whole path to be inaccessible.

chmod (change mode) modifies permissions. In its symbolic form it reads almost like a sentence: chmod [who][operator][permissions] file.

The difference between + and = is crucial: +r adds read while keeping everything else, whereas =r sets that class's permissions to exactly read, removing write and execute if it had them. When you want a deterministic state, use =.

chmod accepts -R to apply recursively, but use it carefully: chmod -R 755 over a tree turns data files that should not be executable into executables. Later on, with find (05-01), you will learn to apply different permissions to files and directories in a single pass.

The octal form is the one you will see in documentation and scripts, because it is compact and deterministic. Each permission has a numeric value and they add up:

r is worth 4, w is worth 2 and x is worth 1. Adding those values gives the eight possible digits:

You write three digits, one per class: user, group, others. The cases that cover 95 % of practice:

A quick mental rule for converting: think of rwx as three switches worth 4, 2 and 1. rw- = 4+2 = 6; r-x = 4+1 = 5; r-- = 4.

Before changing ownership, check who you are:

id shows your user, your primary group and all the secondary groups you belong to. groups gives the short version. The fact that joan is in the veloz group is what lets him read the 640 files owned by veloz.

Two important notes:

• Changing the owner requires root. A normal user cannot "gift" a file to someone else, because that would allow disk quotas to be bypassed and files to be slipped into other people's space.
• Changing the group can be done by the owner, as long as he himself belongs to the destination group.

Adding a user to a group is done with sudo usermod -aG veloz joan. The -a (append) is mandatory: without it, usermod replaces the list of secondary groups instead of adding to it, a classic mistake that leaves someone locked out of sudo. Group changes do not affect sessions that are already open: you have to log out and log back in.

When you create a file, why does it come out with 644 and not 777? Because the system starts from a base set of permissions and subtracts the bits indicated in the umask.

The base permission is 666 (rw-rw-rw-) for files and 777 for directories; the umask turns off bits on that base (it does not subtract arithmetically). Notice that files are never born executable: their base does not include x. That is deliberate, and that is why you have to run chmod +x explicitly on every new script.

You change it with umask 077, and to make it permanent you add it to ~/.bashrc (lesson 01-02). Careful: the umask only affects files created afterwards; it does not modify existing ones.

Besides the nine rwx bits there are three special bits, which show up as a fourth octal digit on the left.

Sticky bit (1000) — On a directory that is writable by everyone, it stops one user from deleting another's files. It is what protects /tmp:

ls -ld /tmp shows drwxrwxrwt. That trailing t is the sticky bit: without it, any user could delete everyone else's temporary files. It is applied with chmod 1777 dir or chmod +t dir.

Setgid (2000) — On a directory, it makes everything created inside inherit the directory's group instead of the primary group of whoever creates it. It is the key piece of shared directories:

The s in the position of the group's x indicates setgid. From now on, any CSV that veloz-api or any member of the team leaves there will belong to the veloz group and will be readable by the whole team with no manual intervention.

Setuid (4000) — On an executable, it makes it run with the privileges of its owner, not of whoever launches it. It is how passwd can modify /etc/shadow while you are a normal user.

Serious warning: setuid is a first-order attack vector. A root-owned setuid executable with a programming bug hands over the entire system. Never set setuid on a shell script —many systems ignore it precisely for that reason— and do not apply it to your own programs unless you know exactly what you are doing. Defense in depth is covered in 08-03.

sudo runs one specific command with root privileges, leaving a record in /var/log/auth.log of who did what and when. That trail is the main reason it is preferred over logging in as root.

The principle of least privilege says that every process and every person should have exactly the permissions they need, not one more. Translated into your day-to-day:

• Always work as a normal user; use sudo only for the command that requires it.
• Avoid sudo su - and long-running root sessions: you lose the audit trail and the safety net disappears.
• Solve access problems with groups, not by handing out sudo. Operations being able to read /srv/veloz/data is a question of veloz group membership, not of administrator privileges.
• Be suspicious of chmod 777. It is the quick answer to a Permission denied and almost always the wrong one: it leaves the file writable by any process on the machine. The correct solution is to adjust the owner or the group.

The reasoning behind each decision:

• 755 on the script: it needs x to run. It holds no secrets, so r-x for group and others is harmless and makes it easy for a colleague to audit it.
• 600 on the configuration: as soon as it stores an API key, any read permission for "others" is equivalent to publishing it. 600 is non-negotiable on files with credentials.
• 2775 on the directory: 775 gives the veloz group control over the content; the leading 2 (setgid) guarantees that new files inherit that group automatically.
• 640 on the CSV: the owner (the application) writes, the team reads, nobody else sees the business data.

• Answering a Permission denied with chmod 777. It works, and it opens a hole. Ask yourself first who should have access and fix it with owner or group.
• Forgetting the x on the directories along the path. If cat /srv/veloz/data/shipments.csv fails despite you having read permission on the file, check ls -ld /srv and ls -ld /srv/veloz.
• Using chmod -R 755 over a mixed tree. It turns data files into executables. Apply different permissions to files and directories (with find, 05-01).
• Confusing +r with =r. The first adds, the second sets the exact state.
• usermod -G without -a. It replaces the secondary groups instead of adding and can lock you out of sudo.
• Expecting a group change to take effect immediately. You have to log out and log back in.
• Leaving a credentials file at 644. It is the most frequent security flaw and the easiest one to avoid.

Exercise 1 — Reading permissions. Interpret these three ls -l lines by saying, for each one, what the owner can do, what the group can do and what everyone else can do, and express its permissions in octal:

Exercise 2 — The script that will not start. You have created ~/veloz-ops/bin/shipment-summary.sh with an editor and when you launch it you get Permission denied. ls -l shows -rw-rw-r--. Explain the cause, fix it in two ways (symbolic and octal) and justify why the file was born without x.

Exercise 3 — Designing the permissions of a shared directory. The operations team (group veloz, three people) needs a /srv/veloz/reports directory where everyone can create reports and read everyone else's, but where nobody can delete somebody else's report and where users outside the group see nothing. Write the commands and explain each bit.

Solution to Exercise 1

On data, the s takes the place of the group's x: the x is still active (if it were not, you would see an uppercase S) and on top of that there is the setgid bit, which in octal is the leading 2.

Solution to Exercise 2

Cause: the file has no x bit in any class, so the kernel refuses to run it, even though its content is a valid script. Why it was born without x: files are created with base permissions 666 (rw-rw-rw-), with no execute in any case, and the umask 022 additionally removes write from group and others, leaving 644. The system never marks a file as executable on its own: it is a conscious decision that a person has to take, and that is precisely the protection.

Solution to Exercise 3

Breakdown of 3770:

• 770: owner and the veloz group have rwx (list, create, enter); others have nothing, which meets the invisibility requirement for outside users.
• 3 = 2 + 1, that is, two special bits at once:
  • 2 (setgid): the reports created inside will belong to the veloz group regardless of the primary group of whoever creates them, so the whole team can read them.
  • 1 (sticky): even though everyone has w on the directory, each user can only delete or rename their own files. It is the same mechanism that protects /tmp.

The trailing uppercase T indicates a sticky bit without x permission for others; if others had x you would see a lowercase t. This directory is the canonical example of how the special bits solve a collaboration requirement that the nine rwx bits cannot express.

You can now read an ls -l line field by field, tell apart the role of the x bit on files and on directories —the hidden cause of so many "permission denied" messages— and modify permissions in both symbolic and octal form, with the four patterns that solve almost everything: 644, 755, 600 and 700. You control ownership with chown and chgrp, you know how to check your groups with id, you understand why the umask decides the permissions of every new file, and you know the three special bits, including the setgid that makes a real shared directory work. And above all, you have the judgment: least privilege, groups before sudo, and never 777.

~/veloz-ops is left with its script executable and its configuration locked down to 600, and /srv/veloz/data with the veloz group and automatic inheritance. Defense in depth —command injection, safe temporary files, secret management— is tackled in 08-03.

In lesson 02-04 comes the piece that multiplies everything you have learned: redirection and pipes. You will learn to separate normal output from errors, to save results into files, to discard noise with /dev/null and to chain the Module 2 filters into pipelines that answer complex questions about access.log in a single line.