begin  kpneal@pobox.com quotation.
> >   What is the problem that PAM is meant to solve?

> when given a (login,password) tuple, verify that the login and password
> match. 

see getpwnam(3) and nsswitch.conf(5), an architecture which exists on the 
same systems that purport to need PAM, and already accomplishes the purpose 
you mentioned.

The one thing PAM adds over nsswitch is the ability to swap out password 
ciphers as well.  But, even this doesn't go very far.  If you want S/Key 
to work with both login(1) and xdm(1), PAM's ``abstraction'' becomes a 
nuissance rather than an aid.

You do not need the PAM architecture to shadow passwords, put passwords 
in a db(3) database, use NIS or Hesiod, or add new code to store the 
user database in a SQL backend.  libc can do all these things.

so, once again, What is PAM for?

> PAM simply saves having to touch n-squared server-side programs 

again, so does putting nameservice routines in libc.  but, why n^2 rather 
than n?

> your MVS sounding RACF-like scheme cannot solve those exact same issues
> either. 

I never said it could.  I only said it was a very naive and 
quickly-constructed architecture that is much better than PAM, and that 
one of the biggest advantages of my architecture over PAM is that its 
limitations are obvious.

What can PAM do that my architecture can't?  It takes a little while to 
convince yourself that the answer is ``nothing''.  That little while 
you spend convincing yourself is the main reason my architecture is 
better than PAM.

Using neither PAM nor my architecture accomplishes the same thing, once 
you understand that PAM is absent because it's useless and not because 
no one has bothered to add it.  People continue to get confused about 
this last point.

> No single layer of abstraction can [...] That doesn't make a layer 
> [...] bad or useless or dumb.

It is a strawman argument only if you complete the enthymeme, ``Only 
architectures which can X, Y, and Z are Good.  Therefore, PAM which 
cannot do these things is Bad.''  That was not the completion I intended.  
I suspect that _nothing_ can X, Y, and Z, which is why I said, ``flawed 
problem statement.''

Layers of abstraction with no clear purpose or problem-statement do more 
harm than good.  They confuse people, which is bad because those same 
people go off to design other foolish architectures.  They also waste 
time for people who just want to get stuff done.

My point was not merely that PAM can't do a lot of things that need to be 
done.  Rather, the _existence_ of PAM makes people think it can do things 
that it can't do---if PAM can't make adding a biometric scanner easier, 
then why would anyone use it?  so, surely it must do that.  It doesn't.

You are burdened not only with showing that PAM can Do Things.  Of course 
it can.  To show that PAM is Good, you must show that it's easier to Do 
Things with PAM than without.  I don't think you can show this.  To show 
that PAM belongs in NetBSD, you must even further show that PAM is a 
``reasonably sane'' way of Doing Things.  I'm absolutely positive you 
can't show _that._