KRB5_REALM_CANT_RESOLVE errors ?

[Ken Raeburn]

Christopher Burke <craznar at hotmail.com> writes:
> Its there.... I get it now, I think it does and that could definitely be a 
> show stopper. I don't have the source code to the main application - so I 
> have no way of stopping the main application using gethostbyname outside my 
> mutex.

Worst case, if your OS supports it, use something like LD_PRELOAD to
pull in a shim library that defines a bunch of names like
gethostbyname as routines that grab a lock, dlopen the system C
library, find the corresponding routine, call it, copy out the results
into thread-local storage, release the lock, and return.  But let's
hope it doesn't come to that. :-)

(And of course we don't know what C library routines are likely to be
causing the problem; I'm just using gethostbyname as an example.)

If the application code was already multithreaded, then they must have
some way of dealing with this sort of problem internally.  Is there
any chance you can take advantage of this somehow -- say, use the same
mutex locks they use for C library routines -- or are you stuck
solving it locally in the Kerberos interface?

If you've got developer time to invest into this, you could look at
the snapshots available from MIT where I've eliminated some of the
uses of gethostbyname in favor of getaddrinfo, which is supposed to be
thread-safe.  (Though I'll note that the NetBSD 1.5 implementation, at
least, is not.)  Whatever other unsafe routines might be in use in the
krb5 library we can also look at working around.  Note that some folks
at IBM are also working on the thread safety issue on a somewhat
larger scale.

Ken