205821 - Mozilla using wrong files after profile switch, causing information leaks

Status: RESOLVED WORKSFORME

(Core Graveyard :: Profile: BackEnd, defect)

Description

[:aceman]

User-Agent:       Mozilla/5.0 (X11; U; Linux i586; sk-SK; rv:1.3) Gecko/20030312
Build Identifier: Mozilla/5.0 (Windows95?; sk-SK; rv:1.3) Gecko/20030312

After working in one profile, then switching to another one, Mozilla still has
some files from the first profile open. They are not written to, but are used
and referenced. These files include Inbox.msf, XUL.mfl, etc. (see related bugs
for more).

Reproducible: Always

Steps to Reproduce:
1.Make several profiles
2.Install new language pack (I used SK)
3.Restart and select the pack in one of the profiles
4.Restart
5.The profile is transtaled ok
6.Switch to another profile, which has another language chosen (EN)
Actual Results:  
The texts are mixed - some are in language1, some in language2. I can provide a
screenshot if nobody will be able reproduce it.
I think because Mozilla is now using XUL.mfl from both profiles and similar
cache files. I will describe it more later.

Expected Results:  
Close ALL files from the old profile and open the correct files in the new profile.

If Mail was opened in the first profile, and Inbox was viewed, exactly this
Inbox.msf is still opened after the switch (haven't seen any usage of it, but it
is dangerous).

If this wasn't enough, here is a method for showing how the XUL.mfl is wrongly
updated:
1. delete XUL.mfl file in 2 profiles.
(1.5. I haven't tried this with clean profiles, therefore it is better when both
profiles were already used with Navigator (only) - XUL.mfl contains only
Navigator stuff)
2. start in one of these profiles and start Mail
3. switch to the second profile
4. start Mail
5. watch both XUL.mfl files - the 1st is bigged (containing the Mail stuff), the
2nd has only Navigator stuff (because I suppose Mozilla sees the mail stuff in
the 1st profile and therefore doesn't need to update the file)
6. start e.g. Composer in the 2nd profile
7. 2nd XUL.mfl grows, because this wasn't in any of the 2 XUL.mfl files
8. close Mozilla
9. start it with the 2nd profiles
10. start Mail
11. the 2nd XUL.mfl grows because of new Mail stuff - but this already should
have been there at step 4.!!!

So this is my experience. I suggest running Mozilla and watching it with some
program which shows which files it has open. I used TaskInfo. Interestingly, the
XUL.mfl is usually closed...


Actually, the XUL.mfl isn't very important (I don't know, what's its purpose, as
it can be freele deleted. And the language packs delete it.), except for the
language problem above.
But I think this is a serious bug and calls for serious problems with other
files. Possible consequences of this are bug 203657, bug 194653, bug 192761,
maybe many more.
All this was tested on Windows 95 B (yes it works even when it isn't listed as a
acceptable platform in the OS selection box:)).

Comment 1

[Alexander Opitz]

Does the problem occures in newer builds?

Comment 2

[:aceman]

In a week I will check this in the new Mozilla 1.5.

But the referenced bugs aren't fixed either, therefore it is possible it is 
still there.

If it proves to be still there, we should make this a meta bug for the partial 
problems described in those bugs, make dependencies and mark this a dataloss - 
it destroys training.dat files, at least.

Comment 3

[:aceman]

I'm sorry to say that, but this bug is still there in Mozilla 1.5.

Test 1: 
1. I started it with 1 profile, no mail accounts (mailnews never started).
2. Used it a bit, then I tried to switch profiles.
3. Created a new profile, so now there were 2.
4. I switched to the new profile (no restart).
5. Now Mozilla was using *.db (cert8, key3) files from the old profile. In the
new one, there were no .db files created.

Test 2:
1. I opened also mailnews.
2. Created the first account.
3. Used it a bit (moving around in folders, etc.)
4. Switched back to the previous profile (default).
5. Now Mozilla had still the files Inbox.msf and abook.mab open, even though
Mailnews was closed in the switch and just a single browser window was reopened.
6. I wondered why is addressbook file still open, so I went into it.
7. Opened addressbook window - it was clean, no cards - OK.
8. I clicked the personal addressbook.
9. I don't know why, but it wanted to create a new mail account (this profile
has none so far) and asked for the master password into the password manager. I
didn't want that, so I cancelled both prompts.
10. I created a new card in the personal addressbook - went OK.
11. I closed addressbook window and then Mozilla.
12. Guess what? The new card was written into the abook.mab file of the previous
profile (non default)!

