Permissions

What is it? #

Every file and directory has an owner, a group and three sets of permissions: for the owner, for the group, and for everyone else.

Each set has three bits: read, write and execute. That is the whole model, and it covers most of what you need on a server.

The numbers people use — 644, 755 — are just those bits written in octal. Read is 4, write is 2, execute is 1, added together per set.

Execute means something different for directories. On a file it means "can be run"; on a directory it means "can be entered", which is why directories are usually 755 and files 644.

Think of it like this #

A shared building. Each room has a nameplate for the owner, a department label, and a rule for everyone else.

Entering a corridor is different from reading a document inside a room. That is exactly the difference between execute on a directory and read on a file.

Simple example #

An application needs to read its configuration but not modify it, write to a log directory, and execute a deployment script. Each needs different permissions, and getting them wrong either breaks the service or exposes secrets.

Code #

ls -l
# -rw-r--r-- 1 appuser appgroup  1240 Sep 22 10:15 config.yml
# drwxr-xr-x 2 appuser appgroup  4096 Sep 22 10:15 static/
# -rwxr-x--- 1 appuser appgroup   820 Sep 22 10:15 deploy.sh

# - rw- r-- r--
# │  │   │   └── others:  read
# │  │   └────── group:   read
# │  └────────── owner:   read, write
# └───────────── type: - file, d directory, l symlink

The numbers

read    r = 4
write   w = 2
execute x = 1

644 = rw- r-- r--     normal file: owner writes, everyone reads
600 = rw- --- ---     private file: only the owner, used for secrets and keys
755 = rwx r-x r-x     directory or script: everyone can enter or run
750 = rwx r-x ---     directory for owner and group only
700 = rwx --- ---     fully private directory

# Setting permissions
chmod 644 config.yml            # numeric
chmod u+x deploy.sh             # letters: add execute for the owner
chmod g-w,o-rwx secrets.env     # remove group write, remove all for others
chmod -R 755 static/            # recursive

# A safer recursive pattern: directories 755, files 644
find /srv/app -type d -exec chmod 755 {} \;
find /srv/app -type f -exec chmod 644 {} \;

# Ownership
sudo chown appuser config.yml
sudo chown appuser:appgroup config.yml
sudo chown -R appuser:appgroup /srv/app

# Files that must be locked down
chmod 600 ~/.ssh/id_ed25519     # SSH refuses to use a key others can read
chmod 700 ~/.ssh
chmod 600 /srv/app/.env         # environment file with secrets

Execute on a directory

read (r)     you may list the names inside
write (w)    you may create and delete entries inside
execute (x)  you may enter it and access things through it

A directory with r but no x lets you see the names but not open anything.
Every directory in a path needs x for the file at the end to be reachable.

How it works #

The ten characters in ls -l are the file type followed by three permission triplets. Reading them left to right — owner, group, others — becomes automatic quickly.

The octal numbers add the bits per set. 6 is read plus write, 7 is all three, 5 is read plus execute. That is why 755 and 644 appear everywhere.

chmod u+x uses letters instead: u owner, g group, o others, a all, with +, - or =. It is clearer when changing one bit without touching the rest.

Blanket chmod -R 755 on a mixed tree makes every file executable, which is untidy and occasionally dangerous. The find pair applies different permissions to directories and files, which is what you almost always want.

SSH enforces permissions on private keys. A key readable by others is refused outright, which is a deliberate and helpful strictness.

The directory execute rule explains a common confusion. If any directory in the path lacks execute for your user, the file at the end is unreachable regardless of its own permissions.

umask decides default permissions for new files. The usual value of 022 means new files are 644 and new directories 755.

Real-world use #

The two permission mistakes that cause real harm are the opposite extremes. chmod 777 on a web directory allows any process to modify your application; overly strict permissions break the service in ways that look mysterious.

Secrets deserve 600 and an owner check. An .env file readable by other accounts on a shared machine is a credential leak waiting to happen.

Uploaded files should never be executable. A writable upload directory combined with execute permission is how a file upload becomes remote code execution.

Web servers need read access to static files and execute on every directory in the path. Missing execute on a parent is a frequent cause of a 403 that makes no sense at first glance.

For finer-grained needs, ACLs exist, but the standard owner-group-others model covers the vast majority of server work.

Common mistakes #

• Using chmod 777 to make something work instead of finding the real problem.
• Recursive chmod 755 making every file executable.
• Leaving .env and key files readable by group or others.
• Forgetting that every parent directory needs execute for a path to be usable.
• Changing permissions when the actual problem was ownership.

Practice #

Create a directory with a config file, a script and a secrets file. Set them to 755, 644, 755 and 600 respectively, with the correct owner. Then remove execute from the directory and observe exactly which operations start failing.