Closed Bug 453735 Opened 15 years ago Closed 14 years ago

When using cert9 (SQLite3) DB, set or change master password fails

Categories

(NSS :: Libraries, defect, P1)

Product:
NSS
Component:
Libraries
Version:
3.12.1
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
3.12.4

People

(Reporter: KaiE, Assigned: rrelyea)

References

Details

(Whiteboard: FIPS)

Attachments

(1 file)

Update database is keydb is not initialized
882 bytes, patch
nelson
: review+
wtc
: superreview+
Details | Diff | Splinter Review 
This test was performed using Firefox 3.0.x, NSS 3.12.1 and env var NSS_DEFAULT_DB_TYPE="sql"

I start Firefox, to to prefs, privacy, select "use a master password".
We bring up a dialog to enter and confirm a new password.
I click OK and nothing happens.

The error console shows me the following error:

Error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIPK11Token.initPassword]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://mozapps/content/preferences/changemp.js :: setPassword :: line 139"  data: no]
Source File: chrome://mozapps/content/preferences/changemp.js
Line: 139

This call maps to PSM's C++ function nsPK11Token::InitPassword
which calls:
    PK11_InitPin(mSlot, "", const_cast<char*>(aUtf8InitialPassword.get()));
Assignee: nobody → rrelyea
But 458750 might be releated.
I'm setting the FIPS keyword on the whiteboard for this bug.
Although this bug was NOT reported about a token in "FIPS mode",
the problem appears to be in the token, and any token change will 
affect the FIPS validation.  This bug must be fixed for Shared DB
to be usable.
Priority: -- → P1
Whiteboard: FIPS
Target Milestone: --- → 3.12.7
I see the same bug in Seamonkey 1.1.14. It look like, it works fine, when changing the master password. However, the next time I bring up the Change Master Password dialog, the security device has a spooky name like NS Shared [something I do not remember], and the current master password is disabled. Entering a new password and clicking the OK button has no effect, the dialog won't close.

I switched back to Seamonkey 1.1.13. Everything works fine. The security device is Software Security Device. And I can change the master password.
The bug still exists in Seamonkey 1.1.15 and 1.1.16. This makes all Seamonkey releases after 1.1.13 effectively unusable, if you want to do anything with saved passwords or certificates.
Bob, isn't this a "show stopper" for NSS 3.12 FIPS?  
If this bug remains unfixed, and FIPS-evaluated softoken isn't usable,
doesn't that make it rather useless?
I have been using Seamonkey 1.1.15 with saved passwords and don't have any problems changing the master password. I wasn't using FIPS or the shared DB env variable. I didn't override the NSS release that came with Seamonkey either. Just adding another data point.
Julien, this point of this bug is that the product cannot switch to using
cert9 DBs until setting and changing master passwords works with them.
Sorry, brain fart here. Is this a confirmed NSS bug ? I remember that FIPS had certain harsh requirements for passwords. The password may need to meet the FIPS requirement on the non-FIPS token before turning on FIPS. I think we have run into the same issues using our command-line tools when switching to FIPS.
Trying to set the password as "" is probably not valid for FIPS, but that would be a PSM error IMO.
> Is this a confirmed NSS bug ? 

No.  There is a problem.  That's confirmed.  Given that the problem is 
reproduced by replacing SM's ordinary NSS distribution with NSS 3.12.3 
and setting the environment variable, it seems likely, but not confirmed, 
that the problem is in NSS.
BTW, This bug says nothing about the user having tried FIPS mode. 
I see no reason to believe it is peculiar to FIPS mode.

It is a FIPS issue only because 
a) FF FIPS users use SQL DBs, and 
b) if it is a bug in softoken, it will be a problem to fix after the FIPS 
validation gets underway.
Summary: Shared DB, set master password fails → When using cert9 (SQLite3) DB, set or change master password fails
Target Milestone: 3.12.7 → 3.12.4
I have been unable to reproduce this bug at all. There were several problems in initialization of databases from old databases where where fixed in NSS 3.12.3.

What exactly are the steps to reproduce this? Is this on a fresh profile? A profile that has an old database. Doe the old database have a master password or not?

bob
I download 1.1.14 specifically. I found one issue with the package that I downloaded --- it was missing libsqlite3.so, which meant I couldn't reproduce any of the issues as it would never use the shared DB.

Also, seamonkey is missing libnssdbm3.so, which will cause no end of problems for users as *no* DB will be accessible. (It looks like on Linux it is picking up my system version).

