[1666] in Kerberos-V5-bugs
Re: beta-5.75 krshd compiled with v4 compatibility isn't from Linux to AIX
daemon@ATHENA.MIT.EDU (Sam Hartman)
Thu Oct 12 20:20:22 1995
To: Mark Eichin <eichin@cygnus.com>
Cc: hartmans@MIT.EDU, krb5-bugs@MIT.EDU
In-Reply-To: Your message of "Thu, 12 Oct 1995 11:42:37 EDT."
<199510121542.LAA11906@tweedledumber.cygnus.com>
Date: Thu, 12 Oct 1995 20:20:01 EDT
From: Sam Hartman <hartmans@MIT.EDU>
>>>>> "Mark" == Mark Eichin <eichin@cygnus.com> writes:
Mark> Right now we have a one-way dependency (in the MIT code):
Mark> compat_recv (sendauth compatibility) in libkrb5 requires
Mark> things from libkrb4. In the Cygnus tree, we've also got a
Mark> dependency from libkrb4 to util/profile (in order to find
Mark> krb.conf/krb.realms/v4srvtab in a controllable way) but
Mark> except for aklog, any program that uses libkrb4 already has
Mark> the profile code pulled in by other things in libkrb5, so I
Mark> wasn't concerned about that. I was expecting to put this
Mark> code in the MIT tree unless we figured out how to do the
Mark> srvtab conversion.
A one-way dependency is fine; you build libkrb4 before libkrb5
and link that way when you do the shared libraries. If you have a
two-way dependency there is no generally portable shared library
solution. If we could make libkrb4 dependent on libkrb5 and remove
all dependencies from libkrb5 on libkrb4, then this would also work.
Note that since the profile code is in libkrb5, in order to integrate
your change, we either need to make a shared libprofile and pull out
the code or significantly complicate the shared library build.
Mark> One fix to consider is to put compat_recv et.al. *in*
Mark> libkrb4, so that libkrb4 *always* precedes libkrb5.
Mark> I'm surprised and concerned about the libkrb4 sendauth
Mark> problem you mention, it's probably some subtle interaction
Mark> (as libkrb4 is based on working CNS V4 code.) A send_to_kdc
Mark> error is somewhat strange in that context...
Not really; sendauth calls krb_mk_req, which can get tickets if you don't have them.
--Sam