I am still not sure about the Xul.mfl and training.dat cases, I will investigate
them further in the weekend.

Comment 4

[:aceman]

I tested it on my production machine. I can confirm the XUL.mfl case is still 
open. That file is still kept open after profile switch. I haven't yet found 
out whether it is written to or data from it is used.

I haven't been able to reproduce the training.dat file corruption. I hope that 
dataloss is finally fixed.

Anyway, I will investigate it further to be sure and to find out which other 
files are wrongly opened.

Changing OS and Hardware according to dependent bugs.

Comment 5

[:aceman]

Somebody should already confirm this and set to NEW, because the dependents are 
confirmed.

Comment 6

[:aceman]

I can now confirm the case with XUL.mfl - mixed languages stil appear as
described in the steps to reproduce.

Comment 7

[Wayne Mery (:wsmwk)]

Rich, Chris, Aceman, have you seen this in recent years?  Or any of its blockers? 

Note: the requirement to change language in the STR seems dubious to me, given that none of the blocking bugs mention it.

Comment 8

[Chris Ilias [:cilias]]

I assume that this (if it still exists) would only occur in SeaMonkey, not Firefox or Thunderbird, because neither Firefox nor Thunderbird have a Profile Switcher. If so, does that mean this is a XPFE bug? Do the current SeaMonkey trunk builds (which don't use XPFE) have a profile switcher?

Comment 9

[Wayne Mery (:wsmwk)]

It is on the tools menu for trunk builds.

Comment 10

[Wayne Mery (:wsmwk)]

Tony, can you reproduce?

Comment 11

[Tony Mechelynck [:tonymec]]

"Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081010 SeaMonkey/2.0a2pre" - Build ID: 20081010000529

(In reply to comment #10)
> Tony, can you reproduce?

No. Here's what I did, trying to follow steps more or less parallel to those of comment #3 part 2 with no risk of damaging my daily-use profile. Also, bear in mind that I don't have any OS tools that I know of to tell which files are "being used" by which process.

1. seamonkey -no-remote -P clean
-- This is actually an "almost clean" profile, it includes some non-default prefs and extensions.
-- Mail and Browser come up
2. Open Address Book and create a card about myself.
3. Tools => Switch Profile
4. Create a new profile named "testing" and switch to it.
-- Browser comes up, with only the "Welcome" page.
5. Window => Mail & Newsgroups
-- "Create New Account" popup comes up.
6. Create an account for news.mozilla.org. Don't subscribe to any newsgroups.
7. Window => Address Book
8. File => New => Address Book Card
9. Make a new card about my daddy.
10. Ctrl+Q (i.e., "Quit SeaMonkey")
11. seamonkey -no-remote -P clean
-- Mail and Browser come up
12. Window => Address Book
13. Click "Personal Address Book".
-- Only the card created at step 2 is visible (not the one created at step 9).

If you want me to run a different test, I'm listening.

Comment 12

[Wayne Mery (:wsmwk)]

perhaps the different language in each profile made a difference, which you didn't test unless I missed something.

Comment 13

[:aceman]

I can also not reproduce anymore, on a quick test with seamonkey 1.1.9. I do not have the setup I mentioned in the original bug report. I have mu users (thus profiles) completely separated now and don't use profile switching. On the quick test I just created a new profile and switched between my old one and this new one, created some address book cards. And watched which files seamonkey has open (using the Taskinfo application - http://www.iarsn.com/). I could not see any problems. But both of the profiles had the same language now - EN.

Comment 14

[Tony Mechelynck [:tonymec]]

WFM according to comment #13. REOPEN (or open a new bug) if the bug is seen again on a _current_ build. (At the moment, this would mean Sm 1.1.13 or 2.0a2, Tb 2.0.0.18 or 3.0b1, or later nightlies of the same.)