I think this is a response to this:
<a href="http://adamierymenko.com/privileged-ports-are-causing-climate-change/" rel="nofollow">http://adamierymenko.com/privileged-ports-are-causing-climat...</a><p>See discussion here:
<a href="https://news.ycombinator.com/item?id=14712576" rel="nofollow">https://news.ycombinator.com/item?id=14712576</a>
Rather than proxying data, why wouldn't you just bind the socket, and then transfer the file descriptor over the UNIX domain socket (using sendmsg/recvmsg)?<p>Or acept() incoming connections, and <i>then</i> pass the connection's file descriptor.
User space proxying for protocols other than http, though, is a bit tricky. If you aren't exposing things like source ip, listen queue depth, buffer sizes, errno from failures, etc...you are potentially limiting how well it works. Plus the read/write overhead. I'm not convinced this is any better than other approaches. Brokered iptables (or pf,etc) port rewrites seems cleaner, though it has issues as well.
It sounds like you should probably just go the whole hog and give each user their own network namespace and bridge them to the main network. Then they can run DHCP and get their own address and do with it what they like.<p>Wouldn't really work for Internet accessible IPv4 addresses, but IPv6 would be fine.
This is neat. There's a minor race condition at startup because scanhostdir calls scanportdir before watchdir. Reversing the order of calls would close the gap and shouldn't have any adverse effects.
For the most common case of lots of users needing ports (web apps), there's the option in nginx and newer Apache versions to proxy to a UNIX socket, so no port is needed for the user app. It's not gonna work for everything but <i>many</i> web app servers are fine with using a socket instead of a port.<p>There's also <a href="http://cyberelk.net/tim/software/portreserve/" rel="nofollow">http://cyberelk.net/tim/software/portreserve/</a> for when ports are really needed (not as elegant as the solution under discussion, though, as it just holds a port by binding to it until the rightful owner/service comes along).
I think these days I would approach the problem by creating per-user network namespaces and hack the privileged port limitation away from kernel (is there a sysctl for that/why not?)