[ On Saturday, September 13, 2003 at 13:27:31 (-0400), Roland Dowdeswell wrote: ]
> Subject: Re: BSD auth for NetBSD 
>
> That is what PAM and BSD Auth are, wrapper APIs around things that
> do authentication.  I was suggesting that it is going overboard to
> put a wrapper around two wrappers which will surely end up having
> the compromises of both systems.

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.

> I do not see how wanting to be able to use 3rd party applications
> is ``market-_focused_ reasoning''.

The point is that choosing an authentication framework solely based on
its market share does not jive at all with the expressed common goals of
NetBSD, especially when it's not the technicaly superior framework.

>  Maybe you do not feel that it
> is necessary to use anything that is not in basesrc, but many of
> the rest of us actually appreciate the fact that NetBSD can compile
> and run applications that were written on other UNIX systems.

Indeed, but as I pointed out most of those problems are already solved
for the vast majority of applications without having to be compatible
with any particular authentication framework.

> Do you think that providing POSIX compatibility is ``market-_focused_
> reasoning''?  Maybe it is...  But I am quite glad that we have
> decided to be `sale droid'-ish on that issue.

While POSIX compatability is at a whole different level, the point is
that choosing anything solely based on market share, especially for any
open source system, is not productive.

If there were an agreed upon, non-vendor-driven, authentication API that
met all the common needs and didn't force irrelevant implementation
decisions on users then it would be a good thing to implement
_compatability_ to that API just as POSIX _compatability_ is good thing.

> Greg, when you have provided BSD Auth client level support to all
> of the things in pkgsrc that support PAM, e.g. gdm, kdm, xlock,
> xscreensaver, and so on, then please by all means tell us how little
> you care about 3rd party support for _our_ authentication mechanisms.
> I have little desire to do that, and apparently you do not either
> since I haven't seen any patches from you providing said support.

All those things that need specific support for either PAM or BSD Auth
or whatever cool new thing comes along next are equally broken by
design.

Step one is to implement an API at the level of nsswitch that hides the
authentication framework.

At that point it becomes irrelevant which framework you choose to use on
your system.

> One of the big reasons to go with PAM or BSD Auth is to get NetBSD
> out of the rather annoying situation that 3rd party applications
> do not authenticate in the same way as the base operating system.

Well, actually, no, that's not any real reason at all.

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.

The real reason to integrate both PAM and BSD Auth is to make it
possible to have run-time configurable and run-time extensible
authentication frameworks that themselves have run-time configurable and
extensible authenticators.

> Yes, I probably don't care either.  What I care about is the _clients_
> will acutally authenticate in the same way as login(1).

Me too, which is why step one is to implement a runtime configurable and
extensible authentication API that can drive any framework.

> Uh, SASL and PAM solve entirely different problems.

Really?  :-)

-- 
						Greg A. Woods

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