Run Apache workers as an unprivileged user

The fixapache2.conf / httpd.conf

User www-data       # Debian, Ubuntu
Group www-data
# User apache       # RHEL, Rocky, Alma

Distribution packages already do this. The page matters for hand-built installs, containers, and configs where someone set User root to fix a permissions error.

Why it matters

Apache runs as two kinds of process, and only one should concern you:

• The parent starts as root. It has to: binding ports below 1024 requires privilege, as does reading a properly locked-down TLS private key. It handles no requests.
• The children parse requests, terminate TLS and run your application. They drop to the configured User.

So one root line in ps is normal. Every other root line is the finding.

The children are where the risk lives. Apache 2.4.68 fixed thirteen CVEs including use-after-free and heap overflow conditions — all in request-handling code, all child-side. Whether such a bug is a contained compromise or a root shell is decided entirely by the User directive.

The document root should not be writable by the web user

This is the part people skip, and it matters more than the User line on most servers, because the User line is usually already right.

If www-data can write to the directory it serves, then any file-upload bug, any path traversal, any vulnerable CMS plugin can drop a .php file into the web root — and Apache will happily execute it. That’s a web shell from a bug that would otherwise be a nuisance.

sudo chown -R root:www-data /var/www/html
sudo find /var/www/html -type d -exec chmod 750 {} +
sudo find /var/www/html -type f -exec chmod 640 {} +

# Only the directories that genuinely need writes:
sudo chown -R www-data:www-data /var/www/html/uploads
sudo chmod 750 /var/www/html/uploads

Serve-only, don’t-write is the default you want; carve out the exceptions.

And for the upload directory that must be writable, stop it executing anything:

<Directory /var/www/html/uploads>
    Options -ExecCGI
    php_admin_flag engine off
    AddType text/plain .php .phtml .php5 .phar
</Directory>

That combination means a .php dropped there is served as plain text, not run.

The private key should not be readable by the workers

The parent reads SSLCertificateKeyFile at startup while still root, so it does not need to be readable by www-data — and it shouldn’t be:

sudo chown root:root /etc/ssl/private/site.key
sudo chmod 600 /etc/ssl/private/site.key

A key readable by the worker user is a key readable by anything that compromises a worker.

Verify it worked

Check the processes. Expect one root parent and unprivileged children:

ps -o user,pid,args -C apache2 2>/dev/null || ps -o user,pid,args -C httpd

root      1234 /usr/sbin/apache2 -k start
www-data  1235 /usr/sbin/apache2 -k start
www-data  1236 /usr/sbin/apache2 -k start

Every child running as root is the finding.

Confirm the config agrees:

sudo apachectl -t -D DUMP_RUN_CFG 2>/dev/null | grep -iE 'User|Group'

Now the test that matters — can the web user write to the web root?

sudo -u www-data test -w /var/www/html && echo "WRITABLE — fix this" || echo "not writable"

Find every directory it can write to:

sudo find /var/www -type d -writable -user www-data 2>/dev/null
sudo -u www-data find /var/www -type d -writable 2>/dev/null

That list should contain only your genuine upload and cache paths. Anything else is a web shell waiting for a bug.

And confirm the key is out of reach:

sudo -u www-data cat /etc/ssl/private/site.key

Expect permission denied.

Before you apply this

Tightening document root permissions breaks applications that write where they serve, and a great many do — WordPress writing wp-content/uploads and updating itself, Laravel writing storage/ and bootstrap/cache/, Nextcloud writing data/, and any CMS with a built-in updater.

Find out what needs writing before you chmod:

sudo -u www-data find /var/www/html -newermt '-7 days' -type f 2>/dev/null | \
  xargs -r -n1 dirname 2>/dev/null | sort | uniq -c | sort -rn | head

Directories with recent writes are the ones to carve out. Grant those and lock the rest.

The self-updater is the real trade-off. WordPress’s one-click update needs write access to the whole install — which is precisely the access that turns a plugin vulnerability into a web shell. Locking the root means updating by another route (WP-CLI, or your deploy pipeline). That’s a workflow decision, not a config one, and it deserves a conversation rather than a surprise at 2am.

Changing User needs a restart, not a reload — the parent must re-fork its children. That drops in-flight connections, unlike a graceful reload.

Don’t set User root to fix a permissions error. It works instantly and it makes every future bug a root bug. The error is telling you a path’s ownership is wrong; fix the path.

Related

• Disable unused modules — mod_cgi runs as this user.
• The Apache path traversal — what a worker can read matters once a path bug exists.