Linux chmod Cheat Sheet: Stop Using 777 (Safer Fixes)

Linux chmod Cheat Sheet: The File Permissions Every SOC Analyst and Sysadmin Should Master

Quick Answer
chmod sets who can read, write, or execute a Linux file. Use 640 or 600 for sensitive files, 755 for scripts, and 700 for private directories; avoid 777, and audit setuid files regularly.

Picture a composite scenario that many SOC teams will recognize. During a routine review, an analyst notices that a backup script run by root every night is writable by every user on the server. Nobody attacked it. Someone once ran a quick chmod 777 to fix a "permission denied" error and never reverted it. Now any low-privileged account, or any attacker who lands one, can edit a file that root executes on a schedule.

That is why Linux file permissions are a security control, not a housekeeping detail. They are the foundation of least privilege access control and a core part of any Linux server hardening checklist. This guide covers every common chmod pattern, explains the reasoning behind the safe choices, and shows how to audit for the risky ones.

Table of Contents

• How Linux Permissions Actually Work
• Numeric (Octal) chmod Modes You Will Use Daily
• Symbolic chmod: Add, Remove, and Set Exact Permissions
• Recursive chmod and the Mistake That Bites Everyone
• Checking Permissions: ls, stat, and --reference
• SSH Key and Directory Permissions
• Setuid, Setgid, and Sticky Bit Explained
• Detecting Risky Permissions in Security Audits
• Expert Tips From the SOC Floor
• FAQ
• Conclusion

How Linux Permissions Actually Work

Every file and directory has three permission classes: the owner (u), the group (g), and others (o). Each class can hold three permissions: read (r), write (w), and execute (x). Running ls -l shows them as a 10-character string:

-rw-r--r-- 1 alice alice 1024 Sep 29 10:15 file.txt

The first character is the file type (- for a regular file, d for a directory). The next nine characters are three triplets: owner, group, others. Here the owner can read and write, while the group and others can only read.

Numeric mode adds up three values per class: read = 4, write = 2, execute = 1. So rw- is 4+2 = 6, r-x is 4+1 = 5, and r-- is 4. Three digits map to owner, group, and others, so 644 means rw-r--r--.

Directories interpret the bits differently. Read lets you list names, write lets you create or delete entries, and execute lets you traverse into the directory and access items by name. A directory without execute permission is effectively locked, even if it is readable.

Numeric (Octal) chmod Modes You Will Use Daily

Numeric mode sets every bit in one shot. It is fast, and it is how most hardening guides and compliance baselines express permissions.

Command	Result	Typical use
chmod 644 file.txt	Owner rw, group r, others r	Default for regular files and web content
chmod 664 file.txt	Owner rw, group rw, others r	Files edited by a shared team group
chmod 660 shared.txt	Owner rw, group rw, others none	Shared files that others must not read
chmod 640 config.txt	Owner rw, group r, others none	Config files a service group must read
chmod 600 secret.txt	Owner rw only	Credentials, tokens, private keys
chmod 444 file.txt	Read-only for everyone	Files that should not be modified accidentally
chmod 755 script.sh	Owner rwx, group rx, others rx	Scripts and programs everyone may run
chmod 750 script.sh	Owner rwx, group rx, others none	Admin scripts limited to a specific group
chmod 700 script.sh	Owner rwx only	Private scripts and personal tooling
chmod 775 project/	Owner rwx, group rwx, others rx	Collaborative project directories
chmod 700 private/	Owner only	Private directories
chmod 000 file.txt	No access for anyone	Locking a file down temporarily (root can still access it)
chmod 777 file.txt	Everyone rwx	Almost never. See the warning below.

Warning: chmod 777 lets every local user modify and execute the file. If a privileged process, cron job, or web server touches that file, you have effectively handed those privileges to anyone who can log in. When a "permission denied" error appears, work out which user or group needs access and grant only that.

Two more notes. chmod 755 directory/ is the standard directory mode: everyone can traverse and list, but only the owner can change contents. chmod 000 is safe, but it also blocks you until you restore access with something like chmod 644 file.txt.

Symbolic chmod: Add, Remove, and Set Exact Permissions

Symbolic mode changes only the bits you name and leaves the rest alone. That makes it the better choice when you want a targeted change without overwriting everything else. The syntax is [who][operator][permissions], where who is u, g, o, or a (all), and the operator is + (add), - (remove), or = (set exactly).

Adding permissions

chmod +x script.sh
chmod a+x script.sh
chmod u+x script.sh
chmod u+rw file.txt
chmod g+rx script.sh
chmod o+r file.txt

These add execute for the default scope, execute for everyone, execute for the owner, read/write for the owner, read/execute for the group, and read for others. One subtlety: plain chmod +x with no "who" letter respects your umask, so it may not add execute for every class. Use a+x when you explicitly mean everyone.

