329138 - Severe problems with multiple users and FileVault

Status: VERIFIED DUPLICATE of bug 326668

(Camino Graveyard :: OS Integration, defect)

Description

[David Becker]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Version 2006021400 (1.0)

When using Camino on a multi-user machine, and both users have FileVault turned on, Camino will ask for the password for the other user at startup and periodically thereafter.  You can continue if you click Cancel, but it is quite obnoxious.

Reproducible: Always

Steps to Reproduce:
1. Create a new user A.
2. Enable FileVault for user A.
3. Create a new user B.
4. Enable FileVault for user B.
5. Reboot, just to make sure everything took.
6. Login as user A and run Camino.
7. You should be greeted by an Authenticate dialog asking you to "Enter password to access the files on B.sparseimage".
8.  Likewise, if you login as user B and run Camino, it asks for the password to "A.sparseimage".

Actual Results:  
I don't even understand how this is occurring since all user preferences should be stored in ~/Library/Application Support/Camino, and it should not (theoretically) even know that another user exists.  Clearly whatever it is doing is not required, as clicking Cancel allows you to continue with no other ill effects.

Expected Results:  
Starting Camino should not prompt for passwords to access any other user's FileVault.

Comment 1

[David Becker]

Personally, this makes Camino unusable for me.  Note, that until I added the second user, this was not a problem.

Comment 2

[Chris Lawson (gone)]

I'm assuming that Camino is the only browser that has this problem, and if either user does NOT use FileVault, this problem goes away entirely. Am I right?

cl

Comment 3

[David Becker]

(In reply to comment #2)
> I'm assuming that Camino is the only browser that has this problem, and if
> either user does NOT use FileVault, this problem goes away entirely. Am I
> right?

I have not tested the case where one user has it and the other doesn't.  But yes, it's Camino only.  I've gone back to Firefox because of this...

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

This sounds really familiar...we've either seen this before in a bug (without FileVault in the summary) or in the forum.

Comment 5

[[e-mail]]

Looks simular to the problem mentioned in this forum thread: http://forums.mozillazine.org/viewtopic.php?t=330809
Which points to bug 275241

Comment 6

[David Becker]

(In reply to comment #5)
> Looks simular to the problem mentioned in this forum thread:
> http://forums.mozillazine.org/viewtopic.php?t=330809
> Which points to bug 275241

Agreed.  However like in that thread, my attempts to locate an existing bug on this didn't turn anything up.  Also, that bug is closed.  While there is a workaround, that hardly seems like a suitable solution for the casual user (though I'll try it for myself)...

Comment 7

[David Becker]

(In reply to comment #6)
> (though I'll try it for myself)...
FYI, that does appear to have resolved it for me.

Comment 8

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

mento, will the fixes for bug 326668 fix this for good?  In the forum thread, you fingered that file....

Comment 9

[Mark Mentovai]

This is absolutely, positively, that idiot xpti.dat file.

David, try this: download a fresh copy of Camino and copy it out of the disk image to its home (like /Applications).  Don't open it yet!  Open a new Terminal window, and type:

"chmod -R a-w "

(with a space after the letter w, and not including the quotation marks, and not pressing return.)

Then, drag the Camino icon from your applications folder onto the Terminal window, and press Return in the terminal.  This will revoke write access from everyone on Camino, and will prevent anything from changing xpti.dat or its equally idiotic cousin, compreg.dat, and setting FileVault-protected paths in them.

Or wait for Camino 1.1, where I hope to have bug 326668 fixed, preventing the app from ever trying to write to itself.

*** This bug has been marked as a duplicate of 326668 ***