Re: Why should setcred be called after session open?

[Nicolas Williams <Nicolas Williams ubsw com>]

On Tue, May 15, 2001 at 10:58:16AM -0700, Andrew Morgan wrote:
> Nicolas Williams wrote:
> 
> > I think having a module's setcred() be called EVEN if its authenticate()
> > was not IS useful: it gives the module a way to find out that the user
> > was successfully authenticated by PAM even though it (the module) was
> > not involved.
> 
> There are other ways to do this, notably with an entry of this form at
> the top of the authentication stack:
> 
>   auth optional pam_foo.so no-op
>   auth <stuff as before>

Can a module appear multiple times in the stack?

And then, how can a module distinguish the second call to its
pam_sm_authenticate() from the first call resulting from a second call
to pam_authenticate() by the app?!

Solaris' /bin/login, for example, calls pam_authenticate() again, with
the same PAM handle, if the first call fails.

> [...]
> > Why password? I can understand session...
> 
> pam_sm_password() is called twice. Once [PAM_PRELIM_CHECK] to prepare
> for setting the password (and ping necessary servers etc.) and then, if
> the stack as a whole returned success this first time, the stack is
> invoked for a second time [PAM_UPDATE_AUTHTOK]. The point being to force
> the stack to follow the same path the second time through.

Ah, right, I'd forgotten about the prelim check. Yes, this makes sense.

> > I think suuficient in auth should become optional in setcred, everything
> > else should remain as in auth, and ALL auth modules should have their
> > setcred() be called...
> 
> Could you give some examples of why this makes more sense than a simple
> 'required/optional' scheme?

It's the same thing.

[...]

> > so, I'd love that sort of thing -- I might even write a patch for
> > Solaris PAM and submit it to sun in an RFE...
> 
> This idea actually came from Vipin (half author of the original DCE RFC
> for PAM) from Sun.

Ah, but it doesn't mean Sun is implementing that.

Mind you, skip-N-if-condition is a rather crude way to add
conditionality. A logic expression would be better, more exact and
comprehensible. It's like coding in assembly with an instruction set
whose conditional instructions are skip-if and/or jump-if vs. coding in
a higher-level language that properly supports structured conditional
expressions.

Thirty years after C, more than 40 years after FORTRAN and Lisp, I
don't see why descend to such a low-level programming concept as
skip-if...:) :/

So consider a PAM logic expression consisting of  grouping operators
('(' and ')'), logic operators ('&&' and '||'), comparison operators
('==' and '!=', operating on symbols [e.g., error messages] and strings
[e.g., PAM_USER names] in a context-dependent manner, module calling
operators (bare module names), item reference operators, plus, finally,
immidiate/delayed failure/success operators.

There is a complexity issue though. I'll drop this now. :) :)

> Cheers
> 
> Andrew


Cheers,

Nico
--