Bug#372626: marked as done (LD_PRELOAD and multiarch)
Your message dated Sun, 9 Sep 2007 16:01:15 +0200
with message-id <20070909140112.GA9873@farad.aurel32.net>
and subject line LD_PRELOAD and multiarch
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
Package: libc6
Version: 2.3.2.ds1-22
Severity: wishlist
Background: some of the 32-bit binaries my users would like to run on
amd64 require tricks such as LD_PRELOAD=/usr/lib32/libpangohack.so.0.
Problem: ld-linux (part of the libc6 package) chokes if LD_PRELOAD
contains a library for the wrong architecture (i.e. a 32-bit library
if the executable is 64-bit, and vice-versa). Since LD_PRELOAD is
propagated through the environment, this can prevent a legacy 32-bit
binary from exec()ing a 64-bit binary (e.g., /bin/sh as in the system(3)
library call).
Wish: please make ld-linux skip libraries of the wrong architecture in
LD_PRELOAD without aborting the load. This would make life a lot easier
for users.
My apologies if this has been discussed before: I searched for such a
discussion with Google and didn't find anything.
I've thought a little about alternative solutions. For example, one
could introduce additional environment variables LD32_PRELOAD etc.
(I seem to recall that IRIX is/was doing something along these lines.)
This seems less elegant to me, and may cause security problems since
some software may strip LD_PRELOAD from the environment but let other
variables through.
Another possibility might be to LD_PRELOAD a library that intercepts
the exec() call and prevents LD_PRELOAD propagation to the child
process. But I find that a lot less convenient in general (although
it may be a desirable approach in some cases; but I don't think my
proposal would prevent anyone from taking that approach where warranted).
Question: does LD_LIBRARY_PATH need similar treatment?
--- End Message ---
--- Begin Message ---
Version: 2.3.6.ds1-13
On Sat, Jun 10, 2006 at 08:16:57PM +0200, Sergio Gelato wrote:
> Package: libc6
> Version: 2.3.2.ds1-22
> Severity: wishlist
>
> Background: some of the 32-bit binaries my users would like to run on
> amd64 require tricks such as LD_PRELOAD=/usr/lib32/libpangohack.so.0.
>
> Problem: ld-linux (part of the libc6 package) chokes if LD_PRELOAD
> contains a library for the wrong architecture (i.e. a 32-bit library
> if the executable is 64-bit, and vice-versa). Since LD_PRELOAD is
> propagated through the environment, this can prevent a legacy 32-bit
> binary from exec()ing a 64-bit binary (e.g., /bin/sh as in the system(3)
> library call).
This problem has been fixed somewhere between version 2.3.2.ds1-22 and
version 2.3.6.ds1-13. Closing the bug.
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
--- End Message ---
Reply to: