[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#550428: marked as done (getaddrinfo: AI_CANNONAME should not do PTR lookups)

Your message dated Thu, 5 Jun 2014 23:25:24 +0200
with message-id <20140605212524.GA17498@volta.rr44.fr>
and subject line Re: getaddrinfo: AI_CANNONAME should not do PTR lookups
has caused the Debian Bug report #550428,
regarding getaddrinfo: AI_CANNONAME should not do PTR lookups
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
550428: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550428
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: libc6
Version: 2.7-18
Severity: normal


I'm reporting essentially a duplicate of this old bug:
  http://sources.redhat.com/bugzilla/show_bug.cgi?id=304

That bug is marked "resolved" but it clearly isn't resolved, since
getaddrinfo() still has a __gethostbyaddr_r() call in it (see
sysdeps/posix/getaddrinfo.c). This bug isn't resolved until that code is
dead! As far as I can tell, that code is still present in the newest glibc
and eglibc too.

Here's a little demonstration, with actual DNS records that exist today:

mail.gnu.org.		300	IN	A	199.232.76.166
166.76.232.199.in-addr.arpa. 23360 IN	CNAME	rev-c76-166.gnu.org.
rev-c76-166.gnu.org.	300	IN	PTR	mail.gnu.org.
rev-c76-166.gnu.org.	300	IN	PTR	mx10.gnu.org.
mx10.gnu.org.		300	IN	A	199.232.76.166

mail.gnu.org does not have a CNAME record. If you ask for the canonical name
of mail.gnu.org, the correct answer is mail.gnu.org. But glibc does a reverse
lookup, picks one of the PTRs at not-quite-random, and half the time you get
mx10.gnu.org instead:

$ cat canon.c
#include <stdio.h>
#include <sys/socket.h>
#include <netdb.h>

int main(void)
{
  struct addrinfo *res, hints={.ai_family=AF_INET, .ai_flags=AI_CANONNAME};
  int err;

  puts((err=getaddrinfo("mail.gnu.org", NULL, &hints, &res)) ?
       gai_strerror(err) : res->ai_canonname);
  return err;
}
$ cc canon.c -o canon
$ ./canon
mx10.gnu.org
$ ./canon
mail.gnu.org
$ ./canon
mx10.gnu.org

Neither mx10.gnu.org nor mail.gnu.org is the canonical name of the other. No
such relationship exists between those 2 names, and no such relationship can
ever be implied by any PTR records. glibc's behavior is completely bogus.

I believe a correct fix would be to reduce that entire block containing the
__gethostbyaddr_r() call to just these 2 lines:
  if (canon == NULL)
    canon = orig_name;

But there's a sign that may not be enough. Each time I run the demo program
above, it generates the bogus PTR query twice. I wonder if removing the
__gethostbyaddr_r will take care of both of them, or if there's a similar bug
in the nss_dns module.

-- System Information:
Debian Release: 5.0.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: powerpc (ppc)

Kernel: Linux 2.6.31.2
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages libc6 depends on:
ii  libgcc1                      1:4.3.2-1.1 GCC support library

libc6 recommends no packages.

Versions of packages libc6 suggests:
ii  glibc-doc                     2.7-18     GNU C Library: Documentation
pn  locales                       <none>     (no description available)

-- debconf information:
* glibc/upgrade: true
  glibc/restart-failed:
* glibc/restart-services: rsync openbsd-inetd lpd cron atd

--- End Message ---
--- Begin Message --- 
Version: 2.19-1

On Fri, Oct 09, 2009 at 07:22:28PM -0500, Alan Curry wrote:
> Package: libc6
> Version: 2.7-18
> Severity: normal
> 
> 
> I'm reporting essentially a duplicate of this old bug:
>   http://sources.redhat.com/bugzilla/show_bug.cgi?id=304
> 
> That bug is marked "resolved" but it clearly isn't resolved, since
> getaddrinfo() still has a __gethostbyaddr_r() call in it (see
> sysdeps/posix/getaddrinfo.c). This bug isn't resolved until that code is
> dead! As far as I can tell, that code is still present in the newest glibc
> and eglibc too.
> 

This bug has been fixed in version 2.19-1. Closing the bug for this 
version.

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

--- End Message ---
Reply to: