Bug 603313 - Cannot import private key
Cannot import private key
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: nss (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Elio Maldonado Batiz
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 466626 612269 619241 630101 630103 643132 643557 643559
  Show dependency treegraph
 
Reported: 2010-06-12 06:48 EDT by David Woodhouse
Modified: 2010-10-15 19:19 EDT (History)
8 users (show)

See Also:
Fixed In Version: nss-3.12.7-4.fc14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 630101 643132 (view as bug list)
Environment:
Last Closed: 2010-08-19 21:31:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
init user db first (2.40 KB, patch)
2010-06-15 12:58 EDT, David Woodhouse
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 625480 None None None Never

  None (edit)
Description David Woodhouse 2010-06-12 06:48:15 EDT
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.
Comment 1 Kai Engert (:kaie) 2010-06-14 04:31:23 EDT
Directory /etc/pki/nssdb is owned by root. My understanding is that it's read-only for ordinary users.
Comment 2 David Woodhouse 2010-06-14 07:06:55 EDT
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.
Comment 3 Kamil Dudka 2010-06-14 07:51:04 EDT
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
Comment 4 Elio Maldonado Batiz 2010-06-14 10:33:00 EDT
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
Comment 5 David Woodhouse 2010-06-14 10:56:25 EDT
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”);
Comment 6 David Woodhouse 2010-06-14 20:50:22 EDT
I think the problem here is happening because PK11_GetInternalKeySlot() is returning the read-only system database slot, not the writeable user database slot.
Comment 7 David Woodhouse 2010-06-14 21:03:37 EDT
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.
Comment 8 Bob Relyea 2010-06-15 12:29:22 EDT
Dave is correct, though the bug should be assigned to Elio or me. Shouldn't Elio be the default on NSS bugs now?

bob
Comment 9 Bob Relyea 2010-06-15 12:33:01 EDT
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
Comment 10 David Woodhouse 2010-06-15 12:58:11 EDT
Created attachment 424226 [details]
init user db first

This is my test patch. Should we open an upstream NSS bug?
Comment 11 David Woodhouse 2010-06-15 13:04:17 EDT
Also, can we add some tests to the NSS test suite so this sysinit stuff doesn't keep breaking?
Comment 12 Elio Maldonado Batiz 2010-06-17 15:18:08 EDT
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.
Comment 13 Elio Maldonado Batiz 2010-06-17 17:49:38 EDT
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.
Comment 14 David Woodhouse 2010-06-17 18:17:50 EDT
(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?
Comment 15 Bob Relyea 2010-06-17 19:04:39 EDT

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)
Comment 16 David Woodhouse 2010-06-17 19:18:02 EDT
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.
Comment 17 Bob Relyea 2010-06-17 19:32:57 EDT
yes, the cacert-ca package is exactly the thing we are trying to enable with this.
Comment 18 Elio Maldonado Batiz 2010-06-17 19:35:49 EDT
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.
Comment 19 David Woodhouse 2010-07-29 17:15:45 EDT
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?
Comment 20 Elio Maldonado Batiz 2010-07-31 18:10:54 EDT
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.
Comment 21 Fedora Update System 2010-08-02 01:11:04 EDT
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
Comment 22 Fedora Update System 2010-08-02 22:16:07 EDT
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
Comment 23 Fedora Update System 2010-08-03 14:57:48 EDT
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
Comment 24 David Woodhouse 2010-08-03 17:24:48 EDT
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...
Comment 25 Fedora Update System 2010-08-05 10:28:15 EDT
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
Comment 26 Fedora Update System 2010-08-05 19:32:47 EDT
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
Comment 27 Fedora Update System 2010-08-10 01:35:49 EDT
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
Comment 28 Fedora Update System 2010-08-10 22:55:55 EDT
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
Comment 29 Fedora Update System 2010-08-11 19:01:09 EDT
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
Comment 30 Fedora Update System 2010-08-11 19:01:25 EDT
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
Comment 31 Fedora Update System 2010-08-15 12:31:33 EDT
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
Comment 32 Fedora Update System 2010-08-15 12:36:33 EDT
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
Comment 33 Fedora Update System 2010-08-15 12:38:15 EDT
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
Comment 34 Fedora Update System 2010-08-19 21:31:10 EDT
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.
Comment 35 Fedora Update System 2010-09-02 11:42:06 EDT
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
Comment 36 Fedora Update System 2010-09-02 16:35:15 EDT
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.
Comment 37 Fedora Update System 2010-09-07 15:09:00 EDT
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
Comment 38 Fedora Update System 2010-09-10 23:39:00 EDT
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.

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