[users-admin] Password is reset to old value when it's been changed by running about-me

[Thales MG]

Binary package hint: gnome-system-tools

gnome-sytem-tools version: 2.28.1-0ubuntu2
Running on Ubuntu 9.10 Karmic Koala, updated.

By using the System->Preferences->About Me, I can change my password. The problem I have, is if I try to change my own password by going thru System->Administration->Users and groups.
If I try to change it there, it says my password is changed. I try to authenticate it on the same window, it says my new password is correct. But when I do something that requires my password (like updating packages) it doesn't accept my new pass, only the old one.
Even if I reboot, the pass to login is still the old one.
And I tried to change it again today, using users-admin, and it just keeps loading, and loading... For more than 5 minutes.
Posting as requested by Milan Bouchet-Valat.

[Carl Davis (carl.davis)]

I can confirm this behavior. Below are more specific steps to reproduce it.

1. Open Users and Groups
2. Select your user and choose properties
3. Click change password

After following through with the steps to change your password here the /etc/shadow file shows the change

4. Click "OK" to close out of the "Account 'username' Properties" dialog box.

After you authenticate with the dialog box that opens, your password will revert to the original. The /etc/shadow file is rewritten with the original hash.

NOTE: If you click "Cancel" instead of "OK" to leave the "Account 'username' Properties" dialog box the /etc/shadow file does not revert to the original.

[Thales MG (thalesmg)]

A small update: I triead again to change my pass yesterday, and I can't even using About Me. It just hangs when I type the new one 2 times.
I believe it's because my new password is just the old one plus a new string of characters, so when I try to change it via passwd, it rejects it reporting "Bad: new password must be different than the old one".

[Milan Bouchet-Valat (nalimilan)]

Now I can see what's the problem. You shouln't have to authenticate when closing the first dialog. If it does so, that's because it wants to commit your user configuration - and since there are two separate programs here, the first one (users-admin) overwrites the changes that were made since it was started. Though I'd have thought it is more clever than that, and should ask you to reload the configuration from system files.

The easiest fix I can think of would be to close the first dialog after changing the password. You may lose changes you could have made there, but that's not very likely that you first edited other settings.

Thanks for catching the /etc/shadow funny behavior, that really saves us much debugging.

[Milan Bouchet-Valat (nalimilan)]

About the hang problem: do you get the hang even when the new password is completely different from the old one? I thought we were always using strong encryption methods that did not have the problem you describe (which occurred when using 3DES).

[Thales MG (thalesmg)]

No, it changed instantly... Guess that it was passwd's limitation that was hanging it!

[gregor (gregor-v1)]

the gnome keyring (for evolution) changed to my new pasword, but for the rest my old password kept valid.

[Pjotr12345 (computertip)]

This bug also happens when I try to change the password in a terminal: sudo passwd seems to work, it asks for a new UNIX password, after that asks for a confirmation. Everything as usual. But.... upon reboot the system only recognizes the old password!

This is very weird; I've never seen a terminal command fail where a graphical app does the job fine (System - Preferences - About me).

[Milan Bouchet-Valat (nalimilan)]

Pjotr12345: please report your problem separately against the package 'passwd', this has nothing to do with the present bug. BTW, when changing your own password, you should use 'passwd' instead of 'sudo passwd'. The latter won't update your eCryptfs Private dir and your main keyring password. Please test whether 'passwd' alone works, and tell this in your report (About Me is using passwd in the background, so it *must* work.)

[Pjotr12345 (computertip)]

@Milan: it seems that you're right. "passwd" works, where "sudo passwd" fails.

Changing the password through System - Administration - Users and groups still fails, though. So I can only confirm the bug you reported, without adding new information. :-)

[Hew (hew)]

This changed my ecryptfs password but not my user password, rendering my system broken beyond login. After some testing to work out what was going on, I used 'passwd' to change to the new password so everything matched.

[Gavin (gavin-sharp1)]

This bug required me to login under my old password, but the Keyrings required my new password.

Only going to System>Prefs>About Me could I change the login Password so all matched again.

