On Mon, 23 Nov 1998, der Mouse wrote:

// 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.

	Actually, I've seen a PAM GINA for Windows, so the stuff could
work there, too.

// > [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....

	The same code base can authenticate everything from web servers to
login and su on several different UNIXish systems and NT logins.  The
system specific magic is generally just a compiler option and some link
magic, which is generally simpilified by gcc, but either way, it's pretty
easy to figure out how to do it on your specific system.  I create a
single piece of code that I can use on all my Solaris machines at work,
anywhere I use a PAM GINA, and it'd be nice if I could use it on my
laptop, too (without installing Linux or Solaris on it).  :)

	This is *much* more portable than something that currently only
works on what, BSDi?

// * 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.

	What about making a static library out of the PAM module?  It
shouldn't be too hard to have a default authentication method for static
builds.

// * 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.

	Not that much...it'd be fairly easy to emulate PAM with BSD auth
or BSD auth with PAM, though, as you said, PAM would be more efficient
generally.

// * 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.

	If a trojan can be introduced, it doesn't matter either way,
really.

// 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.

	Technical superiority is nice, but I'm a huge fan of portability.
I use Solaris a lot, Solaris has been using PAM for a little while now.
I admit I've never written a PAM module, but I have built an
authentication mechanism and had to wedge it into multiple different
applications.  It gets old.

--
SA, beyond.com                            The world is watching America,
pub  1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin@spy.net>
|    Key fingerprint =  87 02 57 08 02 D0 DA D6  C8 0F 3E 65 51 98 D8 BE 
L________________________________________ and America is watching TV. __