Comment by fc417fc802
11 hours 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.
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.
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.
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.
[dead]