Linux File Permissions Explained

Every file and directory in a Linux operating system belongs to an access control hierarchy designed to safeguard multi-user environments. Whether you manage high-traffic cloud infrastructure, maintain self-hosted Docker containers, or run a local development machine, file permissions represent your primary defense against unauthorized data modification, sensitive credential exposure, and software misconfiguration. At its foundation, the Linux Discretionary Access Control (DAC) model evaluates who is trying to access a resource and what specific operations they are permitted to execute. Understanding how permissions translate between human-readable characters like rwxr-xr-x and numerical values like chmod 755 is an indispensable skill for systems engineers and software developers.

Owner, Group, Others

Linux organizes permissions around three distinct security boundaries known as classes. When any process or command attempts to open, write to, or execute a file, the Linux kernel determines which single class governs that request by evaluating access in a strict hierarchical sequence:

• User (Owner): The single user account that created or currently owns the file. The kernel tests the user class first. If the process UID matches the file owner UID, the owner permissions apply exclusively, and group or world permissions are ignored.
• Group: A collection of user accounts organized under a common GID. Group permissions apply when the process executing the command belongs to the file group but is not the file owner. This enables collaborative development workflows, such as granting deployment teams write access to shared directories via chmod 775 without exposing the files to outside users.
• Others (World): Every other user account on the operating system that is neither the file owner nor a member of the assigned group. Settings for others govern public access. Restrictive security standards frequently reduce others to zero access, as seen in chmod 700 or chmod 600.

It is important to remember that permissions do not stack or combine across classes. If you are the file owner, your access is strictly bounded by the owner permissions, even if the group or others classes possess broader rights. For example, in unusual configurations like chmod 077, the file owner is denied all access while coworkers in the group can freely read and edit the file.

Read, Write, Execute

Within each user class, Linux provides three distinct permission bits. These bits are represented symbolically by the letters r, w, and x, or numerically by binary weights that sum to an octal number from 0 to 7:

• Read (r = 4): Grants the right to view, open, and read the contents of a file. For directories, read permission allows a user to query and list the names of files stored inside using utilities like ls.
• Write (w = 2): Permits modifying, appending to, or overwriting file data. For directories, write permission grants the ability to create new files, rename existing files, or delete files located within that directory.
• Execute (x = 1): Allows a file to be launched and executed as a compiled binary or interpreted script. For directories, the execute bit serves a unique purpose: it acts as the "traverse" or search bit, permitting processes to enter the directory via cd and access subdirectories and files.

Because each bit represents an independent power of two (4, 2, and 1), any combination of permissions produces a unique mathematical sum between 0 and 7. For example, Read plus Write equals 6 (4 + 2), which is why standard non-executable files use chmod 644. Read plus Execute equals 5 (4 + 1), and full access equals 7 (4 + 2 + 1).

Reading ls -l Output

The standard method for inspecting permissions in the terminal is the long-format directory listing command ls -l. Executing this command displays an output block similar to the following:

$ ls -l
drwxr-xr-x 2 webmaster www-data 4096 Jan 15 10:00 public_html
-rw-r--r-- 1 webmaster www-data 1024 Jan 15 10:05 index.html
-rwxr-xr-x 1 webmaster www-data 2048 Jan 15 10:10 deploy.sh
-rw------- 1 webmaster www-data  512 Jan 15 10:15 database.env

The first column consists of ten characters that convey the complete access profile. The very first character indicates the file type: a hyphen (-) denotes a regular file, a d indicates a directory, and an l represents a symbolic link. The remaining nine characters represent three groupings of three bits each:

• Characters 2–4 represent the Owner permissions (e.g., rwx or rw-).
• Characters 5–7 represent the Group permissions (e.g., r-x or ---).
• Characters 8–10 represent the Others permissions (e.g., r-- or ---).

In the example above, index.html displays -rw-r--r--, which corresponds directly to chmod 644. The shell script deploy.sh shows -rwxr-xr-x, which matches chmod 755, and the confidential configuration file database.env displays -rw-------, matching chmod 600.

Octal vs Symbolic

Linux administrators change permissions using the chmod (change mode) command. You can express permission changes using either numerical octal notation or alphanumeric symbolic syntax. Both achieve identical system states, but each offers distinct operational strengths:

# Setting absolute permissions with octal notation
chmod 755 deploy.sh
chmod 644 index.html
chmod 600 database.env

# Modifying specific permissions with symbolic notation
chmod u+x build.sh
chmod g-w config.json
chmod o-rwx secret.key

Octal notation is deterministic and absolute. When you issue chmod 755 script.sh, you define the entire permission mask in one command, overwriting all existing bits. This makes octal syntax ideal for automated provisioning scripts, Dockerfiles, and CI/CD deployment pipelines where consistent, reproducible states are required.

Symbolic notation, on the other hand, is relative and surgical. It allows you to add (+), remove (-), or set (=) specific bits without altering untouched flags. For example, running chmod +x run.sh grants execute access to the owner while leaving group and other permissions intact. Conversely, stripping world permissions with chmod o-rwx private.key guarantees security without forcing you to look up existing owner and group values.

Files vs Directories

The single most frequent mistake made by engineers new to Linux is treating files and directories interchangeably when applying permissions. Because the underlying kernel interprets the execute bit differently based on inode type, applying the same permission recursively with chmod -R often causes widespread system failures:

# The wrong way: recursively making everything 755
chmod -R 755 /var/www/html  # Bad: marks all images and text files as executable!

# The correct way: separate directories from files using find
find /var/www/html -type d -exec chmod 755 {} +
find /var/www/html -type f -exec chmod 644 {} +

On a regular file, read permission enables reading content, write allows saving edits, and execute turns the file into a runnable program. On a directory, read permission only allows querying the list of file names inside. To actually open a file inside that directory, read its size, or navigate into it using cd, your process must have execute permission on the directory. If you configure a directory as chmod 644, users can see the names of files inside, but attempting to open or read any file triggers an immediate "Permission Denied" error.

By enforcing chmod 755 on directories and chmod 644 on regular assets, you maintain an airtight, standards-compliant server environment that guarantees stability, security, and predictable application behavior.

Frequently Asked Questions