HAProxy as root

Requests
1

Hi,

regarding haproxy.cfg, the global section contains:

global
        maxconn 64
        chroot /var/lib/haproxy
        stats socket /run/haproxy.sock mode 660 level admin
        stats timeout 30s
        user root
        group root

I wanted to flag this because running the HAProxy worker process as user root and group root seems to present a few security issues:

  1. Defeating the chroot jail: The config sets chroot /var/lib/haproxy, but a root user can break out of a chroot jail if remote code execution occurs.

  2. Principle of Least Privilege: HAProxy only needs root permissions at startup to bind to privileged ports (80/443). After binding, best practice is to drop privileges to a non-root system account (e.g., haproxy:haproxy).

Is there a specific DietPi architectural reason why user root and group root are set in the default configuration?

If not, would it be better to change this default to user haproxy / group haproxy (and ensure /var/lib/haproxy ownership is updated accordingly) in future image builds or software installations?

thanks

2

something we would need to have a look into

3

done with dietpi-software: HAProxy: switch from source build to own APT packages by Joulinar · Pull Request #8310 · MichaIng/DietPi · GitHub
As well we will switch to an own deb package instead of compiling from source.

4

i see a PR is in place for next release of dietpi, as HAProxy user i’m very grateful.
i see the fix of conf.d folder that not automatically created, the daemon removal. looking forward for the release.

1 note is on the log short and notice
understand this might more on personal choice/preferences. but i prefer something like

log stderr format raw local0 info

but again its more on preferences.

5

The “short” format is explicitly made for systemd logging: HAProxy then sends logs with correct severity to the systemd journal, so that it can be filtered by that with journalctl, als messages are correctly colored based on severity. When using “raw”, it logs with the fixed default info severity and fixed facility, and the severity/level is instead shown as part of the log message, which is not great. IIRC, also the PID was shown in HAProxy’s message, i.e. doubled in journal, and correctly skipped in “short” format.

Is there anything you are missing with the “short” format?

6

sorry if i’m not clear enough, i’m more toward the notice/info level, since haproxy can consider as the gate, it would be better if the logs shows any kind of traffic from 200 - 500 status
i’m ok with the short and color also personal preferences

7

If you need access logs, you can enable them. But I personally promote the oppinion of not logging sole access by default, but enabling this on demand, when facing issues, for diagnosis etc.

Though HTTP errors in logs would be good, for Fail2Ban etc. I got the impression, that HAProxy logs them with info severity as well. Maybe there is a way to raise the severity of request logs with 4xx/5xx response.