Permissions, Users & sudo

Every file you've touched so far quietly answered a question you never asked: are you allowed? Linux was designed from the start for computers shared by many people, so it tracks, for every file, who owns it and what each person may do with it. That system is permissions — and understanding it is the difference between confidently administering a server and being mystified by "permission denied." This chapter makes the whole model legible.

Why permissions exist at all

Your personal laptop feels like it's yours alone, but Linux never assumes that. It grew up on university and lab machines where dozens of people shared one computer, and that heritage runs deep: every file and folder records who owns it and who's allowed to do what. Even on a solo laptop, that same machinery protects the system's own files from being changed by accident, and keeps programs from stepping on each other.

The moment it stops being abstract is your first real server. A production machine has your account, your teammates' accounts, and accounts for the programs themselves (the web server runs as its own limited user). Permissions are what stop a compromised web app from reading everyone's private keys, and what stop a typo in your home folder from damaging the operating system. They're the fabric of security and safety on every Linux box you'll ever touch.

The whole model: three actions, three audiences

Here's the entire system in one breath. There are three things you can do to a file, and Linux tracks each separately for three groups of people.

The three actions:

• read (r) — look at the file's contents (or, for a folder, list what's inside).
• write (w) — change the file (or, for a folder, add and remove files in it).
• execute (x) — run the file as a program (or, for a folder, enter it with cd).

The three audiences:

• owner — the single user who owns the file (usually whoever created it).
• group — a named set of users who share access (say, everyone on the developers team).
• others — everyone else on the system.

That's it. Every permission question reduces to "which of read/write/execute does this file grant to owner, to group, and to others?" Nine yes/no answers in total.

Reading the rwx string

Run ls -l and every line begins with a ten-character code that spells out those nine answers. Let's decode a real one:

-rwxr-xr--  1  raghav  developers  8192  Jul 17  app.py

That leading block, -rwxr-xr--, breaks into four pieces:

-        rwx        r-x        r--
type    owner      group      others

• The first character is the type: - for a normal file, d for a directory, l for a link.
• The next three (rwx) are the owner's permissions: read, write, execute — all granted.
• The next three (r-x) are the group's: read and execute, but not write (the w is a dash).
• The last three (r--) are everyone else's: read only.

So this file is owned by raghav, associated with the developers group, and reads as: Raghav can do anything to it; developers can read and run it but not change it; everyone else can only read it. A dash always means "this permission is denied." Once you can read this string at a glance, you can look at any file and know exactly who can do what.

Changing permissions: chmod

chmod (change mode) sets those permission bits. The friendliest way to use it is the symbolic form — you name who, whether you're adding or removing, and which permission:

$ chmod +x deploy.sh          # make a script runnable (add execute for all)
$ chmod u+w notes.txt         # give the owner (u) write permission
$ chmod g-w report.txt        # take write away from the group (g)
$ chmod o-r secret.txt        # remove read for others (o)

Here u is owner (user), g is group, o is others, and a is all; + grants and - revokes. The single most common use by far is chmod +x — a script you just wrote won't run until you mark it executable, and this is the fix.

You'll also see a numeric form that looks cryptic at first: chmod 755 file. Each digit is one audience (owner, group, others), and the number encodes the three bits by adding read=4, write=2, execute=1. So 7 is 4+2+1 = rwx, 5 is 4+1 = r-x, and 755 means rwxr-xr-x — the standard for a program or folder. 644 (rw-r--r--) is the standard for a regular file: owner can edit, everyone else can only read. You don't need to love the numbers, but you'll recognise 755 and 644 everywhere.

Changing ownership: chown

Permissions decide what each audience may do; chown (change owner) decides who the owner and group actually are:

$ sudo chown raghav report.txt              # make raghav the owner
$ sudo chown raghav:developers report.txt   # set owner AND group

Changing ownership is itself a privileged act — you generally can't give away or seize files freely, which is why chown almost always needs sudo (coming up next). It matters most on servers: when you copy files as an admin, they often end up owned by root, and the application that needs to read them can't, until you chown them to the right user. "The app can't read its own config" is very often really "the config is owned by the wrong user."

root: the user with no rules

Every Linux system has one special account called root, also known as the superuser. root is exempt from every permission check — it can read, change, or delete any file, regardless of the rwx bits. That's not a loophole; it's the point. Someone has to be able to install software, edit system configuration, and manage other users, and root is who does it.

That power is also the danger. Because root ignores all the safety rails, a careless command run as root can delete critical system files or wreck the machine with no "permission denied" to stop it. The infamous horror stories of the command line are almost all root running something destructive against the wrong target.

sudo: borrow root for one command

sudo (superuser do) runs a single command as root, then hands control straight back to your normal user. You prefix the command with sudo, it asks for your password to confirm it's really you, and it runs just that one line with root's power:

$ sudo apt install nginx           # install software (needs root)
$ sudo systemctl restart nginx     # restart a system service
$ sudo chown raghav config.yml     # fix ownership on a protected file

Three things make sudo the safe choice over logging in as root. It's scoped — only the one command runs elevated, so the rest of your session stays protected. It's deliberate — typing sudo and your password is a conscious "yes, I mean this," a speed bump before anything dangerous. And it's audited — every sudo command is logged, so on a shared server there's a record of who did what. Living as root gives up all three.

A word of caution to carry forward: treat sudo rm, and anything sudo touching system directories, with real deliberateness. The permission system is the safety net that catches your everyday mistakes — and sudo is you briefly stepping over that net on purpose. Read the line, then run it.

What you can now reason about

Permissions stop being a wall of cryptic letters once you hold the shape: three actions (read, write, execute), three audiences (owner, group, others), read them from the rwx string, change them with chmod, change ownership with chown, and reach for sudo — never a permanent root login — when a task genuinely needs elevated power. That model explains almost every "permission denied" you'll meet, and it's core to keeping a server secure.

So far we've dealt with files sitting still. Next we bring the system to life: processes — the running programs on a machine — how to see them, how to stop a misbehaving one, and how they claim the network ports that let your app answer requests.