Bug#647992: chromium 14 broken with libnss3-1d from sid

Jonathan Nieder jrnieder at gmail.com
Wed Nov 16 01:11:16 UTC 2011


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





More information about the Pkg-games-devel mailing list