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

GAW> BTW, it seems to me as though everyone who has spoken up repeatedly in
GAW> favour of having BSD Auth integrated into NetBSD is actually willing and
GAW> able and eager to help direclty in making it happen, and the sooner the
GAW> better.  Why don't those of you who are developers think about how you
GAW> might make use of these additional volunteer resources so that we can
GAW> get this integration done.  Then maybe instead of just discussing the
GAW> whole issue over and over to death we'll then have time to work directly
GAW> on the other issues that are faced by with the likes of AFS and
GAW> commercial non-source PAM modules.

A question I forgot to ask:

What ELSE, besides AFS, has the needed functionality that (currently)
only PAM supports?

Looking at it from a programmer's point of view, the requirements of
the way PAM works are absolutely abhorrent.  While I appreciate the
flexibility of, i.e. dynamically loaded modules (and shared libs
(quiet, Greg!)), I don't see that this flexibility need be foisted
in a non-flexible manner upon those who wish not to use it.

Also, I have been bitten more than enough times by PAM in the past
to make it slightly distasteful, so I would lean more positively
toward getting BSD Auth done first.  From my perception of need,
it appears that the only thing that needs PAM's functionality beyond
what BSD Auth could provide is AFS.  Unless I am not understanding
something correctly, even Radius and TACACS can work properly with
BSD Auth and not demand PAM.

The other alternative is one I've already suggested, and I recognise
its impracticalities, and that is the ability to manipulate the
cred list of a process from without.  It would, however, mitigate
completely the need for PAM.

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