Ticket #698 (closed defect: fixed)

Opened 14 years ago

Last modified 13 years ago

New users are ending up with corrupted FF profiles

Reported by: jdreed Owned by: jdreed
Priority: normal Milestone: Natty Beta
Component: -- Keywords:
Cc: Fixed in version:
Upstream bug:

Description

We've seen a dramatic increase in the number of "SSL is disabled" tickets. zap-firefox-certs always fixes it, but some of the users are incoming students who insist that they've never logged into Athena before. I wonder if something in Firefox changed such that the new profiles we create are corrupted.

Change History

comment:1 Changed 14 years ago by geofft

Are these brand new, or did they log in once and then corrupt their profile by logging in somewhere else? I've heard a bunch of these as "I can't access [site with SSL, usually Gmail] any more".

I can always try blowing away a test account and reinitializing it from prototype_user, but I'm not convinced I believe it.

comment:2 Changed 14 years ago by jdreed

I also could not reproduce, but I had two users assert that they had never been able to access secure sites since first logging in. Doesn't mean that the profiles didn't somehow get corrupted. Multiple launches, perhaps? I have seen many users hammer on the FF icon due to the delay in the wrapper on first launch. Maybe we could throw up a zenity dialog when we muck with the profile in the awk script?

comment:3 Changed 13 years ago by jdreed

Poking at this, I was able to make it happen once by hammering on the FF icon.

Here's a potentially terrible idea:

jdreed@INFINITE-LOOP:~/src/athena/debathena/debathena/firefox-wrapper$ svn diff
Index: firefox.sh
===================================================================
--- firefox.sh	(revision 24944)
+++ firefox.sh	(working copy)
@@ -3,6 +3,16 @@
 # $Id: firefox.sh,v 1.8 2007-06-22 15:13:03 rbasch Exp $
 # Firefox wrapper script for Athena.
 
+wrapperlock=/tmp/ff-wrapper.${USER}.lock
+
+if [ -f $wrapperlock ]; then
+    exit 0
+fi
+
+touch $wrapperlock
+
+trap 'rm -f $wrapperlock' EXIT
+
 moz_progname=firefox
 
 # Profile directory's parent.
@@ -269,4 +279,6 @@
   fi
 fi
 
+rm -f $wrapperlock
+
 exec /usr/bin/firefox.debathena-orig "$@"

comment:4 Changed 13 years ago by jdreed

Alternatively, is there a way to check the {cert,key}[0-9].db files for corruption, and just nuke them on launch if they're corrupt? (Rather than make users run zap-firefox-certs)

comment:5 Changed 13 years ago by quentin

After watching a user replicate this problem, I think I know what is causing it. It happens when you use the GNOME panel's logout button to end your first Firefox session. Firefox seems to exit uncleanly, and trashes your cert db. (This only seems to happen if this was the first launch of Firefox, or the first launch since running zap-firefox-certs)

comment:6 Changed 13 years ago by jdreed

  • Status changed from new to accepted
  • Owner set to jdreed

So, we can fix this one of two ways. One is with something like this:

jdreed@INFINITE-LOOP:~/src/athena/debathena/debathena/firefox-wrapper$ svn diff
Index: firefox.sh
===================================================================
--- firefox.sh	(revision 24997)
+++ firefox.sh	(working copy)
@@ -269,4 +269,15 @@
   fi
 fi
 
+FIRSTRUNFILE="$HOME/.config/edu.mit.ist.firefox.firstrun"
+if ! [ -f "$FIRSTRUNFILE" ]; then
+    touch "$FIRSTRUNFILE"
+    zenity --warning --title="Firefox on Athena" --text="When running Firefox \
+on Athena, it is important that you completely quit Firefox (by choosing \
+\"Quit\" from the \"File\" menu) before logging out.  Failure to do so can \
+corrupt your MIT Certificates and result in you being unable to visit any \
+sites using SSL (e.g. Gmail, Amazon, etc.). \
+\n\n
+Click \"OK\" to continue."
+fi
 exec /usr/bin/firefox.debathena-orig "$@"

(If we go the above route, maybe the zap-*-cert* scripts should remove that file so the user will get warned each time they nuke their certs)

