Subject: Re: BSD auth for NetBSD
To: NetBSD Security Technical Discussion List <tech-security@NetBSD.ORG>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-security
Date: 09/16/2003 00:17:59
On Mon, 15 Sep 2003, Greg A. Woods wrote:

> [ On Sunday, September 14, 2003 at 20:53:40 (-0700), Bill Studenmund wrote: ]
> > Subject: Re: BSD auth for NetBSD
> > It
> > looks like just using PAM and having a BSD Auth using module ship in the
> > base system would be the best way to go.
>
> That doesn't solve _any_ of the problems BSD Auth solves nor does it
> even provide the BSD Auth client API (which, IIUC, was Peter's minimum

Uhm, read closer. 1) It does not solve the "no modules" desire of BSD
Auth, but it keeps the list to one, which should be a rather
easily-audited one. 2) The full BSD Auth will still be there, it just
won't be used by the apps in basesrc directly. 3) it means that an admin
that wants to use BSD Auth can do so with the base system, and the admin
that wants to use PAM can do so with the base system. No recompiling of
base binaries needed, and the code doesn't look like chopped liver.

> requirement).  I.e. it's a slam in the face of everything BSD Auth
> stands for.  It's also an unfair choice since it would seem to be
> ignoring all the true technical merits and be based on perceived market
> share alone.  What a sham, especially for an open source system that
> purports to have only the highest of technical and quality standards.
> I.e. you're going backwards here again Bill, not forwards.

And maybe if you actually listened to what people had to say, you'd hear
how you are not correct in your above statements.

[snip]

> An alternate solution is to evaluate each API fairly on its technical
> merits _alone and choose the best one.  That one client API can then be
> used as a wrapper around both frameworks.  It would seem adapting to the

That's what we're suggesting. And the one wrapper API is PAM.

Take care,

Bill