ldd: resolve versus exec

[Rob Landley]

On Friday 31 October 2008 03:21:29 Bernhard Reutner-Fischer wrote:
> On Thu, Oct 30, 2008 at 12:56:42PM -0500, Rob Landley wrote:
> >On Wednesday 29 October 2008 14:49:59 Bernhard Reutner-Fischer wrote:
> >> Hi,
> >>
> >> I'm a bit puzzled about ldd, i admit:
> >>
> >> Not sure if running the binary is such a good idea. Thoughts?
> >
> >Sounds like you're using the glibc version of ldd, which has always run
>
> No, i'm using uClibc's ldd.
>
> >binaries when trying to figure out what they link to.  (This is one of the
> >reasons ld-linux.so needed the executable bit set, I forget the details
> > and archive.org is being stroppy.  I'm fairly certain I'm not a spambot,
> > but try telling them that...)
> >
> >The uClibc version worked like readelf last I checked, and it would be
> >criminally stupid to change that.
>
> Look at utils/ldd.c::find_dependancies()
> #ifdef __LDSO_LDD_SUPPORT__
> if (we could potentially run the binary)
>     execle(...)
>
> I'm resisting to change those "dependancy" to dependency for now..

Config option LDSO_LDD_SUPPORT is under General Library Settings.  It makes 
the uClibc ldd work like the glibc ldd.  I thought this option merely added 
the security hole to ld-uClibc.so so that you could use it to bypass NOEXEC 
mounts, but apparently it also makes the uClibc ldd incredibly stupid as 
well.  Do not select this option.

I don't know what happens if you run gnu ldd on a program that does an 
rm -rf / when run with no arguments, and I'm not sure I _want_ to know.  
Readelf gives you all the data you actually _need_; ldd merely formats the 
output more conveniently.  There's no need to run the binary, and lots of 
reasons not to.

Rob