"Sam" == Sam Hartman <hartmans@xxxxxxx> writes:Hearing no comments whatsoever, I'll go fix this in Debian and submit a patch that can be ignored like all the rest.
In the words of a friend from college: "Harsh, but fair."
I disagree with your existing sourcforge patch. Please see the bug report for my concerns. [I just placed my feedback in that bug report.]
[You previously wrote:]
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.
Simply put, because it may have something to say.
The auth (etc) stack (or more generally chain) is an oportunity for PAM to select a set of modules. You agree on this point.
If an applicant user can satisfy this chain of modules in the manner that the admin configures them, then they are 'macroscopically authenticated'. No module in the stack has the 'microscopic' right to override the sys-admin on this macrocsopic decision.
When executed in the credential mode, a module shouldn't pull the plug and use this credential phase to reiterate with 'weren't you listening, I said you couldn't authenticate before so why are you asking for a credential now?'. It needs to respect the fact that the admin has configured stuff in such a way that the module's authentication requirements were not met, but it doesn't seem to matter, so thats ok.
If the credential component has no credential to offer - since credentials are often tied to authentication (as per kerberos) then the module should return PAM_IGNORE. If the module can offer a credential anyway, then it should return PAM_SUCCESS. If, independent of it authentication decision, it believes it should be able to offer a credential but for some reason there is some transient problem getting one - it should return the appropriate error, which will get communitcated to the user.
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.
What had been intended by this change to the frozen chain stuff is that the credential run could return something 'meaningful' in its credential setting phase. Prior to this change, for sane execution of the stack, the credential run of a module had to return exactly the same thing as the auth run - which communicated nothing at all.
Cheers
Andrew
_______________________________________________ Pam-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/pam-list