[abePdIta (abepdita)]

I confirm hangs.
It happens when you fill out the "old password" with incorrect data or when the new password differs little from the previous one.
Well they are not real hangs. Simply the cursor keeps being busy and every element except the "Close" button are deactivated. It seems hung, but it's not. You can still close the window using "X" or "Close" buttons. Obviously changes are not applied. The problem is that gnome-system-tools (or whatever) does not handle passwd errors correctly.
This is my diagnosis.

[Milan Bouchet-Valat (nalimilan)]

Please, this bug is not about gnome-about-me hanging. I think I've found the hanging problem and I've posted a patch upstream, so it should be fixed at some point in Lucid. Else, open a new report.

As regards the true subject of this report, new upstream version of users-admin fixes the problem by handling the password change itself, instead of starting gnome-about-me. So that will be fixed for Lucid.

[abePdIta (abepdita)]

Ok, sorry, my mistake.

[Gilbert Glick (gilbert-glick)]

Possibly a separate bug, but erring on the side of less churn in bug reporting/duplication.

Using relatively freshly installed Ubuntu 9.10 system

An unprivileged user attempts to change their password as follows:
  Navigate to System -> Administration -> "Users and Groups" tool
  Unlocks configuration--is prompted to authenticate using _privileged_ account (surprising, but will authenticate)
  Navigates to their own account -> properties
  Selects "Change Password..." and authenticates account's current password, sets new password
  Feedback is that password was changed

The password has not been changed.

[Milan Bouchet-Valat (nalimilan)]

Yeah, that's the same bug. If you click Validate on the dialog with the Change Password button, you reset your password to its old value, and you break your keyring and eCryptfs encrypted dir. But (again) that will be fixed in Lucid with next upload of users-admin.

[Milan Bouchet-Valat (nalimilan)]

Fixed with 2.29.3 now in Lucid.

[Gabriel M. (gabrielm)]

Are you going to fix this for Karmic?

This bug is not so bad for users that have the time and skills to find and apply the workaround, but for the vast majority of users it's a horrible security risk. I have a friend who accidentally typed his password in a high-traffic chat room because the keyrind dialog didn't steal focus, and he was completely unable to change his password by himself. Frequently changing one's password is recommended by about everybody who cares about security, so this can't be taken lightly.

Nominated for Karmic to bring it to attention; I think this should receive the "security risk" label and be fixed asap.

[Milan Bouchet-Valat (nalimilan)]

It's a little late to fix this for Karmic, it should have been done months ago. For now, best answer is "upgrade to Lucid", since it's a LTS.

The fix wouldn't be very complex. We should close the user settings dialog when user clicks on the "Change password" button. I can post a patch, if a core dev is OK to upload a new package to Karmic.

[Gabriel M. (gabrielm)]

Since Canonical offers support for Karmic until April 2011, I don't think they have the choice but to fix things of this importance. Upgrading to Lucid right away is not a very good idea for most users either, since it's gonna bring with it a truckload of new bugs, as happens with each release, including the last LTS. It's like picking between Scylla and Charybdis: http://en.wikipedia.org/wiki/Scylla_and_Charybdis

Now instead of pushing each version of Ubuntu as Linux for Humans and all the other hype, I think non-LTS versions should receive a permanent Beta label, and support for them should be deprecated as soon as the next version arrives. This is basically what happens already, so why not make it official? On the other hand the LTS version should receive extra work to be stable *on release*, and release should be delayed for up to three months is it still has critical bugs on popular hardware, and stuff like that.

In the meanwhile, if you offer support, try to give at least equivalent support as Microsoft... they're still supporting Windows XP (how old is that?) for security, and they certainly wouldn't let unpatched a flaw that prevents you from changing your password: imagine the uproar!

[Mélodie (meets)]

Hi,

Same at UNR Karmic. I just added it.

[Didier Roche-Tolomelli (didrocks)]

UNE is using the same component than GNOME for that. No special action has to be taken down in UNE side, only fix in gnome-about-me is needed.