Run nginx workers as an unprivileged user

The fix/etc/nginx/nginx.conf

user www-data;    # Debian, Ubuntu
# user nginx;     # 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 problem.

Why it matters — and the part that confuses people

nginx runs as two kinds of process, and only one of them should worry you:

• The master starts as root. It has to: binding ports below 1024 requires privilege, and so does reading a TLS private key that is correctly locked down. It does no request handling.
• The workers are what actually parse requests, terminate TLS and talk to your application. They drop to the user you configure.

So ps showing root for one nginx process is normal and not a finding. Every other line showing root is.

That distinction matters because the workers are where the risk is. nginx has shipped memory-safety bugs in request-handling code — the 1.30.4/1.31.3 releases in 2026 fixed a buffer overflow in map with regex, a memory disclosure in the slice module, and a use-after-free. Those are worker-side. Whether such a bug is a contained compromise or a root shell is decided entirely by the user directive.

Don’t use root to fix a permissions problem

The usual road to user root; is a static file nginx can’t read, or a socket it can’t connect to. Root makes the error go away instantly.

Fix the permission instead:

sudo chown -R www-data:www-data /var/www/site
sudo chmod 640 /etc/nginx/ssl/site.key   # readable by root; master reads it before dropping

The key file is the one that trips people. The master reads it at startup while still root, so it does not need to be readable by www-data — and it shouldn’t be. A key readable by the worker user is a key readable by anything that compromises a worker.

systemd sandboxing

Cheap additional containment for the same bug:

/etc/systemd/system/nginx.service.d/hardening.conf

[Service]
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
ReadWritePaths=/var/log/nginx /var/lib/nginx /run

ProtectSystem=strict makes the filesystem read-only apart from the paths you name, so even a worker running as root couldn’t write to /etc.

Note NoNewPrivileges is compatible with binding port 80 here — the master binds before dropping privileges, so nothing needs to gain privilege later.

Verify it worked

Check the actual processes. Expect exactly one root master, and workers as your user:

ps -o user,pid,args -C nginx

root      1234 nginx: master process /usr/sbin/nginx
www-data  1235 nginx: worker process
www-data  1236 nginx: worker process

Confirm the effective config agrees:

sudo nginx -T 2>/dev/null | grep -E '^\s*user '

Check the private key is not readable by the worker user — this is the check people skip:

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

Expect permission denied. If the worker can read your private key, a worker compromise is a key compromise.

Confirm the sandbox holds:

systemctl show nginx -p User -p NoNewPrivileges -p ProtectSystem
sudo -u www-data touch /etc/nginx/test   # expect: permission denied

Before you apply this

Low risk on a packaged install — you’re confirming what’s already true.

ProtectSystem=strict breaks writes you forgot. nginx writes more places than people expect: logs, the client body temp path, proxy cache, fastcgi cache, and the pid file. Any of them outside ReadWritePaths fails, and cache write failures in particular surface as intermittent 500s rather than a clean startup error.

Find them before you apply it:

sudo nginx -T 2>/dev/null | grep -E 'access_log|error_log|_temp_path|_cache_path|pid '

Every path there needs to be in ReadWritePaths or under a path that is.

Changing user on a live server needs a restart, not a reload. A reload spawns new workers but the existing master keeps its original user setting for some purposes. Verify with ps after, not before — and remember a restart drops in-flight connections, unlike a reload.

Related

• The alias path traversal — what a worker can read matters more once a path bug exists.