File Permissions
debt(d7/e3/b3/t7)
Closest to 'only careful code review or runtime testing' (d7). The term's detection_hints.tools field is empty. File permission misconfigurations produce no compile-time or lint errors — they are invisible during development and only manifest at deployment or runtime, often only when a specific code path tries to write a file or when an attacker exploits overly permissive settings. A security audit or manual inspection of deployed files is typically required to catch them.
Closest to 'simple parameterised fix' (e3). The quick_fix is essentially a set of chmod/chown commands applied to specific paths. While trivially expressed as shell commands, correcting permissions often requires identifying the correct web server user, checking which directories need write access, and updating deployment scripts or provisioning configs — slightly more than a single-line patch but well within one component (the deployment/server config).
Closest to 'localised tax' (b3). The burden applies to deployment and server configuration contexts. Once permissions are set correctly (typically in a deployment script, Ansible playbook, or Dockerfile), the ongoing cost is low. It doesn't pervade application logic or shape architectural decisions, though it does require attention every time a new file type or upload directory is introduced.
Closest to 'serious trap' (t7). The misconception field directly states the canonical wrong belief: '777 fixes permission errors.' This is a well-documented but persistently common mistake that contradicts secure practice — the 'obvious' quick fix (give everyone access) is actively harmful. It doesn't merely surprise; it introduces a real security vulnerability under the guise of solving a problem, which is a serious cognitive trap for developers unfamiliar with Unix permission models.
Also Known As
TL;DR
Explanation
Unix file permissions are represented as three octal digits: owner, group, world — each a sum of read (4), write (2), execute (1). Common values: 644 (owner read+write, group read, world read — typical for web files); 755 (owner read+write+execute, group and world read+execute — typical for directories and scripts); 600 (owner read+write only — for sensitive config files); 777 (everyone can do everything — a security problem). PHP web processes run as the web server user (www-data, apache, nginx). Upload directories need write permission for the web user; config files containing credentials should not be world-readable; PHP files should never be executable (execute bit unnecessary for interpreted files). The principle: files should have the minimum permissions necessary. chmod() in PHP changes permissions programmatically; chown() changes ownership.
Common Misconception
Why It Matters
Common Mistakes
- Setting upload directories to 777 — use 755 or 775 with the web server user in the group instead.
- Making .env and config files world-readable — .env should be 600 (owner read+write only).
- Setting PHP files to executable (chmod +x) — PHP files are interpreted, not executed directly; the execute bit is unnecessary and slightly increases attack surface.
- Running PHP as root — the web server and PHP-FPM should never run as root; a compromised PHP process then has full system access.
Code Examples
# 'Fix' that creates a security hole
chmod 777 /var/www/html/uploads/
# Now ANY user on the server can read, write, delete uploads
chmod 777 /var/www/html/.env
# Every account on shared hosting can read your DB password# Correct: give web server user ownership of upload dir
chown www-data:www-data /var/www/html/uploads/
chmod 755 /var/www/html/uploads/
# Only www-data can write; owner/group can read and list
# Config files — owner only
chmod 600 /var/www/html/.env
# Standard web files
find /var/www/html -type f -name '*.php' -exec chmod 644 {} \;
find /var/www/html -type d -exec chmod 755 {} \;