[[ I think it may still be worthwhile returning to the questions posed
   here in this now somewhat dated post.... ]]

[ On Friday, September 12, 2003 at 20:19:39 (-0400), Todd Vierling wrote: ]
> Subject: Re: BSD auth for NetBSD
>
> 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.

I already knew how that PAM client API worked.  It's pretty obvious if
one reads the code of login.c in FreeBSD, for example.  Note how similar
the BSD Auth client API is by reading the code in login.c from OpenBSD.

I didn't ask you about generics about the API -- I asked you for
specifics about the authentication mechanism(s) you suggested might need
to exchange ongoing information during the length of the authenticated
seesion.

> 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.

Well, if you consider a session to be only something tied to a TTY, then
yes, OK, you're right.  (I don't assume a session is tied to a TTY.)

> 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.

BSD Auth can be used for things other than "login sessions" too you
know.

As I've already hinted several times now BSD Auth's client API could
relatively trivially be modified to require the caller not close the
auth session until the session ends (which would indeed help by
providing some way to call k5destroy() at session end).

I believe BSD Auth could even support having an instance of the
authenticator run for the duration of the session, though I'm still not
sure what the point would be.

> In either case, the angle you're coming from is login session
> authentication.

Actually I'm not, but "whatever".

>  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).

Now I think we're back on more or less the same page.

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>