On Thu, 23 Jan 2003, Jason R Thorpe wrote:

> On Thu, Jan 23, 2003 at 05:10:00PM -0800, Bill Studenmund wrote:
>
>  > We want to start with PAM as we can put BSD Auth on top much more easily
>  > than PAM over BSD Auth; getting PAM puts us on a path that will get us
>  > both.
>
> Note that we don't necessarily have to consider BSD Auth a non-starter.  If
> someone can propose an extension to BSD Auth to address its deficiencies,
> then I think that would be fine.

I don't think that BSD Auth is a non-starter, just that PAM (or something
like it) would be what we build into libc & friends, and that we'd use
that to get BSD Auth.

I personally suspect that on my machines, I'll configure in the BSD_Auth-
on-PAM module, and then configure BSD Auth. :-) Yes, I expect *I* will be
using this BSD_Auth-on-PAM stuff, and that it will work well. I'm not just
suggesting it to dismiss objections.

> As Paul and others have pointed out, BSD Auth does have some nice properties.
> But it does have one really major drawback, that being the inability to modify
> the calling process's state (with the exception of environment variables, as
> Paul pointed out it can do), with the canonical example being authentication
> methods (usually Kerberos-based ones, e.g. AFS) which have to push a token
> into the kernel (AFS, DFS, and Kerberized-NFS need this in order to be able
> to access your files).

The big aspect of not being able to directly modify the calling process's
state is that, while we can extend BSD Auth to deal with this or that new
token add-in (say teach BSD Auth to add AFS Tokens), whenever we come up
with a new method that needs an as-of-yet unexpected state mod, we have to
go to all the client programs and teach each of them to deal with this new
state mod.

We wanted to do something so that you can add _totally_ arbitrary
authentication methods to a stock system. You could download 2.0, take
stuff you got from your auth vendor, and tie it all together w/o
rebuilding your distribution.

The only way to do this w/o recompile is with a loadable-module approach
(to extend nss).  PAM is a loadable-module approach, and it seemed silly
to make one loadable-module approach that would then load other loadable
modules.

While BSD Auth would let us add lots of auth methods, w/o some form of
loadable modules, we can't support adding _totally_ arbitrary
authentication methods w/o recompile.

Now that we are fully dynamic, this problem mightn't be so bad, since all
you need to do is make a new libc and new /rescue.

> The people claiming those things (AFS, DFS, etc.) are broken are simply going
> to have to realize that people *do* use NetBSD in these types of environments,
> and so ripping the rug out from under them is, IMO, a non-starter.

Agreed.

Take care,

Bill