Proposal to reduce anti-bundling requirements

[Florian Weimer]

On 09/11/2015 04:34 PM, Carlos O'Donell wrote:

>> How do you propose to resolve symbol conflicts if both the system
>> library and the bundled library are loaded into the same process?  The
>> current ELF linking scheme lacks good support for bundling libraries
>> whose exported symbols have not been mangled in some way.

> If you need different versions of the same shared libraries in the same
> process then you must use dlmopen to load the conflicting set into a
> distinct load namespace.
> 
> At present dlmopen is not functional for this purpose in upstream
> glibc master. It is something that I'm working on fixing [1].

I looked at the Solaris documentation, and I'm not sure if it's the
right use-case.  This seems to provide complete isolation, and would
break things like SQLite (at least older versions without file-private
locks) which need process-global state.

I think the real issue here is the ELF model with backwards/forwards
linking and symbol interposition.  Ideally, we should load each DSO
exactly once, resolve object symbols only against explicit DT_NEEDED
dependencies (not indirect dependencies), and make most symbols
non-interposable by default.  At least this is my gut feeling.  This is
a very difficult problem, especially at distribution scale.

We currently do not perform proper symbol namespace management in Fedora
(as we discussed before).  Perhaps we should try to track DSO symbol
namespaces first, and use that data to guide further evolution of
dynamic linking.

-- 
Florian Weimer / Red Hat Product Security