This works: $ pk12util -d sql:/home/dwmw2/.pki/nssdb -i ~/Download/dwmw2a.p12 Enter password for PKCS12 file: pk12util: PKCS12 IMPORT SUCCESSFUL This doesn't: $ pk12util -d sql:/etc/pki/nssdb -i ~/Download/dwmw2a.p12 Enter password for PKCS12 file: pk12util: PKCS12 decode import bags failed: Unable to import. Error attempting to import private key. Given that I have the system nss database enabled, surely these two commands should have the same effect? This is causing problems for applications which attempt to use the system database and import private keys.
Directory /etc/pki/nssdb is owned by root. My understanding is that it's read-only for ordinary users.
With the 'shared system database' enabled (run 'setup-nsssysinit on' as root), the user's directory in ~/.pki/nssdb is automatically opened as an 'overlay'. You can't write to the _system_ part of the database, of course; any writes should to to the user's store. I've just noticed that bug 547860 has recurred too -- I can't write certs to the system store either, although I should be able to.
FWIW, here is the vision of how it should work, that Elio posted me the other day: https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX
Yes, that's the vision of how things work with brand new applications that follow the guidance given there. p12util was written a while back, it is totally unaware of the system database and even shared db for that matter. Behind the back of the application nsssysinit ensures that the system database is opened read only when it detects that the user doesn't have write permissions to /etc/pki/nssdb. pk12util is behaving as expected by users and existing autamated scripts which is a good thing. Admittedly, it doesn't live up to the vision expressed in the wiki. We could write some new samples that illustrate how best to comply with the new guidance. We do have an on-going effort to create brand-new sample code, see https://bugzilla.mozilla.org/show_bug.cgi?id=490238
No, the whole _point_ of libnsssysinit.so was to hide the details from the application -- so when you open sql:/etc/pki/nssdb, you _automatically_ get the writeable ~/.pki/nssdb directory opened too. From the beginning of the NSS_Shared_DB_And_LINUX page linked above, we are told that we can open sql:/etc/pki/nssdb for read AND WRITE access: > The short summary: Except as noted below, all applications should initialize > NSS with the following call: > > rv = NSS_InitReadWrite(“sql:/etc/pki/nssdb”);
I think the problem here is happening because PK11_GetInternalKeySlot() is returning the read-only system database slot, not the writeable user database slot.
A slot only seems to be marked as the internal key slot if it's _not_ the first time that module has been loaded. pk11_setInternalKeySlot() is only ever called from secmod_handleReload(). Changing the order of the slots in sysinit.c so that the system database is registered first, and the user database afterwards, seems to 'fix' this.
Dave is correct, though the bug should be assigned to Elio or me. Shouldn't Elio be the default on NSS bugs now? bob
Looks like an interaction between the nsssysinit code and the library init code. I think changing sysinit as David suggests is probably the right initial thing to do, but we should look at why we don't try to set the InternalKeySlot on the initial call if we aren't using the library init stuff... bob
Created attachment 424226 [details] init user db first This is my test patch. Should we open an upstream NSS bug?
Also, can we add some tests to the NSS test suite so this sysinit stuff doesn't keep breaking?
In the meantime here's a simple-minded test i did on the patch. This works: [emaldona@elioT43 userdb-first-test]$ pk12util -i cert4user.p12 -d sql:/etc/pki/nssdb Enter Password or Pin for "NSS user database": Enter password for PKCS12 file: pk12util: PKCS12 IMPORT SUCCESSFUL Unfortunately, this also works: [emaldona@elioT43 userdb-first-test]$ su Password: [root@elioT43 userdb-first-test]# pk12util -i cert4root.p12 -d sql:/etc/pki/nssdb Enter password for PKCS12 file: pk12util: PKCS12 IMPORT SUCCESSFUL We can't have private keys imported to the system-wide database. Let's double-check: [root@elioT43 userdb-first-test]# certutil -K -d sql:/etc/pki/nssdb certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key and Certificate Services" < 0> rsa d4244dac7200b54e48b01ad898606176a51d3b5b cert4root [root@elioT43 userdb-first-test]# Root doesn't have an nssdb so that key did indeed made it to the system db.
The checks for access permissions are still there /* return a list of databases to open. First the system database. */ if (sysdb) { const char *readonly = userCanModifySystemDB() ? "" : "flags=readonly"; ..... /* Next the user database, but not for root. */ if (userdb != NULL && !userIsRoot()) { module_list[next++] = PR_smprintf( nsssysinit allows root to write access to the system db as it did before. At this stage there is no knowledge of what the write will be for. That restriction needs to be enforced somewhere else, either in the application or preferably within nss itself when there is sufficient knowledge of what the operation involves.
(In reply to comment #12) > We can't have private keys imported to the system-wide database. Um, why? If root wants to do that, why should we make it impossible?
Well we can have keys imported, but in general we shouldn't. If everyone is opening the token to get certs out, you don't want them to have to type in a password for the token itself (which usually happens if you have keys in there). Keys storage requires that the password be at least 'initialized'. If the password is 'initialized' and not null, certain operations will require a password. If FIPS is turned on access to the token will require a password just to read the certs. So we shouldn't do this in our normal operations. That being said, if there is a reason for root to insert a key, there should be a way to to this, and this is a perfectly reasonable way to do so. (Who knows maybe they want a machine wide private key available to everyone)? > Um, why? If root wants to do that, why should we make it impossible? You are right, we shouldn't make it impossible. I had a "talk" with Elio and he agrees with us now. (/me puts away his nerf weapons)
I'm perfectly happy to tell root "Don't Do That Then". In the general case, the only things that'll be modifying the root database in /etc/pki/nssdb will be our version of update-ca-certificates, run from the %post scripts in stuff like the cacert-ca package. No keys.
yes, the cacert-ca package is exactly the thing we are trying to enable with this.
Agreed even before the first shot. You should see his arsenal. By the away, no test regressions, there is F-13 scratch build at http://koji.fedoraproject.org/koji/taskinfo?taskID=2255612 if anyone is interested.
We think this is probably the cause of GNOME bug 625480. Can we have a fixed NSS for F-13 please? If not, surely we need to disable the NSS system DB by default in Fedora?
The NSS fix for F-13 should come in a few days. For Rawhide build see http://koji.fedoraproject.org/koji/buildinfo?buildID=187404 I hope affected folks can test with this build until once on-going tweaks to the git server are over and I can commit again and get the F-13/F-14 ones out.
nss-3.12.6-9.fc14 has been submitted as an update for Fedora 14. http://admin.fedoraproject.org/updates/nss-3.12.6-9.fc14
nss-3.12.6-9.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update nss'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/nss-3.12.6-9.fc14
nss-3.12.6-9.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/nss-3.12.6-9.fc13
Thanks. If we can just get the xulrunner patch in https://bugzilla.redhat.com/show_bug.cgi?id=546221#c24 shipped too, I think we're most of the way there...
nss-3.12.6-9.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update nss'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/nss-3.12.6-9.fc13
nss-3.12.6-11.fc14 has been submitted as an update for Fedora 14. http://admin.fedoraproject.org/updates/nss-3.12.6-11.fc14
nss-3.12.6-11.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update nss'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/nss-3.12.6-11.fc14
nss-3.12.6-11.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/nss-3.12.6-11.fc12
nss-3.12.6-11.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/nss-3.12.6-11.fc13
nss-3.12.6-12.fc14 has been submitted as an update for Fedora 14. http://admin.fedoraproject.org/updates/nss-3.12.6-12.fc14
nss-3.12.6-12.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/nss-3.12.6-12.fc13
nss-3.12.6-12.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/nss-3.12.6-12.fc12
nss-3.12.6-12.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
nss-3.12.7-3.fc14,nss-softokn-3.12.7-3.fc14,nss-util-3.12.7-2.fc14,nspr-4.8.6-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/nss-3.12.7-3.fc14,nss-softokn-3.12.7-3.fc14,nss-util-3.12.7-2.fc14,nspr-4.8.6-1.fc14
nss-3.12.6-12.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
nss-3.12.7-4.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/nss-3.12.7-4.fc14
nss-3.12.7-4.fc14, nspr-4.8.6-1.fc14, nss-util-3.12.7-2.fc14, nss-softokn-3.12.7-3.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.