[ On Sunday, September 14, 2003 at 10:52:25 (-0700), Jason Thorpe wrote: ]
> Subject: Re: BSD auth for NetBSD 
>
> 
> On Sunday, September 14, 2003, at 10:14  AM, Greg A. Woods wrote:
> 
> > [...and that defeats the whole purpose of using either.
> >
> > I don't think so!  Why do you think so?  Are you really sure you
> > understand what I'm trying to describe?
> 
> One of the major features of using PAM is API compatibility with 
> PAM-using applications (of which there are many, especially compared to 
> BSD Auth).

That answer simply does not have anything whatsoever to do with my
original statement.

In fact on the contrary you are now simply confirming the reason for
using a shim or wrapper API, especially a two-way one as I suggested, in
the first place -- i.e. an API which includes both BSD Auth client
functions and PAM client functions and which can be configured (at
runtime or at compile time) to call either framework out the back end.
Such a shim or wrapper API actually makes it better for everyone since
with any application would use either framework without (as much)
porting effort regardless of which client API it might support best
natively.

I.e. such a shim API does exactly the opposite of defeating "the whole
purpose" of using either authentication framework -- rather it makes it
possible for any application to use either framework transparently thus
allowing the purpose of either framework to be fulfilled regardless of
the application author's initial choice of API!

To me the "whole purpose" of using BSD Auth is to move the authenticator
code out into a sub-process.  The way this is done behind the scenes has
nothing whatsoever to do with the client API since in the end the BSD
Auth and PAM client APIs are both almost identical at a functional
level.  I.e. except for the changes necessar to the layout of the data
structures and parameters you could almost use 'sed' to map one's
functions to another.  For example Using a BSD Auth authenticator that
knows how to set an AFS PAG for its parent process will still work even
if the caller is actually using the PAM client API.  The caller doesn't
really even know that the PAG has been created, let alone how.

I believe this can be done without too much hassle or effort, assuming
we're willing to force one tiny but significant change on the BSD Auth
API, which I've already discussed (and which would also be necessary
even if the choice were simply to implement only the BSD Auth client API
and then allow it behind the scenes to call upon PAM).

-- 
						Greg A. Woods

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