Ticket History #6569: krb5-1.7 hangs on Solaris

" Arlene Berry via RT" <rt-comment@krbdev.mit.edu> writes:


Interesting... what release of Solaris? I thought that the
thread-safe res_ninit() were available on modern Solaris releases.

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....