Re: dlopen_from()

["Carlos O'Donell" <carlos at redhat dot com>]

On Thu, Jan 23, 2020 at 10:28 AM Nick Barnes via libc-help
<libc-help@sourceware.org> wrote:
> The semantics of dlopen() depend on which shared object the calling
> function is in (RUNPATH, RPATH, ORIGIN, etc). This makes it difficult
> for shim libraries (using LD_PRELOAD) to wrap calls to dlopen(). There's
> no documented way to get at the underlying functionality (the actual
> implementing function, dl_open, which takes a caller address). I find
> myself digging through the libc source code, trying to fake up internal
> data structures which will allow me to fool dlopen() that I'm calling it
> from some other shared library. The only alternative seems to be some
> sort of ROP attack.

Can you provide a concrete example of a shim library that doesn't work
and how this would solve the problem?

I'd like to understand the use case in more detail.

I think I know where you're going, but I'd like to hear your thoughts
on the use cases.

> If I do the work to write a patch implementing and documenting void
> *dlopen_from(const char *filename, int flags, void *caller), would it
> stand any chance of incorporation into a future Glibc/libDL?

That depends largely on convincing maintainers that your new API has a
use case that users care about and is worth maintaining forever.

I'm all ears, I love hearing from users and seeing the problems they
face. The hard part is actually finding motivated people such as
yourself who are willing to tell their story :-)

Cheers,
Carlos.