encrypted home directory isn't mounted if password changed by another user

Had the same problem. I think this bug is really critical.

What is the official/recommended way to change the password in a way that decryption of the home directory still works?

I think this is because:
- the home directory is in some way encrypted with your password and when you log in, it gets decrypted
- when you change your password as root, the decryption-passphrase doesnt get changed to fit the new password because you do it as root
- your new password then doesnt work with the old passphrase

i do not know if it is a problem, when you change your password in the "normal" way

greetz

I can corroborate Sisu's diagnosis. If you use passwd from the native user account, this does not cause the problem and would be a descent work around for the bug.

This bug is very critical. It also happens when you change a password using the user management module in KDE's system settings. When you use system settings it asks for the admin password then it runs the password change as root. The next time you login you're hosed. You have to drop down to console and change your password back because the home directory stays encrypted by your old password.

Bad, bad, bad. All methods of changing a password should do EXACTLY the same thing or set of things. If you have more than one person on a server, you could lock someone out just by changing their password as root (which could happen if that user forgot his password and called you to have i reset).

I'm running Kubuntu 10.10 + current patches with KDE 4.5.5.

Also, this bug is from May. How is it still Undecided/Unassigned?

I can confirm that this bug is still occurring as of Natty Beta.

I changed the summary because it works fine so long as you change the password yourself using either passwd or the password module in gnome-system-tools.

I do not know about the status in KDE on Kubuntu.

I tested changing the password yourself with users-admin and my encrypted home directory was mounted - I'm using an up to date version of Natty.

I then did the following:

sudo -i
passwd ubuntu

and changed the password for the user ubuntu to a different one. When ubuntu logged in again their home directory was not mounted.

The user could work around this by manually mounting their home directory with ecryptfs-mount-private and change their ecryptfs passphrase to their new password using ecryptfs-wrap-passphrase.

We need to turn this report into a question, rather than a bug. This is a fundamental design issue that must be clearly documented, but cannot be fixed.

I'm trying to do that now, but Launchpad keeps timing out.

The root of the problem is that in order to re-wrap the user's ecryptfs mount passphrase, the system needs *both* the old password *and* the new password.

When root forces the change of another user's password, root is not required to enter the user's old password, and therefore the mount passphrase cannot be decrypted, before re-encrypting.

About the best we could do is print an informative message to that effect.

Or we could allow the root user to "escrow", or save a copy of each user's mount passprhase. This is how Apple solves it. But this does mean that the root user will have each non-root user's private key.

Marking "won't-fix", or rather "can't-fix". It would be nice if someone could turn this into a question, and add the answer when Launchpad becomes more cooperative.

While it may not be fixable I think would be helpful if an attempt to change a users password by root were to produce a warning message. This warning message is more discoverable than a question or bug report in Launchpad. Some irc discussion from #ubuntu-devel regarding this:

