>There are three major components of such a system which I believe
>can be discussed separately.  Namely:

>	i.   the API/ABI which is presented to the client
>	     applications needing to authenticate users,
>	ii.  the internal workings of the system including
>	     configuration and administration, and
>	iii. the API/ABI which is presented to the external
>	     authentication modules.

Sounds reasonable.

>to complete its job.  Of the aforementioned clients, all of them
>already support PAM but only some of them support BSD Auth.

>This suggests that no matter what strategy we end up taking that
>we should actually present a PAM client interface to clients of

Also sounds reasonable.

>For now, I propose that we take the following actions:

>	1.   write a PAM client interface which rather than
>	     loading .so's simply follows the same procedures
>	     as login(1),

Again, reasonable - assuming that the full API is supported.
It might be prudent to look at BSD Auth and see if any API extensions
are needed to meet its capabilities too.  While that might end up
being counter productive (a variation on a "standard") it
might be worth considering for those that want to implement a shim to 
utilize BSD Auth.

>	2.   ensure that the interface is ABI compatible with
>	     LinuxPAM,

Ok, here I get nervous.  One of the common themes from the ``PAM over my
dead system camp'' has been the quality or lack thereof of Linux PAM.
From the API perspective, how does LinuxPAM compare to BSD PAM 
(as used by FreeBSD)?  I'm more familiar with that - since we 
use it at work.  I've not looked at freebsd lately - but I 
know Juniper contributed PAM code to freebsd and so support for 
radius, tacplus, skey, ssh, opie and of course unix should all be there.

>Having the small PAM library will also enable static-only builds
>in a very straight--forward fashion.  It will not change the default
>behaviour of the system if the LinuxPAM pkg is not installed.

Sounds good.

Thanks
--sjg