Re: _pam_dispatch_aux does not ignore chained setcred on skip action

[Andrew Morgan <morgan@xxxxxxxxxxxxx>]

Sam Hartman wrote:
> > > > > > "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