[281] in Kerberos-V5-bugs
Re: kadmin and multiple realms.
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Sat Jan 16 00:55:55 1993
Date: Sat, 16 Jan 93 00:55:36 EST
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
To: Rocky - Rakesh Patel <rapatel@theophilus.rutgers.edu>
Cc: marantz@klinzhai.rutgers.edu, gmachin@somnet.sandia.gov,
Cc: krb5-bugs@MIT.EDU
In-Reply-To: Rocky - Rakesh Patel's message of Thu, 14 Jan 1993 19:36:33 -0500 (EST),
Date: Thu, 14 Jan 1993 19:36:33 -0500 (EST)
From: Rocky - Rakesh Patel <rapatel@theophilus.rutgers.edu>
I found a solution that is generic enough to use without affecting
normal usage. I eliminated the keyproc and keyprocarg from
krb5_recvauth(), and ended up having kadmind not find any
keys for changepw/kerberos. This was because the default keytab
file was (/etc/v5srvtab), which meant I needed to add the service
keys into the servers v5srvtab. Once I traced down all the code,
I found that out and added in the service keys, and did the trick, as
rd_req_dec() uses the remote server principal to determine the service
key to fetch and feeds it to krb5_kt_get_entry().
I really would have preferred having it fetched from the database, but
that would probably mean adding in changepw/kerberos specific conditions
in rd_req_dec(). As it is, I have to update adm_process() to call
krb5_recvauth() without the keyproc only if the server is serving
more than one realm.
Any comments or suggestions on this hack?
Yup: Ick. :-)
If it weren't for how the rcache is initialized, it would be be possible
to pass NULL as the server to krb5_recvauth(), and have it do the right
thing. It's too late and I'm too tired to do it now, but it won't be
too hard to fix krb5_recvauth() so that you can pass a null server to
it. I'll put it on my todo list.
Note that once this is done, if the passed in server is NULL, it is the
responsibility of the krb5_recvauth()'s caller to make sure that the
server actually used by the client was an appropriate one and not one
from outer space.
- Ted
