Subject: Re: integrating PAM
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
From: Greywolf <greywolf@starwolf.com>
List: current-users
Date: 01/23/2003 10:55:50
On Thu, 23 Jan 2003, Ken Hornstein wrote:

[KH: >I.e. without it being a PITA, it would be *so* nice to have the options of
[KH: >
[KH: >	credauth(USER, username) -> pam.auth[USER](username) ->
[KH: >		BSD_authmod(username) -> getpwnam(user)

(don't forget the credauth(USER, username) -> getpwnam(user) option -- you
 left it out...)

[KH: I don't really have a problem with this, FWIW (as long as I'm not the one
[KH: that has to write the unspecified shim layer).  But I'm not sure how you're
[KH: going to deal with PAM's conversation functions.  But if that gets worked
[KH: out, I'm happy, BSD auth people are happy, and the "I don't want PAM on the
[KH: system even though I can't give a good reason why" people are happy :-)

...perhaps what we need is for the current nss to be expanded, one final
time, to include "pam" in its list of sought-after authentications (though
I can see an immediate problem with recursion).  In any case, do a check
for pam/nopam -- somehow -- and if pam is not specified, then the PAM
routines should never need to be loaded.

I don't quite understand the problem here with PAM stuff living in the
libraries ending up in programs:  The only place it will end up in the
program proper is if you compile with static libs.  But, hey, PAM and
statically linked binaries are not currently interoperable, so it's
really a moot point.

[KH: --Ken

				--*greywolf;
--
NetBSD: The choice of hundreds worldwide.