On Fri, 12 Sep 2003, Greg A. Woods wrote:

: > That rather defeats the purpose of PAM.  Some authenticators (two-way smart
: > cards are a common example) are *stateful* and cannot run outside the
: > authenticated process without significant authenticator-specific context
: > copy operations.
:
: What stateful operations take place during (or at the end of) a session?

You have some research to do.  We might as well end the discussion of the
internals here, and you can come back after reading the PAM client API.

: Sounds like a pretty broken design for something that's just supposed to
: authenticate a user so that processes can be authorized to be run as the
: UID that represents that user.

That's not the only thing PAM does.  A "session" (i.e. login to logout) is
not the only encapsulating body for an authentication token.

You should note, Greg, that I personally don't like or use PAM, for similar
reasons to those you have mentioned.  But certainly, given that it is
module-based, it wouldn't be unreasonable to desire NetBSD to have it as an
optionally loaded subsystem.  "Don't use it if you don't want it."

Now, I have had occasion and necessity to use it in process control systems
at a semiconductor manufacturer.  As a result, I do understand some of its
strong points, particularly how it's not just a "session" authentication
system.  BSD Auth, however, *is* just a login session based authenticator.

In either case, the angle you're coming from is login session
authentication.  This is something that need be neither of the BSD Auth nor
PAM APIs; that is why nsswitch exists.  It's true that nsswitch as
implemented today isn't enough for either of BSD Auth or PAM, but it's the
perfect place to implement a way to get to either (...or the internal
authenticators).

-- 
-- Todd Vierling <tv@duh.org> <tv@pobox.com>