Bug 129680 - Upgrading to krb5-libs 1.2.2-27 can cause undefined symbol __dn_expand
Upgrading to krb5-libs 1.2.2-27 can cause undefined symbol __dn_expand
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: krb5 (Show other bugs)
2.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-08-11 15:48 EDT by Phil D'Amore
Modified: 2007-11-30 17:06 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-08-11 16:40:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Phil D'Amore 2004-08-11 15:48:23 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030314

Description of problem:
After upgrading to krb5-libs 1.2.2-27 we found that a module we had
rebuilt from a later distro (mod_auth_kerb apache module) failed to
load and prevented apache from starting.  The error was:

[root@foo tmp]# service httpd start
Starting httpd: Syntax error on line 237 of /etc/httpd/conf/httpd.conf:
Cannot load /etc/httpd/modules/mod_auth_kerb.so into server:
/usr/kerberos/lib/libkrb5.so.3: undefined symbol: __dn_expand
                                                           [FAILED]

We originally rebuilt our apache module thinking the problem was
there.  No dice.  Then I realized that dn_expand was a resolver
routine.  After digging I found that some of the krb5 libraries like
libkrb5.so.3 and one or two others, were not linking against
libresolv.so.  This was causing the symbol to not resolve.

Version-Release number of selected component (if applicable):
krb5-libs-1.2.2-27

How reproducible:
Always

Steps to Reproduce:
1. Upgrade to krb5-libs-1.2.2-27
2.  Observe that some programs (possibly only ones that don't
themselves link against libresolv.so and therefore cause it to load)
no longer work.
    

Additional info:

I noticed that in release 25 of this rpm (not released AFAICT) a
change was made to address a problem where dns KDC discovery was not
working.  I think when this was fixed, it actually caused the krb5
libs to start using dn_expand, where it probably wasn't before.

In aclocal.m4 starting around line 557, it looks like this after all
the patches in the RPM are applied:

AC_ARG_WITH([netlib],
[  --with-netlib[=libs]    use user defined resolve library],
  if test "$withval" = yes -o "$withval" = no ; then
        AC_MSG_RESULT("netlib will link with C library resolver only")
  else
        LIBS="$LIBS $withval"
        AC_MSG_RESULT("netlib will use \'$withval\'")
  fi
  [KRB5_AC_ENABLE_DNS]
,dnl


The problem here is that the processing of --with-netlib sets LIBS,
but does *not* set RESOLV_LIB, which some of the Makefiles rely on
when they do the final link to know that -lresolv must be used. 
Adding this line:

        RESOLV_LIB="$withval"

After 

        LIBS="$LIBS $withval"

and rebuilding fixed the problem for me.

Changing the krb5-1.2.2-dns.patch in the RPM to the following seems to
clear up the issue:

--- krb5-1.2.2/src/aclocal.m4.orig      Wed Feb 28 17:06:31 2001
+++ krb5-1.2.2/src/aclocal.m4   Wed Aug 11 15:22:06 2004
@@ -560,8 +560,10 @@
        AC_MSG_RESULT("netlib will link with C library resolver only")
   else
        LIBS="$LIBS $withval"
+       RESOLV_LIB="$withval"
        AC_MSG_RESULT("netlib will use \'$withval\'")
   fi
+  [KRB5_AC_ENABLE_DNS]
 ,dnl
 [AC_LIBRARY_NET]
 )])dnl
Comment 1 Nalin Dahyabhai 2004-08-11 16:40:17 EDT
Resolving in 1.2.2-29 and 1.2.7-26.
Comment 2 Mark J. Cox (Product Security) 2004-08-31 13:30:47 EDT
An errata has been issued which should help the problem 
described in this bug report. This report is therefore being 
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, 
please follow the link below. You may reopen this bug report 
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2004-448.html

Note You need to log in before you can comment on or make changes to this bug.