On Wed, 28 Aug 2002, Greg A. Woods wrote:

> All those things might offer a PAM API, but they all also offer their
> own native APIs (or network protocols, or whatever) too.  PAM is just an
> abomination they (or some other PAM freak) have decided to "support" on
> top of what "they" do natively.  NetBSD's nsswitch library could just as
> easily have code added to it such that any of the above databases could
> be used as a source for various types of queries.

Why is it an abomination? Well, since you chose to use such a subjective
adjective, you're probably made up your mind well past openness.

> Adding RADIUS support to nsswitch, for example, might be a very good
> idea and might make NetBSD more useful for some tasks in some ISP
> environments than it is today.  I've even considered doing it as a local
> patch to my own systems, though at the moment I no longer have a direct
> application in need of such a solution.  It wouldn't even be very much
> code (and templates exist already where similar stuff has been directly
> integrated into getpwent() et al without the mediation of nsswitch), so
> could be added to the default libraries shipped by TNF.  However one
> thing I would not ever want is a pluggable interface of any kind to
> allow nsswitch to load such modules at run time, not for this kind of
> local code, nor for anything else anyone might dream up.  If I can't
> compile the code directly into my nsswitch library and relink all my own
> binaries then I don't want that code anywhere near my systems -- it
> wouldn't be a "solution" but rather a risk and a support problem.

Well, you've chosen to do things in a manner a number of folks haven't.
They find having to compile each module into each program a support mess.

Yes, our lives are a bit easier in that we have nsswitch, so that there is
an API all these modules need to use. But it still means rebuilding chunks
of libraries and programs. We want loadable modules so you don't have to
do that.

> > In contrast, there aren't such projects out there for BSD-Auth or for
> > some alternate `standard' we might invent.  This seems to dictate that
> > we should at least support PAM as a compatibility API.
>
> There's undoutably programming involved either way you go, so why not
> K.I.S.S. and avoid the PAM nightmare?

Because in the long run it looks like PAM (or bsd auth) is simpler. We get
to re-use what other folks have written. We work once to get those methods
to work, then we just start using what other folks have done.

> > Now, given that BSD-Auth can easily be implemented as a PAM plugin,
> > while it is impossible to implement PAM as a BSD-Auth plugin (because
> > BSD-Auth cannot modify process state),
>
> That's not true.  You could implement a PAM "method" for BSD-Auth.
> Obviously the result wouldn't work for some PAM modules, but maybe most
> of us wouldn't care.

Uhm, "the result wouldn't work for some PAM modules" indicates that
you can't build PAM on top of BSD-auth.

> Meanwhile it would seem that if support for whatever auth methods which
> might have to modify the querying processes context were integrated
> directly into nsswitch so that the code doing the modifying would/could
> be statically linked into the process in question then this silly idea
> that only PAM works for for such auth methods would be blown right out
> of existance.

What idea that "only PAM works"?? No one has said that. What we've said is
that we want to build an extensable authentication system, where you can
have nsswitch load auth modules. We also want to be able to support auth
methods (like PAM and BSD-auth) that others are using, to reduce the
effort it takes to get them working on NetBSD.

To be able to do PAM-style auth, we need to load auth modules into
binaries. To do some of the auth methods we want to do, we have to load
auth modules into binaries (like AFS auth, where you deal with tokens in
your process space). The reason we think it would be easy to start with
PAM is, well, because what PAM pruports to do is pretty much what we want.

This doesn't mean we plan on repeating the mistakes we think other PAM
implementations make.

> > it seems pretty clear where we
> > should start...
>
> It seems pretty clear that all these arguments for PAM are based on
> misinformation and false assumptions.

Is it that, or that you heard some of what folks wanted to do and
projected thoughts onto that that they didn't say?

Take care,

Bill