Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
Re: _pam_dispatch_aux does not ignore chained setcred on skip action
From: Andrew Morgan (morgantransmeta.com)
Date: Wed Jun 25 2003 - 12:06:58 CDT
Sam Hartman wrote:
>>>>>>"Sam" == Sam Hartman <hartmansMIT.EDU> 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
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.
Pam-list mailing list