Jonathan Nieder wrote:
> All I know is that changing the source to say
>
> if (nodb_init) {
> std::cerr << "about to call NSS_NoDB_Init(NULL)\n";
> status = NSS_NoDB_Init(NULL);
> std::cerr << "finished NSS_NoDB_Init(NULL)\n";
>
> causes the "about to call" line to be printed, but the "finished" line
> not to.
On the NSS side, in
mozilla/security/nss/lib/pk11wrap/pk11load.c::secmod_ModuleInit():
}
fprintf(stderr, "about to call C_Initialize\n");
crv = PK11_GETTAB(mod)->C_Initialize(pInitArgs);
fprintf(stderr, "finished C_Initialize\n");
if (CKR_CRYPTOKI_ALREADY_INITIALIZED == crv) {
causes the "about to call" line to be printed, but the "finished" line
not to.
This is the second time secmod_LoadPKCS11Module() is called. The
first time, it returns early (if (mod->moduleDBOnly) { ... return
SECSuccess; }).
The renderer process is sandboxed[1], which means that (among other
things) I think it lives in its own PID namespace, and at some point
later it will get chrooted to avoid filesystem access. Here's what
the caller (the ChromeRenderProcessObserver constructor) looks like:
if (!command_line.HasSwitch(switches::kSingleProcess)) {
// We are going to fork to engage the sandbox and we have not loaded
// any security modules so it is safe to disable the fork check in NSS.
crypto::DisableNSSForkCheck();
crypto::ForceNSSNoDBInit();
crypto::EnsureNSSInit();
}
[1] http://code.google.com/p/chromium/wiki/LinuxSUIDSandbox
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
