Re: ld.so not ignoring LD_PRELOAD on seduid binaries?

[joostje@komputilo.org (joost witteveen)]

Je 2001/05/23(3)/ 9:05, Brian Ristuccia montris sian geniecon skribante:
> On Wed, May 23, 2001 at 03:26:07PM +0200, joost witteveen wrote:
> > 
> > Now, I'm wondering if anyone knows why ld.so silently ignores
> > $LD_PRELOAD if it does contain a `/', while it fails to load the
> > program when $LD_PRELOAD doesn't contain a `/'.
> > 
> 
> Good question. Perhaps it is because when a library is specified with no
> path, ld.so will attempt to preload it for setuid/setgid binaries provided
> the library image in question has its setgid bit set.

Ah, I didn't know that. Yes, you may be right.

> With regard to bug #98467: Has the value of LD_PRELOAD set by the fakeroot
> shell script changed between the current version and past versions of
> fakeroot

Yes. It was changed in a NMU, for sparc64.
Before, LD_LIBRARY_PATH wasn't used.

>, and if so, is this the reason why setuid programs now fail to
> execute at all? Is there any compelling reason why the value of LD_PRELOAD
> set by fakeroot couldn't be reverted to the one containing a '/'?

Well, see last point in the changelog.Debian:

  * fakeroot: Use LD_LIBRARY_PATH for setting directory, and only
    LD_PRELOAD the library name. This makes it so the the 32/64 libs for
    sparc/sparc64 will load which ever one is needed.

I just tried setting 

LD_PRELOAD=libfakeroot/libfakeroot.so.0
LD_LIBRARY_PATH=/usr/lib

but then unfortunately libfakeroot.so.0 cannot be found by ld.so:(

Of cource, at the moment on any system but spark64 we can revert to
the old situation. But that'll fail as soon as i386 also needs special
stuff.

Thanks,
joostje