passwd - passwords do not match but updated successfully

I cannot reproduce it here (on Debian).

Can you provide your /etc/pam.d/passwd ?
(and files included from there)

userX@ehud:/$ ls -l /etc/pam.d/
total 80
-rw-r--r-- 1 root root 182 2008-07-10 10:01 atd
-rw-r--r-- 1 root root 384 2008-06-09 13:02 chfn
-rw-r--r-- 1 root root 581 2008-06-09 13:02 chsh
-rw-r--r-- 1 root root 1186 2008-09-18 12:18 common-account
-rw-r--r-- 1 root root 1221 2008-09-18 12:18 common-auth
-rw-r--r-- 1 root root 1584 2008-09-18 12:18 common-password
-rw-r--r-- 1 root root 1309 2008-09-18 12:18 common-session
-rw-r--r-- 1 root root 289 2008-09-09 14:45 cron
-rw-r--r-- 1 root root 69 2008-09-13 04:37 cups
-rw-r--r-- 1 root root 400 2008-09-04 07:53 gdm
-rw-r--r-- 1 root root 316 2008-09-04 07:53 gdm-autologin
-rw-r--r-- 1 root root 56 2008-09-10 15:23 gnome-screensaver
-rw-r--r-- 1 root root 3224 2008-06-09 13:02 login
-rw-r--r-- 1 root root 520 2008-09-16 02:12 other
-rw-r--r-- 1 root root 92 2008-06-09 13:02 passwd
-rw-r--r-- 1 root root 105 2008-08-06 03:24 polkit
-rw-r--r-- 1 root root 168 2008-06-23 07:12 ppp
-rw-r--r-- 1 root root 69 2008-09-12 09:23 samba
-rw-r--r-- 1 root root 2305 2008-06-09 13:02 su
-rw-r--r-- 1 root root 119 2008-09-01 08:17 sudo
a324@ehud:/$ cat /etc/pam.d/passwd
#
# The PAM configuration file for the Shadow `passwd' service
#

@include common-password

userX@ehud:/$

Thanks.

And what about the content of /etc/pam.d/common-password ?

Did you make any change to PAM configuration?

I haven't made any changes after installing the Alpha6 besides running the Update Manager and installing Samba. Here's the contents of common-password:

userX@ehud:/$ cat /etc/pam.d/common-password
#
# /etc/pam.d/common-password - password-related modules common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of modules that define the services to be
# used to change user passwords. The default is pam_unix.

# Explanation of pam_unix options:
#
# The "sha512" option enables salted SHA512 passwords. Without this option,
# the default is Unix crypt. Prior releases used the option "md5".
#
# The "obscure" option replaces the old `OBSCURE_CHECKS_ENAB' option in
# login.defs.
#
# See the pam_unix manpage for other options.

# As of pam 1.0.1-5, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules. See
# pam-auth-update(8) for details.

# here are the per-package modules (the "Primary" block)
password [success=1 default=ignore] pam_unix.so obscure sha512
# here's the fallback if no module succeeds
# this is obviously a completely redundant line, except that it lets us
# handle better the case where there are no "Primary" modules provided
password required pam_permit.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
password required pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config
userX@ehud:/$

Reproducible on Intrepid.

This looks like a PAM configuration bug.

When pam_unix fails, the error is (willingly) ignored.

One temporary solution to fix this could be to change the line:
    password [success=1 default=ignore] pam_unix.so obscure sha512
to
    password required pam_unix.so obscure sha512

That seems to have fixed it. I changed that entry in /etc/pam.d/common-password like this:

#password [success=1 default=ignore] pam_unix.so obscure sha512
password required pam_unix.so obscure sha512

And now it throws out a better error message for both root and regular users when they fail changing their passwords:

ROOT:
root@ehud:/etc/pam.d# passwd
Enter new UNIX password:
Retype new UNIX password:
Sorry, passwords do not match
passwd: Authentication information cannot be recovered
passwd: password unchanged
root@ehud:/etc/pam.d#

USERX:
userX@ehud:/$ passwd
Changing password for userX.
(current) UNIX password:
Enter new UNIX password:
Retype new UNIX password:
Sorry, passwords do not match
passwd: Authentication information cannot be recovered
passwd: password unchanged
userX@ehud:/$

I'm stepping this bug up to critical, and milestoning it against Intrepid release. I spoke with slangasek and he's going to work on it.

This is currently affecting pam_ecryptfs.

If the user is using an encrypted private directory, and tries to change their password with passwd, the password change might fail, but their passphrase might get rewrapped. This is highly undesirable, and causes automounting of ~/Private to fail.

:-Dustin

My apologies....

Please disregard my last message. This bug is still very important, but I was completely mistaken.

