On Thu, Mar 12, 2009 at 10:09:14PM -, 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. Choos
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.
--
passwd indicates password updated although it wasn't
https://bugs.launchpad.net/bugs/303515
You received this bug notification because
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 Passwo
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
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:
j...@neo:~$ passwd
Changing pa
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
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-screensa
andr...@hawat:~$ cat /etc/pam.d/passwd
#
# The PAM configuration file for the Shadow `passwd' service
#
@include common-password
andr...@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 s
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.
andr...@pc13267v2:~$ cat /etc/pam.d/passwd
#
# The PAM configura
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)
--
passwd indicates password updated although it wasn't
https://bugs.launchpad.net/bugs/303515
You received this bug notif
I *think* this is in our PAM configuration. Surely [success=1
default=ignore] for pam_unix in common-password isn't right?
** Changed in: pam (Ubuntu Jaunty)
Sourcepackagename: shadow => pam
--
passwd indicates password updated although it wasn't
https://bugs.launchpad.net/bugs/303515
You receiv
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.
** Changed in: sh
** Summary changed:
- passwd command bug in gnome-terminal
+ passwd indicates password updated although it wasn't
--
passwd indicates password updated although it wasn't
https://bugs.launchpad.net/bugs/303515
You received this bug notification because you are a member of Ubuntu
Bugs, which is s
13 matches
Mail list logo
