It strikes me that there's a possible compromise solution...  Provide
a PAM library (solves the "player in the OS game" problem), but don't
actually make any of the system utilities use it.  Instead, create a
BSD-authenticator which speaks PAM, and make the system utilities use
BSD-auth.

The thing that really irritated me about PAM (this is a fuzzy memory
from at least three years ago) was that the external API was defined,
but I didn't see any documentation on actually creating the PAM
modules, and got the distinct impression that the internal API was
not standardized...  I.e., it would be impossible to use the same
source code to generate a PAM module for all the PAM-providing
platforms (Linux, Solaris, etc.).  Can someone correct me on this?

On Tue, Jan 21, 2003 at 12:40:31PM -0800, John Nemeth wrote:
>      There is the issue that a bug in a PAM module could cause a
> security vulnerability in all the apps that use it.  There isn't much
> that can be done about this, beyond careful coding and thorough
> testing.  This is, of course, a problem with all library routines.
> Since modules will be common and a lot of people will be using them,
> there will be lots of people to search for and fix bugs.  Hopefully,
> this will minimise them.

I don't like this line of reasoning...  It's one thing to make it in
the context of an unprivelaged application, and another thing entirely
to make it WRT security-critical code.  OTOH, I think PAM _would_ be
an improvement over what we have now, where every security module we
want to support is statically linked in, as if a problem is uncovered
in the current setup it becomes much more work for admins to patch
them.  (recompilation/reinstallation vs. just changing pam.conf to
remove the tainted library.)

--aidan