Possible bug in PAM pam-0.99.8.1 regarding password changing

[decoder]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tomas Mraz wrote:
> On Sun, 2007-10-14 at 21:41 +0200, decoder wrote:
>> Hello all,
>>
>>
>> I ran into problems when using the "requisite" keyword with
>> password changing modules. I reduced my problem to a very simple
>> stack which only involves 2 instances of pam_debug, to make it
>> easier to understand:
>>
>> password   requisite   pam_debug.so prechauthtok=success
>> chauthtok=authtok_err password   sufficient  pam_debug.so
>> prechauthtok=success chauthtok=success
>>
>> This accurately describes the current situation I am having with
>> two pam modules (pam_krb5 and pam_smbpass). The first module is
>> failing in the change phase because the new password does not
>> satisfy a given policy (similar to cracklib policies).
>> Nevertheless, the output for `passwd` as a user is:
>>
>> decoder at myserver ~ $ passwd prechauthtok=success
>> prechauthtok=success chauthtok=authtok_err chauthtok=success
>> passwd: Authentication token manipulation error
>>
>>
>> As you can see, the second chauthtok is still returning success
>> here, although it shouldn't even get called at all! (because of
>> requisite). This essentially causes my password databases to go
>> out of sync because PAM does not stop although it is told to stop
>> on failure with the requisite keyword.
>>
>> System Information:
>>
>> OS: Gentoo Linux Installed PAM version: pam-0.99.8.1-r1 provided
>> by Gentoo portage
>>
>> If anyone could verify this behavior, and, if this is not a
>> problem on my side, tell me if this is supposed to happen or not,
>> that would help me a lot.
>>
>
> This behavior is right. The order of module stack evaluation is
> frozen in the first pass (prechauthtok) and because both modules
> are successful in the first pass both must be called in the second
> pass regardless of requisite keyword. The pam_krb5 module should
> check the policy in the prechauthtok pass so the failures in the
> chauthtok pass would happen only on special circumstances like a
> network failure and so on.
How would the pam_krb5 module be able to check the password if it
doesn't have it yet? To my knowledge, these modules ask for the new
password in the second phase (not only pam_krb5 but almost all modules
I know). By the way, this is not only happening with pam_krb5 but also
with pam_cracklib. When I try to use pam_cracklib with requisite, the
stack continues as well, even though cracklib rejected the password.
This behavior is illogical and not very useful.


Best regards,


Chris


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHEoByJQIKXnJyDxURAnSbAJ0d8pzCx8wB9MHCfusPFLxVzlnT3wCfUt/V
Kx7pibTKWPXMxZUqHcCFz9I=
=75LY
-----END PGP SIGNATURE-----