On Mon, Oct 15, decoder wrote:
> Tomas Mraz wrote:
> > 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.
> Yes and as I stated before, even modules that ship with PAM, such as
> pam_cracklib, ask for the new pass in the second phase although they
> need to verify it. So this bug also affects at least module which is
> shipped with PAM. When I have the time I will try to write a patch to
> change the behavior but you guys can do that a lot better I guess. I
> had a quick look at the source and it looks anything else than simple ;)
No, it does not really affects modules shipped with PAM.
Normally what happend is:
- one module reports an error. In that case, the new password
will be deleted from the stack ("pam_set_item(pamh, PAM_AUTHTOK, NULL);").
- the following modules will try to get the already entered password
and fail, so they cannot change the password and will fail, too.
Or, if the stack is misconfigured, the followng modules will ask
again for the new password. This should be fixed in the pam configuration
(the relevant options are "use_authtok" and maybe "use_first_pass").
So I see no need to change a very, very old behavior being there
from day one of Linux-PAM and working fine if configured correct.
The only condition under which I would think about changing this
behavior is, if somebody can prove that Linux-PAM behaves different
than openpam and Solaris. But I doubt it, because having different
stacks for precheck and chauthtok could break cleanup functionality
of modules.
Thorsten
--
Thorsten Kukuk, Project Manager/Release Manager SLES
SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg
GF: Markus Rex, HRB 16746 (AG Nuernberg)
_______________________________________________
Pam-list mailing list
Pam-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/pam-list
