[ On Saturday, September 6, 2003 at 20:08:04 (-0500), Peter Seebach wrote: ]
> Subject: Re: BSD Authentication 
>
> I don't think either can be done in terms of the other; each has features
> the other can't implement, so a mod_bsdauth.so for PAM wouldn't let you do
> everything that libbsdauth and a program which supported it would do, and
> vice versa for /usr/libexec/login_pam.

While that's clearly true in the most strict sense, let us remain very
clear that there's really absolutely nothing at all, as far as pure
technical features go, that PAM can do which is truly necessary to use
any known authentication mechanism where PAM is now used.

I.e. all of the technical features that have been used as arguments to
support the need for PAM are strictly unnecessary as each feature can be
implemented in some quite simple and equally effective alternative way
by BSD Auth (at least that's proven true for everything including AFS so
long as one's willing to add new system calls).

You said yourself very well:

    Basically, PAM lets me do *anything* in an auth module.  Call setproctitle().
    Spawn child processes.  Scan process memory space for interesting data and
    save it somewhere.  Anything I want.

    BSD Auth gives me a firewall between each new authentication method and the
    program invoking it.

It's pretty damn hard for any well defined and highly specific mechanism
to compete with the "I can do anything I want" capability, but what I'm
trying to show is that it doesn't have to.

The one and only known "feature" PAM offers which BSD Auth cannot
directly offer itself, by definition, is support for proprietary
software vendors who only provide loadable PAM object modules (i.e. they
don't provide source).  However you've suggested that even this
non-technical feature of PAM might be supported sufficiently well with a
BSD Auth wrapper that interfaced to PAM.

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>