[regression] passwd -e locks account

[Nick Barcet]

On an up to date intrepid desktop or server

- create a user "test"
- sudo passwd -e test
- try to log in as test
--> "you are required to change your password immediately (root enforced)"
"Authentication failure"
then back at the login prompt

I would have expected to be asked for a new password where it seems that the account is locked.

Impact: users that should be able to change their passwords at login time are instead locked out.

Regression potential: none of note

TEST CASE: expire a user account with 'passwd -e'; try to log in; see the above-mentioned error. install the updated package, try to log in again, and get a prompt for changing the password.

[Jamie Strandboge (jdstrand)]

This occurs because of the new entries in /etc/pam.d/common-account:
account [success=1 default=ignore] pam_unix.so
account requisite pam_deny.so
account required pam_permit.so

On Hardy (where this still worked), common-account contained:
account required pam_unix.so

[Kees Cook (kees)]

Changing this to:

account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so

Seems to work, but I'm worried about side-effects of using "done" here. Is this a bug in pam_unix? new_authtok_reqd=ok doesn't work.

[Soren Hansen (soren)]

How about new_authtok_reqd=1 (i.e. skip the pam_deny entry)? In Hardy pam_unix used to be "required", which translates into [success=ok new_authtok_reqd=ok ignore=ignore default=bad], so success and new_authtok_reqd had the same action back then, too.

[Steve Langasek (vorlon)]

On Fri, Oct 31, 2008 at 09:57:31AM -0000, Soren Hansen wrote:
> How about new_authtok_reqd=1 (i.e. skip the pam_deny entry)? In Hardy
> pam_unix used to be "required", which translates into [success=ok
> new_authtok_reqd=ok ignore=ignore default=bad], so success and
> new_authtok_reqd had the same action back then, too.

No, that's definitely wrong. "new_authtok_reqd=1" would mean pam_unix would
not contribute at all to the return code of the stack, it would instead jump
to pam_permit and return PAM_SUCCESS.

new_authtok_reqd=ok or new_authtok_reqd=die should have the desired effect.

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

[Tux (peter-hoogkamer)]

I have tested this with "new_authtok_reqd=die" and this works. The "new_authtok_reqd=ok" is not working. I am not an expert on pam, so I don't know if the "die" option has any consequences for other function within ubuntu.

Tux

[Kees Cook (kees)]

Proposed patch for SRU.

[Kees Cook (kees)]

Uploaded to -proposed with slangasek's approval.

[Steve Langasek (vorlon)]

Accepted into intrepid-proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Steve Langasek (vorlon)]

pam 1.0.1-4ubuntu5.1 copied to jaunty.

[Tux (peter-hoogkamer)]

I have seen this fix in Jaunty and it works there with the TEST CASE given by Steve :
TEST CASE: expire a user account with 'passwd -e'; try to log in; see
+ the above-mentioned error. install the updated package, try to log in
+ again, and get a prompt for changing the password.

When testing this case in Intrepid this does not work and I don't see a changed /etc/pam.d/common-account file. I have Intrepid-proposed enabled.

Tux

[Martin Pitt (pitti)]

I bumped the build priority of the intrepid-proposed update, it got stalled due to the sync wave in Jaunty. Shuold be available for testing in a matter of hours now.

[Tux (peter-hoogkamer)]

Ok. Thanks. I'll do the test case then and report back with the result.

2008/11/7 Martin Pitt <email address hidden>:
> I bumped the build priority of the intrepid-proposed update, it got
> stalled due to the sync wave in Jaunty. Shuold be available for testing
> in a matter of hours now.
>
> --
> [regression] passwd -e locks account
> https://bugs.launchpad.net/bugs/291091
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Martin Pitt (pitti)]

-5.2 needs to be copied to jaunty once it's built in intrepid-proposed.

[Nick Barcet (nijaba)]

Verified test case and fix with the version of pam in intrepid-proposed

[Martin Pitt (pitti)]

Works for me, too.

[Martin Pitt (pitti)]

intrepid-proposed package copied to jaunty.

[Martin Pitt (pitti)]

Copied to intrepid-updates.

[Soren Hansen (soren)]

>> How about new_authtok_reqd=1 (i.e. skip the pam_deny entry)? In Hardy
>> pam_unix used to be "required", which translates into [success=ok
>> new_authtok_reqd=ok ignore=ignore default=bad], so success and
>> new_authtok_reqd had the same action back then, too.
> No, that's definitely wrong. "new_authtok_reqd=1" would mean pam_unix
> would not contribute at all to the return code of the stack, it would
> instead jump to pam_permit and return PAM_SUCCESS.

Reading the docs again, I've apparantly had the wrong idea about the
"ok" action (I somehow thought that that too would result in PAM_SUCCESS
being returned). I see the problem now. Thanks for pointing this out.

[🤖 Landscape Builder (landscape-builder)]

This bug has not seen any activity in the last 6 months, so it is being automatically closed.

If you are still experiencing this issue, please feel free to re-open.

Landscape Team