4 ms·
> Otherwise some user service can (inadvertently) take some port before a system service that was supposed to use that port started and cause completely prevent
by rascul 4y ago
> Otherwise some user service can (inadvertently) take some port before a system service that was supposed to use that port started and cause completely preventable failure of the system service.
There are plenty of cases where a web server is just a reverse proxy to :8080 or some other non-privileged port that could potentially be taken over in such a manner.
- XorNot 4y agoWhen you get right down to it the issue is port numbers just plain don't work for this. SELinux had some concept of sending SELinux security contexts over the network so you could get positive claims about what you were talking to, but it was never developed into a full system AFAIK. Which is ultimately what you want: TLS "I'm securely talking to the controller of this domain name" and then a secondary "within that controllers namespace, I'm definitely talking to the service I think I am".
- philsnow 4y ago> There are plenty of cases where a web server is just a reverse proxy to :8080 or some other non-privileged port that could potentially be taken over in such a manner True, but you can also proxy through a named unix domain socket on the filesystem and control access to it that way. At least nginx, haproxy, and caddy can all use a unix domain socket as an upstream.
- rascul 4y agoThis should generally be preferred when reverse proxying to localhost, as you get to adjust permissions on the socket. Unfortunately people aren't always doing this, and sometimes the upstream app isn't capable.