After changing a user password in the system settings (home partition encrypted) and rebooting it isn't possible for the user that changed his/her password to login (?with lightDM?) again. A login in the console couldn't be tested as switching to consoles [Strg]+[Alt]+[F?] doesn't work either. Reproducible: Always Steps to Reproduce: 1. Install KDE neon with encrypted home partition and set a password for the user 2. After installation: Reboot the mashine and login. 3. Change password in the system settings. 4. Reboot the system. 5. Try to login. -> Doesn't work. Actual Results: The mouse cursor changes to an X, he password field becomes grey and nothing else happens Expected Results: Login successful and desktop is shown.
For reasons I cannot apprehend .encryptfs/wrapped-passphrase is not being updated correctly, thus preventing decryption, so plasma login gets stuck.
(In reply to Harald Sitter from comment #1) > For reasons I cannot apprehend .encryptfs/wrapped-passphrase is not being > updated correctly, thus preventing decryption, so plasma login gets stuck. How to fix it manually? (My main system isn't working any more.)
in grub boot into recovery, recover via root shell, change your user password back to the one it was before. alternatively install ecryptfs-utils which should have a tool to update your encryption passphrase (I think /usr/bin/ecryptfs-rewrap-passphrase)
IT WORKED!!! THANK YOU!!! I set back the password in the root shell. Rebooted the system. Logged in (regularly). Worked. Set the new ecryptfs password: ecryptfs-rewrap-passphrase ~/.ecryptfs/wrapped-passphrase (ecryptfs-utils are already installed.) Set the new (login) password.
I can confirm the same issue on KDE 5.12.3. Normally pam_ecryptfs will rewrap the mount passphrase on a login password change, so long as it is done by a tool that uses PAM. By design it cannot do so if the old password is not known as it needs to unwrap (decrypt) the mount passphrase first. Although User Manager does ask for the current password, this seems to be the generic prompt to elevate privileges. I suspect User Manager executes the password change as root passing only the new password, leaving PAM_OLDAUTHTOK empty and breaking pam_ecryptfs.
*** Bug 374031 has been marked as a duplicate of this bug. ***
*** Bug 370407 has been marked as a duplicate of this bug. ***
>I suspect User Manager executes the password change as root passing only the new password, leaving PAM_OLDAUTHTOK empty and breaking pam_ecryptfs. It's even more simple than that. In accountsservice Password is changed via fgetpwent rather than pam. We probably should change our code to do it all locally at least if you're changing your own user.
I just wrote a load of PAM code, only to learn something from the whole exercise. pam_chauthtoken only works as root. I can still write a helper, but at that point we're not doing much different from just invoking chpasswd and forwarding std/stdout. The latter is what gnome does.
url|location bar|field -focus
In speaking with Harald today, it seems like the feature of encrypted home directories on Ubuntu that was at issue here has been deprecated by Ubuntu due to it not actually being secure. I see in Ubuntu 22.04 that the option to encrypt your home directory has even been removed from the GUI. In Neon's Calamares installer, the option is still there but it uses a different underlying backend and actually encrypts the whole disk, not just the home directory. So the bug is not possible anymore.