Possible bug in PAM pam-0.99.8.1 regarding password changing

[Tomas Mraz]

On Sun, 2007-10-14 at 22:47 +0200, decoder wrote:
> Tomas Mraz wrote:
> > On Sun, 2007-10-14 at 21:41 +0200, decoder wrote:

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

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

The modules could ask for and check the new password in the first pass.
But the module writers guide documentation of PAM library states that
the modules should only check whether they will be to contact the
authentication service server. So you're probably right that in case of
pam_chauthtok the stack shouldn't be frozen in the first pass.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb