Run HAProxy as a non-root user

The fix/etc/haproxy/haproxy.cfg

global
    user haproxy
    group haproxy
    chroot /var/lib/haproxy

Most distribution packages set these already. The job here is usually to confirm it rather than to change it.

Why it matters

HAProxy starts as root because it has two things to do that require it: bind ports below 1024, and read TLS private keys that should not be readable by anyone else. Having done both, it drops privileges — the process that then spends its life parsing untrusted bytes off the network runs as haproxy, not root.

That split is what makes the parsing bugs survivable. HAProxy’s CVE history is mostly memory-safety and protocol-handling issues in exactly that code path; whether such a bug is a bad day or a total host compromise is decided by which user the worker was running as when it hit.

If user and group are absent, HAProxy keeps root for the whole process lifetime. The config is valid and the service works, so nothing draws attention to it.

chroot

chroot confines the worker to a directory after privileges are dropped, so a process that gets hijacked cannot see the filesystem. HAProxy’s documentation is explicit that the jail must be empty and non-writable by anyone — an empty directory is the whole point, since there is nothing inside it to abuse.

sudo mkdir -p /var/lib/haproxy
sudo chown root:root /var/lib/haproxy
sudo chmod 755 /var/lib/haproxy

Owned by root and empty. Do not put the socket, certificates or logs inside it; HAProxy opens all of those before it chroots, so they belong in their normal locations.

Keys and permissions

Because the key is read before the drop, the private key does not need to be readable by the haproxy user — and should not be:

sudo chown root:root /etc/haproxy/certs/site.pem
sudo chmod 400 /etc/haproxy/certs/site.pem

This is the same two-process reasoning as Apache and nginx: the privileged parent reads the secret at startup so the unprivileged worker never holds it.

Verify it worked

Check the config, then check reality — the running process is the claim that matters:

grep -E '^\s*(user|group|chroot)' /etc/haproxy/haproxy.cfg
ps -o pid,user,args -C haproxy

Expect the worker processes to show haproxy. In master-worker mode you will see a master and one or more workers; the workers are the ones that must not be root.

Confirm the chroot took, using a worker PID:

sudo ls -l /proc/$(pgrep -f 'haproxy -sf|haproxy -W' | tail -1)/root

That should point at your jail directory, not /.

Then confirm the key is not readable by the worker user:

sudo -u haproxy cat /etc/haproxy/certs/site.pem

Expect Permission denied. If it prints the key, the worker can read it.

Before you apply this

Three ways this bites, all of them at reload time rather than immediately:

Ports below 1024. Dropping privileges is fine for a process that already bound :443 as root. But if you later run HAProxy in a context where it never had root — a container with a non-root entrypoint — binding :443 fails. Either grant the capability or listen high and map the port:

sudo setcap 'cap_net_bind_service=+ep' /usr/sbin/haproxy

Anything opened after startup breaks under chroot. Files HAProxy opens lazily — certain map or ACL files loaded at runtime, or a certificate added later through the runtime API — are resolved relative to the jail and will not be found. If a reload starts failing after you add chroot, this is why.

Logging. HAProxy logs to a syslog socket, and under chroot it cannot reach /dev/log. Distribution packages solve this by having rsyslog create a socket inside the jail. If you set up chroot by hand and logs stop, that is the cause, not a logging misconfiguration.

Validate before reloading, and keep the current process alive until it passes:

sudo haproxy -c -f /etc/haproxy/haproxy.cfg && sudo systemctl reload haproxy

Related

• Configure TLS on HAProxy — the key the parent reads at startup.
• Protect the runtime API socket — which user should own it.