Linux File Permissions Explained: chmod, chown and umask for Developers

Linux file permissions control who can read, write, and execute files. Get them wrong and you either lock yourself out of your own files or leave sensitive data readable by anyone on the server. This guide explains the permission model from first principles.

The Permission Model

Every file and directory on a Linux system has three types of permissions applied to three groups of users:

GroupWho it applies to
Owner (u)The user who owns the file
Group (g)Users who are members of the file's assigned group
Others (o)Everyone else on the system

Each group gets three independent permission bits:

  • Read (r) — view the file contents / list the directory
  • Write (w) — modify the file / create or delete files in the directory
  • Execute (x) — run the file as a program / enter (traverse) the directory

Reading the Symbolic Notation

When you run ls -la, you see permissions in symbolic notation:

-rwxr-xr-x  1  alice  devs  4096  Mar 22  deploy.sh
drwxr-xr-x  2  alice  devs  4096  Mar 22  scripts/

The first character is the file type (- for regular file, d for directory, l for symlink). The next 9 characters are three groups of three permission bits:

rwx r-x r-x
│   │   └── Others: read, no write, execute
│   └─────── Group: read, no write, execute
└─────────── Owner: read, write, execute

Understanding Octal Notation

Each permission bit is a binary 1 (enabled) or 0 (disabled). The three bits in each group map to a single octal digit: read = 4, write = 2,execute = 1. Add the values of enabled bits to get the digit.

BinarySymbolicOctalMeaning
111rwx7read + write + execute
110rw-6read + write only
101r-x5read + execute only
100r--4read only
000---0no permissions

So chmod 755 means: owner=7 (rwx), group=5 (r-x), others=5 (r-x).

Common Permission Patterns

OctalSymbolicUse case
755rwxr-xr-xExecutables, binaries, shell scripts, directories
644rw-r--r--Config files, web assets, documentation
600rw-------SSH private keys, .env files, secret credentials
700rwx------~/.ssh/ directory, private script directories
664rw-rw-r--Shared files within a team group
400r--------Immutable backups, read-only reference files

chmod, chown, and chgrp

# Change permissions
chmod 755 deploy.sh         # Set exact permissions (octal)
chmod u+x deploy.sh         # Add execute for owner only
chmod go-w secret.conf      # Remove write from group and others
chmod -R 755 /var/www/html  # Recursive (use carefully)

# Change owner
chown alice deploy.sh
chown alice:devs deploy.sh  # Owner and group simultaneously

# Change group
chgrp devs shared-config.yml

umask: Default Permissions

umask is a mask that subtracts permissions from the default when new files and directories are created. The typical default is 022, meaning:

  • New files: 666 (default) − 022 = 644 (rw-r--r--)
  • New directories: 777 (default) − 022 = 755 (rwxr-xr-x)

A stricter umask like 027 would give 640 files and 750 directories — no read access for others. Set in ~/.bashrc or /etc/profile:

umask 027  # More restrictive default permissions

Use the Chmod Calculator to visually build permission sets and instantly see the octal value and symbolic notation.

Frequently Asked Questions

Why does SSH refuse to use my private key and say 'permissions are too open'?

SSH enforces strict permissions on private keys for security. If your key file (~/.ssh/id_rsa) has permissions more permissive than 600 (rw-------), SSH will refuse to use it with an 'Unprotected private key file' error. Fix: chmod 600 ~/.ssh/id_rsa. The ~/.ssh directory itself should be 700 (drwx------). This prevents other users on the system from reading your private key.

What is setuid, setgid, and sticky bit?

These are three special permission bits beyond the basic rwx. setuid (s in place of owner execute): when set on an executable, it runs as the file's owner, not the user who executed it — used by /usr/bin/passwd to temporarily get root privileges. setgid (s in place of group execute): on an executable, runs as the file's group; on a directory, new files inherit the directory's group. sticky bit (t in place of other execute): on a directory, only the file owner (or root) can delete files — used on /tmp to prevent users deleting each other's temp files.

How do I find files with dangerous permissions?

Use find with the -perm flag. Find world-writable files: 'find / -type f -perm -002 2>/dev/null'. Find setuid binaries: 'find / -type f -perm -4000 2>/dev/null'. Find files with no owner: 'find / -nouser 2>/dev/null'. These are common security audit checks. On a production server, world-writable files or unexpected setuid binaries are red flags that warrant investigation.