FYI: FileVault and Security Update 2004-09-07 Bug
This is both a posting of a FileVault bug and the work-around for it.
After installing the latest security update, upon reboot and login to the main account for the machine [10.3.5] I discovered that my account was *gone*--as in, it might as well have been a clean install.
Ouch.
To make the story short, I think I figured out what went wrong. FileVault had been on [and still was]--which was scary, as I was afraid that since it was on, that it had replaced the actual image. Luckily, this was not the case:
Located at /Users/$USER/$USER.sparseimage was the actual FileVault image [where $USER is the account-name]. On a whim I double-clicked it and found that I could mount it as a regular image, though password protected.
The trick is: the password for the image was the ORIGINAL password used when it was created and not the account password. When you turn on FileVault, these are [and must be] one and the same--changing the account password seems to allow these to fall out-of-synch.
So, this was the first update since I changed the passwords for this account [and root]--and it appears that it was simply unable to authenticate to the FileVault image.
THE FIX [not all of these steps may be necesary, this is merely how I got around it]:
Mount the image using your original password.
Copy the contents to a root-accessible location.
Turn off FileVault for the user.
Rename the FileVault image [just being cautious].
Log out.
Log in as root.
Copy the contents of the image over that user's directory.
Log out.
Log in as user--everything should be back.
Turn FileVault on.
[one should then root-ify and secure wipe the archived files et alia].
[EDIT]: when copying, be sure to copy the hidden directories as well (turn them on in the UI or use command line "cp -prv " or such) -- otherwise, you may lose your .ssh, .gpg, .shell configurations :[EDIT]
Since then, I've also noticed that KeyChain is also using the original password, and not the current one for the account.
Conclusions: Somebody at Apple was *smart* to have it FileVault not replace a user's image when one isn't available [like in this situation] and FileVault is still on [running from a 2nd image, I suppose].
KeyChain and [if separate] FileVault do *NOT* get updated automatically when a user changes their password. If this is the case, this is *BAD*, as it leaves a back-door when passwords are updated [in the case that a password is compromised, such as when an employee leaves a company].
After installing the latest security update, upon reboot and login to the main account for the machine [10.3.5] I discovered that my account was *gone*--as in, it might as well have been a clean install.
Ouch.
To make the story short, I think I figured out what went wrong. FileVault had been on [and still was]--which was scary, as I was afraid that since it was on, that it had replaced the actual image. Luckily, this was not the case:
Located at /Users/$USER/$USER.sparseimage was the actual FileVault image [where $USER is the account-name]. On a whim I double-clicked it and found that I could mount it as a regular image, though password protected.
The trick is: the password for the image was the ORIGINAL password used when it was created and not the account password. When you turn on FileVault, these are [and must be] one and the same--changing the account password seems to allow these to fall out-of-synch.
So, this was the first update since I changed the passwords for this account [and root]--and it appears that it was simply unable to authenticate to the FileVault image.
THE FIX [not all of these steps may be necesary, this is merely how I got around it]:
Mount the image using your original password.
Copy the contents to a root-accessible location.
Turn off FileVault for the user.
Rename the FileVault image [just being cautious].
Log out.
Log in as root.
Copy the contents of the image over that user's directory.
Log out.
Log in as user--everything should be back.
Turn FileVault on.
[one should then root-ify and secure wipe the archived files et alia].
[EDIT]: when copying, be sure to copy the hidden directories as well (turn them on in the UI or use command line "cp -prv " or such) -- otherwise, you may lose your .ssh, .gpg, .shell configurations :[EDIT]
Since then, I've also noticed that KeyChain is also using the original password, and not the current one for the account.
Conclusions: Somebody at Apple was *smart* to have it FileVault not replace a user's image when one isn't available [like in this situation] and FileVault is still on [running from a 2nd image, I suppose].
KeyChain and [if separate] FileVault do *NOT* get updated automatically when a user changes their password. If this is the case, this is *BAD*, as it leaves a back-door when passwords are updated [in the case that a password is compromised, such as when an employee leaves a company].