Linux File Permissions Binary

rwx as Binary Bits

Every Linux file permission is stored as a sequence of binary bits. I've spent years working with Linux systems, and the single most important insight I can share is this: think of rwx not as letters, but as a 3-bit binary number. Each letter is a position: r (read) is the high bit (2² = 4), w (write) is the middle bit (2¹ = 2), and x (execute) is the low bit (2⁰ = 1).

When you see rwx, that's binary 111 which is decimal 7. When you see rw-, the execute bit is 0, so it's 110 = 6. A dash simply means that bit position is 0. This is why chmod uses octal: each octal digit from 0 to 7 maps perfectly to a 3-bit rwx group. Here is the complete mapping:

I have debugged many permission issues on production Linux servers where a file was readable but not executable — that is the difference between 644 and 755 in action, and it always comes down to that execute bit being set.

In my experience, the confusion most people have is that 4 does not mean "read" — it means "the read bit is 1 and the write and execute bits are 0." The value 4 is just the decimal representation of the 3-bit binary sequence 100. When you type chmod 644, Linux interprets each octal digit independently and sets the corresponding 3-bit pattern.

The Full 9-Bit Permission Mask

A Linux file permission string like rwxr-xr-- is 9 bits grouped into three triples: owner (bits 8-6), group (bits 5-3), and others (bits 2-0). The full binary representation is:

chmod 754 Binary Breakdown

Let's walk through one of the most common permission sets I use in production. chmod 754 is typical for directories and executable scripts where the owner needs full control, the group needs read and execute, and everyone else gets read-only access.

I use 754 extensively for web application directories. The web server process typically runs under a specific group, so group members can traverse directories (execute) and read files. The owner — usually my deployment user — has full control to create, delete, and modify files within the directory. Others can only read, which prevents unauthenticated users from listing directory contents or executing scripts.

Here is the bit-by-bit breakdown of every individual bit in the 754 mask:

chmod 644 Binary Breakdown

chmod 644 is the standard permission set for regular files. I have thousands of files on production servers with 644 — it is the default for most Linux distributions when you create a new file. The owner can read and write, while everyone else can only read.

One thing I've learned the hard way: never put executable scripts in 644. If you create a shell script or a Python script and the file is 644, you will get a Permission denied error when trying to run it. The execute bit (bit 6 in the owner triple) is 0. You need at least 755 for executables. But for configuration files, HTML files, CSS, JavaScript assets, and log files, 644 is perfectly fine and actually preferred from a security standpoint.

In my work, I always reserve 644 for static assets. Here is a quick rule of thumb I follow:

• 644 — Regular files: HTML, CSS, JS, images, text, configs
• 755 — Directories and executables: scripts, binaries, folders
• 600 — Sensitive files: SSH keys, credentials, private data
• 700 — Private directories: only the owner can enter

chmod 777 Binary Breakdown

chmod 777 is the most permissive — and most dangerous — permission set. In binary it is 111111111. Every single bit is set to 1. The owner, group, and others all have read, write, and execute permissions. I want to be very clear: in almost every production scenario, this is a bad idea.

I have seen 777 used as a quick fix when a web application can't write to a directory. And yes, it works — but it also means any user on the system, including compromised accounts, can modify those files. If an attacker gains even minimal access to a server, 777 directories are gold mines.

A far better approach in my experience is to find the correct owner and group for the process that needs write access and set 775 instead. This gives the owner and group full access while locking others to read and execute only. The binary difference is 111111101 vs 111111111 — just the last 2 bits of the others triple go from 11 to 01.

Owner, Group, and Others in Binary

The Linux permission model divides users into three security classes, each represented by exactly 3 bits. Understanding this structure is fundamental to working with file permissions at the binary level.

The Owner Triple (Bits 8-6)

The first three bits encode the file owner's permissions. Bit 8 is the read bit (numerical value 256 in the full 9-bit mask), bit 7 is write (128), and bit 6 is execute (64). When you see rwx------, that's 111000000 in binary — 700 in octal. Only the owner has any access at all.

The Group Triple (Bits 5-3)

Bits 5 (read, value 32), 4 (write, value 16), and 3 (execute, value 8) define what members of the file's group can do. For ---rwx---, that's 000111000 in binary, or 070 in octal — only the group has full access. I use this pattern rarely but it is useful for shared project directories where the group needs control but the owner should not be special.

The Others Triple (Bits 2-0)

Bits 2 (read, value 4), 1 (write, value 2), and 0 (execute, value 1) control everyone else. For ------rwx, that's 000000111 = 007 octal. I have never used 007 in production — giving write permission to "others" is almost always a mistake.

Binary Bit Manipulation of Permissions

Once you understand that permissions are just bits, you can manipulate them programmatically using bitwise operations. I frequently write scripts that need to check or modify file permissions without calling external commands.

Checking a Specific Bit

To check whether the group execute bit is set, you test bit 3 of the permission mask:

Setting a Specific Bit

To add the group write permission without affecting other bits, use OR:

Clearing a Specific Bit

To remove the others write bit, use AND with NOT:

In my shell scripts, I use these patterns with $((...)) arithmetic to compute permission masks on the fly. For instance, $((mask | (1 << 4))) adds group write. This is much cleaner than parsing and reconstructing the symbolic u+x form when you are working with numeric permission values programmatically.