Learn Linux - File Permissions & Ownership

#Introduction

After episode 8 where we covered user & group management — how to create identities and group them — in this episode we'll discuss what those identities are allowed to do to files: file permissions & ownership.

Why is this topic important? Users and groups are only half of the Linux security model. The other half is the rules: who can read a config file containing credentials? Who can run a script? Who can write to a shared directory? Without understanding permissions, you'll be trapped between two extremes: too strict so applications break, or too loose (chmod 777 everywhere) so the server becomes an open door.

In this episode we'll cover: first, the basic permission model and the read/write/execute bits; second, octal vs symbolic chmod; third, chown and chgrp for ownership; fourth, umask as the default value; fifth, the special bits SUID, SGID, and the sticky bit; finally, a case study securing SSH key files and shared directories.

#Main Discussion

#The Basic Permission Model: Read, Write, Execute

Every file in Linux has an owner, a group, and the others category. For each category, there are three permission bits:

The octal values (4, 2, 1) aren't a coincidence — it's a binary system: combined bits sum to a single 0–7 digit. 7 = 4+2+1 (rwx), 6 = 4+2 (rw-), 5 = 4+1 (r-x), 4 = r--.

ls -l /etc/hosts

-rw-r--r-- 1 root root 204 Agu  1 08:00 /etc/hosts

Let's break down the output -rw-r--r--. The first character indicates the file type (- regular file, d directory, l symlink). The next nine characters are three triplets: rw- for the owner (root), r-- for the group (root), r-- for others. So /etc/hosts can be read by everyone, but only root can write.

#Inspecting Permissions in Depth with stat

If ls -l is the "summary", stat is the "full card" — showing permissions in both symbolic and numeric form, plus other metadata:

stat -c "%A %a %U:%G" /etc/hosts

-rw-r--r-- 644 root:root

The %A format shows the rwx string, %a shows the octal number (644), %U:%G shows owner:group. When you need to confirm "which owner does this 600 file belong to", stat -c "%a %U:%G" answers in one line — far easier to read than guessing from ls -l.

#chmod: Changing Permissions

chmod changes the permission bits. There are two styles: octal (numbers) and symbolic (letters). Both produce the same result — choose whichever is easier to read in context.

#The Octal Style

chmod 755 skrip.sh
chmod 644 konfig.conf
chmod 600 rahasia.txt

The three octal digits are respectively for owner, group, others: 755 = rwxr-xr-x, 644 = rw-r--r--, 600 = rw-------. Note that the owner (you) must have write on a file to modify its contents later — that's why 600 is for files you write, 755 for executables others may run.

#The Symbolic Style

Symbolic mode works with u (user/owner), g (group), o (others), a (all), plus the operators +, -, =:

chmod u+x skrip.sh
chmod g-w konfig.conf
chmod go= rahasia.txt

The diff below shows the command to make a script executable — before and after:

chmod +x deploy.sh
chmod u+x deploy.sh

chmod +x gives execute to all categories (a+x); chmod u+x restricts it to the owner only — a more conservative and commonly used choice.

#chown and chgrp: Changing Ownership

Permissions only mean something if the ownership is correct. chown changes the owner and group; chgrp changes only the group:

sudo chown budi:webapps /var/www/proyek
sudo chown -R budi:webapps /var/www/proyek

#umask: Setting Default Permissions

When you create a file, it isn't born with arbitrary permissions — the default value is set by umask. umask is a "mask" that subtracts permission bits from a base value:

umask
touch baru.txt
ls -l baru.txt

0022
-rw-r--r-- 1 dev dev 0 Agu  2 09:00 baru.txt

With umask 0022, new files are born 644 (666 - 022 = rw-r--r--) and new directories 755 (777 - 022). The base logic: 666 for files (never executable by default), 777 for directories.

#Special Bits: SUID, SGID, and the Sticky Bit

Three special bits complete the basic permission model — each changes the behavior of executables or directories.

The best-known SUID example is passwd — displayed as -rwsr-xr-x. This file is owned by root, but regular users are allowed to run it; thanks to SUID, the process runs with root rights so it can write to /etc/shadow. That's how users can change their own password without becoming root.

chmod 4755 alat-ku   # SUID
chmod 2755 alat-ku   # SGID
chmod 1777 /tmp      # sticky bit

The sticky bit is the one you'll see most often — check /tmp:

drwxrwxrwt 1 root root 4096 Agu  2 09:00 /tmp

The t at the end marks the sticky bit as active: everyone can create files in /tmp, but only the file's owner (or root) can delete them — preventing user A from deleting user B's files in a shared directory.

#Case Study: Securing SSH Keys and Shared Directories

Now let's apply all the concepts in two real scenarios.

#Scenario 1: SSH Key with chmod 600

SSH refuses to use a private key with overly loose permissions — and this is deliberate, for security. When a new key is created, make sure its permissions are correct:

chmod 600 ~/.ssh/id_ed25519
ls -l ~/.ssh/id_ed25519

600 means only the owner can read/write — the credential isn't readable by other users. If a key is accidentally created with 644, ssh will refuse with the message Permissions too open; chmod 600 is the cure.

#Scenario 2: A Secure Shared Directory

The webapps group (from episode 8) wants to share a directory with these rules: all members can write, new files automatically get the webapps group, and only the owner can delete their own files. The command sequence:

sudo mkdir -p /srv/webapps
sudo chown root:webapps /srv/webapps
sudo chmod 2750 /srv/webapps

Breaking down the three lines: chown root:webapps makes the owning group webapps; chmod 2750 means 2 (SGID) + rwxr-x--- — the group can enter and write, others can't at all; SGID ensures every new file inside automatically gets the webapps group, so all members can work with each other's files without waiting for an admin to change each file's group.

#Common Pitfalls

#Conclusion

In this episode 9, we've covered Linux's complete permission model: the read/write/execute bits for owner, group, and others; chmod in octal and symbolic styles; chown/chgrp for ownership; umask as the default value when files are born; the special bits SUID, SGID, and the sticky bit; and two real case studies — securing SSH keys and building a secure shared directory.

Key takeaways:

• Permissions are the rwx triplet × 3 categories — and x means something different for files vs directories.
• Octal (755, 600) is concise; symbolic (u+x, g-w) is explicit — master both.
• 777 fixes the symptom, not the problem — always seek the minimum permission.
• umask determines default permissions — 0027/0077 are far stricter than 0022.
• SUID, SGID, the sticky bit grant special powers — use them with full awareness, especially SUID.

With this episode, your Linux administration foundation — basic commands, pipelines, text processing, backups, users/groups, and permissions — is complete. In the next episode 10, we'll shift to Package Management — getting to know apt, dnf, and the differences between distro ecosystems, understanding the repository concept, searching for and installing software, through to managing system updates safely. Stay motivated, because from here you start assembling a production-ready server!