pam_ecryptfs will NOT re-wrap the passphrase if the operation actually fails (regardless of the success message). Whew.

I stepped this bug back down to Confirmed/High.

:-Dustin

Aaaaaahhhhh...

Okay, so I can now characterize the problem better, and how to reproduce...

On a system using an encrypted private, `mount | grep Private` to check:
 1) invoke passwd
 2) enter the "correct" current password
 3) enter an invalid new password (such as something too simple) 6 times

The system level password will *not* be changed, even though the spurious password change is printed.

However, pam_ecryptfs will be invoked in error, which will rewrap the encrypted passphrase.

This will cause the system login passphrase and the ecryptfs wrapping passphrase to be out-of-sync. The user's ~/Private directory will not be mounted.

Further, "proper" attempts to "fix" the eCryptfs wrapped-passphrase will fail, because the wrapping passphrase and the system passphrase are not the same.

The only way for the user to rectify this problem will be to:
 1) set the system password properly using passwd successfully
 2) run `ecryptfs_rewrap_passphrase [file] [old wrapping passphrase] [new wrapping passphrase]`

:-Dustin

Not a bug in shadow at all; this is entirely a pam problem, related to the pam-auth-update changes to the default PAM stack. I'm working through this today to fix up the stack semantics.

This bug was fixed in the package pam - 1.0.1-4ubuntu5

---------------
pam (1.0.1-4ubuntu5) intrepid; urgency=low

  * debian/libpam0g.postinst: change 'cupsys' to 'cups' in the list of
    default desktop services that are ignored in deciding whether to prompt
    for service restarts on upgrade. Partially addresses LP #278117.
  * debian/libpam0g.postinst: also filter out samba, which may be installed
    on the desktop to enable filesharing.
  * debian/libpam-cracklib.prerm, debian/libpam-runtime.prerm: add the
    ubiquitous debhelper tokens (currently a no-op)
  * pam-auth-update: Use -Initial only for the first profile, even when
    there's no explicit -Initial config for that first profile
  * fix common-session/common-password to use the same overall stack
    structure as auth/account, so that we get the correct behavior when
    all password modules fail. LP: #272232.

 -- Steve Langasek <email address hidden> Wed, 15 Oct 2008 18:11:13 -0700

Having looked at the code, I think the ecryptfs-utils case is an ecryptfs-utils bug and not a pam bug. The relevant code in pam_ecryptfs is:

        if (!old_passphrase || !new_passphrase) {
                syslog(LOG_WARNING, "eCryptfs PAM passphrase change module "
                       "retrieved at least one NULL passphrase; nothing to "
                       "do\n");
                goto out;
        }

but this leaves rc as PAM_SUCCESS - since this module is designed to be an optional module, this really ought to return PAM_IGNORE instead for this case.

proposed patch for ecryptfs-utils; Dustin, please review.

Whoops - tested that patch out, it doesn't work. We need to return an actual failure here in order to let the stack DTRT, instead of returning PAM_SUCCESS or PAM_IGNORE. This revision of the patch does that.

It still doesn't work in my tests, though; still trying to sort out why that is...

Steve-

Actually, I'm not so sure about pointing the finger entirely at pam_ecryptfs.

I have an up-to-date Intrepid system here, without ecryptfs at all. I run passwd and give:
 current password: (correct password)
 new password 1: foo
 new password 2: bar

And it prints:
 Sorry, passwords do not match
 passwd: password updated successfully

And the exit code is 0.

For posterity, I'll note that the password is not actually changed. It's still a matter of the message and error code.

:-Dustin

Here's an updated patch for the ecryptfs part of this.

As discussed on IRC, fixing this to not give problems on /any/ stack requires very subtle libpam surgery indeed, not appropriate for intrepid; but this patch brings pam_ecryptfs in line with what other modules do, and fixes the problem for me.

Steve-

Your patch fixes at least one of the problems (given two non-matching passwords).

It still has the same problem if you a) enter an empty password 6 times, or b) enter a "too simple" password 6 times in a row.

Per discussion in IRC, I added an additional check to ensure that the new_password is not the empty string (which is subtlely different from the new_password == NULL check).

The attached patch includes the fix for bug #272232, as well as bug #283477.

I have a test package in my PPA. Any testing feedback from the community would be much appreciated.

:-Dustin

I have updated the patch based on a security review of the code for bug #283477 by Jamie Strandboge.

The attached patch includes fixes for bug #272232, as well as bug #283477.

I have uploaded a package for testing in my PPA. I'm satisfied with my testing of both patches. I will be committing both of these patches to the ecryptfs upstream project. I'm requesting sponsorship for Intrepid now.

Steve? Jamie?

