[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: pam_unix_auth cleanup: NIS+ issues

On Fri, 11 Jun 1999, Olaf Kirch wrote:

> You misunderstand me. The only reason why RPC currently consults the
> effective uid is because it wants to obtain a conversation key from
> keyserv. I feel this is bad, and absolutely not necessary, in an
> authentication context.

It seems to me that your proposal makes at least as much sense as the code
that's currently in place.  I've been trying to hash out the logic that
would allow pam_unix to change euid's safely (i.e., without stranding the
application as a user it didn't really intend to be yet), given that there
is no portable way to find the saved uid (not portable meaning the method I
have won't even work on Linux 2.0).  

So far, I have 6 uid-changing calls /before/ the call to getpwnam().  This
seems excessive, at least to me, but I haven't found a way to do this more
efficiently.  The only way I can think of to clean this up would be to place
restrictions on application behavior, specifying what credentials (uids)
the application should have when making the pam_authenticate call (a
topic which I remember coming up on the list last month).  The pam_unix
module itself will work no matter what, so long as it has sufficient perms
to seteuid() to the user, but if the application isn't expecting this call,
it can (and does) seriously fubar things when pam_authenticate returns.

> My point is that the above approach does NOT require us to muck around
> with keyserv's cache /before we have authenticated the user/. And it
> avoids the seteuid business. You don't have to seteuid to user
> kukuk in order to transmit a UDP packet that has kukuk's credentials
> in it.

> How do we pass on the above information to the RPC layer? It's a bit
> of overkill to put aditional code into librpc just for this
> purpose. Alternatively, we can use a copy of authdes_clnt.c, and replace
> the keyserv part with our cooked information. This is linked into
> the PAM module. Instead of the seteuid/getspnam calls in PAM, we do
> this:

> 	AUTH	*foo;
> 	CLNT	*bar;
> 	foo = authdes_cooked_create(nisplus_serv, window, 0,
> 				netname, &conv_key);
> 	bar = clntudp_create(...);
> 	auth_destroy(bar->cl_auth);
> 	bar->cl_auth = foo;
> 	/* Call NIS+ and get the passwd */
> 	clnt_destroy(bar);

My one reservation is that, if something like this is done which checks the
password directly against the NIS+ server instead of using the NSS
interface, does this any longer belong in the module called pam_unix, or
should it be moved to a separate module?  I guess to a certain extent,
compatibility with Sun's implementation is desirable.  Just another question
to consider in all of this.

-Steve Langasek
postmodern programmer

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []