This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: dlmopen with RTLD_GLOBAL
- From: Elliott Slaughter <elliottslaughter at gmail dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: libc-help at sourceware dot org
- Date: Mon, 3 Jul 2017 11:37:32 -0700
- Subject: Re: dlmopen with RTLD_GLOBAL
- Authentication-results: sourceware.org; auth=none
- References: <CAJ9X=kbxVUyf5DzZMPvkpTkehWEfeoirNNJcGMNb6Lvv98tHNA@mail.gmail.com> <fb221449-a68e-5aed-8b2d-815cc0fcad88@redhat.com> <CAJ9X=kZndr5kYoLUpp7-g+ffeCo-fXgSXEHLn1vEV=bgFnWX1Q@mail.gmail.com> <cb2ec4f8-91ac-d586-9888-b93619234259@redhat.com>
On Mon, Jul 3, 2017 at 11:27 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 06/30/2017 11:52 PM, Elliott Slaughter wrote:
>> main:
>> dlmopen(LM_ID_NEWLM, "libpython2.7.so", RTLD_DEEPBIND | RTLD_LOCAL |
>> RTLD_LAZY)
>> from inside user Python script:
>> import some_native_module
>> this causes Python to execute the following (remember this is
>> inside the new namespace):
>> dlopen("some_native_module.so", ...)
>>
>> If RTLD_GLOBAL is an option with dlmopen, then the symbols can be
>> exposed within the new namespace, and subsequent dlopen calls to
>> shared objects that do not explicitly mention Python will succeed.
>
> What happens if you reload libpython2.7.so with RTLD_GLOBAL within the
> namespace?
I believe there is an outstanding bug for that:
https://sourceware.org/bugzilla/show_bug.cgi?id=18684
Though if it were fixed then yes, I think that would be sufficient.
--
Elliott Slaughter
"Don't worry about what anybody else is going to do. The best way to
predict the future is to invent it." - Alan Kay