:-Dustin

I have mentioned bug #283477 in error at least 3 times in this bug report. Too much copy and paste. Sorry.

The attached patch fixes bugs #272232 and bug #259293.
 * passwd - passwords do not match but updated successfull
 * Ecryptfs Private Directory Randomly Unmounts

:-Dustin

One more update to the patch. The last uploaded patch dropped the manpage updates.

This update simply adds those back.

Requesting sponsorship.

:-Dustin

Sponsored, waiting for release team approval. Thanks, Dustin!

This bug was fixed in the package ecryptfs-utils - 53-1ubuntu10

---------------
ecryptfs-utils (53-1ubuntu10) intrepid; urgency=low

  [Dustin Kirkland]
  * debian/patches/45-mount_private_counter.dpatch: implement a counter to
    track mounts/unmounts of the private directory; unmount if the
    counter is 0; allow a -f override to force unmount. LP: #259293.

  [Steve Langasek]
  * debian/patches/50-error-on-empty-password.dpatch: return
    PAM_AUTHTOK_RECOVER_ERR from the password changing module if we
    didn't get a password from the other modules in the stack, instead
    of returning success. LP: #272232.

 -- Dustin Kirkland <email address hidden> Sun, 19 Oct 2008 10:30:08 -0500

Updating this package didn't solve the wrong success problem:

ara@sushirider:~$ apt-cache policy ecryptfs-utils
ecryptfs-utils:
  Installed: 53-1ubuntu10
  Candidate: 53-1ubuntu10
  Version table:
 *** 53-1ubuntu10 0
        500 http://es.archive.ubuntu.com intrepid/main Packages
        100 /var/lib/dpkg/status
ara@sushirider:~$ sudo passwd
Enter new UNIX password:
Retype new UNIX password:
Sorry, passwords do not match
passwd: password updated successfully

On Mon, Oct 20, 2008 at 6:28 PM, Ara Pulido <email address hidden> wrote:
> Updating this package didn't solve the wrong success problem:
>
> ara@sushirider:~$ apt-cache policy ecryptfs-utils
> ecryptfs-utils:
> Installed: 53-1ubuntu10

You need to upgrade libecryptfs0 to at least 53-1ubuntu10.

:-Dustin

No luck... Anything else?

ara@sushirider:~$ apt-cache policy libecryptfs0
libecryptfs0:
  Installed: 53-1ubuntu10
  Candidate: 53-1ubuntu10
  Version table:
 *** 53-1ubuntu10 0
        500 http://es.archive.ubuntu.com intrepid/main Packages
        100 /var/lib/dpkg/status
ara@sushirider:~$ apt-cache policy ecryptfs-utils
ecryptfs-utils:
  Installed: 53-1ubuntu10
  Candidate: 53-1ubuntu10
  Version table:
 *** 53-1ubuntu10 0
        500 http://es.archive.ubuntu.com intrepid/main Packages
        100 /var/lib/dpkg/status
ara@sushirider:~$ sudo passwd
[sudo] password for ara:
Enter new UNIX password:
Retype new UNIX password:
Sorry, passwords do not match
passwd: password updated successfully

I cannot reproduce this problem:

kirkland@t61p:~$ passwd
Changing password for kirkland.
(current) UNIX password:
Enter new UNIX password:
Retype new UNIX password:
Sorry, passwords do not match
passwd: Authentication information cannot be recovered
passwd: password unchanged
kirkland@t61p:~$ echo $?
10

Are you absolutely sure you're on a fully updated Intrepid system?

:-Dustin

Yes it is:

ara@sushirider:~$ sudo apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
ara@sushirider:~$ sudo passwd
Enter new UNIX password:
Retype new UNIX password:
Sorry, passwords do not match
passwd: password updated successfully

But, Dustin, this is only reproducible when you type "sudo passwd". If you change current user's password:

ara@sushirider:~$ passwd
Changing password for ara.
(current) UNIX password:
Enter new UNIX password:
Retype new UNIX password:
Sorry, passwords do not match
passwd: Authentication information cannot be recovered
passwd: password unchanged

On Tue, Oct 21, 2008 at 01:03:44PM -0000, Ara Pulido wrote:
> No luck... Anything else?

Please post the contents of /etc/pam.d/common-password on this system.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

# here are the per-package modules (the "Primary" block)
password [success=1 default=ignore] pam_unix.so obscure sha512
# here's the fallback if no module succeeds
password requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
password required pam_permit.so
# and here are more per-package modules (the "Additional" block)
password optional pam_ecryptfs.so
# end of pam-auth-update config

I am not able to reproduce this using "sudo passwd" or simply "passwd"
on an up-to-date Intrepid system.

:-Dustin