Removing permissions

chmod a-x script.sh
chmod a-r file.txt
chmod a-w file.txt
chmod g-w file.txt
chmod o-rwx file.txt

These remove execute, read, or write from everyone, or strip specific permissions from the group or others. chmod o-rwx file.txt is one of the most useful commands in incident response, because it quickly cuts off access for everyone outside the owner and group.

Setting exact permissions

chmod u=rw file.txt
chmod g=r file.txt
chmod o= file.txt
chmod u=rwx,g=rx,o=r script.sh
chmod a=rx script.sh

The = operator replaces that class's permissions entirely. chmod o= file.txt (nothing after the equals sign) clears all permissions for others. The comma-separated form, u=rwx,g=rx,o=r, is equivalent to numeric 754 and reads far better in scripts and code reviews.

Recursive chmod and the Mistake That Bites Everyone

chmod -R 755 project/
chmod -R u+rw project/

The -R flag applies the change to the directory and everything beneath it. It is powerful, and it is also where many accidental exposures start. chmod -R 755 project/ makes every regular file executable, including text files, configs, and uploaded content. That is rarely what you want.

Warning: Always double-check the path before running a recursive chmod, and never run it against /, /etc, /usr, or a home directory root. Wrong permissions on system paths can break authentication, package management, and boot.

Two safer patterns are worth memorizing. The capital X in symbolic mode adds execute only to directories (and to files that already have an execute bit):

chmod -R u=rwX,go=rX project/

Or, set directories and files separately with find:

find project/ -type d -exec chmod 755 {} +
find project/ -type f -exec chmod 644 {} +

The first command gives directories 755 and the second gives files 644, so nothing becomes executable by accident.

Checking Permissions: ls, stat, and --reference

ls -l file.txt
stat -c "%a %n" file.txt

ls -l shows the permission string, owner, group, size, and timestamp. Use stat -c "%a %n" (GNU coreutils) when you want the numeric mode, which is easier to compare in scripts. Expected output looks like:

644 file.txt

To copy permissions from one file to another, use --reference:

chmod --reference=source.txt target.txt

This gives target.txt exactly the same mode as source.txt. It is handy for restoring a file to a known-good baseline without working out the octal value.

Bulk operations work as you would expect:

chmod 644 file1.txt file2.txt file3.txt
chmod 644 *.txt

The shell expands the wildcard before chmod runs, so check what *.txt matches first with ls *.txt.

SSH Key and Directory Permissions

SSH is strict about permissions, and for good reason. A private key readable by other users is a private key that has to be treated as compromised.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/id_rsa.pub

The ~/.ssh directory should be accessible only by its owner. The private key should be readable and writable only by the owner, and the public key can safely be world-readable. If a private key is too open, the OpenSSH client refuses to use it and prints a warning such as "UNPROTECTED PRIVATE KEY FILE" along with a message that the permissions are too open. The server-side sshd also performs strict ownership and permission checks on a user's ~/.ssh contents by default (the StrictModes setting). Fixing the mode is the correct response, and it beats disabling the check.

Setuid, Setgid, and Sticky Bit Explained

Beyond the basic nine bits, Linux has three special permission bits. They matter for security because attackers look for misuse of them, and MITRE ATT&CK tracks the behavior under technique T1548.001 (Setuid and Setgid) and T1222.002 (Linux file and directory permissions modification).

Bit	Commands	What it does
Setuid	chmod u+s program chmod 4755 program chmod u-s program	Runs the program with the file owner's privileges. Displays as -rwsr-xr-x.
Setgid	chmod g+s directory/ chmod 2755 directory/ chmod g-s directory/	On a directory, new files inherit the directory's group. Displays as drwxr-sr-x.
Sticky bit	chmod +t shared/ chmod 1777 shared/ chmod -t shared/	In a shared writable directory, users can generally delete or rename only their own files. Displays as drwxrwxrwt.

The leading digit in four-digit modes is the special-bit value: setuid is 4, setgid is 2, sticky is 1. So 4755 is setuid plus 755, 2755 is setgid plus 755, and 1777 is sticky plus 777. The classic legitimate use of 1777 is /tmp, where everyone can write but nobody can delete another user's files.

Warning: Setuid on the wrong binary is a privilege risk. A setuid-root program that is writable, or that can be coaxed into running arbitrary commands, gives a local user a path to root. Do not set it on anything you have not audited, and remove it from anything that does not need it. Note also that Linux ignores the setuid bit on interpreted scripts, so it has no effect on shell scripts.

A capital S or T in the permission string means the special bit is set but the matching execute bit is not. That combination is usually a misconfiguration worth investigating.

Detecting Risky Permissions in Security Audits

