Re: [PATCH 1/3] elf: Allow dlopen of filter object to work [BZ #16272]

[Florian Weimer <fweimer at redhat dot com>]

* David Kilroy:

>> Florian Weimer
>> * David Kilroy:
>> 
>> >> Florian Weimer
>> >> * David Kilroy:
>> >>
>> >> >> The Solaris documentation does not mention symbol filtering
>> >> (constraining
>> >> >> the set of exported symbols) at run time.  This kind of filtering
>> >> >> is
>> >> achieved at
>> >> >> run time because the link editor only looks at symbols in the
>> >> >> filter and
>> >> does
>> >> >> not consult the filtee.
>> >> >
>> >> > My assumption was that on Solaris only the symbols mentioned in the
>> >> filter
>> >> > actually get bound at runtime. I haven't looked at what would have
>> >> > to be
>> >> done
>> >> > to support that behaviour. I'm sounds non-trivial :)
>> >>
>> >> I expected that based on the name of the feature, but the Solaris
>> >> documentation does not support that.  It's only clear that they
>> >> filter at link time.
>> >
>> > [I just wanted to respond to this part of your email here. I'll
>> > respond to the rest via Szabolcs email.]
>> >
>> > The web page does say "The runtime linker uses the filtee to resolve
>> > any symbols defined by filter.so.1. If the filtee is not found, or a
>> > filter symbol is not found in the filtee, the filter is skipped for
>> > this symbol lookup."
>> 
>> It says “not found in the filtee”.  I think this means that the filter is
>> never used for symbol lookup (something we do not implement in glibc), not
>> that the symbol set of the filtee is restricted to that of the filter (not
>> implemented either).  It is possible that there was a typo here in and the
>> roles of filter and filtee are swapped in this documentation paragraph,
>> though.
>
> It makes sense to me. I agree that the filter is never used for symbol lookup.
>
> filter.so.1, has symbol a(), b() and has DT_FILTER filtee.so.1
> filtee.so.1, has symbols a(), c()
>
> The first sentence says that the symbols defined in filter.so.1 would be
> resolved from filtee.so.1. So the runtime linker should look for a() and b()
> in filtee.so.1.
>
> The second sentence deals with b(), which is not in the filtee. To me it says
> that b() shouldn't resolve to the filters implementation, and therefore b()
> has to come from later in the search path.

Ahh, thanks for explaining it to me.  So this is the part that specifies
that filters do actually filtering.

As I said, I think glibc does not implement this, and I'm not sure if
implementing it would break your use case (hence my question about
interposition and default implementations).

Florian