[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: authbind (LD_PRELOAD) and multiarch



Raphael Hertzog <hertzog@debian.org> writes:

> On Mon, 12 Dec 2011, Ian Jackson wrote:
>>  * I will need to arrange for the same LD_PRELOAD setting to load the
>>    correct libauthbind for each arch.  So I guess I do
>>    LD_PRELOAD=libauthbind.so.1 rather than supplying an absolute path,
>>    and trust ld.so to get the right one out of /usr/lib/<triplet>.
>>    Is that right ?
>
> I don't know, ld.so(8) does not document this. (But it doesn't look wrong
> at least)
>
>>  * AFAICT there is no way on a multiarch system to say in my
>>    dependencies "I need this package on all architectures supported on
>>    this system".  I went and looked at testing's fakeroot but I'm not
>>    sure I should be using what it does as an example.  How should an
>>    LD_PRELOAD hack approach this problem ?
>
> What does fakeroot do? My first idea would be to fail early and provide a
> useful error message.

fake(ch)root sets LD_PRELOAD=lib.so and
LD_LIBRARY_PATH="/usr/lib/fakeroot:/usr/lib32/fakeroot:/usr/lib64/fakeroot:$LD_LIBRARY_PATH"
or nowadays the same using the multiarch dirs. So the library remains a
private library but ld.so is tasked with searching for the one mathing
the elf format it is loading.

> Find out the arch of the executable, verify if the corresponding preload
> library is available. If it's not, then fail and instruct the user to
> install the missing library.
>
> But this means that you have done (part of) the work that you were
> intending to offload to ld.so.
>
>> To best avoid transitional problems I guess piece 2 should go into
>> "authbind" (Multi-arch: same; Depends: authbind-support) and pieces 1
>> and 3 would in "authbind-support" (Multi-arch: foreign; no
>> dependency).  But I'm not sure.
>
> Yes.
>
> Cheers,

The hard part comes with extending this past the simple biarch cases and
support for example arm binaries run via binfmt-misc on amd64. The list
of directories to add to LD_LIBRARY_PATH needs to be dynamic depending
on what architectures are configured for the system.

Since we have a few packages that do LD_PRELOAD tricks (eatmydata is
another one) maybe we should have a common tool that extends the
LD_LIBRARY_PATH, e.g.

LD_LIBRARY_PATH="$(extend-library-path --pkg fakeroot)"
LD_LIBRARY_PATH="$(extend-library-path --pkg fakechroot --sysroot /srv/chroot)"

The tool would then contain the know-how to figure out which multiarch
directories to include in a single point instead of eveyone duplicating
that code.

MfG
        Goswin


Reply to: