Mastering Linux File Permissions: A Comprehensive Guide to -rw-r–r–

Run `ls -l` on any Linux box and you'll see strings like `-rw-r–r–` attached to every file. That ten-character line is the fastest security audit you have: in one glance it tells you who can read, modify or run each file on the system. This guide decodes it completely — then shows you how to set permissions correctly with `chmod`, fix ownership with `chown`, and avoid the classic mistakes (looking at you, `chmod 777`). Whether you're on Ubuntu, Debian, Fedora or anything else in the Linux family, the permission model is identical.

Quick Answer: `-rw-r–r–` means a regular file that the owner can read and write, while the group and everyone else can only read — the octal equivalent is 644. Position 1 is the file type, characters 2–4 are the owner's permissions, 5–7 the group's, and 8–10 everyone else's.

Decoding `-rw-r–r–` Character by Character

So `-rw-r–r–` is a regular file the owner can edit, everyone else can only view. In numeric form that's 644 — and it's the default you'll see on most text files, configs and web assets.

Two everyday variations worth recognizing instantly: `drwxr-xr-x` (755) is a directory everyone can enter and traverse but only the owner can modify, and `-rwxr-xr-x` (755) is a script or binary anyone can run.

What r, w and x Actually Do

The three permission letters mean different things depending on whether they're on a file or a directory — and the directory meaning is the one that trips people up:

The subtle one: execute on a directory is the license to traverse it. Remove `x` and users with `r` can list filenames but can't open anything inside — a classic cause of mysterious "Permission denied" errors where the file's own permissions look fine.

Changing Permissions with chmod

Symbolic mode (who + op + what)

“`bash

chmod g+rw example.txt # add read+write for the group

chmod o-r notes.md # remove read for others

chmod u+x script.sh # make a script executable

chmod a=r file.txt # set exactly read for everyone (a = ugo)

“`

Who can be `u` (owner), `g` (group), `o` (others) or `a` (all); the operator is `+` (add), `-` (remove) or `=` (set exactly).

Octal mode (the numbers)

Each class gets one digit: read = 4, write = 2, execute = 1, summed:

“`bash

chmod 644 report.txt # owner rw, group r, others r (= -rw-r–r–)

chmod 755 deploy.sh # owner rwx, everyone else rx (= -rwxr-xr-x)

chmod 600 ~/.ssh/id_ed25519 # private key: owner only — ssh enforces this

“`

Add `-R` to apply recursively (`chmod -R 755 /var/www`), and use `X` (capital) to add execute only to directories and files that already have it — far safer than blanket-777-ing a web tree.

Ownership: chown and chgrp

Every file carries one owner and one group. Permissions only make sense relative to them:

“`bash

sudo chown johndoe example.txt # change owner

sudo chgrp developers example.txt # change group

sudo chown johndoe:developers app/ # both at once, recursively with -R

“`

Two ownership facts solve most web-server mysteries: the web server process (e.g. `www-data` on Debian/Ubuntu) can only read files its own user or group permits — and a file's group can be any group you're in, which is how teams share directories without sharing accounts.

Special Permissions: setuid, setgid, Sticky Bit

Three extra bits extend the rwx model, and they replace `x` in `ls -l` output:

• setuid (`s` in the owner slot, octal +4000): the program runs with the owner's identity. `passwd` uses it so a normal user can edit the root-owned `/etc/shadow`.
• setgid (`s` in the group slot, +2000): on files, runs with the group's identity; on directories, new files inherit the directory's group — ideal for shared team folders.
• Sticky bit (`t` in the others slot, +1000): on directories, only the file's owner (or root) can delete their own files. `/tmp` is the textbook case: `drwxrwxrwt`.

“`bash

chmod 2775 /srv/shared # setgid + rwx for owner/group, rx for others

chmod +t uploads/ # add the sticky bit

find / -perm -4000 -type f # audit every setuid binary on the system

“`

Treat setuid with respect: it's the classic privilege-escalation vector, which is why auditors hunt unexpected setuid binaries.

Defaults with umask

`umask` strips permissions from every new file. A common server umask of `022` means new files arrive as 644 and new directories as 755 — which is exactly why those values are everywhere. Check yours with `umask`, set it per-session with `umask 022`, and make it permanent in `~/.bashrc` or `/etc/profile`. If your new files keep appearing with odd permissions, your shell's umask is the first place to look.

Best Practices

• Least privilege by default. 644 for files, 755 for directories and executables. Start narrower and widen only when something actually breaks.
• Never `chmod 777` to "fix" a problem. It's world-writable — any process or user can alter the file. If a web app demands it, the real bug is ownership: `chown` the tree to the web server's user instead.
• Guard the door. SSH private keys (600, `.ssh` directories 700), credentials and config secrets should be owner-only.
• Use groups for sharing. A shared group with setgid on the directory beats scattering write access across users.
• Audit periodically. `find / -perm -4000` for setuid surprises, and review world-writable files with `find / -type f -perm -o+w`.

Server hardening goes beyond permissions — our cloud server security guide covers the wider picture, and our Linux servers primer is the starting point if you're new to running one.

Troubleshooting Common Permission Problems

"Permission denied" on a file you own? Check the path, not just the file — every parent directory needs `x` for you. `namei -l /path/to/file` prints the whole chain's permissions.

Can list files but not open them? You have `r` on the directory but not `x`. Add it: `chmod +x directory`.

Deleted a file by mistake? Permissions don't protect against `rm` — write access to the directory is what deletion requires. Recovery depends on backups, and our drive-failure recovery steps explain your options; tools like R-Studio can attempt recovery, and our R-Studio review covers when that's worth it.

"Permission denied" with sudo too? You're probably hitting an immutable file (`lsattr`, remove with `chattr -i`) or a read-only mount (`mount | grep ro`), not a permission bit.

Frequently Asked Questions

What does -rw-r–r– mean in Linux?

It's a regular file (`-`) where the owner can read and write, the group can read, and everyone else can read — permissions 644. It's the standard default for documents and config files on most distributions.

How do I change -rw-r–r– to executable?

Run `chmod +x filename` (or `chmod 755 filename` to get `-rwxr-xr-x`). The owner gains execute immediately; use `chmod a+x` if every user should be able to run it. Verify with `ls -l`.

What's the difference between chmod 644 and 755?

644 (`rw-r–r–`) is for data files — the owner edits, others read. 755 (`rwxr-xr-x`) adds execute for everyone and is standard for directories, scripts and programs. Putting 755 on a plain data file is usually a sign someone was fighting a directory-traversal problem.

Is chmod 777 ever safe?

Almost never. It lets every account and process on the system modify the file, which is both a security hole and a debugging trap. For web servers, the fix is ownership (`chown -R www-data:www-data` or a shared group), not world-writable permissions.

What is the difference between rwx for files and directories?

For files, `r` reads contents, `w` edits, `x` executes. For directories, `r` lists names, `w` creates/deletes entries, and `x` grants the ability to enter and access anything inside. Directory `x` is required for practical access even when `r` is present.

Related reading:

• What Is Cloud Server Security? A Complete Guide
• Linux Servers: A Primer
• From Emergency to Recovery: Recovering from a Failed Drive

Have a permissions puzzle that cost you an afternoon? Share it in the comments — the weirder the better.