Every file and directory on a Linux system carries a permission mask that determines who can read, write, or execute it. These permissions are not decorative — they are the fundamental security boundary of the operating system. Misconfigured permissions are the root cause of countless security vulnerabilities, from exposed private keys to world-writable log directories that attackers exploit for privilege escalation.
Yet even experienced developers hesitate when they need to set permissions beyond the familiar chmod 755 and chmod 644. What does chmod 600 do? When should you use chmod g+s? How do Access Control Lists extend beyond the traditional owner-group-others model? What is the sticky bit, and why does every shared temporary directory rely on it?
Our free interactive Linux file permissions cheat sheet provides an interactive chmod permission calculator, fifty-plus copyable commands organized by category, and comprehensive reference tables for permission bits and numeric values. The Vault Keeper's Master Key aesthetic — deep steel vault door background with brass accents, floating gear animations, and mechanical toggle switches — transforms permission management into precision engineering. Everything runs in your browser. No server, no signup, no data collection.
Why Linux File Permissions Matter More Than Ever
Linux dominates server infrastructure. Over 96% of the top one million web servers run Linux, and that percentage climbs higher in cloud and containerized environments. Every container image, every CI/CD pipeline, every deployment script, and every configuration file depends on correct permission settings. A single chmod 777 applied to the wrong directory can turn a minor deployment script into a critical security hole.
Modern development workflows have made permission management more complex, not less. Containers run as arbitrary users. CI/CD pipelines write artifacts with unexpected ownership. Shared development servers require group collaboration without granting world access. Cloud instances ship with default user accounts whose home directories contain SSH keys that must be locked down to 600.
A well-organized permission reference provides three benefits. First, it eliminates the guesswork of converting between symbolic and numeric notation. Second, it surfaces special permissions — SUID, SGID, and sticky bits — that many developers encounter but few fully understand. Third, it provides copyable commands for real-world scenarios, from securing SSH keys to setting up shared group directories.
Permission Basics — The Three Classes
Linux permissions operate on three classes of users: the owner (the user who created the file), the group (a named collection of users), and others (everyone else on the system). For each class, permissions can be read, write, or execute — three permissions across three classes produces the nine-character string you see in ls -l output.
Read, Write, and Execute
The meaning of each permission depends on whether it applies to a file or a directory. Read permission on a file allows viewing its contents. Read permission on a directory allows listing its files. Write permission on a file allows modifying its contents. Write permission on a directory allows creating, deleting, and renaming files within it. Execute permission on a file allows running it as a program. Execute permission on a directory allows entering it with cd and accessing files inside.
# View permissions
ls -l /etc/passwd
# -rw-r--r-- 1 root root 2875 Jan 10 09:23 /etc/passwd
# Breakdown:
# - = regular file
# rw- = owner can read and write
# r-- = group can only read
# r-- = others can only readNumeric Representation
Each permission has a numeric value: read is 4, write is 2, execute is 1. Adding the values for each class produces a three-digit octal number. This is the most compact and unambiguous way to express permissions.
# Numeric values per class
# rwx = 4 + 2 + 1 = 7
# rw- = 4 + 2 + 0 = 6
# r-x = 4 + 0 + 1 = 5
# r-- = 4 + 0 + 0 = 4
# Common permission sets
chmod 777 file # rwxrwxrwx — everyone has full access
chmod 755 file # rwxr-xr-x — owner full, others read+execute
chmod 644 file # rw-r--r-- — owner read+write, others read
chmod 600 file # rw------- — owner only
chmod 700 file # rwx------ — owner only, full accessSymbolic Representation
Symbolic notation uses letters and operators to modify permissions incrementally. The classes are u (user/owner), g (group), o (others), and a (all). The operators are + (add), - (remove), and = (set exactly). This is useful when you want to change one permission without affecting the others.
# Add execute permission for owner
chmod u+x script.sh
# Remove read permission for others
chmod o-r confidential.txt
# Add write permission for group
chmod g+w shared-file.txt
# Set exact permissions: owner rwx, group rx, others none
chmod u=rwx,g=rx,o= file
# Add read permission for everyone
chmod a+r fileCommon Permission Patterns
Certain permission combinations appear repeatedly in production environments. Memorizing these five patterns covers 90% of real-world permission tasks.
644 — The Standard File
chmod 644 file sets read and write for the owner, read-only for group and others. This is the default permission for most text files, configuration files, and source code. It allows the owner to edit while letting others view without the risk of accidental modification.
755 — The Executable
chmod 755 file or chmod 755 directory gives the owner full access and gives everyone else read and execute permission. This is the standard for executables, scripts, and public directories. Web servers typically require 755 on directories to serve content.
600 — The Private Key
chmod 600 file grants read and write access to the owner only. No one else can read, write, or execute. This is the correct permission for SSH private keys, API credential files, and any file containing secrets. OpenSSH will refuse to use a private key with permissions looser than 600.
700 — The Private Directory
chmod 700 directory gives the owner full access and denies all access to everyone else. Home directories should be 700. Any directory containing sensitive data, build artifacts, or temporary files that should not be shared should use this permission.
750 — The Shared Team Resource
chmod 750 file gives the owner full access, gives the group read and execute, and gives others nothing. This pattern is ideal for team scripts and shared executables where the group needs access but the general public does not.
Ownership Management with chown and chgrp
Permissions only matter in the context of ownership. A file with 644 permissions means nothing until you know who the owner and group are. The chown command changes ownership, and chgrp changes group membership.
Changing the Owner
The most common use of chown is changing the owner of a file. Only root or the current owner can change ownership.
# Change owner to alice
chown alice file.txt
# Change owner and group simultaneously
chown alice:developers file.txt
# Change only the group (same as chgrp)
chown :developers file.txt
# Recursively change ownership of a directory
chown -R alice:developers /var/www/project
# Use environment variable for current user
chown $USER:$USER file.txtCopying Ownership from a Reference File
The --reference option copies ownership from one file to another. This is useful when you want a new file to have the same ownership as an existing file without manually specifying the user and group.
# Copy ownership from existing file to new file
chown --reference=existing.txt new.txtSpecial Permissions — SUID, SGID, and Sticky Bit
Beyond the nine standard permission bits, Linux provides three special permissions that modify behavior in powerful ways. These are SUID (Set User ID), SGID (Set Group ID), and the sticky bit. Each has a numeric value that adds a fourth digit to the permission number.
SUID (Set User ID) — Numeric Value 4
When SUID is set on an executable file, the program runs with the privileges of the file's owner, not the user who executed it. This is how the passwd command allows regular users to change their passwords despite /etc/shadow being owned by root. SUID is displayed as s in the owner's execute position.
# Set SUID bit
chmod u+s /usr/bin/some-program
chmod 4755 /usr/bin/some-program
# Check: rwsr-xr-x — the 's' indicates SUID is setSUID is powerful and dangerous. A vulnerability in a SUID program can grant root access to any user who can execute it. System administrators should audit SUID files regularly with find / -perm -4000.
SGID (Set Group ID) — Numeric Value 2
SGID on an executable causes the program to run with the file's group privileges. On a directory, SGID is even more useful: new files created in that directory inherit the directory's group ownership rather than the creator's primary group. This is essential for shared project directories where multiple users collaborate.
# Set SGID on a shared directory
chmod g+s /shared/project
chmod 2775 /shared/project
# Now files created in /shared/project inherit the project group
# instead of the user's default groupSticky Bit — Numeric Value 1
The sticky bit on a directory restricts file deletion to the file's owner, the directory's owner, and root — even if other users have write permission on the directory. Without the sticky bit, any user with write permission on a directory could delete any file in it. The sticky bit is why /tmp works securely despite being world-writable.
# Set sticky bit on a shared directory
chmod +t /shared/upload
chmod 1777 /shared/upload
# Check: drwxrwxrwt — the 't' indicates sticky bit is setAccess Control Lists (ACLs)
Traditional Linux permissions are limited to one owner, one group, and everyone else. Access Control Lists (ACLs) extend this model by allowing arbitrary users and groups to have specific permissions on a file. ACLs are essential for complex collaboration scenarios where the traditional three-class model is too restrictive.
Reading ACLs
The getfacl command displays the full ACL of a file, including the base permissions and any extended entries.
getfacl /shared/project/file.txt
# file: file.txt
# owner: alice
# group: developers
# user::rw-
# user:bob:r-x
# group::r--
# group:admins:rw-
# mask::rwx
# other::---Setting ACLs
The setfacl command modifies ACLs. The -m flag modifies entries, -x removes entries, and -b removes all extended ACLs.
# Give a specific user read+write+execute
setfacl -m u:bob:rwx file.txt
# Give a specific group read+execute
setfacl -m g:contractors:rx file.txt
# Remove a user's ACL entry
setfacl -x u:bob file.txt
# Remove all extended ACLs, keep base permissions
setfacl -b file.txt
# Set default ACL on a directory (inherited by new files)
setfacl -d -m u:bob:rx /shared/project
# Recursively apply ACL to directory and contents
setfacl -R -m u:bob:rwx /shared/projectDefault ACLs
Default ACLs on directories are inherited by newly created files and subdirectories. This is the ACL equivalent of SGID for group ownership — it ensures consistent permissions across a project tree without manually setting permissions on every new file.
Recursive Permission Management
The -R flag applies permission changes recursively through directories. This is powerful and dangerous — a mistyped recursive chmod can render a system unusable. Always double-check your command before executing recursive permission changes.
# Recursively set 755 on a directory tree
chmod -R 755 /var/www/project
# Recursively change ownership
chown -R alice:developers /var/www/project
# Smart recursive: directories get 755, files get 644
chmod -R u+rwX,go+rX,go-w /var/www/project
# The capital X only adds execute to directories and
# files that already have execute permission somewhereUmask — Setting Default Permissions
The umask determines the default permissions for newly created files and directories. It subtracts from the base permissions (666 for files, 777 for directories). A umask of 022 produces files with 644 and directories with 755. A umask of 077 produces files with 600 and directories with 700.
# Check current umask
umask
# 0022
# Set umask for maximum privacy
umask 077
# Set umask for shared team environment
umask 002Security Best Practices
Permission management is security management. Following these practices prevents the most common Linux security mistakes.
Never use 777 in production. World-writable files and directories are vulnerabilities waiting to be exploited. If a process needs write access, create a dedicated user and group, set appropriate ownership, and use 770 or 775.
Audit SUID and SGID files regularly. Run find / -perm -4000 -o -perm -2000 to list all files with special permissions. Any unexpected SUID binary is a potential privilege escalation vector.
Keep SSH keys at 600. OpenSSH enforces this for a reason. A private key with looser permissions can be stolen by any process running as the same user or, in some cases, by other users on the system.
Use ACLs instead of 777 for complex sharing. If multiple groups need different levels of access, ACLs provide fine-grained control without opening permissions to the entire system.
Test recursive commands before running them. Use find with -ls to preview what a recursive command will affect. For example: find /target -type f -ls before running chmod -R.
The Interactive Cheat Sheet
Our free interactive Linux file permissions cheat sheet includes an interactive chmod permission calculator. Toggle read, write, and execute for owner, group, and others, and watch the numeric mode and symbolic notation update in real time. The calculator also generates the exact chmod command to copy and run.
Beyond the calculator, the cheat sheet organizes over fifty commands into six categories: numeric modes, symbolic modes, ownership commands, special bits, ACLs, and reference tables. Each command includes a description, tags for common use cases, and a one-click copy button. The permission bits reference table shows the numeric value, binary representation, and effect on both files and directories for every permission bit.
The Vault Keeper's Master Key aesthetic uses deep steel vault textures, brass accents, floating gear animations, and mechanical toggle switches. Permission bits are rendered as illuminated switches on a security panel. The design reinforces the serious nature of permission management while making the reference pleasant to use.
Everything is 100% client-side. Your file paths and permission experiments never leave your browser.
Related Tools and References
Linux permissions do not exist in isolation. They interact with user management, shell scripting, server administration, and version control. These related DevToolkit resources cover adjacent topics:
- Terminal & Shell Commands Cheat Sheet — 80+ Linux, macOS, and Bash commands with the Mainframe Operator's Console aesthetic.
- Git Commands Cheat Sheet — 100+ Git commands covering branching, merging, rebasing, and history manipulation.
- Docker Commands Cheat Sheet — 90+ Docker and Docker Compose commands for container management.
- SQL Commands Cheat Sheet — 70+ SQL commands covering DDL, DML, JOINs, and aggregation.
- VS Code Shortcuts Cheat Sheet — 80+ keyboard shortcuts for the most popular code editor.
- NPM Commands Cheat Sheet — 65+ Node.js package management commands.
- HTTP Status Codes Reference — Complete guide to HTTP response codes and their meanings.
Bookmark the Linux File Permissions Cheat Sheet for instant access whenever you need to set permissions, calculate numeric modes, or look up ownership commands. Whether you are securing a production server, configuring a shared development environment, or studying for a Linux certification, this reference provides the commands and concepts you need.