However, I could have sworn that I've seen a similar patch in recent years, but either my memories are serving me wrong or I simply can't find it anymore.
Nevertheless, I didn't benchmark whether this is the case, nor was performance the main goal for writing ip2unix. So if performance is a concern, maybe benchmark with your specific workload?
So for example if you have a service listening to TCP port 1234, you could do something like this:
socat UNIX-LISTEN:foo.sock TCP:localhost:1234
Now the service will still listen to port 1234 and you now have another socket that redirects to the other. This not only comes with a bit of overhead, but port 1234 is still reachable.
While using packet filtering on that port might lower the attack surface a bit, this won't prevent other (possibly compromised) services/users on the system to access port 1234.
Sure you could also filter based on uid, but IMHO it's better if that port isn't accessible in the first place.
socat as a TCP to unix socket proxy is doing a different job.
// "LD_PRELOAD" should've been in the submission title to avoid the "socat" questions
[1]: https://github.com/nixcloud/ip2unix/tree/d7d297ed68cdadc65dc...
While listening on localhost is some level of security it still means that lateral movement is possible if one of the services is compromised. It also means that if I give give someone else a user account or similarly run any less trusted code then they can access all of the services without authentication.
I'm going to look into this an apply this so that these services aren't accessible by other users.
ip2unix -r out,addr=127.1.1.1,path=foo-%p.sock firefox --new-instance
Whenever you then head over to something like http://127.1.1.1:9000/, the browser will try to connect to foo-9000.sock.
Things are a bit trickier if it gets to getpeername(), since we want to have somewhat stable addresses. This is done by querying SO_PEERCRED and encoding[2] the pid for IPv4 or pid, uid and gid for IPv6 into the address.
In summary: Programs shouldn't get confused, but if they do, it's certainly a bug in ip2unix. Feel free to open an issue :-)
[1]: https://github.com/nixcloud/ip2unix/blob/d7d297ed68cdadc65dc...
[2]: https://github.com/nixcloud/ip2unix/blob/d7d297ed68cdadc65dc...
That's what I had in mind someday™. Unfortunately, this has to wait for version 4.x maybe :-/