Possible bug with dlsym and LD_PRELOAD
Paul Millar
paul.millar@desy.de
Tue Aug 21 18:51:00 GMT 2012
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.
> There is also a bug in your sources: wrapper.c is missing<stdlib.h>,
> which makes it fail to build like so:
>
> cc -Wall -c wrapper.c -o wrapper.lo -fPIC
> wrapper.c:9: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
> before ‘write’
> make: *** [wrapper.lo] Error 1
Hmm. that's rather odd.
The compiler seems to be complaining about "ssize_t" when declaring the
return value of the "write" function. For me (Debian unstable, using
2.13?), this is defined in various places (stdio.h, unistd.h,
i386-linux-gnu/sys/types.h, ...) but, strangely, not in stdlib.h.
The man pages for getline(3) and getdelim(3) functions say they're
declared in stdio.h and both return ssize_t. So I'd have expected
including stdio.h to have been sufficient.
> Not that it matters, but saying "on my machine" gives us no
> information about it. What version of glibc is installed on your machine?
Yeah, sorry about that. I'm running Debian unstable, which I believe is
currently v2.13.
Cheers,
Paul.
More information about the Libc-help
mailing list