Okay, I've seen a whole bunch of stuff about PAM and "BSD
Authentication".  The major technical difference I see so far is that
PAM gets hold of the relevant code by dl_open()ing a shared object,
whereas BSDAuth ditto by forking and execing an external program.  Each
way has good and bad sides, a few of which have been mentioned; below,
I'll list what I can think of.

On the nontechnical side, it seems that PAM is beginning to become a
de-facto standard.  I'm not sure how much weight should be given to
that; if we go for "de-facto standard", we should just support Windows
DLLs and be done with it.  One of the things NetBSD is about, as I
understand it, is technical excellence.

On the implementation front, one person has posted a shudder at the
implementation of BSDAuth ("I would be absolutely horrified if the
BSD/os authentication stuff were incorporated into NetBSD.   I had the
misfortune of having to hack it at one point, and was amazed at the
byzantine complexity ..."); another person posted something vaguely
similar about PAM ("PAM is a good idea, but from what I've seen the
actual design isn't so hot").  Given these, I suspect we'll have to
come up with our own implementation of whatever we choose.  To the
extent that it doesn't conflict with a clean implementation, we should
try to be interface-compatible with the other implementation(s) of
whatever we choose.

To reply to a couple of specific messages.

> [PAM] certainly simplifies a lot of development for portable
> applications.

How?  Building shared objects is system-specific magic on every system
I know of that has them....

> You may want to talk to John Polstra <jdp@FreeBSD.org> about PAM vs.
> BSD Auth since he looked at both before deciding on PAM for FreeBSD

I will send a note in that direction; thanks for the pointer.

As for the good and bad sides I referred to above:

* Overhead and speed: dl_open() wins here, no question about it -
   dl_open() is much less resource-consumptive than fork/exec.

* When linked static, dl_open() can't work unless/until we redo our
   dynamic linker as a .a library for use by such applications.  (In my
   mind, doing this defeats much of the purpose of linking static; when
   I link something static I usually do it because I want a completely
   self-contained executable.)  BSDAuth wins here.

* Ease of constructing new auth methods and the flexibility available:
   BSDAuth's design wins here too, since external programs can be C,
   sh, perl, elisp, what have you, whereas new shared objects are much
   more restricted.

* Damage containment: what happens if the authentication method is
   buggy (or trojaned)?  With BSDAuth, an auth method that crashes may
   cause that auth method to fail, but that should be the worst that
   happens; with PAM, an auth method that crashes will take down the
   whole process.  With BSDAuth, the most a trojaned auth program can
   do is authenticate sessions it shouldn't; with PAM, as soon as you
   call it it can take over the whole process in toto; either is very
   bad, but the latter seems slightly worse to me.

As various people have pointed out, either method can in principle
provide a hook to support the other.

Personally, I'm leaning towards BSDAuth, as it "feels" more "UNIXy" to
me (small self-contained programs, well-defined byte-stream interfaces
on stdin/stdout, all that).  However, as either way has to have some
sort of config file driving it, I see no reason we couldn't support
both.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B