Open secondary (additional) read-only system NSS database



11 years ago
a month ago


(Reporter: kaie, Unassigned)


Firefox Tracking Flags

(Not tracked)


(Whiteboard: [psm-shared-db])


(1 attachment, 1 obsolete attachment)



11 years ago
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

9 years ago
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 3

9 years ago
This bug was initially filed against the NSS component with the expectation to
Whiteboard: [psm-shared-db]
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

9 years ago
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.
Attachment #451412 - Flags: review?(kaie)

Comment 6

9 years ago
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.
Attachment #451412 - Flags: review?(rrelyea)

Comment 7

9 years ago
(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

9 years ago
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.

Attachment #451412 - Flags: review?(rrelyea) → review+

Comment 9

9 years ago
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

8 years ago
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-


8 years ago
Duplicate of this bug: 620373


8 years ago
Attachment #451412 - Flags: review?(kaie) → review-

Comment 12

8 years ago
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

6 years ago
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

6 years ago
kai, can you switch this bug to PSM? Both the patch and the ultimate solution are PSM issues.


Comment 15

5 years ago
Any progress on this yet? As was mentioned earlier, this can be a major inconvenience in an enterprise environment.

Comment 16

5 years ago
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

4 years ago
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

4 years ago
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.
Probably relates to bug 454036 and should be platform all
You need to log in before you can comment on or make changes to this bug.