Subject: Re: PAM
To: NetBSD-current Discussion List <current-users@NetBSD.ORG>
From: Gary Thorpe <firstname.lastname@example.org>
Date: 09/22/2002 19:22:50
--- "Greg A. Woods" <email@example.com> wrote:
> [ 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
> 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; <firstname.lastname@example.org>;
> Planix, Inc. <email@example.com>; VE3TCP; Secrets of
> the Weird <firstname.lastname@example.org>
What about systems that CANNOT be rebooted every time
you want to add capabilities? Reconfigure and
reboot...sounds like Windows, not UNIX (at least not
In an ideal situation, clients should not have to have
code compiled into them to do authentication
(statically or dynamically linked): they would only
ask some system oracle and the only code they would
need is that which is necessary to "ask the question":
e.g. "I need to authenticate a user at this time from
this location for this service." and a response being
"Access granted" or "Access denied" etc.
Post your free ad now! http://personals.yahoo.ca