Bug 205243 - gethostbyname2 queried with AF_INET6 (IPv6) return ok with IPv4 address
gethostbyname2 queried with AF_INET6 (IPv6) return ok with IPv4 address
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: nss_ldap (Show other bugs)
4.8
All Linux
urgent Severity urgent
: rc
: ---
Assigned To: Nalin Dahyabhai
Ondrej Moriš
: ZStream
Depends On: 651364
Blocks: 602966
  Show dependency treegraph
 
Reported: 2006-09-05 11:26 EDT by Albert Fluegel
Modified: 2011-02-16 09:00 EST (History)
10 users (show)

See Also:
Fixed In Version: 253-12
Doc Type: Bug Fix
Doc Text:
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.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-02-16 09:00:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Testcase as mentioned in bug report (850 bytes, text/plain)
2006-09-05 11:29 EDT, Albert Fluegel
no flags Details
Patch to fix the gethostbyuname2 bug in nss_ldap (353 bytes, patch)
2006-09-05 11:31 EDT, Albert Fluegel
no flags Details | Diff

  None (edit)
Description Albert Fluegel 2006-09-05 11:26:04 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.0.5) Gecko/20060719 Firefox/1.5.0.5

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

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
_nss_ldap_gethostbyname2_r :

#ifndef        INET6
  if(af == AF_INET6)
    return NSS_NOTFOUND;
#endif

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
inet_pton(AF_INET,...) fails)


Version-Release number of selected component (if applicable):
nss_ldap-226-13.i386.rpm

How reproducible:
Always


Steps to Reproduce:
Case A:
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
Case B:
1. and 2. see above
3. run with a host, that is not in /etc/hosts: getent hosts <hostname>

Actual Results:
Case A:
prompt# ./gethostent2 cliff18
Official Name:
cliff18.muc.infineon.com
Aliases:
cliff18
IPv4 (found IPv6) Address:
172.23.4.92

Case B:
prompt# getent hosts cliff19
636c:6966:6631:3900:636c:6966:6631:3900 cliff19.muc.infineon.com 
prompt# getent hosts cliff19
172.23.4.17     cliff19.muc.infineon.com cliff19

(the 2nd time the output is ok)


Expected Results:
Case A:
Output:
Official Name:
cliff18.muc.infineon.com
Aliases:
cliff18
IPv4 (found IPv4) Address:
172.23.4.92

Case B:
expect correct output at first call of getent


Additional info:
Comment 1 Albert Fluegel 2006-09-05 11:29:34 EDT
Created attachment 135570 [details]
Testcase as mentioned in bug report

See bug report
Simply compile with
gcc gethostent2.c -o gethostent2 [ -g ]
Comment 2 Albert Fluegel 2006-09-05 11:31:07 EDT
Created attachment 135571 [details]
Patch to fix the gethostbyuname2 bug in nss_ldap
Comment 3 Albert Fluegel 2006-11-06 10:17:16 EST
lukeh@padl.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 )
Comment 4 Karsten Weiss 2009-08-19 05:12:27 EDT
I can still reproduce the getent problem on 5.3 with nss_ldap-253-17.el5 - but only if nscd is enabled.
Comment 5 Karsten Weiss 2009-08-19 10:46:37 EDT
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)
Comment 9 Chris Ward 2009-10-21 05:43:05 EDT
@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.
Comment 10 Albert Flügel 2009-10-21 05:54:04 EDT
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.
Comment 11 Chris Ward 2009-10-21 06:11:54 EDT
Perfect. Thanks.
Comment 13 Eduard Benes 2009-10-21 07:55:13 EDT
(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?
Comment 19 Karsten Weiss 2009-10-25 10:53:45 EDT
Chris, if you provide a RPM I could test as well. (Eduard, as far as I remember it was a separate issue.)
Comment 21 Chris Ward 2009-10-26 04:50:09 EDT
@Karsten, 

Once there is a test build available, we'll get it to you for testing. At this time there's nothing available.
Comment 25 Albert Flügel 2009-11-03 11:39:06 EST
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.
Comment 26 Albert Flügel 2009-11-04 03:54:09 EST
Opened Bug 532892 for the segfault of getent -s ldap hosts
Comment 28 Ondrej Moriš 2010-07-08 07:26:19 EDT
RHTS test proposed, see QA whiteboard.
Comment 29 Jaromir Hradilek 2010-07-16 10:28:12 EDT
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.

New Contents:
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.
Comment 37 errata-xmlrpc 2011-02-16 09:00:18 EST
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.

http://rhn.redhat.com/errata/RHBA-2011-0239.html

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