I hadn't heard of LD_PRELOAD before now, but my first reaction was "oh wow, better static link all the things!". Is that wrong?
Depends. Sadly, current trend is to keep everything static in big binary or bundle own set of dependencies. Let's assume your program is using libpng. Now, every program is keeping own libpng in RAM. That is not even the worst case; imagine particular libpng has security issue. The only way to update all those static programs is to recompile everything or download everything; which is trend, again.
I image we will have shared library approach "rediscovered" and commercialized with some cool buzzword.
Regarding security issues. I imagine that we will gradually rewrite everything in memory-safe languages such as Rust. It'll take a while - there's a lot of value in the code that's already been written. But once a library for a given task has been rewritten into a safe language, it's going to be hard to justify using the equivalent C library.
Of course this won't completely eliminate security issues. But I'd guess that along with a bit of fuzzing, it could easily reduce the frequency to <10% of what we have today. That, along with the fact that modern languages have package managers, and updating a library to the latest patch version is a one-line change, will make keeping on top of security issues well within the reach of the average app developer.
Shared libraries were a necessary tool in a world with limited computing resources, but I suspect the current trend will continue until they're used only in niche circumstances (plugins? libc?)
I suppose many/all would require the user's environment to be so throughly compromised that security might be a lost cause. But it still makes me wonder if there's a defense-in-depth argument in favor of static linking.
I mean, LD_PRELOAD is very useful. I used libfaketime once to debug a problem in a project that I worked that only happened when you run the test suite in a specific range of time. This power is very useful.
Can it be abused? Maybe, however you should assume that your environment is trusted or there is way worse ways to modify a process that is running in your system. In some of them it doesn't matter if the binary is static or not.
There are so many strong arguments for static linking that this one feels like a drop in the swimming pool; but yes.
LD_PRELOAD does not override syscalls themselves. It can be used to override the wrapper of a syscall.
Depending on your libc implementation, kernel version, and architecture, your `mmap` might not be implemented in terms of the `mmap` syscalls. It might be `mmap64` or `mmap2`. Similarly for `open` -- it's currently implemented with `openat` in glibc.
Erratum: the link meant for "openssl-hook" actually takes you to "otherport".
There’s no such thing...
Edit: I stand corrected. I thought it was a C-Corp.
Most of the time you can spot environment variable usage in binaries using strings(1) (folks still like to use upper case env vars in non-system applications even though this goes against POSIX).
But by using LD_PRELOAD you can easily see if the program is actually hitting the codepath reads that variable without debuggers or grovelling about in the assembly.
https://github.com/zliuva/ktlswrapper
Did it for fun to get my Transmission daemon behind TLS without socat or nginx.
It took me a minute to understand why this is useful for backups. It prevents your backup tool from leaving a bunch of stuff in cache that isn't needed. It's a performance thing. (And it's not a data integrity thing, which came to mind because one reason for flushing a cache is to be sure writes to the underlying layer been done.)
This leads to an interesting question: do most backup tools not already have this optimization built in? From a quick perusal of the GNU tar manual page and source and running it under strace, it doesn't seem like it supports it. (Though tar is really more of an archive tool than a backup tool, which isn't precisely the same thing.)
I remember I used LD_PRELOAD along with fakechroot and fakeroot packages to get most things working. Those days' android allowed running statically linked binaries among other things.
(except DNS resolution and argv[0] was always ${some_large_path}/ld-linux-armhf.so, as I invoked glibc dynamic loader)..
Those days I didn't have a laptop and learned some C programming and unix stuff through termux. I sometimes think, as a CSE student, I lack the enthusiasm I had in those 12th grade days..
There are tons of extremely OpenVZ hostings on the interweb but with an ancient 2.6 kernel like centos5.
With LKL you can enjoy the benefits of modern kernel with minimal performance penalty.
Submitted an issue here: https://github.com/gaul/awesome-ld-preload/issues/1
https://github.com/mariusae/trickle
"Trickle is a userland bandwidth shaper for Unix-like systems."
