passwd indicates password updated although it wasn't

Thank you for taking the time to report this bug and helping to make Ubuntu better. However, you are not using the most recent version of the packages for your Ubuntu release. Please upgrade to the most recent versions and let us know if you are still having this issue. Thanks in advance.

I've recreated this bug report using passwd 1:4.1.1-1ubuntu1.1 version from Intrepid. It would be more correct if the last message did not say 'password updated successfully'.

This is not merely a cosmetic matter of the wrong message being printed; it also results in passwd exiting zero, thereby fooling adduser into believing that the account was set up successfully. This could easily lead to systems without any valid logins, requiring manual recovery.

I *think* this is in our PAM configuration. Surely [success=1 default=ignore] for pam_unix in common-password isn't right?

It reminds me https://bugs.launchpad.net/ubuntu/+bug/272232

Could you provide your PAM configuration?
(/etc/pam.d/passwd and /etc/pam.d/common-password should be sufficient)

andreas@hawat:~$ cat /etc/pam.d/passwd
#
# The PAM configuration file for the Shadow `passwd' service
#

@include common-password

andreas@hawat:~$ 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_unix.so obscure sha512
password [success=1 user_unknown=ignore default=die] pam_ldap.so use_authtok try_first_pass
# 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

The post above was from my intrepid laptop. Looking closer at the result I guess I had been playing around somewhat with ldap on it.

Anyhow, I can reproduce the same issue on a jaunty system, having the following pam configuration.

andreas@pc13267v2:~$ cat /etc/pam.d/passwd
#
# The PAM configuration file for the Shadow `passwd' service
#

@include common-password

andreas@pc13267v2:~$ 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-6, 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

I am running Jaunty Alpha 3 on a vmware install and do not have this problem. I know that I do have this problem on my Intrepid install at home. Both are updated with the latest updates.
I have the following versions of passwd and gnome-screensaver installed.

sudo apt-cache policy gnome-screensaver
gnome-screensaver:
  Geïnstalleerd: 2.24.0-0ubuntu4
  Kandidaat: 2.24.0-0ubuntu4
  Versietabel:
 *** 2.24.0-0ubuntu4 0
        500 http://nl.archive.ubuntu.com jaunty/main Packages
        100 /var/lib/dpkg/status

sudo apt-cache policy passwd
passwd:
  Geïnstalleerd: 1:4.1.1-6ubuntu2
  Kandidaat: 1:4.1.1-6ubuntu2
  Versietabel:
 *** 1:4.1.1-6ubuntu2 0
        500 http://nl.archive.ubuntu.com jaunty/main Packages
        100 /var/lib/dpkg/status

And this is the contents of my /etc/pam.d/passwd and /etc/pam.d/common-passwd
peter@test-desktop:~$ cat /etc/pam.d/passwd
#
# The PAM configuration file for the Shadow `passwd' service
#

@include common-password

peter@test-desktop:~$ cat /etc/pam.d/common-passwd
cat: /etc/pam.d/common-passwd: Bestand of map bestaat niet
peter@test-desktop:~$ 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-6, 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

I can check my passwd and common-password on my intrepid install at home and see what's the case there.

Tux

Steve Langasek told me in person that this is due to PAM's return value calculation, and the lack of a third pass through the stack to cope with the situation where the second pass (in this case, checking that passwords match) fails when the first pass succeeds. Apparently there's been some recent work on this upstream.

I can still confirm this bug in jaunty, but it is a little different...

trying with non matching passwords now fails, but first entering a password that is to short, and then trying again with 2different passwords still has the wrong behaviour:

2different passwords:
jens@neo:~$ passwd
Changing password for jens.
(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

first only 1char, 2nd attempt 2different passwords:
jens@neo:~$ passwd
Changing password for jens.
(current) UNIX password:
Enter new UNIX password:
Retype new UNIX password:
You must choose a longer password
Enter new UNIX password:
Retype new UNIX password:
You must choose a longer password
Enter new UNIX password:
Retype new UNIX password:
Sorry, passwords do not match
passwd: password updated successfully

This bug was fixed in the package pam - 1.0.1-5ubuntu2

---------------
pam (1.0.1-5ubuntu2) jaunty; urgency=low

  * New patch dont_freeze_password_chain, cherry-picked from upstream:
    don't always follow the same path through the password stack on
    the PAM_UPDATE_AUTHTOK pass as was used in the PAM_PRELIM_CHECK
    pass; this Linux-PAM deviation from the original PAM spec causes a
    number of problems, in particular causing wrong return values when
    using the refactored pam-auth-update stack. LP: #303515, #305882.

 -- Steve Langasek <email address hidden> Fri, 27 Feb 2009 16:20:24 -0800

Also with the latest updates "passwd" sometimes reports successful password changes, but password leaves unchanged.

Here is an example. The new example password could not be set by the user, because the password has already been used:

$ passwd
Changing password for user1.
Old Password:
New Password:
Password has been used already. Choose another.
New Password:
Password has been used already. Choose another.
New Password:
Control-C

This behavior is ok. But now I try to change the password for the same user als root:

$ sudo -i
# passwd user1
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully

The problem is that "passwd" reports a successful password change, but the old password is still used.

I use a standard passwd/PAM configuration (created with "pam-auth-update --force" and these options
     [ ] likewise-open
     [*] unix
     [*] consolekit).

Please forget my last comment. After calling "pam-auth-update --force" the passwd/PAM setup now works. Password history as in my last comment is now disabled.

On Thu, Mar 12, 2009 at 10:09:14PM -0000, Bjoern Voigt wrote:
> Here is an example. The new example password could not be set by the
> user, because the password has already been used:

> $ passwd
> Changing password for user1.
> Old Password:
> New Password:
> Password has been used already. Choose another.
> New Password:
> Password has been used already. Choose another.
> New Password:
> Control-C

This transcript doesn't match your stated PAM configuration. These are not
the messages printed by the pam_unix module on a password change.

> This behavior is ok. But now I try to change the password for the same
> user als root:

> $ sudo -i
> # passwd user1
> Enter new UNIX password:
> Retype new UNIX password:
> passwd: password updated successfully

> The problem is that "passwd" reports a successful password change, but
> the old password is still used.

That's an unrelated issue; please file a new bug report.

--
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>