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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
