Linux chmod Calculator — File Permission Generator

Understanding Unix File Permissions

Unix file permissions are one of the most enduring designs in computing. Introduced with Bell Labs Unix in the early 1970s, the read/write/execute model has remained essentially unchanged across Linux, macOS, BSD, and every Unix derivative for over fifty years. Its longevity comes from its simplicity: three operations (read, write, execute) applied to three categories of user (owner, group, other).

Every file and directory on a Unix system has an associated owner (a user account) and an associated group. When a process attempts to access a file, the kernel checks which category the process falls into — is the process running as the file's owner? Is it a member of the file's group? Or is it neither (other)? It then checks whether that category has the requested permission. This check happens in order: owner bits are tested first, then group, then other. The moment one category matches, that set of bits determines access — the other categories are not consulted.

This model was designed to support multi-user time-sharing systems where researchers needed to share files with colleagues but protect them from unrelated users. In a modern context, the same model protects web server configuration files from being readable by the nobody user running PHP, or ensures SSH private keys are accessible only to their owner.

The Octal Notation Explained

The nine permission bits — three sets of read, write, execute — map directly onto a nine-bit binary number. Each octal digit represents exactly three binary bits, which makes octal a natural shorthand for permission values. This is why chmod uses octal, not decimal or hexadecimal.

The mapping is straightforward: read = 4 (binary 100), write = 2 (binary 010), execute = 1 (binary 001). Add the values for the permissions you want in each category. rwx = 4+2+1 = 7. rw- = 4+2 = 6. r-x = 4+1 = 5. r-- = 4. --x = 1.

A three-digit octal like 755 is read left to right: the first digit (7) sets owner permissions, the second digit (5) sets group permissions, the third digit (5) sets other permissions. So 755 means owner can read/write/execute, while group and other can read and execute but not write. A four-digit octal adds a leading digit for the special permission bits: 4755 means SUID is set on an owner-rwx, group-rx, other-rx file.

The symbolic alternative to chmod 755 is chmod u=rwx,g=rx,o=rx. The symbolic form can also express relative changes: chmod a+x adds execute for all, and chmod o-w removes write from other without touching anything else. For scripted permission management where you want to set exact permissions regardless of the current state, the absolute octal form is clearer and safer than additive/subtractive symbolic forms.

Special Permission Bits

Beyond the nine standard bits, Unix defines three special bits occupying a fourth octal digit position. These bits modify execution behaviour and are important to understand — misuse can create significant security vulnerabilities.

Setuid — SUID (octal 4000)

When the setuid bit is set on an executable, the process runs with the file owner's privileges rather than the invoking user's privileges. The classic example is /usr/bin/passwd: regular users must be able to change their own passwords, but the password database (/etc/shadow) is only writable by root. The passwd binary has SUID set and is owned by root, so when a user runs it, the process gains root's effective UID just long enough to update the shadow file, then exits. The SUID bit appears as s (or S if execute is not also set) in the owner execute position of the symbolic notation: rwsr-xr-x.

SUID on shell scripts is ignored by the Linux kernel for security reasons. SUID on directories has no standard effect on Linux (though some systems use it differently).

Setgid — SGID (octal 2000)

On an executable, setgid works like setuid but for the group: the process runs with the file's group as its effective GID. On a directory, setgid has a more useful everyday effect: new files created inside the directory inherit the directory's group rather than the creating user's primary group. This is invaluable for shared project directories — all files in /srv/project/ will automatically be owned by the project group regardless of which team member creates them. The SGID bit appears as s in the group execute position.

Sticky Bit (octal 1000)

On modern Linux, the sticky bit is meaningful only on directories. When set, it prevents users from deleting or renaming files they do not own, even if they have write permission on the directory. The canonical example is /tmp, which is world-writable (so anyone can create files) but has the sticky bit set (drwxrwxrwt), preventing users from deleting each other's temporary files. The sticky bit appears as t (or T if execute is not set) in the other execute position.

Common Permission Patterns

Several permission values appear repeatedly across Unix systems because they represent well-understood security tradeoffs for specific use cases.

Directory vs File Permissions

The same rwx bits mean different things depending on whether they apply to a file or a directory, and this catches many newcomers off guard.

For a file: read means you can read its contents, write means you can modify it, and execute means you can run it as a program.

For a directory: read means you can list the directory's contents (run ls), write means you can create, delete, or rename files within it, and execute means you can traverse (enter) the directory and access files within it by name. The execute bit on a directory is sometimes called the "search" bit.

This has practical consequences. If you set a directory to 644 (no execute), users cannot cd into it and cannot access any file within it, even if those files have permissive permissions. A directory needs at least --x to be traversable. Typical directories should be 755 (public) or 700 (private). Setting a directory to 644 is almost certainly an error — it allows listing but not entering, which is rarely what is intended.

If you have write permission on a directory but not on a file within it, you can still delete that file — because deletion is an operation on the directory (removing a name entry), not on the file itself. This is why the sticky bit on /tmp is necessary.

Worked Examples

Making a shell script executable

You write a deployment script deploy.sh. By default, new files are created with 644 based on the umask. To make it executable by you only: chmod 700 deploy.sh. To allow your team's group to run it but not modify it: chmod 750 deploy.sh. To allow anyone to run it: chmod 755 deploy.sh.

Securing an SSH private key

The OpenSSH client will refuse to use a private key file that has group or world read permissions. The correct setting is 600:

chmod 600 ~/.ssh/id_ed25519
chmod 700 ~/.ssh/

The .ssh/ directory itself should be 700 — other users should not be able to list its contents at all.

Web server files

A typical LAMP/LEMP stack runs the web process as www-data. PHP files should be readable by www-data but not writable (to limit damage if PHP code execution is compromised): owner deploy, group www-data, permissions 640. Static assets served directly by Nginx (644, world-readable) are fine. Upload directories that the web server writes to need 775 with the SGID bit set so uploaded files inherit the www-data group.

Disclaimer

This calculator and the accompanying guide are provided for educational and reference purposes. File permission requirements vary by operating system, distribution, application, and security policy. Always review your system's documentation and consult a security professional when hardening production systems. Setting overly permissive permissions on sensitive files can expose credentials and private keys to other users and processes. The authors accept no liability for security incidents arising from misconfigured permissions.