HN Explorer

8 comments

[ 19.6 ms ] story [ 598 ms ] thread
hamandcheese
Does this work for statically-linked binaries (like golang programs)?
salawat
No. You would need to recompile the binary. This will only work for dynamically linked code.
ratdragon
I love LD_PRELOAD hacks, too bad it is less & less binaries that can be "hacked" like this.
kohlschuetter
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.

riedel
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

kohlschuetter
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.

jwilk
> 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.

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