Red Hat Bugzilla – Bug 205243
gethostbyname2 queried with AF_INET6 (IPv6) return ok with IPv4 address
Last modified: 2011-02-16 09:00:18 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:126.96.36.199) Gecko/20060719 Firefox/188.8.131.52
Description of problem:
i think there is a small inconsistency in the nss_ldap
implementation leading to larger problems on application level
and in combination with other utilities:
nss_ldap-226-13 is built without IPv6 capabilities. I think this
is intended. When i try to a make with INET6 defined, i get errors
because the function map_v4v6_address is not available. The
function _nss_ldap_gethostbyname2_r behaves partially, as if it
was able to return IPv6 address entries: It does not return an
error, when an IPv6 entry is requested in the 2nd argument, it
silently ignores this argument and returns an IPv4 entry. This
is unlike nss_files, nss_dns, nss_nis and probably more modules.
Furthermore it contrasts to the man-page, that reads:
Glibc2 also has a gethostbyname2() that works like gethostbyname(),
but permits to specify the address family to which the address must
So passing AF_INET6 to the IPv6 unable function should always fail,
otherwise the calling environment could misinterpret the result
in the address structure as IPv6 address.
At least two programs come with the System that get confused by this,
these are nscd and getent, what leads to other problems.
nscd first calls gethostbyname2 requesting AF_INET6. gethostbyname2
returns with good status, so nscd thinks, the IPv6 lookup was
successful and passes a strange IPv6 hosts entry to the requestor.
For caching it stores the entire address structure, who contains AF_INET
as protocol specifier. Thus the next time queried, the nscd knows,
that it's a IPv4 address and the result is ok, but when the cache
gets invalid or being queried the first time, nscd delivers garbage.
getent does similar things and misbehaves in a different way: The
problem leads to an incorrectly evaluated hosts entry in nsswitch.conf .
Assume you have hosts: files ldap dns in the nsswitch and you want
to override a hosts entry in ldap with an entry with the same name
in /etc/hosts . getent makes an IPv6 lookup through gethostbyname2 .
Looking up "files" fails (no Ipv6 address !), looking up LDAP
succeeds !!!!?! and returns the IPv4 entry found there.
Basically this problem is not that severe, nonetheless the result
is not the expected one.
The fix for the problem is very small and simple: e.g. adding the
following 4 lines to the ldap-hosts.c file, start of function
if(af == AF_INET6)
As far as i have tested in a production environment it has no negative
side effects and when INET6 is defined some time in the future, it
is disabled anyway and lookup into LDAP with AF_INET6 requested, but
only IP4 address found, is being failed appropriately in the
_nss_ldap_parse_hostv6 function (through inet_pton failing - there
is a note in the man page of inet_pton, that they consider it a bug,
that "AF_INET6 does not recognize IPv4 addresses" - hope, they won't
fix this "bug", if yes, in _nss_ldap_parse_hostv6 one should in my
opinion make sure, that inet_pton(AF_INET6,...) succeeds while
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. ldap must be queried for host entries (in /etc/nsswitch.conf: hosts: files ldap dns)
2. restart nscd or invalidate the host cache, but let nscd cache (/etc/nscd.conf)
3. compile the attached program
4. run the program with the name of a host not in /etc/hosts, but in LDAP
5. see the output
1. and 2. see above
3. run with a host, that is not in /etc/hosts: getent hosts <hostname>
prompt# ./gethostent2 cliff18
IPv4 (found IPv6) Address:
prompt# getent hosts cliff19
prompt# getent hosts cliff19
172.23.4.17 cliff19.muc.infineon.com cliff19
(the 2nd time the output is ok)
IPv4 (found IPv4) Address:
expect correct output at first call of getent
Created attachment 135570 [details]
Testcase as mentioned in bug report
See bug report
Simply compile with
gcc gethostent2.c -o gethostent2 [ -g ]
Created attachment 135571 [details]
Patch to fix the gethostbyuname2 bug in nss_ldap
email@example.com has confirmed this and committed to fix it in nss_ldap254
(Bug 297, see here: http://bugzilla.padl.com/show_bug.cgi?id=297 )
I can still reproduce the getent problem on 5.3 with nss_ldap-253-17.el5 - but only if nscd is enabled.
I've rebuilt nss_ldap-253-17 with the attached patch and I can confirm that it fixes the getent problem.
Side note: We also just discovered this:
# /etc/init.d/nscd stop
nscd beenden: [ OK ]
# getent hosts nehalem1 -s ldap
(This works fine if nscd is enabled)
@knweiss, @tdsc.af, @GSS
We need to confirm that there is commitment from the
reporter(s) to test for the resolution of this request
if it is accepted into the release.
Please post a confirmation as soon as possible,
including the contact information for testing engineers.
When there is a RPM having the fix incorporated, i can test that within a few days. Cannot confirm a faster commitment, but i think 2 or 3 days should suffice, thinking about how long this case is hanging around now.
(In reply to comment #5)
> I've rebuilt nss_ldap-253-17 with the attached patch and I can confirm that it
> fixes the getent problem.
> Side note: We also just discovered this:
> # /etc/init.d/nscd stop
> nscd beenden: [ OK ]
> # getent hosts nehalem1 -s ldap
> Segmentation fault
> (This works fine if nscd is enabled)
Is is a separate/new bug? (=> file it please)
Or introduced by the patch?
Chris, if you provide a RPM I could test as well. (Eduard, as far as I remember it was a separate issue.)
Once there is a test build available, we'll get it to you for testing. At this time there's nothing available.
I think the segfault with -s ldap is a different bug. It happens on RedHat-EL3, too, but the bug reported in this issue strikes on EL4 and higher, not on EL3. But until now i did not find any time to investigate the -s ldap problem.
Opened Bug 532892 for the segfault of getent -s ldap hosts
RHTS test proposed, see QA whiteboard.
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
Being built without the Internet Protocol version 6 (IPv6) support, when the "gethostbyname2()" function was used, nss_ldap used to return the Internet Protocol version 4 (IPv4) address even though the IPv6 had been requested. With this update, nss_ldap produces the expected output.
An advisory 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 therefore 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.