Thus spake Greg A. Woods ("GAW> ") sometime Today...

GAW> Nsswitch is not sufficient on its own, dynamic or otherwise.  It still
GAW> leaves us with just a way to pull username/crypted-passwd strings and
GAW> the other associated account information from run-time configurable
GAW> sources.  I.e. it still leaves us stuck with just secret passwords and
GAW> many #ifdefs everywhere for anything and everything else.  I.e. nsswitch
GAW> still needs some way to allow the choice of authentication test to be
GAW> configured at runtime, and that's exactly what BSD Auth does, and only
GAW> what BSD Auth does.  I.e. it fills a currently void niche in NetBSD.

I'm not a big fan of PAM, but I see what needs to be accomplished.
The light went on as soon as I fully understood the difference between
authentication (which is easy and is a read-only operation) and
authorisation (which is the write-half of the process, which is trickier
because it needs to be able to modify the credentials of the process).

As long as we focus only on authentication, the requirements for one,
the other, or both are not as clear.  Once we integrate authorisation
into the requirements, it becomes clearer as to why different solutions
are desired.

We need to accept the following:

BSD Auth / PAM won't work 100%.
PAM / BSD Auth won't work 100%.
Static lookups won't work 100%.
Switch lookups won't work 100%.

Static and switch can share code; BSD Auth and PAM probably can't, even
though there may be similar methodology involved.

The solution is to implement BSD Auth and PAM separately, with some
overlap possible once all is said and done, but make sure they
each work as they need to individually.

A totally different issue involves allowing a mix of static/dynamic
linking.

For the PAM folks:  Keep in mind that even if we do implement PAM, there
are third parties out there who have proprietary modules.

["But we can handle just doing object modules, that's fine."]

For i386 and possibly SPARC, sure; what about the other CPU architectures
that we support?  They're dead in the water.  I will grant that this is
an orthogonal issue, but it's something to consider.  (Not that we could
do much about it except possibly write an i386 emulation layer (um...ew?)).

The same problem might exist WRT BSD Auth, except I haven't heard of too
many companies writing BSD Auth modules.  If OpenBSD (*gasp* don't say
that!) does well (seeing as they are more interested in marketing share
than we seem to be (which isn't a bad thing (damn, I'm rambling this
morning!))), perhaps more third parties will become interested in doing
BSD Auth modules.

Sorry for the rambling.  The news of the day has set my mind awhir.

				--*greywolf;
--
"I didn't get where I am today without using NetBSD."