This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Possible bug with dlsym and LD_PRELOAD
On 21/08/12 20:50, Paul Millar wrote:
> Hi Paul,
>
> Thanks for the quick reply.
>
> On 21/08/12 16:16, Paul Pluzhnikov wrote:
>> On Tue, Aug 21, 2012 at 12:14 AM, Paul Millar<paul.millar@desy.de>
>> wrote:
>>> I'm trying to use the LD_PRELOAD to override symbol bindings, to allow
>>> alternative behaviour. While doing this, I've found something that
>>> could be
>>> a bug and wanted to ask people's opinion before submitting a
>>> bug-report.
>> The bug appears to be in your program.
>
> Actually, the "bug" is more just a demonstration of the problem.
>
> In reality, I want to write some wrapper code to take unmodified
> binaries (and their libraries) and run them in a controlled
> environment. The plan is to provide a functional testing framework,
> somewhat similar to mocking. Calls to certain libc functions would be
> intercepted and either passed on (to libc) or a fake reply is
> provided. The framework would maintain the state, consistent with a
> test-plan. Mapping this to the demonstrator code, this is equivalent
> to being unable to modify 'test-dynamic', 'test-static' and
> 'libhello.so', but being able to modify libwrapper.so and how the
> 'test-dynamic' and 'test-static' is called.
>
> So, although you're quite right that this could be fixed by changing
> RTLD_NEXT to RTLD_DEFAULT, it isn't the answer I was hoping for! The
> behaviour I was hoping for was for the LD_PRELOAD libraries always
> appearing first when the linker tries to resolve a symbol. However,
> that isn't the case (and this isn't considered a bug).
>
> So, would using LD_AUDIT work here, to intercept the linker (both when
> resolving symbols and dlsym) and provide alternative symbols? I
> believe the la_symbind* functions allow the registered library to
> modify which function a symbol is bound to.
>
> The alternative would be to do code-analyse at runtime and inject
> break-point at the API calls (and dlsym). I believe ltrace does this;
> however, I was hoping to avoid that by using either LD_PRELOAD or
> LD_AUDIT.
Have you tried simply replacing dlsym() ?
There you could place yourself in front of any call.