>>>>> "Andrew" == Andrew Morgan <morgan@xxxxxxxxxxxxx> writes:
Andrew> I guess I'm completely confused by your
Andrew> observations. Could you try again to explain what you
Andrew> think is wrong?
OK, we are mostly on the same page for how the frozen chain works. Or
at least I agree with you that if you were to accept my bugs on
sourcforge, the frozen chain would work as you describe. Its released
behavior is broken for PAM_IGNORE, but that bug and a patch fixing it
is already on sourceforge.
I have some module that fails in the auth phase. As a sysadmin, I
have decided that I specifically want to ignore the failure in
question and jump over some dependent modules.
That is, I have something like
auth [default=1 other_stuff_goes_here] pam_module.so
No, I agree that the module path is set by the chain freezing and that seems fine.
The question is why does this module get to influence the return value
at all in the setcred, chauthtok or close_session phase even though
its return is ignored in the auth, open_session and first chauttok
phase.
I.E. in the freezing part of chain creation, a jump is a jump there
and ignore the value.
But a frozen jump is a jump over there and require the module to
succeed.
Why does the module not get to influence the return value when
creating the chain, but get to influence it when using the chain.
As a side note, I'm actually unclear on whether requiring modules
whose auth phase fails to return PAM_SUCCESS or PAM_IGNORE in the
setcred phase is a good idea. I thought one of the goals of the
frozen chain stuff was to make sure I didn't have to return the same
value in both phases. I had always assumed that this was intended to
avoid module authors having to keep the same state between calls. Yet
it seems that if I should return PAM_SUCCESS or PAM_IGNORE if my auth
phase called, I end up having all the complexity I did before, plus
the complexity of the frozen chain.
_______________________________________________
Pam-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/pam-list
