Hacker News Reader

Comment by ffsm8 | Hacker News Reader

> Everything runs directly as root - nginx, php-fpm, smb,

For the record: you need root on Linux to open ports below 1000. By necessity, these programs need at least one thread that runs as root just from that.

Can't comment on the rest. As I never used it. Fedora server + cockpit UI was enough for me when I switched from my Synology NAS the other day

View on HN

You can use cap_net_bind_service to bind ports <1024. You can listen on >1024 and redirect in iptables, or even with a trivial TCP proxy.

There are options on pretty much any system, but certainly on Linux with capabilities. None of these require direct support from the application (dropping root after binding does).

You almost never need to run anything as root, especially not with these "run 6 different types of services in a box" type of appliances.

None of this is new; this was already widely considered best practice when I was starting out 25 years ago.

> There are options on pretty much any system, but certainly on Linux with capabilities.

If you're using systemd, you can grant the appropriate capability to the process by setting:

    [Service]
    AmbientCapabilities=CAP_NET_BIND_SERVICE

in its service file. Note that this will necessarily allow the process to listen to any port; there is, unfortunately, currently no way to lock it down to a single port.

You can drop root after binding, or you can use capabilities to allow a particular program to bind on privileged ports. php-fpm could listen on a UNIX socket instead of a TCP socket.

Exactly. A more modern secure approach is to let the init system open the socket and pass it as an FD. This has some side benefits too (not even temporary root for daemon, less custom code, standard&declarative config, socket activation).

(Of course Unraid, being based on Slackware, has a legacy init system that doesn't support this scheme. But there are enough other options.)

Reply on news.ycombinator.com