It's more that Unix systems were timesharing systems, any user could run a daemon, but you didn't want users to have the ability to grab a port used by system services, not just because they could impersonate a system service on the network, but also because then you couldn't trust localhost services, either, as well as it just being a PITA. This is still true today; though vanishingly few Linux systems are multi-tenant, it's still common to implicitly trust a local service.
Comments
Wait nginx ran as root?
It's usually launched as root and then drops its privileges for its workers. Unless... ;)
If you have write access to nginx.conf, you can set "user root root;"
Long ago in Linux if you wanted to listen on a privileged port (< 1024) you had to do so as root.
If you're connecting to a host on a port < 1024, then you know a SysAdmin must have set it up, and it must be trustworthy. It was a simpler time.
It's more that Unix systems were timesharing systems, any user could run a daemon, but you didn't want users to have the ability to grab a port used by system services, not just because they could impersonate a system service on the network, but also because then you couldn't trust localhost services, either, as well as it just being a PITA. This is still true today; though vanishingly few Linux systems are multi-tenant, it's still common to implicitly trust a local service.
is that no longer true?
No, now you have the option of using CAP_NET_BIND_SERVICE
There is also net.ipv4.ip_unprivileged_port_start
If the application supports it, there’s also systemd socket activation (or traditional inetd sorta stuff too if that fits)
Forgot to mention: you can use systemd-socket-proxyd to bridge to an application that doesn't support socket activation too: https://www.man7.org/linux/man-pages/man8/systemd-socket-pro...