[ On Friday, September 12, 2003 at 16:50:03 (-0700), Jason Thorpe wrote: ]
> Subject: Re: BSD auth for NetBSD
>
> Well, those who are proponents of BSD Auth are basically preventing 
> people from using PAM by suggesting that PAM-on-top-of-BSD-Auth is 
> workable.

Jason I'm sure that's the most bogus thing I've ever heard from you!  I
can't believe you said it!  Are you sure you're the same Jason Thorpe we
know from NetBSD circles behind that keyboard?

First off, how in heck can anything I, Peter, or anyone else have said
possibly ever prevent someone from using PAM!?!?!?!?  Do we somehow have
far more power than we ever imagined possible?  Are our mere words
somehow vexing everyone?  Have our arguments really successfully won the
majority over and we're left now with even the core developers saying,
in private obviously, that PAM is right out?  If so then "Hurray!", but
if not then what the heck are you talking about?

Secondly, how in the heck can saying that PAM via BSD Auth proxy is
possible ever even remotely be interpreted as "preventing people from
using PAM"!?!?!  I'm saying _exactly_ the opposite!  I'm saying anyone
_can_ use PAM; _and_ I'm showing how it is even feasible (for at least
the most sensible and most often expressed reasons) via a custom BSD
Auth authenticator proxy.

The only thing I've said that would not be acceptable to me for NetBSD
to implement is BSD Auth via PAM proxy.  That would not only be a total
insult to the goals and ideals of BSD Auth, but it would also make it
impossible for anyone wanting a PAM-free system to make direct use of
BSD Auth authenticators (without first integrating BSD AUth directly by
themselves).  It would also make it impossible to build a static-linked
NetBSD system (and especially one that used BSD Auth authenticators) (at
least without first going to the trouble of writing a fake dlopen() that
would simply hook in the already loaded PAM code and then hope its
authors didn't do something really stupid which caused it to fail when
their code was static linked (as some fans of dynamic linking are quite
prone to do)).

>  In fact, it is not, since BSD Auth cannot do some of the 
> things PAM can do, period.

Clearly BSD Auth cannot do some of the things PAM can do.  However that
does not mean that PAM cannot be used by way of a BSD Auth proxy.  It
also does not mean that PAM cannot be used independently of, but in
parallel with, BSD Auth by way of something like an extended nsswitch
API (and possibly via loadable nsswitch dispatch routines).

1. Peter (I think) said it most eloquently and more accurately before,
   but the fact that BSD Auth cannot do some of the things PAM can do is
   a tremendous, huge, _feature_ of BSD Auth, not a problem.  If that's
   not become obvious over all these _years_ of discussion, then I don't
   know what has.  None of us will ever even dare try to argue against
   the fact that BSD Auth cannot do some of the things PAM can do.

2. Conversely BSD Auth can do some things that PAM will never be able to
   do, such as delegation of authenticator privileges, protection of the
   caller's address space and process context from un-wanted
   interference by the authenticator (e.g. wandering pointer bugs and
   worse), and avoidance of dynamic linking.  I'm sure there are many
   more such things, but hopefully you get the point.

3. Anything that any reasonable PAM code can do to its caller can be
   done by proxy to the parent of a BSD Auth authenticator process
   unless maybe the PAM thing does something like start a separate
   thread and then expect to be able to run in that thread context until
   the process exec()s or exits (which in my books is one of the least
   reasonable things I can imagine any real PAM code ever doing, but
   what the hell I've seen some really stupid things cooked up by
   proporietary software vendors and I doubt I've seen the last of them)

Obviously proxies for PAM code are a lot more work to implement.  I'm
not claiming otherwise.  However they are clearly possible (for many, if
not most known examples of PAM code) and they make it possible to use
even third-party proprietary binary PAM code in a primarily BSD Auth
environment.

Then there's still the whole range of un-answered questions about just
who needs PAM and exactly why they need PAM for NetBSD and not some
equivalent alternative.

Nowhere yet have we seen anyone even attempt a scientific measure of the
real-world need for PAM amongst the current and the potential NetBSD
user-base.

People say they want AFS support and that they currently use PAM on
(pick-your-favourite-commercial-OS-or-linux) to make it work, but yet
AFS can quite easily be integrated into a system using BSD Auth with
only a slight modification to the existing mechanisms for registering
AFS credentials for a process group.  Is PAM support really be necessary
to make it possible for NetBSD users now using PAM on other systems to
integrate AFS support into their NetBSD systems?  What if NetBSD already
had at least the framework for AFS support by way of BSD Auth?  How many
current and potential NetBSD users would use AFS support?

People say they want support for authenticators to designate template
accounts for users authenticated by a non-local mechanism that can't be
tied into nsswitch and that they currently use PAM on (pick-your-
favourite-commercial-OS-or-linux) to make it work, but yet Peter has
shown to the apparent satisfaction of at least one such requestor that
BSD Auth can quite easily implement such a scheme.  Is PAM really
necessary to make it possible for NetBSD users now using PAM to do this
on other systems?  What if NetBSD already had such support by way of BSD
Auth?  How many current and potential NetBSD users would use template
account support?

People say they want support for proprietary, and possibly binary-only,
third-party PAM code.  Obviouly only a PAM framework of some kind can
even begin to make this possible on NetBSD without reverse engineering
and re-implementing the third-party code.  However every BSD Auth
proponent I'm aware of has allowed that it would be quite acceptable to
also include PAM support via something like a slightly enhanced nsswitch
API (assuming a proxy authenticator interface is not possible because
the vendor doesn't document what the PAM code does to its caller).
However the question here is how many current or potential NetBSD users
really need such support?  Is it even possible to maintain full ABI
compatability on any existing platform with any existing native-OS PAM
framework?  (Yes I know we have working syscall emulation for some other
operating systems, but what about native shared libraries the PAM code
might need clashing with NetBSD code the caller might need, and what
about the actual PAM ABI itself as well?)  Are any PAM proponents able
to volunteer to work on such support and help get it integrated cleanly
into NetBSD such that it can work in parallel with BSD Auth?

Almost all of these questions have been asked several times already in
this most recent discussion, either directly or implicitly, by myself
and others, and yet outside the few people talking directly about their
own requirements there have not even been any projections made of
plausible answers, especially not to the quantifiable questions!  Do we
need to re-ask over in netbsd-uers?  Does nobody have even half a guess
to any one of these questions?

-- 
						Greg A. Woods

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