Linux File Permissions: chmod, chown, umask, setuid & ACLs

Linux File Permissions & Ownership

Every file and directory on Linux has an owner, a group, and a set of permission bits that decide who can read, write, or execute it. This simple model underpins system security, from protecting SSH keys and configuration secrets to isolating services from one another and keeping container workloads contained.

Most permission problems ("permission denied", a web server that can't read its files, a script that won't execute, a shared directory where users delete each other's files) come down to a handful of concepts: the three permission classes, what x means on a directory, umask, and the special bits. This page covers them, plus ACLs and capabilities for cases the basic model can't express.

TL;DR

Permissions apply to three classes: user (owner), group, and others, each with read, write, and execute.
On directories: r lists names, w creates, deletes, and renames entries, and x lets you enter and access items inside.
chmod changes modes (chmod 640 file, chmod g+w dir); chown user:group changes ownership.
umask subtracts bits from default permissions of new files (a common default is 022).
Special bits: setuid (run as the file owner), setgid (run as the group, or inherit the group in directories), and sticky (only owners delete in shared dirs like /tmp).
ACLs grant per-user and per-group access beyond one group; capabilities grant specific root powers without full root.

Quick Example

Core Concepts

Users, Groups, and Classes

Each process runs as a user (UID) with a primary group and optional supplementary groups. When a process accesses a file, the kernel checks, in order: is it the file's owner? Then use the user bits. Otherwise, is it in the file's group? Then use the group bits. Otherwise use the others bits. Only the first matching class applies. Root (UID 0) bypasses most checks.

id shows your user and groups; /etc/passwd and /etc/group (or a directory service) define them.

Permission Bits on Files vs Directories

Deleting a file depends on write permission on the directory, not the file. And a directory with r but no x lets you see names but not open anything inside.

chmod: Symbolic and Octal

Octal: each class is the sum of r=4, w=2, x=1. 754 = owner rwx (7), group r-x (5), others r-- (4).
Symbolic: chmod u+x,g-w,o= file, where u/g/o/a are the classes, +/-/= add, remove, or set, and X means execute only for directories or files that are already executable.

Common modes:

chown and chgrp

chown user file, chown user:group file, and chgrp group file change ownership. Only root can change a file's owner; owners can change the group to one they belong to. Use -R for recursion carefully, and --reference=other to copy ownership.

umask

New files start from 666 (files) or 777 (directories), minus the umask. With umask 022, files become 644 and directories 755. With 027, you get 640 and 750, a tighter default for servers. Set it in shell profiles, systemd units (UMask=), or login configuration.

Special Bits

ls -l shows them as s/S in execute positions and t/T for sticky. setuid-root binaries are prime attack targets. Audit them with find / -perm -4000 -type f 2>/dev/null.

ACLs

When one owner and one group aren't enough (say "the deploy user and the backup group and alice need access"), POSIX ACLs add entries:

A + at the end of the ls -l mode string indicates ACLs are present.

Capabilities

Linux splits root's powers into capabilities such as CAP_NET_BIND_SERVICE (bind ports below 1024), CAP_NET_ADMIN, and CAP_SYS_ADMIN. Grant a specific capability instead of running as root:

Containers and systemd units use capabilities to drop privileges (--cap-drop=ALL, CapabilityBoundingSet=). See container security.

Best Practices

Run Services as Dedicated Users

Each service gets its own unprivileged user and group, owning only what it needs to write. A compromised process is then limited to that user's files. systemd's DynamicUser=yes automates this.

Use Groups and setgid for Shared Directories

For team-shared paths, create a group, chgrp the directory, set chmod 2775, and give it a default ACL or umask 002. New files get the right group and stay writable by the team.

Protect Secrets Strictly

Private keys, .env files, and credential stores should be 600 (or 640 for a service group) and owned by the service user. SSH refuses keys with loose permissions for good reason. See SSH.

Use sudo, Not Root Shells

Grant specific commands through sudoers rules (edited with visudo), and log sudo usage. Avoid shared root passwords and long-lived root shells.

Common Mistakes

chmod 777 to "Fix" Permission Denied

Find the actual process user (ps -o user= -p <pid>) and grant the minimum: correct ownership, group membership, and modes like 750/640.

Forgetting Execute on Parent Directories

A file with mode 644 is still unreadable if any parent directory lacks x for that user. Check the whole path with namei -l /srv/app/config/app.yml.

Recursive chmod Making Files Executable

chmod -R 755 dir marks every file executable. Use find with -type d and -type f separately, or chmod -R u=rwX,g=rX,o= with capital X.

FAQ

What does chmod 755 mean?

The owner can read, write, and execute (7 = 4+2+1), and group members and others can read and execute (5 = 4+1). It's typical for executables and directories that everyone may access but only the owner may modify.

Why can't I delete a file I own?

Deleting depends on write and execute permission on the containing directory. If the directory has the sticky bit set and you don't own it, you can only delete your own files there. An immutable attribute (chattr +i, visible with lsattr) also blocks deletion, even for root.

What's the difference between setuid and sudo?

A setuid binary always runs with its owner's privileges for anyone who executes it, a coarse and risky mechanism. sudo lets an administrator grant specific users permission to run specific commands as another user, with authentication and logging. Prefer sudo rules, or better, capabilities or dedicated service users.

How do permissions work inside Docker containers?

The same UID-based model applies. Bind-mounted files keep their host UID and GID, so a container process running as UID 1000 needs the host files to be accessible to UID 1000. Run containers as non-root users and drop capabilities. See Docker volumes.