Proposal to reduce anti-bundling requirements

[Florian Weimer]

On 09/15/2015 03:41 PM, Carlos O'Donell wrote:
>> 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.

> Correct, with dlmopen you have complete isolation, but I don't understand
> the SQLite issue, so if you could expand on the requirement I'm happy
> to listen.

Before file-private locks, SQLite has its own locking framework which
prevents it from closing file descriptors prematurely if there is still
another database object using that file.  This is global state, which
has to be shared across all internal SQLite database objects.

If two copies of SQLite are loaded into the same process, they will not
share these support data for correct locking.  Of two copies of SQLite
happen to open the same database file, the first close operation will
release the lock of the other database file, too.  (That's due to the
broken semantics of POSIX locking SQLite tries to work around.)

More concretely, if we change Python to load extension modules with
dlmopen and a private namespace, and the user loads two extension
modules, and both of them try to use the same SQLite-based NSS
certificate database, then the locking will fail to work.  Whereas
currently, with a global namespace, we have one copy of SQLite, shared
global state, and the locking works.

The same issue will arise with any other library which implements sane
locking semantics on top of POSIX fcntl locks.  Such libraries will
break if there are multiple copies in the same process and the same file
is opened multiple times (even unlocked).

-- 
Florian Weimer / Red Hat Product Security