Knowing the commands is half the job. The other half is finding what is already wrong. These read-only find queries are a staple of Linux compliance audit work and align with common hardening baselines such as the CIS Benchmarks.

# World-writable regular files
find / -xdev -type f -perm -0002 2>/dev/null

# World-writable directories without the sticky bit
find / -xdev -type d -perm -0002 ! -perm -1000 2>/dev/null

# Setuid files
find / -xdev -type f -perm -4000 2>/dev/null

# Setgid files
find / -xdev -type f -perm -2000 2>/dev/null

Each command lists matching paths. On a healthy system the world-writable results should be short and explainable, and the setuid list should contain only familiar system binaries (for example passwd or sudo). Save a baseline, then diff future runs against it. A new setuid binary in /tmp, a home directory, or a web root deserves immediate attention. Because -xdev stays on one filesystem, run the queries against each mounted filesystem you care about.

For continuous monitoring, the Linux audit framework can log permission changes. This rule records chmod-family system calls on 64-bit systems and tags them for searching:

auditctl -a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -k perm_mod

Search the results later with ausearch -k perm_mod. Add the rule to a file in /etc/audit/rules.d/ so it persists after reboot, and forward the events to your SIEM. Be prepared for noise on busy servers, and tune by excluding known package-manager and deployment activity.

Expert Tips From the SOC Floor

• Start restrictive, then open up. Begin with 600 or 640 for files and 700 or 750 for directories, and grant more only when something demonstrably needs it.
• Fix ownership, not permissions. Many "permission denied" problems are really wrong owner or group. chown or adding a service account to the correct group beats widening access to others.
• Prefer group-based sharing. A setgid project directory (2775) with a dedicated group gives teams collaboration without exposing files to everyone.
• Use symbolic mode in scripts. u=rwx,g=rx,o= is self-documenting, and reviewers catch mistakes faster than with bare octal.
• Protect the secrets first. API tokens, .env files, database configs, and private keys should be 600 or 640 with the correct owner. This is often the highest-value quick win.
• Watch unusual timing. A chmod on a sensitive file outside a change window, or a sudden u+s, is worth alerting on.
• Remember what chmod cannot do. It does not stop root, and it does not replace SELinux, AppArmor, or proper service isolation. Treat it as one layer of defense in depth.

Related Cybersecurity Topics You Should Explore

• OnePlus 15 Root Exploit: Zero-Permission Apps Can Take Full Control
  
• One Misconfigured chmod Command Gave Attackers Root Access
  
• How SOC Analysts Use sed to Catch Attacks Before the SIEM Does
  
• Linux tr Command Tutorial: Fix Messy SOC Logs in Seconds
  
• Linux tee Command: The SOC Trick That Saves Evidence Before It's Gone
  
• Linux wc Command Tutorial: Count Log Lines Like a SOC Pro
  
• Linux cmp Command Explained: Every Flag SOC Teams Actually Use
  
• Linux diff Command Tutorial: Detect Config Drift Like a SOC Analyst
  
• Linux uniq Command: 6 Log Analysis Tricks SOC Analysts Use

FAQ

What does chmod 755 mean?

The owner can read, write, and execute, while the group and others can read and execute. It is the standard mode for scripts, programs, and most directories.

What is the difference between chmod 644 and 600?

With 644, everyone on the system can read the file. With 600, only the owner can read or write it. Use 600 for secrets and private keys.

Is chmod 777 ever safe?

Rarely. It lets every user modify and execute the file. In almost every case a narrower mode plus the right owner or group solves the underlying problem.

What does chmod +x do?

It adds execute permission using the default scope, which is influenced by your umask. Use chmod a+x to explicitly grant execute to owner, group, and others, or chmod u+x for the owner only.

How do I check a file's permissions in numeric form?

Run stat -c "%a %n" file.txt on systems with GNU coreutils. It prints the octal mode followed by the filename.

Why does SSH say my private key permissions are too open?

OpenSSH rejects private keys that other users can access. Set the key to 600 and the ~/.ssh directory to 700.

What is the sticky bit used for?

It is set on shared writable directories such as /tmp, so users can generally delete or rename only their own files there.

Conclusion

chmod looks simple, but it sits at the center of Linux security. The commands above cover nearly every situation you will face: the numeric modes for quick, standardized settings, symbolic mode for surgical changes, recursion with care, and the special bits with respect. Just as important is the audit side. Regularly check for world-writable files, review setuid binaries, and log permission changes so drift is caught before an attacker uses it.

Bookmark this cheat sheet, adopt "least privilege by default" as your habit, and the next time a script fails with "permission denied," you will fix it correctly instead of reaching for 777.

Analysis based on SOC monitoring experience and review of public Linux documentation and hardening guidance.