Closed Bug 449498 Opened 13 years ago Closed 7 months ago
Open secondary (additional) read-only system NSS database
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).
It shouldn't be an additional database; the application should open sql:/etc/pki/nssdb _instead_ of its old database. The libnsssysinit.so module automatically handles opening the user's own database in ~/.pki/nssdb as an 'overlay'. With the NSS bugs fixed as described in https://bugzilla.redhat.com/show_bug.cgi?id=603313 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.
This bug was initially filed against the NSS component with the expectation to
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 firstname.lastname@example.org
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 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 "library=libnsssysinit.so". 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)
(In reply to comment #6) > Bob, it'd be bad if an application had to read pkcs11.txt > directly and look for "library=libnsssysinit.so". Yeah, it sucks that we have to do this. cf. https://bugzilla.mozilla.org/show_bug.cgi?id=490238#c37 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 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 libnssysinit.so 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. bob
Attachment #451412 - Flags: review?(rrelyea) → review+
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 libnsssysinit.so ?
This patch uses NSS_InitWithMerge 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: https://wiki.mozilla.org/PSM:UIforSharedDB If you agree with me that application assisted merging is necessary, I believe this patch is r-
Attachment #451412 - Flags: review?(kaie) → review-
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.
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?
kai, can you switch this bug to PSM? Both the patch and the ultimate solution are PSM issues. bob
Any progress on this yet? As was mentioned earlier, this can be a major inconvenience in an enterprise environment.
FWIW the trust issue has mostly been solved. Fedora for example ships p11-kit-trust.so as a replacement for NSS's libnssckbi.so. It provides all the trust roots in the place that NSS *expects* them to come from.
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).
Are you referring to my comment 16? You do need your distribution to ship p11-kit-trust.so in place of Mozilla's libnssckbi.so, 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
Status: NEW → RESOLVED
Closed: 7 months ago
QA Contact: jjones
Resolution: --- → WONTFIX
Flags: needinfo?(jjones) → needinfo?(david.ward)
You need to log in before you can comment on or make changes to this bug.