On Wed, Oct 03, 2001 at 05:33:39PM -0600, Miles Nordin wrote:
> > If you implement such a system, it is up to you to
> > make shure it works with pop/telnet whatever.
> 
> It's up to me to patch my retinal scanner into telnet, pop3d, netatalk, 
> and so on.  Not up to PAM.  okay.
> 
> Here, then, is the question-of-questions for you:  
> 
>   What is the problem that PAM is meant to solve?

PAM appears to me to be meant to allow for server-side-only code sharing of
authentication functionality. Server-side ONLY. Your strawman arguments
border on silly. PAM is a layer of abstraction over top of APIs that,
when given a (login,password) tuple, verify that the login and password
match. 

PAM, and APIs built for similar tasks, simply exports an interface to
databases storing (login,password) pairs. PAM isn't meant to add
features to any existing protocol, and it cannot do anything to
client-side software. PAM simply saves having to touch n-squared
server-side programs every time a different (login,password) database 
is to be used.

If you want to use a retinal scanner then you need to write support
for it into your telnet client, your pop3 client, your netatalk client,
and "so on". If the retinal scanner needs special server-side support,
like fuzzy pattern matching or the like, then a backend can be plugged
into PAM. The retinal scanner would not be plugged directly into
your server-side applications. 

PAM cannot solve the issues you seem to be presenting here. Then again,
your MVS sounding RACF-like scheme cannot solve those exact same issues
either. No single layer of abstraction can save the world or even make 
good coffee. That doesn't make a layer of abstraction (like PAM or RACF) 
bad or useless or dumb.

If you want to knock PAM then knock PAM for what it was meant to do, not
what you want it to do. 
-- 
Kevin P. Neal                                http://www.pobox.com/~kpn/

Seen on bottom of IBM part number 1887724:
DO NOT EXPOSE MOUSE PAD TO DIRECT SUNLIGHT FOR EXTENDED PERIODS OF TIME.