I still see this on my updated Intrepid system (dist-upgraded from edgy to hardy to intrepid), i.e.:
"Sorry, passwords do not match
passwd: password updated successfully"

Longer session with initial warning for password 'too simple':
ubuntu:~$ passwd
Changing password for sysuser.
(current) UNIX password:
Enter new UNIX password:
Retype new UNIX password:
Bad: new password is too simple
Enter new UNIX password:
Retype new UNIX password:
Sorry, passwords do not match
passwd: password updated successfully

 /etc/pam.d/common-password :
$ egrep -v '#|^$' /etc/pam.d/common-password # removing '#' and empty lines
password [success=1 default=ignore] pam_unix.so obscure sha512
password requisite pam_deny.so
password required pam_permit.so

No ecryptfs-utils installed:
~$ apt-cache policy ecryptfs-utils
ecryptfs-utils:
  Installed: (none)
  Candidate: 53-1ubuntu11
  Version table:
     53-1ubuntu11 0
        500 http://us.archive.ubuntu.com intrepid/main Packages

On Wed, Oct 29, 2008 at 03:02:12AM -0000, wire_transfer wrote:
> $ egrep -v '#|^$' /etc/pam.d/common-password # removing '#' and empty lines
> password [success=1 default=ignore] pam_unix.so obscure sha512
> password requisite pam_deny.so
> password required pam_permit.so

I'm afraid this is the one case we can't fix for intrepid because it depends
on the internals of how libpam calculates return values and can't be changed
without a *lot* of testing.

The cases where users have more than one password module installed, however,
should now be fixed.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

hi,

I've got a simlar problem: I cannot change my password anymore!!

root@ced16:~# passwd
passwd: password updated successfully
root@ced16:~#

it does not even ask the current passwd. The same happens for the user, except that it asks for current passwd and when entered it just exits.
I attach the `strace passwd` command

pescio, please post the contents of your /etc/pam.d/common-password config.

here it is,
$ cat /etc/pam.d/common-password
#
# /etc/pam.d/common-password - password-related modules common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of modules that define the services to be
# used to change user passwords. The default is pam_unix.

# Explanation of pam_unix options:
#
# The "sha512" option enables salted SHA512 passwords. Without this option,
# the default is Unix crypt. Prior releases used the option "md5".
#
# The "obscure" option replaces the old `OBSCURE_CHECKS_ENAB' option in
# login.defs.
#
# See the pam_unix manpage for other options.

# As of pam 1.0.1-5, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules. See
# pam-auth-update(8) for details.

# here are the per-package modules (the "Primary" block)
password [success=2 default=ignore] pam_lwidentity.so
password [success=1 default=ignore] pam_unix.so obscure use_authtok try_first_pass sha512
# here's the fallback if no module succeeds
password requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
password required pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config

thanks,
pescio

On Thu, Nov 27, 2008 at 07:48:52PM -0000, pescio wrote:
> # here are the per-package modules (the "Primary" block)
> password [success=2 default=ignore] pam_lwidentity.so
> password [success=1 default=ignore] pam_unix.so obscure use_authtok try_first_pass sha512

Ok, that's bug #302026.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

I wanted to agree with Ara that this bug IS still a problem on a fully updated Intrepid system. Not much has been installed. This is important to us because it is causing problem with some of our sysadmin scripts that check the exit code of passwd. Here are details - I have tested this on two different machines, one 32-bit and one 64-bit.

# uname -a
Linux hostname 2.6.27-9-generic #1 SMP Thu Nov 20 22:15:32 UTC 2008 x86_64 GNU/Linux

# cat /etc/issue
Ubuntu 8.10 \n \l

# cat /etc/pam.d/common-password
#
# /etc/pam.d/common-password - password-related modules common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of modules that define the services to be
# used to change user passwords. The default is pam_unix.

# Explanation of pam_unix options:
#
# The "sha512" option enables salted SHA512 passwords. Without this option,
# the default is Unix crypt. Prior releases used the option "md5".
#
# The "obscure" option replaces the old `OBSCURE_CHECKS_ENAB' option in
# login.defs.
#
# See the pam_unix manpage for other options.

# As of pam 1.0.1-5, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules. See
# pam-auth-update(8) for details.

# here are the per-package modules (the "Primary" block)
password [success=1 default=ignore] pam_unix.so obscure sha512
# here's the fallback if no module succeeds
password requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
password required pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config

# apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

------------

Finally, entering mismatching passwords when prompted yields:

# passwd
Enter new UNIX password:
Retype new UNIX password:
Sorry, passwords do not match
passwd: password updated successfully

# echo $?
0

------------

I appreciate the effort to fix this.

Thanks.