Subject: Re: integrating PAM
To: Alan Barrett <apb@cequrux.com>
From: Bill Studenmund <wrstuden@netbsd.org>
List: current-users
Date: 01/24/2003 13:42:45
On Fri, 24 Jan 2003, Alan Barrett wrote:

> On Thu, 23 Jan 2003, Jason R Thorpe wrote:
> > 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),
>
> Is it possible to enumerate the kinds of changes to the calling
> process's state that should be possible?
>
> If so, one could have a protocol for plug in modules that execute in a
> different process (a la BSD Auth) to communicate the necessary changes
> to a shim that lives inside the calling process (probably in a shared
> library).  The protocol and the shared library shim would have to change
> when new kinds of process state are added, but I hope that that would be
> rare.

The needing to change the shared library shim is why we wanted to make PAM
be the built-into-libc method. The goal was to permit adding a _totally_
arbitrary auth method to a distribution without recompiling. Since BSD
Auth requires recompiling to do that, we wanted to make PAM the built-
into-libc method, since we can then readily update the BSD Auth module if
needed.

The reason for PAM, as noted in a note to Jason, was that we want to have
SOME sort of nss-loadable-module method, and it seemed silly to have both
an nss-specific method AND PAM. PAM is a loadable-module method, so let's
just use it.

We certainly can change our minds, but these were the thoughts that went
into the current decisions. If we change our mind on what we want to do,
we should address the concerns that led us to the current view.

Take care,

Bill