The other is by building [modutil  http://www.mozilla.org/projects/security/pki/nss/tools/modutil.html], which is in the SeaMonkey? source tree (though for some reason Ubuntu doesn't ship it, AFAICT), and trying to read the various .db files when we launch Firefox, and if we can't, inform the user that they're about to lose and give them a chance to fix the situation.

comment:7 Changed 13 years ago by jdreed

(er, the final version of the wrapper will ensure that $HOME/.config exists, although it almost always does)

comment:8 Changed 13 years ago by jdreed

Hrm, is verification as simple as installing libdb1-compat and calling db_dump185 on semod.db and comparing the output to some known-good patterns? That won't test the certs of course, but it will help us avoid the stupid "SSL is disabled" error.

comment:9 Changed 13 years ago by quentin

Can we do something clever with the Athena firefox extension to commit the cert database on first launch, or whenever they get a new cert? I don't know if the extension API gives you enough rope to do that...

comment:10 Changed 13 years ago by davidben

It's not clear they have enough rope to do that period. The database abstraction of NSS does have transaction hooks (begin, commit, etc.), but they're only implemented for the
SQLite backend. Firefox is still using the old BDB-based backend. (It's the 'legacydb' code in 'softoken'. I still have vague recollections of this codebase from over the summer; they had a nasty threading bug in the SQLite backend that I ended up looking into.)

comment:11 Changed 13 years ago by quentin

Worst-case, the firefox extension could immediately close Firefox on first launch, or trigger the built-in restarting behavior a la the built-in upgrader. Or the wrapper could install a known-good certificate database on first launch.

comment:12 Changed 13 years ago by rbasch

modutil is in the libnss3-tools package.

The wrapper could, say, create the profile on first launch, e.g. "firefox-debathena.orig -CreateProfile? default", then create the DBs via "modutil -create -force -dbdir". The "-list" option could presumably be used to check an existing profile.

comment:13 Changed 13 years ago by jdreed

Sounds good to me. If we're going to go that, I'd like to have us throw up a zenity dialog with --timeout saying something like "Creating Firefox profile, please wait" so that people don't hammer on the button.

comment:14 Changed 13 years ago by jdreed

  • Status changed from accepted to committed

OK, I finally was able to reproduce and have a borked profile to work with. "modutil -list -dbdir <whatever>" is a reasonable test. However, its failure mode on a borked (but existent) cert/key database is the same as on a nonexistent one. Additionally, it won't re-create the database if a borked one exists, it needs to be empty.

Note that it's probably over-conservative to nuke all the databases, since modutil only reads secmod.db (certutil is its analog for cert8/key3), but *shrug*

Fixed in r25134.

comment:15 Changed 13 years ago by jdreed

  • Status changed from committed to development

ACK'd and uploaded 10.0.9

comment:16 Changed 13 years ago by geofft

WFM. I did need to delete key3.db and cert8.db to trigger the dialog; deleting secmod.db was insufficient.

comment:17 Changed 13 years ago by geofft

Remember that firefox-wrapper is architecture-dependent because it includes the C binary testlock. You did not build this package for i386; please build and upload it.

comment:18 follow-up: ↓ 19 Changed 13 years ago by jdreed

Remember that firefox-wrapper is architecture-dependent because it includes the C binary testlock.

If the only point of C is to have fcntl(2), can't we do this in Perl with Fcntl.pm?

You did not build this package for i386; please build and upload it.

If you'd deployed your dasource change from October to the locker, I'd have noticed this... Fixed.

comment:19 in reply to: ↑ 18 Changed 13 years ago by geofft

  • Status changed from development to proposed

Replying to jdreed:

Remember that firefox-wrapper is architecture-dependent because it includes the C binary testlock.

If the only point of C is to have fcntl(2), can't we do this in Perl with Fcntl.pm?

Probably. Or fcntl.fcntl in Python. The package comes from Athena 9, when we apparently preferred writing in C instead of Perl or Python.

comment:20 Changed 13 years ago by jdreed

  • Status changed from proposed to closed
  • Resolution set to fixed

Deployed 6/29

Note: See TracTickets for help on using tickets.