Hacker News Reader

You also get the same thing with LD_PRELOAD.

We only way forward is proper sandboxing and not allowing any form of executables to run from $HOME, even if it means some coding patterns will no longer be as easy to implement.

View on HN

Not only is LD_PRELOAD interpreted by code within the process itself (so it can easily be ignored), but also the parent process which forks the sandbox process can (and most probably does) clear all the environment variables.

I believe it's not as easy on Windows for a process to protect itself against DLL injection.

On my UNIX days I used it as poor man's solution to track memory leaks, by overriding malloc()/free(), this was done at dynamic linker level, not the process.

So I checked and apparently this no longer works since AT_SECURE exists, around 2.6.0 time frame.

It has been a while since I cared to do this on GNU/Linux, maybe around 2002.

So thanks for forcing me to update myself.

> On my UNIX days I used it as poor man's solution to track memory leaks, by overriding malloc()/free(),

That's not a poor man's solution. That's how Valgrind's leak checker works (AFAIK).

Valgrind's leak checker is far more complicated than a simple malloc replacement. It's a virtual machine that runs the program being debugged.

It is poor man's solution, because on the cases there was money to spare, we could use Purify.

Reply on news.ycombinator.com