16:14 < bdmurray> kirkland: could passwd somehow warn about bug 579876?
16:14 < ubottu> Launchpad bug 579876 in ecryptfs-utils (Ubuntu) "encrypted home directory isn't mounted if password changed by another user" [High,Won't fix] https://launchpad.net/bugs/579876
16:15 < kirkland> bdmurray: would take some pam hackery, should probably talk to slangasek
16:15 < kirkland> bdmurray: i could probably make pam_ecryptfs say something
16:15 < bdmurray> that seems nicer than hoping people find an answer in Launchpad
16:15 < slangasek> does pam_ecryptfs stack before or after pam_{unix,krb5,fwibble} for password changes?
16:16 * kirkland checks
16:16 < kirkland> slangasek: that's common-password?
16:16 -!- jbicha [~jeremy@unaffiliated/jbicha] has quit [Quit: leaving]
16:16 < slangasek> yes
16:16 < kirkland> slangasek: ecryptfs is last
16:17 -!- jbicha [~jeremy@unaffiliated/jbicha] has joined #ubuntu-devel
16:17 < slangasek> hmm, ok
16:17 < kirkland> slangasek: if old password is empty, i was thinking i could throw a warning message
16:17 < slangasek> and how's it marked? optional, requisite, etc?
16:17 < kirkland> password optional pam_ecryptfs.so
16:17 < slangasek> yeah, I'm thinking you could downright abort the stack instead, if you wanted :)
16:18 < kirkland> slangasek: i deliberately did not, in the beginning
16:18 < kirkland> slangasek: more and more people are complaining about this
16:19 -!- raphink [~raphink@ubuntu/member/raphink] has quit [Ping timeout: 246 seconds]
16:21 < slangasek> well, I guess giving no option for root to change the password would get a different set of people complaining
16:22 -!- mterry [~<email address hidden>] has quit [Ping timeout: 246 seconds]
16:22 < slangasek> a prompt that has to be explicitly acked might be the best
16:22 < slangasek> so pam_ecryptfs will never prompt for a password of its own in the event that the login credentials don't match the ecryptfs creds?
16:26 -!- jbicha [~jeremy@unaffiliated/jbicha] has quit [Read error: Connection reset by peer]
16:27 -!- jbicha [~jeremy@unaffiliated/jbicha] has joined #ubuntu-devel
16:28 < kirkland> slangasek: correct
16:28 < slangasek> should it?

Not easy, but I agree, it would be nice to produce some useful warning message.

If a message is going to be added, please make sure a similar message shows up in Kubuntu's GUI user management module for System Settings. I reported this as a separate bug, but if the solution is a message it should appear in the GUI not just CLI:

https://bugs.launchpad.net/ubuntu/+source/userconfig/+bug/759319

I have been exploring the geli encryption functions in FreeBSD, and I found that they already have a fully functioning encryption system for whole volume encryption that does not have the problem listed here in this bug. I will quote the pertinent section of their man page here.

From geli(8) in FreeBSD 8.2:
You are the security-person in your company. Create an encrypted
     provider for use by the user, but remember that users forget their
     passphrases, so back Master Key up with your own random key:

    # dd if=/dev/random of=/mnt/pendrive/keys/`hostname` bs=64 count=1
    # geli init -P -K /mnt/pendrive/keys/`hostname` /dev/ad0s1e
    # geli backup /dev/ad0s1e /mnt/pendrive/backups/`hostname`
    (use key number 0, so the encrypted Master Key by you will be overwritten)
    # geli setkey -n 0 -k /mnt/pendrive/keys/`hostname` /dev/ad0s1e
    (allow the user to enter his passphrase)
    Enter new passphrase:
    Reenter new passphrase:

As you can see they have implemented a system where the root user has a master passphrase that can be entered and used to change the user's encrypted data or passphrase.

The geli manpage can be read in full here:
http://www.freebsd.org/cgi/man.cgi?query=geli&apropos=0&sektion=0&manpath=FreeBSD+8.2-RELEASE&format=html

And the source code for geli can be found here:
http://svnweb.freebsd.org/base/head/sys/geom/eli/

I have contacted the author of the code, Pawel Jakub Dawidek, about geli in the past, and he is quite friendly. I'm sure that if you did not want to reuse the code due to its BSD rather than GPL license, he may be able to at least give you a pointer as to how to go about implementing this feature.

On 12.04 LTS x64, I changed my user password via the User Accnts tool. After that I was unable to login again with my new password since my home directory is encrypted and the above-described bug does not allow decryption of the home directory with the new login password. The passphrase to decrypt the home directory is saved in a folder on my encrypted home directory. Is there any way to recover this passphrase and unlock my home directory? Do not have separate record of the decryption passphrase. I still have a functioning Guest Account to which I have access, but I am not clear whether I can somehow gain access to the files in my encrypted user home directory while logged in as Guest and without having the decrypt passphrase. Please advise asap. Thank you.

No help on this critical issue, really??

Mike, requests for help will get more timely and more useful feedback on http://askubuntu.com/

Launchpad's bugs are for bugs.

I hope the following manpage is useful for your situation: http://manpages.ubuntu.com/manpages/precise/man1/ecryptfs-rewrap-passphrase.1.html

This happened to me in 14.04 when a key broke on my portable. I first messed up by using passwd in terminal since it is the more common command (historically) and then I noticed the home directory still used the old password as described in this old bug. After a recovery (replace shadow and passwd files with older versions) I figured I had to use the built in unity gui for changing the password. However, as Mike noted it only changes the login password (separate but related bug). Useless!

The bug description should be changed to:

Encrypted home directory isn't mounted if login password is changed in Unity GUI or by passwd as root user

This is definitely a bug.

And nothing's been done about it after four years. Not even - as discussed here - some simple messages to inform users that they are about to break their system and lose their data. This really is atrocious.

Users are most likely to encounter this problem because:

i) Ubuntu offers disk encryption / home encryption as standard option during install

