[ On Wednesday, August 28, 2002 at 12:46:58 (-0400), Jim Wise wrote: ]
> Subject: Re: PAM
>
> Well, guess what?  The same goes for PAM -- there are a _lot_ of
> projects out there working to integrate PAM with assorted databases,
> network authentication systems (RADIUS, LDAP, NTLM, netinfo, you name
> it) and so forth.  If we adopt PAM, we benefit from all of this.

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.

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.

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

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

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.

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

-- 
								Greg A. Woods

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