[krbdev.mit.edu #6569] krb5-1.7 hangs on Solaris

[Ken Raeburn via RT]

Finding a thread-safe way of using the resolver would be better that  
locking around it within the Kerberos library, since the application  
may use it in other threads at the same time.  It looks to me like  
there should be a workaround, thanks to Sun, but other OSes still  
using such old versions of BIND (are there any such that we still care  
about?) may still have problems.  I'd consider using Sun's helper  
functions, if the early Solaris 8 releases are to be supported...

Some possibly useful references:

http://opensolaris.org/sc/src/iser/iser-on/usr/src/lib/nsswitch/dns/common/dns_mt.c

Several comments discussing thread safety in various versions of BIND  
and the Solaris modifications to it, starting with BIND 8.1.2.   
Apparently Sun's modifications included functions that "enabled and  
disabled MT mode per-thread" for BIND 8.1.2, but weren't needed later  
in 8.2.2.  I'm not sure if that means the new BIND code was entirely  
thread-safe, or just some parts that Sun cared about.

http://docs.sun.com/app/docs/doc/806-7502/6jgce020l?a=view

"Berkeley Internet Name Domain (BIND) has migrated from version 8.1.2  
to 8.2.2 in the Solaris 8 4/01 release."  So before that they were  
using 8.1.2; with the 4/1 release and later, BIND should apparently be  
thread-safe.

http://developers.sun.com/solaris/articles/using_etc_release.html

There were a few releases of "Solaris 8" before the 4/1 release, as  
well as a few after.

http://www.cert.org/advisories/CA-2001-02.html

The info from Sun in the vendor section suggests that BIND 8.1.2 was  
used back in Solaris 7, so I'm guessing it may have been in the  
initial Solaris 8 release.  I could be wrong, if it was put in as a  
later update to both 7 and 8.

http://www.ops.ietf.org/lists/namedroppers/namedroppers.199x/msg03798.html

BIND 8.2 added the "nearly-thread-safe resolver API", so if there are  
thread safety issues it seems likely Arlene is using 8.1.2.  (And 8.2  
is also when getaddrinfo was added, so our fake one is probably being  
used still.)

Ken

P.S.  There's also the route of just saying, "We assume X, Y, and Z  
facilities on your OS are thread-safe; if not, then the Kerberos  
libraries will not be thread-safe either."  And encourage the use of  
OS updates that implement thread safety for routines POSIX says should  
be thread-safe.  In early NetBSD releases, we knew this was an issue  
around getaddrinfo(), for example.  In this case, there are OS updates  
available that fix the thread safety problem, and updating to Solaris  
9 or 10 isn't even required.  But it may still be too much of an  
imposition....