Re: Bug#98467: ld.so not ignoring LD_PRELOAD on seduid binaries?
Je 2001/05/23(3)/12:05, Ben Collins montris sian geniecon skribante:
> On Wed, May 23, 2001 at 05:33:44PM +0200, Richard Braakman wrote:
> > On Wed, May 23, 2001 at 09:50:17AM -0400, Brian Ristuccia wrote:
> > > 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, 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 '/'?
> >
> > I remember this... it was to fix a problem on sparc, where two different
> > libfakeroots were needed (one for sparc32 and one for sparc64). Having
> > the full path in the LD_PRELOAD string prevented the dynamic loader from
> > being smart about which one to load.
>
> Right. So fakeroot set LD_LIBRARY_PATH to the directories. Of course
> this fails when builds clobber LD_LIBRARY_PATH.
Well, with the old ld.so from David Engel (libc5), it was possible
to add the directories to /etc/ld.so.conf, and not use LD_LIBRARY_PATH.
If that works for the new one too, then builds that clobber
LD_LIBRARY_PATH would still be possible to support.
The problem here, however, was that when LD_PRELOAD is set to something
without `/' in it, then ld.so refuses to load setuid binaries.
(unless the library menitoned in LD_PRELOAD happens to be setuid too).
Wait, maybe, If I do the following:
/usr/lib/libfakeroot libfakeroot.so #`normal' version
/usr/lib/64/libfakeroot libfakeroot.so #64-bit version
/usr/lib/setuid/libfakeroot libfakeroot.so #_Fake_ fakeroot, that doesn't wrap anything, but with setuid bit set.
(and mention all dirs in eighter /etc/ld.so.conf or LD_LIBRARY_PATH)
then maybe ld.so will load the last, `setuid' version.
... trying ...
No, doesn't work. Even in that situation, ld.so refuses to load the
setuid binary. Pity.
In the good old days of the ld.so from David Engel, ld.so didn't refuse.
And I still don't see a good reason why it should refuse to run
the setuid binary anyway (ignoring any LD_PRELOAD settings).
--
joostje
Reply to: