4 ms·

> 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

by ffsm8 3y ago

> 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

matthews2 3y ago
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.
- Ao7bei3s 3y ago
  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.)
deleted 3y ago
[deleted]
arp242 3y ago
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.
- duskwuff 3y 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.
  - deleted 3y ago
    [deleted]

by ffsm8 3y ago

matthews2 3y ago

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.

Ao7bei3s 3y ago
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.)

deleted 3y ago

[deleted]

arp242 3y ago

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.

duskwuff 3y 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.
- deleted 3y ago
  [deleted]