Re: RFC: Treat RTLD_GLOBAL as unique to namespace when used with dlmopen

["Carlos O'Donell" <carlos at redhat dot com>]

On 07/24/2015 03:43 PM, Michael Kerrisk (man-pages) wrote:
>>>        If handle is NULL, then the only  permitted  value  for  lmid  is
>>>        LM_ID_BASE.
>>
>> What handle is NULL? If "filename" is NULL? 
> 
> Yes, sorry s/handle/filename/
> 
>> This would be a glibc limitation
>> which we plan to fix in 2.23. We should certainly return the handle to the
>> base object loaded in the namespace as you suggest, just like the application
>> is returned upon dlopen (NULL).
> 
> Okay.

To be more clear, that's exactly what my present patches implement.

>>>        ....
>>>
>>> NOTES
>>>    dlmopen() and namespaces
>>>        A  link-map list defines an isolated namespace for the resolution
>>>        of symbols by the dynamic linker.  Within a namespace,  dependent
>>>        shared  objects  are  implicitly  loaded  according  to the usual
>>>        rules, and symbol references are likewise resolved  according  to
>>>        the  usual  rules, but such resolution is confined to the definiâ
>>>        tions provided by the objects  that  have  been  (explicitly  and
>>>        implicitly) loaded into the namespace.
>>>
>>>        The  dlmopen() function permits object-load isolationâthe ability
>>>        to load a shared object in a new namespace without  exposing  the
>>>        rest  of the application to the symbols made available by the new
>>>        object.  Note that the use of the RTLD_LOCAL flag is  not  suffiâ
>>>        cient  for this purpose, since it prevents a shared object's symâ
>>>        bols from being available to any other shared  object.   In  some
>>>        cases,  we may want to make the symbols provided by a dynamically
>>>        loaded shared object available to  (a  subset  of)  other  shared
>>>        objects without exposing those symbols to the entire application.
>>>        This can be achieved  by  using  a  separate  namespace  and  the
>>>        RTLD_GLOBAL flag.
>>
>> Lastly, RTLD_LOCAL loaded objects may be promoted to RTLD_GLOBAL if they
>> are dependencies of another RTLD_GLOBAL loaded object. Therefore RTLD_LOCAL
>> is still not sufficient to isolate the loaded shared object without explicit
>> control over all object dependencies.
> 
> I wrote this up as
> 
>        The  dlmopen() function also can be used to provide better isolaâ
>        tion than the RTLD_LOCAL flag.   In  particular,  shared  objects
>        laoded with RTLD_LOCAL may be promoted to RTLD_GLOBAL if they are
>        dependencies of another shared object  loaded  with  RTLD_GLOBAL.
>        Thus,  RTLD_LOCAL  is  insufficient  to  isolate  a loaded shared
>        object except in the (uncommon) case where one has explicit  conâ
>        trol over all shared object dependencies.
> 
> Look okay?

Perfect.

>>>        Possible  uses  of  dlmopen() are plugins where the author of the
>>>        plugin-loading framework can't trust the plugin authors and  does
>>>        not  wish  any  undefined symbols from the plugin framework to be
>>>        resolved to plugin symbols.  Another use  is  to  load  the  same
>>>        object  more than once.  Without the use of dlmopen(), this would
>>>        require the creation of distinct  copies  of  the  shared  object
>>>        file.   Using dlmopen(), this can be achieved by loading the same
>>>        shared object file into different namespaces.
>>>
>>>        The glibc implementation supports a maximum of 16 namespaces.
>>>
>>>        ...
>>> BUGS
>>>        As  at  glibc  2.21, specifying the RTLD_GLOBAL flag when calling
>>>        dlmopen()   generates   an   error.    Furthermore,    specifying
>>>        RTLD_GLOBAL  when  calling  dlopen()  results  in a program crash
>>>        (SIGSEGV) if the call is made from any object loaded in a  namesâ
>>>        pace other than the initial namespace.
>>>
>>
>> Looks good to me. We need dlinfo documented also, which you already know,
>> but I wanted to make that explicit in this public discussion.
> 
> I think you didn't catch up on all your mail yet ;-).

When am I ever? :-)

c.