headers
Sam Hartman | 3 Jun 2003 11:48
Picon
Favicon

Re: _pam_dispatch_aux does not ignore chained setcred on skip action

>>>>> "Andrew" == Andrew Morgan <morgan <at> transmeta.com> 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
(Continue reading)

Permalink | Reply |
headers
Sam Hartman | 21 Jun 2003 21:30
Picon
Favicon

Re: _pam_dispatch_aux does not ignore chained setcred on skip action

>>>>> "Sam" == Sam Hartman <hartmans <at> MIT.EDU> writes:

>>>>> "Andrew" == Andrew Morgan <morgan <at> transmeta.com> writes:

    Sam> The question is why does this module get to influence the
    Sam> return value at all in the setcred, chauthtok or
    Sam> close_session phase even though its return is ignored in the
    Sam> auth, open_session and first chauttok phase.

    Sam> I.E. in the freezing part of chain creation, a jump is a jump
    Sam> there and ignore the value.

    Sam> But a frozen jump is a jump over there and require the module
    Sam> to succeed.

    Sam> Why does the module not get to influence the return value
    Sam> when creating the chain, but get to influence it when using
    Sam> the chain.

Hearing no comments whatsoever, I'll go fix this in Debian and submit
a patch that can be ignored like all the rest.
Permalink | Reply |
headers
Andrew Morgan | 25 Jun 2003 19:06

Re: _pam_dispatch_aux does not ignore chained setcred on skip action

Sam Hartman wrote:
>>>>>>"Sam" == Sam Hartman <hartmans <at> MIT.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
> 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
(Continue reading)

Permalink | Reply |

Gmane