Bug#651912: Re: sandboxing-related renderer crash ("Aw, snap") when loading NSS modules

[Jonathan Nieder]

Hi Fabien,

Fabien C. wrote:

> Still, I don't exactly understand what bug is this, and why it has been
> triggered by a Debian patch.

chromium's sandboxed environment is weird.  All file descriptors are
closed or redirected to nowhere at some point, and the sandboxed
process doesn't have access to the regular file system, for example.

Anyway, something about this environment is causing NSS initialization
to trigger SIGABRT.  Feels like a tripped assertion in the dynamic
linker, but I don't know.

I suspect it's not a Debian-specific bug.

For a long time we narrowly escaped trouble by another bug (revived by
the workaround), which is that NSS initialization wasn't happening as
chromium couldn't find the NSS libraries in the paths it was looking
for it, due to multiarch.

I don't know how upstream deals with it --- maybe they have patched
nss, maybe they use a different version of libnss than us, maybe some
other external library we are using interacts with this.  The stack
trace is kind of weird --- the failure reliably happens in NSPR's
equivalent of pthread_once preparing to call a function that would
seed a random number generator --- so maybe NSPR is involved
somewhere.  Maybe it has to do with the linker or the version of
ld.so.  I also haven't looked into how other distros (Tom Calloway's
packaging for Fedora, Fabien Tassin et al's packing for Ubuntu, etc)
deal with this and would be happy to hear if someone finds time to
investigate.