Subject: Re: integrating PAM
To: None <current-users@netbsd.org>
From: Ross Patterson <Ross.Patterson@CatchFS.Com>
List: current-users
Date: 01/23/2003 15:19:36
On Thursday 23 January 2003 02:38 pm, netbsd99@sudog.com wrote:
> I had to pare down the PAM modules involved in a login to just the unix
> auth--but at that point what was the point of having PAM in the way at all?

One point is to allow you to do exactly what you did - to easily customize 
the authentication scheme to meet local needs.  That's really all PAM is 
intended to give you: flexibility in implementation without constant 
recompilation.  In that, it's not much different from the BSD-auth scheme.  
PAM's  configuration bias is towards text files that list operations to be 
performed in a particular order, while (I believe) BSD-auth's is towards 
programs (typically shell scripts).

What is being argued here is really which flavor of Kool Aid NetBSD wants to 
drink.  Both choices seem to have their advantages and drawbacks.  That would 
seem to argue for an interface layer where the assorted zealots can choose 
their personal definition of "good" over "evil".  Since either path will 
require changes to programs that want to use authentication services, there 
will be development to do no matter what the decision.  Unless, of course, 
NetBSD decides that the only way to win is not to play the game.

> The point is that that implementation sucked ass and I'm hoping we aren't
> being led down that same garden path.

With PAM one has to be careful to measure both the interface implementation 
(i.e. libpam) and the specific modules chosen for a particular service by the 
sysadmin (e.g. the contents of /etc/pam.d/login).  There certainly are PAM 
modules available that are slow to respond, but those modules don't 
necessarily mean that the PAM implementation *itself* is bad.  It's kind of 
like claiming that BSD-auth sucks because BlahBSD ships login configured to 
dial out to Passwords R Us, play a sound file and wait for the nice lady to 
say "yes" or "no".
-- 
Ross A. Patterson
Chief Technology Officer
CatchFIRE Systems, Inc.
5885 Trinity Parkway, Suite 220
Centreville, VA  20120
(703) 563-4164