[vlc-devel] [patch] Alter symbol-globalising dlopen(RTLD_NOLOAD) call to succeed

[jpd at m2x.nl]

On Fri, February 13, 2009 1:46 pm, Rémi Denis-Courmont wrote:
> On Fri, 13 Feb 2009 13:07:56 +0100 (CET), jpd at m2x.nl wrote:
>> On Fri, February 13, 2009 12:24 pm, Rémi Denis-Courmont wrote:
>>> AGAIN, the symbols can come from something ELSE than libvlccore.so.
>>> That's the whole point. If we _are_ a libvlccore(.a) linked into another
>>> object, we don't want to go and override ourselves with whatever
>>> _other_ image of libvlccore(.so) happens to be in our process space.
>>>
>>> What we want to expose it ourselves (whatever that means), not
>>> /usr/lib/libvlccore.so.

ITYM you want to expose the already loaded symbols regardless of the
name of the shared object they were loaded from.

If the shared object "we" were loaded from is named differently,
dlopen("libvlccore.so",RTLD_NOLOAD|...) will fail and not load anything.

If on the other hand you are concerned about multiple instances of
vlccore.so in "our" address space, and manage to figure out which is
which, the proper fix, such as it is, would be to use RTLD_DEEPBIND.

It seems that the dlsym call thus does not safeguard against your stated
case since it does not occur in this dlopen call, but it does break the
plugin because it prevents RTLD_GLOBAL from being set.

Besides, some adversary or ill-informed tinkerer can always LD_PRELOAD
--a well-known issue with ld.so, for better or for worse-- so I'm
not sure this intended safeguard ever has a positive effect.

If you believe otherwise, please show how that would work.


>> I do not think that dlsym is the correct way to infer that case.
>
> Well, it is a hack. And so is the following dlopen(). But I am not aware of
> any way to do what we want/need with libdl other than that, or linking the
> plugins against libvlccore. The later, among other things, implies getting
> rid of revision.c, which I has been forced onto VLC by M2X in the first
> place.

I must confess that I have no idea why linking plugins against libvlccore
or the existence of revision.c is in any way or form a factor in calling
dlsym on something else entirely.

I would say that calling dlsym this way checks for a link-time decision,
and it probably would not be unreasonable to require a preprocessor symbol
(given that vlc is open source) or probably more appropriately would be
solved by telling the loader directly what is desired. I'm not aware of a
way to tell webbrowsers to use RTLD_GLOBAL on the plugin directly.


>> In fact and despite my limited knowledge of ld.so, I am reasonably
>> sure it is an incorrect way. It seems to me to be something for ld.so
>> to do using weak symbols, and if not perhaps using the preprocessor.
>
> If you know a better solution, you're welcome to implement it.

I have to focus on the webbrowser plugins for the moment, not on
loader trickery for what appear to be wilfully nonstandard cases.