Subject: Re: BSD auth for NetBSD
To: Todd Vierling <tv@duh.org>
From: Greg A. Woods <woods@weird.com>
List: tech-userlevel
Date: 09/13/2003 16:19:57
[ On Saturday, September 13, 2003 at 14:24:21 (-0400), Todd Vierling wrote: ]
> Subject: Re: BSD auth for NetBSD 
>
> On Sat, 13 Sep 2003, Greg A. Woods wrote:
> 
> : 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.
> 
> Certainly you're not saying that BSD Auth is "technicaly superior" to PAM.

Yes I certainly do feel that technically BSD Auth _is_ far superior to
PAM -- especially in the context of NetBSD.

The whole idea for PAM comes directly from environments that have goals
and requirements which are totally antithetic of open source systems and
unfortunately the resulting design of PAM places constraints on
implementations that are irrelevant and/or contrary to the goals and
requirements of open source systems and open source users, including
those publicly stated for NetBSD.

If you have technical criticisms of BSD Auth which are more
sophisticated than the overly-repeated lame and meaningless excuse that
BSD Auth authenticators can't interact directly and freely with the
caller's address space and process context then please let's hear them!

However if all you can mumble about PAM boils down to the sole fact that
it's design allows authenticators free reign over the caller's address
space and process context then please forget I asked because the reason
I want BSD Auth (and I'm sure I'm not alone on this) is explicitly to
move those authenticators out into their own process space and to be
much more picky about how they can communicate and even what identity
they might run under.  No amount of using that as your excuse to justify
PAM will ever fly, just as the idea of using BSD Auth authenticators
from a PAM proxy module will never fly with anyone who primarily wants
to use BSD Auth as putting PAM in the middle not only complicates
something that would otherwise be very simple but it flies in the face
of the goals of BSD Auth and is an insult to its inventors.

Technically PAM is a wide open mine field giving full and unfettered
access to the caller.

Technically PAM does not even allow authenticator code in the module to
run as a different UID (at least not in any meaningfully secure way).

If you think the presence of those problems in PAM allows it to be
technically superior to BSD Auth in any way then you're welcome to your
opinion but please don't expect me to follow your apparent beliefs.

You say you don't like PAM but yet you've been effectively appologizing
for its failings and helping prop it up.

I clearly don't like PAM and I'm not going to stop fighting against its
scourge, but I'm also still not going to stand directly in the way of
anyone who truly thinks they need to use it (though I will try to point
them to alternatives), and I still won't stand directly in the way of
anyone who wants to find some way to glue it into the base NetBSD source
tree, just so long as it never becomes an absolute requirement for
NetBSD users (at least not at the source level -- I could care less
about the default binary distributions).  I.e. do not confuse my
criticisms of PAM with a refusal to allow it to exist.  I know it exists
and I'm not in a position to either prevent people from using, nor am I
in a position to provide, on my own, a complete ready-to-use alternative
for those people who think they need it.  All I've ever asked is that it
not be thrust down my throat.

-- 
						Greg A. Woods

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