[ On Sunday, September 22, 2002 at 07:43:59 (-0700), Chuck Yerkes wrote: ]
> Subject: Re: PAM
>
> One of the goals was to abstract authentication from the various
> things that needed it. At the time I had folks logging in by s/key
> , challenge/response device or Kerberos, sometimes depending on
> where they were.  The notion of PAM was a godsend.  

An abstraction like that can come in many flavours.  An implementation
requiring dynamic loading of object code is certainly not the one that
any "open" source platform need choose.  We have and want the source for
a reason!

> The implementations,
> less so.  Linux PAM != Sun PAM != FreeBSD PAM.  Alas, a lack.

Which of course only makes it even less interesting to even begin to
think of using dynamic object code loading -- none of that code can ever
be shared between platforms even on identical machine architectures.  If
you have to recompile anyway, what's the point?

> It appears okay to use, per the FreeBSD code.  It would be really
> nice to have ONE PAM implentation that works across different Unixs.
> NetBSD, being a bit marginal, would benefit from being able to snag
> PAM modules from the more mainstream OSs and have them "just work"

Well, since it is very unlikely that all the Unixes would ever agree on
using one ABI-compatible PAM implementation in the first place your
assertion is empty of meaning.  Indeed in this thread alone there have
been hints that any NetBSD implementation would only end up being API
compatible at the source level at the very best.

It would be far better for NetBSD to simply supply patches to the
authors and maintainers of open source PAM modules to make them compile
with NetBSD's existing nsswitch framework.  This should be trivial to do
and probably requires no change to NetBSD proper.  Users who need to use
some auth module that doesn't come native with NetBSD could simply grab
the source for it, drop it in the right place, and re-compile.  I.e. do
_exactly_ the same as they would have to do if it were PAM anyway!

(and of course just as can happen now there could be third-party
suppliers of ready integrated object code so that those happy to run
other's binaries could simply download and install and run them....)

-- 
								Greg A. Woods

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