Last Comment Bug 449498 - Open secondary (additional) read-only system NSS database
: Open secondary (additional) read-only system NSS database
Status: NEW
Product: NSS
Classification: Components
Component: Libraries (show other bugs)
: 3.12
: x86 Linux
: -- normal with 9 votes (vote)
: ---
Assigned To: nobody
: 620373 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2008-08-06 16:14 PDT by Kai Engert (:kaie)
Modified: 2015-07-16 00:41 PDT (History)
23 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---

xulrunner patch to make firefox use system nssdb (2.14 KB, patch)
2010-06-15 12:23 PDT, David Woodhouse
no flags Details | Diff | Review
revised patch to try system db only on unix (2.17 KB, patch)
2010-06-15 16:18 PDT, David Woodhouse
kaie: review-
rrelyea: review+
Details | Diff | Review

Description Kai Engert (:kaie) 2008-08-06 16:14:04 PDT
Fedora has started to ship an NSS database in the OS global location /etc/pki/nssdb, which contains system-wide certificates or security modules that all applications should have access to.

I think the proposal is to open that additional database automatically on NSS init time.

We'd like to do this at least on Linux, and maybe we should start with #ifdef'ed code.
We could add other platforms, too, if there is interest and a standardized location for this kind of database (with the initial version or at a later time).
Comment 1 David Woodhouse 2010-06-15 12:23:04 PDT
Created attachment 451345 [details] [diff] [review]
xulrunner patch to make firefox use system nssdb

It shouldn't be an additional database; the application should open sql:/etc/pki/nssdb _instead_ of its old database. The module automatically handles opening the user's own database in ~/.pki/nssdb as an 'overlay'.

With the NSS bugs fixed as described in this works as expected; merging the old DBM database from the profile directory into the user's SQL database. If the system database isn't configured, then it just uses the DBM database as before.
Comment 2 David Woodhouse 2010-06-15 16:18:32 PDT
Created attachment 451412 [details] [diff] [review]
revised patch to try system db only on unix
Comment 3 Kai Engert (:kaie) 2010-06-16 07:59:52 PDT
This bug was initially filed against the NSS component with the expectation to
Comment 4 Nelson Bolyard (seldom reads bugmail) 2010-06-16 08:45:26 PDT
David, Are you requesting that this patch be reviewed and considered for 
inclusion?  Or is this merely a "work in progress"?  

If you believe this patch is ready for submission, please request that it 
be reviewed by
Comment 5 David Woodhouse 2010-06-16 09:52:37 PDT
Comment on attachment 451412 [details] [diff] [review]
revised patch to try system db only on unix

I think it's ready for inclusion. There are NSS bugs which need to be fixed -- but this part only triggers if the system NSS DB is enabled anyway; if it's not enabled you get the old behaviour.
Comment 6 Wan-Teh Chang 2010-06-16 10:09:02 PDT
Comment on attachment 451412 [details] [diff] [review]
revised patch to try system db only on unix

Bob Relyea is the best person to review this patch.

Bob, it'd be bad if an application had to read pkcs11.txt
directly and look for "".

This should be done by the NSS initialization functions.
If we have a good error code that NSS initialization functions
can return to indicate a missing pkcs11.txt unambiguously,
an application can simply try initializing NSS with
"sql:/etc/pki/nssdb", and fall back on the home/profile
directory if it gets that error code.
Comment 7 David Woodhouse 2010-06-16 10:17:12 PDT
(In reply to comment #6)
> Bob, it'd be bad if an application had to read pkcs11.txt
> directly and look for "".

Yeah, it sucks that we have to do this.


I'd rather have NSS just do the right thing rather than returning an error when we attempt to open sql:/etc/pki/nssdb r/w though.
Comment 8 Robert Relyea 2010-07-30 16:02:51 PDT
Comment on attachment 451412 [details] [diff] [review]
revised patch to try system db only on unix

Way behind on my reviews. I'm OK with this patch with the following caveats.

1) this is PSM code so Kai should have the final say since he'll have to support what goes in.
2) explicity checking for may fail in the future is we support some admin tool that replaces libnsssysinit with something that gets the nss configuration from some admin repository.

#1 is the more critical issue.

Comment 9 David Woodhouse 2010-07-31 01:30:15 PDT
Having talked to people about GNOME keyring plans at GUADEC this week, I'm a little bothered by your #2 too. I can envisage a situation where we point at a GNOME-keyring PKCS#11 module directly from /etc/pki/nssdb, instead of using libnsssysinit. (Although maybe we'd be more likely to put that in the user's pkcs11.txt instead.)

Should we make it trigger if *any* module would be loaded by the /etc/pki/nssdb/pkcs11.txt file, rather than just ?
Comment 10 Kai Engert (:kaie) 2011-02-09 10:49:39 PST
This patch uses 

Unless I missed something new, in my understanding, this may require multiple master password prompts. This is necessary if the old profile db uses a different password than the user's shared db in ~/.pki/nssdb

If this is true, in my understanding, we must use application assisted merging.

This document lists a proposal of how this could be done:

If you agree with me that application assisted merging is necessary, I believe this patch is r-
Comment 11 Kai Engert (:kaie) 2011-02-09 11:10:01 PST
*** Bug 620373 has been marked as a duplicate of this bug. ***
Comment 12 Schlomo Schapiro 2011-11-17 07:46:54 PST
Using Mozilla products in a corporate context is really inconvenient due to this issue. All our users have to individually import our CA certificate because FF and TB don't read it from the available /etc/pki/nssdb files.
Comment 13 David Mansfield 2013-04-18 12:07:25 PDT
The derailment of this bug is caused by a requirement that has nothing to do with this bug.
This bug is supposed to be about using a read-only, system-wide NSS database, however the blocking issue has to do with the fact that somewhere along the line, the decision was to ALSO remove the separate per-user NSS databases used by, e.g. firefox and thunderbird (which are currently stored in profile directory) and instead making a single per-user read-write database stored at, e.g. ~/.pki/nssdb

And while I understand that this is also a desirable outcome, does it have anything to do with allowing site-wide use of TB without having users be forced to hand-configure their TB before accessing corporate mail servers protected with internal CA, which is the essence of THIS bug report?  It doesn't seem the two are actually related...

Any chance that progress could be made on this?
Comment 14 Robert Relyea 2013-04-18 12:23:28 PDT
kai, can you switch this bug to PSM? Both the patch and the ultimate solution are PSM issues.

Comment 15 Cameron H 2014-07-29 14:43:22 PDT
Any progress on this yet? As was mentioned earlier, this can be a major inconvenience in an enterprise environment.
Comment 16 David Woodhouse 2014-12-12 04:53:02 PST
FWIW the trust issue has mostly been solved. Fedora for example ships as a replacement for NSS's It provides all the trust roots in the place that NSS *expects* them to come from.
Comment 17 vamega 2015-07-07 13:33:47 PDT
I'm not sure this bug has been completely fixed. I'm running Ubuntu 15.04 and it's not picking up certificates that the rest of the system is picking up (I checked that curl and wget were fetching the URL's correctly while verifying certificates).
Comment 18 David Woodhouse 2015-07-07 13:46:07 PDT
Are you referring to my comment 16? You do need your distribution to ship in place of Mozilla's, so it has a consistent set of trusted CAs with the rest of the system.
Comment 19 Stefan Fleiter (:sfleiter) 2015-07-16 00:41:04 PDT
Probably relates to bug 454036 and should be platform all

Note You need to log in before you can comment on or make changes to this bug.