Show HN: unsock: shim to automatically change AF_INET sockets to AF_UNIX, etc. | Hacker News Reader

Show HN: unsock: shim to automatically change AF_INET sockets to AF_UNIX, etc.

github.com

unsock is an LD_PRELOAD-able Linux library that converts AF_INET socket connections to AF_UNIX, AF_VSOCK, AF_TIPC, etc, helping reduce the dependency on TCP/UDP/IP for local communication.

It even handles the painful "CONNECT" proxy dance on Firecracker AF_UNIX/AF_VSOCK multiplexing sockets for you.

Open articleView on HN

I have been using ip2unix [1] in the past (for starting RStudio with no password on a multiuser remote system using SSH). Can you add ip2unix to your related software section and say something about the differences.Btw, I had some problems in the past with forks closing sockets, so I will look into this one if it is easier to handle this case.

[1] https://github.com/nixcloud/ip2unix

Thanks for the reference, I didn't know that project! I've added a link.

As far as I can tell the main differences are 1. ip2unix is AF_UNIX-only (but does map AF_INET6), and 2. that it maintains an internal mapping instead of using dup3.

> UNSOCK_DIR=/tmp/unsockets/ LD_PRELOAD=/usr/local/lib/libunsock.so ...

This teaches people it's OK to use predictable names in /tmp. Don't do that.

I've added a section in the README clarifying that this directory is only for demo purposes.

Does this work for statically-linked binaries (like golang programs)?

No. You would need to recompile the binary. This will only work for dynamically linked code.

I love LD_PRELOAD hacks, too bad it is less & less binaries that can be "hacked" like this.

I'd hope that most system-level programs remain dynamically linked to libc. I would be surprised, for example, if Alpine Linux would change their approach.

However, I can see that running code in a Hypervisor environment may benefit from static linking, and yes, unsock may have a hard time intercepting the syscalls.

In that scenario, I think adding kernel-level support for the mapping, like what libkrun's "Transparent Socket Impersonation" patches attempt, may be a viable alternative (see README.md)

I haven't deeply looked into it, but there's also the seccomp/ptrace interception route, which could achieve something like that from userland, but I suspect it's too heavy on performance.

Reply on news.ycombinator.com