Re: Possible bug with dlsym and LD_PRELOAD

[Paul Millar <paul dot millar at desy dot de>]

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.