[ On Saturday, September 13, 2003 at 22:28:28 (+0100), Charles Blundell wrote: ]
> Subject: Re: BSD auth for NetBSD
>
> on Sat, Sep 13, 2003 at 02:18:12PM -0400, Greg A. Woods wrote:
> > No, that's not really true.  PAM and BSD Auth are authentication
> > frameworks.  I'm talking only about a "shim" API that hides the
> > particular flavour of framework from applications.
> 
> Perhaps you could give function prototypes for this api?

I'm working on it!  :-)   Note the person who first proposed it may
already have firmer ideas than mine....

(and prototypes alone do not an API make :-)

In any case it might look one heck of a lot like the one used by
applications for BSD Auth though -- with a couple of caveats needed to
bend to PAM's assumptions.  I.e. while one might have a lot more
difficulty using a separate authenticator process as a proxy to PAM, the
adaption of the BSD Auth application API to alternately call PAM should
be relatively simple (at least given how I've seen both used in OpenBSD
and FreeBSD respectively).

It may be equally possible to wrap the BSD Auth API with functions that
look exactly like the PAM application API and similarly insert a
compile-time or run-time switch to call either out the back-end of this
shim.

It may even be possible to offer both APIs as shims to each other and
with a run-time and compile-time configurable switch in the middle so
that the appropriate back end can be chosen at will.

However from what I've seen of the two APIs to date I find the BSD Auth
application API to be by far the cleaner and more flexible of the two
(with the tiny caveat that BSD Auth's API currently doesn't require the
authentication session to be kept open for the life of the authenticated
session and though I'm not sure PAM really does require it be kept open
for the basic auth methods like unix passwords that is the way it has
been implemented in FreeBSD's login(1)).

Ideally I'd also like to come up with an even more simplified common
"wrapper" API for the common cases where one just wants all the normal
unixy things to happen, such as in login, ftpd, rcmd, or any other place
where a session is started and authenticated once for its lifetime with
a simple password (one-time, challenge, or normal secret) that the
library will obtain directly from the user via a specified R/W file
descriptor.

> > I think you're not looking at how authentication fits into the system
> > and how authentication is used in production environments properly.  All
> > the tools in pkgsrc already work perfectly fine with the existing getpw*
> > support in the native OS.
> 
> Two things: kerberos, s/key.

Adding either PAM or BSD Auth doesn't really make supporting either of
these in third party code all that much easier.  Third party developers
still pretty much have to be prepared to use native OS support for these
two mechanisms regardless of whether they also support some more generic
framework such as PAM and/or BSD Auth.

We have both kerberos and s/key natively supported in the base OS and I
was under the impression that all add-on packages in pkgsrc which needed
to be aware of at least Kerberos already had the necessary hooks to make
them aware of the native Kerberos libraries and utilities.

I'm a little less sure about how well existing packages work with
NetBSD's s/key support.  I haven't tried s/key with Cyrus SASL lately,
for example, though I was hoping to get a chance to do exactly that very
soon.  It should already work if I understand the "--enable-otp"

-- 
						Greg A. Woods

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