Linux File Permissions
debt(d5/e1/b3/t7)
Closest to 'specialist tool catches it' (d5). The detection_hints list semgrep as the tool, and the code_pattern notes `find -perm /o+w` to detect world-writable files. These are specialist tools requiring deliberate setup — a default linter won't catch a chmod 777, and the misconfiguration is silent in production until exploited, but a properly configured semgrep rule or a manual find command will surface it.
Closest to 'one-line patch or single-call swap' (e1). The quick_fix is explicit: set files to 644 and directories to 755, which is a single chmod command or a one-liner script. Correcting a 777 misuse is a trivial operational change with no code refactoring required.
Closest to 'localised tax' (b3). Permission choices apply to web and cli contexts but are operational configuration rather than a structural code decision. Once corrected, the rest of the codebase is unaffected. The burden is real — misconfigured permissions require ongoing vigilance at deployment — but it doesn't reshape the codebase or impose a productivity tax across work streams.
Closest to 'serious trap' (t7). The misconception field is explicit: chmod 777 appears to 'fix' permission problems and is the instinctive response to access denied errors, but it is a critical security misconfiguration that exposes all files to every process on the server. This contradicts what developers expect — they think they are solving a problem when they are creating a far worse one. It scores t7 rather than t9 because the danger is documented and security-aware developers do know about it, though less experienced developers routinely fall into it.
Also Known As
TL;DR
Explanation
Each file has three permission sets: owner (u), group (g), others (o). Each set has read (r=4), write (w=2), execute (x=1). chmod 755 = owner rwx, group r-x, others r-x. Web server files: 644 for files (rw-r--r--), 755 for directories. PHP files should never be world-writable (666 or 777). Config files with secrets should be 600 (owner read/write only). The web server user (www-data) should be in the correct group — not given direct ownership of application files.
Common Misconception
Why It Matters
Common Mistakes
- Setting 777 to 'fix' permission errors instead of diagnosing the actual user/group mismatch.
- Making .env files world-readable — they contain secrets that any process on the server can read.
- Owning application files as root — the web server cannot write to them and deployment scripts fail.
Avoid When
- Never use 777 on any production file or directory — it is always a misconfiguration.
- Do not own application files as root — the web server user cannot write them and deployments will fail.
When To Use
- Set 644 for all PHP files and 755 for directories as the default — only loosen permissions when specifically required.
- Set 600 on .env and config files containing secrets — readable only by the file owner.
Code Examples
# chmod 777 — world-writable: any process on the server can modify files
chmod -R 777 /var/www/myapp # critical misconfiguration# Correct permissions for a PHP web app
find /var/www/myapp -type f -exec chmod 644 {} \;
find /var/www/myapp -type d -exec chmod 755 {} \;
# Writable directories (uploads, cache, logs) — owner only
chmod 700 /var/www/myapp/storage
# Secrets — owner read only
chmod 600 /var/www/myapp/.env