Search code examples
assemblynasmldglibcdynamic-linking

Who is responsible to load files in /etc/ld.so.preload?

I have earlier thought, the programs which are linked to dynamic libraries looks into /etc/ld.so.preload.

But, somewhere I have read that

All programs try to open /etc/ld.so.preload, this behavior is baked into Glibc.

Hence, to avoid glibc I thought of writing the program in assembly code. Compiled it using nasm and ld. Still it is loading /etc/ld.so.preload libraries.

My ultimate goal is to write a program which do not tries to load libraries in /etc/ld.so.preload. For that I need to know who is responsible to load this and how can I write such a program(no language constraint)?

PS : My real problem is that I want to edit /etc/ld.so.preload to include my library. But In case if this library happens to be a broken one then every single command on my machine breaks and I cannot do anything on the machine. Hence, for such a case I want to keep a utility handy which would delete my library from /etc/ld.so.preload. In that case this utility as well as sudo must be completely statically linked.

Solution

  • Who is responsible to load files in /etc/ld.so.preload?

    The dynamic linker is. When using GLIBC, the dynamic linker is ld-linux.so.

    Compiled it using nasm and ld. Still it is loading /etc/ld.so.preload libraries.

    Either you linked against GLIBC dynamically, or the statement above is false.

    actually I am running it using sudo, and sudo needs ld.so.preload. Can we by any means make sudo statically linked?

    You can rebuild many programs to be statically linked, yes. But this has costs (disk space, must rebuild all programs for every security fix, etc.), and may not be entirely trivial. It's also unlikely to fix any real problem you have.

    My real problem is that I want to edit /etc/ld.so.preload to include my library. But In case if this library happens to be a broken one then every single command on my machine breaks and I cannot do anything on the machine. Hence, for such a case I want to keep a utility handy which would delete my library from /etc/ld.so.preload. In that case this utility as well as sudo must be completely statically linked.

    The solution to this problem is to do what Russ Ridge suggested in a comment on this answer: "install a statically linked version of BusyBox".

    BusyBox has both su and rm commands that you desire.

    An alternative solution is to learn how to use Linux recovery CD -- this may come in handy in a lot of situations, so learning how to recover a system is well worth the effort.