Hacker News new | ask | show | jobs
by fc417fc802 159 days ago
> use LD_PRELOAD to wrap fopen/open/openat (I'm pretty sure, ready made solutions for this already exist)

I think I would literally recompile libc to patch fopen/open/openat long before I would even begin to consider writing a kernel module to mess with filesystem paths on a per-process basis.

I feel like if you find yourself seriously considering writing a kernel module then you are either contributing to kernel development, or have embarked on an adventure specifically to learn about kernel internals, or have take a very wrong turn.
1 comments
thwarted 159 days ago
LD_PRELOAD has nothing to do with the kernel, it's entirely resolved in user space; in this context, it would be used to replace libc functions.

> I think I would literally recompile libc to patch fopen/open/openat

That's literally the functionality that LD_PRELOAD provides without having to recompile libc.

link
fc417fc802 159 days ago
Yes, I am aware. I was suggesting that even going to the ridiculous length of patching and replacing libc system wide would likely make more sense than authoring a custom kernel module to accomplish most tasks for which such options are applicable.
link
XorNot 159 days ago
Statically compiled binaries don't use libc. Golang is one, anything with Rust and MUSL is another, and reliably injecting an environment variables into Nix is well..not reliable. It also links its own hashed libc paths which you can't predict and which shouldn't be different to any process which isn't trying to establish TLS connections.

It's not like I didn't try this stuff.

link
fc417fc802 158 days ago
You can hook the system call to open a file regardless of libc use. If for some strange reason you really wanted to patch libc and the program you're using statically links it (ex musl) that isn't an issue - just patch the relevant libc implementation and recompile. But more generally, if you have access to the source code then why would you not directly patch the program in question instead of resorting to these sorts of shenanigans?

Seriously, you're doing it wrong. Just hook the relevant system call and be done with it. Your usecase is literally one of the first eBPF tutorials that comes up when looking for information about modifying system call arguments. https://github.com/eunomia-bpf/bpf-developer-tutorial/tree/m...

link