Unprivileged users can't use iptables, so that doesn't change anything about the blog post. I'd suggest that if it's so easy, but still doesn't get done, that still also leaves the blog post intact. In a way it doesn't help when there's a thousand ways to do something, so none of them get done.

This seems to be a common misunderstanding of the blog post. Yes, there's a ton of ways for root to create privileged ports, and a ton of ways to delegate it in various ways. But all of them require actions by root, and sysadmining, and aren't as secure as a system designed to work this way from the beginning would be, so nobody uses them, so in terms of addressing his discussion points, they might as well not exist.

But surely, creating the user requires sysadmin privs, and as part of setting up the user the appropriate work could be done to allow whatever hole-punching is required. The reality though is that if Mary, Joe and Tim all want to listen in port 80, there's going to be a mess - hence using a common server (on a privileged port!) to demux incoming requests.

I don't understand the use case here. Are people really expecting to be able to configure stock Linux distribution images purely from unprivileged user accounts?

Because this iptables hack can be built right into a custom Linux distribution.

That's not enough, because this would allow only one unprivileged user to bind to the HTTP port (in this case - 8080). Another user trying to bind to the same port would get an error. So for this scenario the author is talking about a custom solution with a reverse proxy would probably work best - getting all requests directed at 80 and distributing them to as many servers as necessary.

My solution was to only put one HTTP server on a machine. I agree that a reverse proxy is the solution for those really wanting HTTP multi-tenancy on individual machines. But is this a really in-demand use case?