On Thursday 23 January 2003 12:19, Ross Patterson wrote:
> 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. 

It was technically in the way, it prevented me from logging in at console, and 
cost me a day or two in tracking down what exactly was the problem and why it 
showed up just at that instant.

I'm not sure why you might call that "easy customization."

In fact, the point was that I had to *recompile* every utility to stop using 
that particular PAM just to get the system to point where it was comfortably 
usable again. Seems to me that's evidence of that particular PAM 
implementation not meeting local needs.

> That's really all PAM is 
> intended to give you: flexibility in implementation without constant 
> recompilation.

Didn't save me the recompile.

> 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.

I'm just saying I'd prefer not to drink from the cups laced with cyanide. I'd 
prefer not to do an update one day, find it works in my test environment, put 
it out into production and suddenly have hundreds of angry customers to deal 
with, as I once did with "that other" PAM implementation.

If we do go PAM--*please* don't follow the lead of whatever PAM is included 
with RedHat. That flaming pile of hot garbage still makes my knees weak when 
I talk about it.

> Unless, of course, 
> NetBSD decides that the only way to win is not to play the game.

Sounds good to me!

> > 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). 

... and here's yet one more thing that'd need to be carefully configured in a 
commercial environment.

> 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. 

If a unix auth module whose only role is to read in and parse flat files is 
slow as hell, is bundled with a PAM implementation, and is written by the 
same programmers, what makes you assume the rest of the code in that PAM 
implementation is any better?

I have personal experience that the one on RedHat was shyte: I ended up having 
to modify some of the authentication on my NetBSD machines, and similarly the 
authentication on the PAM-i-fied RedHat hell-beast. Which one do you think 
made me thank god I run NetBSD at home, and which one do you think made me 
curse the day I was forced to slog through fugly PAM source?

> 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".

No it's not. But that's a funny hyperbole nonetheless.

Look, all I'm saying is that every implementation I've seen or heard about so 
far sucks, from which I (perhaps incorrectly) infer that the complex design 
might be part of the culprit.