We need to consider or perhaps reconsider the idea of importing
and/or implementing a system which allows users to use alternate
authentication systems and that allows third party applications to
use whatever authentication systems that are defined.  So far the
debate has generally been between PAM and BSD Auth.

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.

So far all debates on this topic have in general not made such a
separation.  I believe that it is an important distinction without
which we will not be able to reach any sort of agreement or even
be able to have a rational discussion.

The client API/ABI will be the mechanism which various applications
such as login(1), xdm(1), xlock(1), sshd(1), gdm(1), kdm(1),
xscreensaver(1), etc. use to authenticate users.  The main
considerations for the client side API/ABI should be that it eases
support of third party applications and has enough functionality
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
the authentication system.  Or be left in the position of maintaining
client code for a growing number of third party applications.
Given our track record with adding support to third party applications
for our current hard-coded authentication system, I think that this
is a non-starter (e.g. xdm(1) doesn't support krb4, krb5 or s/key.)

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),
	2.   ensure that the interface is ABI compatible with
	     LinuxPAM,
	3.   rewrite the appropriate userland bits to use the
	     PAM client-side API, and
	4.   modify the LinuxPAM pkg so that it can effectively
	     replace our small PAM library.

In this way, we can support PAM modules for people that want them
if they just install the LinuxPAM pkg.  We also solve the problem
of having a unified authentication scheme for all of our third
party software.

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.

I've already written a good percentage of (1) and my gdm(1) is
already using it to allow me to use krb5 passwds.  It shouldn't
take more than another week to finish it up, if it makes sense as
the right way to go.

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/