Subject: Re: integrating PAM
To: None <firstname.lastname@example.org>
From: Ross Patterson <Ross.Patterson@CatchFS.Com>
Date: 01/23/2003 15:19:36
On Thursday 23 January 2003 02:38 pm, email@example.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