ii) Users would instinctively log in as root to change a user password - "It's a security matter, isn't it? Then surely you must log in as root?"

iii) There is nothing to tell the user that their system is about to break when they attempt to change their user password as root.

I'm still trying to resolve this problem after a day and a night. I'm losing hair, losing money, losing my will to live. Because this sort of thing happens all the time.

I've managed to unlock the lost directory using Dustin's recovery tool. But that just puts the data in a temp directory. That raises more questions. How are you supposed to turn that temp directory into a working home folder again? How do I get back to work? The recovery tool is incomplete. If only there were a tool that would simply reunite my user data with my user account. Or a tool that will change my password properly.

Can anybody imagine what it is like for a user in this situation?

Here's a sample of the web pages I've queried so far in my quest to get my data back and get my home folder working as it was before I attempted to change my password:

https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/1372144
http://askubuntu.com/questions/527085/how-recover-encrypted-home-when-lost-because-user-password-was-changed-with-root
http://askubuntu.com/questions/434446/help-recovering-ecryptfs-user-data
http://askubuntu.com/questions/144360/reset-login-keyring
http://askubuntu.com/questions/128040/how-to-recover-my-data
http://askubuntu.com/questions/256387/recover-encrypted-data-after-reinstall
http://askubuntu.com/questions/60601/unwrapping-passphrase-and-inserting-into-the-user-session-keyring-failed
http://askubuntu.com/questions/36573/trying-to-mount-old-encrypted-home/36783#36783
http://manpages.ubuntu.com/manpages/trusty/en/man1/ecryptfs-recover-private.1.html
http://blog.dustinkirkland.com/2011/04/introducing-ecryptfs-recover-private.html
http://manpages.ubuntu.com/manpages/precise/en/man7/ecryptfs.7.html
http://askubuntu.com/questions/13177/how-do-i-recover-data-from-an-encrypted-home-directory/13178#13178
https://www.google.co.uk/search?client=ubuntu&channel=fs&q=what+cipher+ubuntu+full+disk+encryption+home%3F&ie=utf-8&oe=utf-8&gl=uk&gws_rd=cr&ei=4uUfVIWvH6Td7QbQnIA4#channel=fs&gl=uk&q=ubuntu+full+disk+encryption+key+bytes
http://manpages.ubuntu.com/manpages/trusty/man8/cryptsetup-reencrypt.8.html
http://thesimplecomputer.info/full-disk-encryption-with-ubuntu
http://askubuntu.com/questions/228444/what-is-used-in-the-12-10-full-disk-encryption
http://askubuntu.com/questions/94298/which-algorithm-does-encrypt-home-directory-use
https://www.google.co.uk/search?client=ubuntu&channel=fs&q=ubuntu+encryption+plaintext+passthrough%3F&ie=utf-8&oe=utf-8&gl=uk&gws_rd=cr&ei=E_IfVNv4BOqS7Aaz9oHoCg
http://askubuntu.com/q...

Credible help pages say you should avoid changing a password as root (e.g. http://bodhizazen.net/Tutorials/Ecryptfs#Password).

That is all very well if you know it. But you are not likely to know it if your system doesn't tell you.

And users are encouraged to change passwords on the command line instead of the GUI if they use encryption.

This error is really, inevitable.

i) Users would increasingly feel it advisable to use the Ubuntu installer's option of encryption when installing.

ii) They would also increasingly feel it sensible at some point to change their encryption password.

iii) There is no obvious place in the GUI to change the encryption password (not in Xubuntu at least). Ubuntu forums, when you search for how to change the encryption password, give command line instructions.

iv) Changing encryption password requires root privileges

v) Users would likely change their user password while changing their encryption password

vi) They would likely attempt to make this change as root, since recent instructions have demonstrated it is required and it is anyway intuitive that you would need root privileges to do something as sensitive as change a user password.

Ergo, the problem is inevitable. And it is negligent of linux password system not to warn users when they are about to change their user password as root.

Any news about it? I have the same problem and my data are safely stored away from me...

The correct title and text for this bug should be:

"When a home-encrypted user's password is forcely changed by an admin, there is no warning message that this will break encrypted folder automount"

The ideal solution would be to ask for the user's current password in order to update the wrapped passphrase, but the warning would be much better than the current situation.

Other than that, not much more can be done.
Protecting your data includes protecting your data against the admin users too!
Especially because it includes someone who stole you computer and root'ed into it with a LiveUSB...
That's the whole point of encryption...