Linux User & Group Management
debt(d5/e5/b7/t7)
Closest to 'specialist tool catches it' (d5). The detection_hints list lynis (security auditing tool), ansible (configuration management that can enforce state), and semgrep (SAST). These are specialist tools — not default linters or compilers — that catch patterns like PHP-FPM running as root or shared credentials. A basic code review may miss misconfigurations living in server config files rather than application code.
Closest to 'touches multiple files / significant refactor in one component' (e5). The quick_fix involves creating a dedicated deploy user, reconfiguring PHP-FPM pool settings, adjusting file ownership across the web root, and configuring sudo with specific commands. This spans multiple configuration files (PHP-FPM pool config, /etc/sudoers, file system ownership) and requires coordinated changes across deployment scripts and server config — more than a one-line patch but not full architectural rework.
Closest to 'strong gravitational pull' (e7). User and permission decisions apply to both web and CLI contexts and shape every deployment, file operation, and process execution on the server. Getting this wrong (e.g., sharing www-data across apps, no deploy/web user separation) imposes ongoing risk and operational cost — every new application, deployment pipeline change, or PHP-FPM pool addition must account for the privilege model already established. It's a load-bearing choice across the system.
Closest to 'serious trap' (t7). The misconception field explicitly states that developers believe running PHP-FPM as root is fine for development, when in fact it hands root access to any attacker who exploits a PHP vulnerability. This contradicts developer intuition (root = convenience, not danger) and the common mistakes list shows multiple compounding errors: files owned by www-data, no user separation, shared www-data across apps. These are all traps that a competent developer unfamiliar with Linux privilege models would easily fall into, making this a serious cognitive hazard.
Also Known As
TL;DR
Explanation
Key commands: useradd (create user), usermod (modify user), userdel (delete user), passwd (set password), groups (show user groups), id (show UID/GID), chown (change file ownership), su/sudo (switch user). PHP web security: PHP-FPM pool runs as www-data (or php-fpm); files should be owned by the deploy user, readable by www-data; writable directories (uploads, cache) owned by www-data. Service accounts: always run services as dedicated users with no login shell (/sbin/nologin) and no home directory unless needed. Principle of least privilege: each service user has only the access it needs.
Common Misconception
Why It Matters
Common Mistakes
- PHP-FPM running as root — critical security vulnerability.
- Web files owned by www-data — means a PHP exploit can modify the codebase; own files by deploy user.
- No separation between web user and deploy user — deploy credentials compromise the web process.
- Sharing www-data between multiple applications — one compromised app can read another's files.
Code Examples
# PHP-FPM as root — never do this:
[www]
user = root
group = root
# World-writable files — any process can modify:
chmod 777 /var/www/html/uploads/
# Any user on the system can write here# PHP-FPM pool — dedicated low-privilege user:
[www]
user = www-data
group = www-data
# File ownership separation:
# Application files: deploy user owns, www-data reads
chown -R deploy:www-data /var/www/app/
find /var/www/app -type f -exec chmod 640 {} \;
find /var/www/app -type d -exec chmod 750 {} \;
# Upload dir: www-data writes only here:
chown www-data:www-data /var/www/app/storage/
chmod 750 /var/www/app/storage/
# Create service account with no login shell:
useradd --system --no-create-home --shell /sbin/nologin php-worker