I suspect these are what may be causing the seamonkey problems... however.

Once I put a proper libsqlite3.so in place, I was finally able to reproduce one failure:

1) Create a new profile with the old database (unset NSS_DEFAULT_DB_TYPE).
2) Go to an SSL website to make sure that that old database is created.
3) Restart seamonkey with NSS_DEFAULT_DB_TYPE set to sql.
4) Try to set the master password. Setting the master password appears to 'work', but looking at the dialog again, the master password is not set.
5) If you restart seamonkey, the password you tried to set in step 4 will actually be set.

What is happening is we aren't completely updating the databases because no master password is set. My testing didn't find this because all of our tools start up, do something and shutdown, so in testing this scenario with certutil, It's impossible to see step 4 (step 3 shows success, the next invocation of certutil winds up in step 5.

patch should be forth coming. Mac are you in a position to build a version of seamonkey to test the patch (I'm testing by replacing seamonkey's NSS with my built one)?

bob
Most NSS applications have initialized key databases (they may have an empty password, but they are initialized).

Mozilla products often don't. The key db is kept uninitialized so that when data is first added to the database mozilla can know if the user just had not initialized the database yet, or the user had chosen to run with an empty password.

The update code handles the empty password case and updates immediately (empty password is checked the same way as checking a normal password). This test does not happen if the database has not been initialized yet. If it hasn't been initialized, then database update can happen immediately because no sensitive data is yet stored in the database.

This code makes this update happen immediately, preventing weird situations like that seen in the bug where we initialize the pin for the new database, but we still are running with the old dbm database waiting for an update.

bob
Comment on attachment 372655 [details] [diff] [review]
Update database is keydb is not initialized

Asking for 2 reviews to drop this into a Release candidate tag.
Attachment #372655 - Flags: superreview?(wtc)
Attachment #372655 - Flags: review?(nelson)
Attachment #372655 - Flags: superreview?(wtc) → superreview+
Comment on attachment 372655 [details] [diff] [review]
Update database is keydb is not initialized

r=wtc.

>+    /* If no password is set, we can update right away */
>+    if (((keydb->db->sdb_flags & SDB_RDONLY) == 0) && keydb->update 
>+	&& crv != CKR_OK) {
>+	/* update the peer certdb if it exists */
>+	if (keydb->peerDB) {
>+	    sftkdb_Update(keydb->peerDB, NULL);
>+	}
>+	sftkdb_Update(keydb, NULL);
>+    }

A copy of this code (except for the "crv != CKR_OK" test, and
passing &key instead of NULL to sftkdb_Update, see the note below)
also appears in sftkdb_CheckPassword.  It would be nice to create
a function for this code.

Note: the 'key' argument to sftkdb_Update and sftkdb_mergeObject
is actually ignored, so you may want to remove that argument.

Just curious: why don't we need to update the secmod db?
> A copy of this code

Hey, that's where I got the fragment;).

> Just curious: why don't we need to update the secmod db?

We do, but it doesn't require a key to update, so we can do that right away. (in the code that deals with secmod.db/pkcs11.txt)
Comment on attachment 372655 [details] [diff] [review]
Update database is keydb is not initialized

r=nelson
I'm glad you figured out how to reproduce this, Bob!
Attachment #372655 - Flags: review?(nelson) → review+
Checking in softoken/sftkpwd.c;
/cvsroot/mozilla/security/nss/lib/softoken/sftkpwd.c,v  <--  sftkpwd.c
new revision: 1.9; previous revision: 1.8
done

Mac is it possible you can test this before I close the bug? thanks. bob.
Status: NEW → ASSIGNED
Oh, I'm sorry, I didn't notice, that you were all working **** this bug and actually asked me questions.

And, no. I'm afraid I will not be able to build Seamonkey with the patch. In the old days, I used to build my own Mozilla. But for the last few years, the newest Mozilla/Seamonkey source code releases have been unable to compile on my system, so I'm running the official compilations. I don't remember exactly what was the problem, but probably a lot of missing or old libraries.

My system: Fedora Core 5, x86, 64 bit, Linux Tatooine 2.6.20-1.2320.fc5 #1 SMP Tue Jun 12 18:50:49 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
If you were on a little later Fedora, you could probably get away with pulling the F-9 version of NSS. I think FC-5 was pre-nss selfpackage and has a package like mozilla-nss.

bob
Is this a Linux only bug ?
no.
OS: Linux → All
Hardware: x86 → All
You need to log in before you can comment on or make changes to this bug.