Bug 4980

Summary: gethostbyname() etc break for /etc/hosts with both ::1 and 127.0.0.1 localhost entries
Product: glibc Reporter: Petr Baudis <pasky>
Component: libcAssignee: Ulrich Drepper <drepper.fsp>
Status: RESOLVED FIXED    
Severity: normal CC: 1asfjwejafwea, netjoker45, petteri.pasila, vapier
Priority: P2 Flags: fweimer: security-
Version: unspecified   
Target Milestone: ---   
Host: Target:
Build: Last reconfirmed:
Bug Depends on:    
Bug Blocks: 5460    
Attachments: getaddrinfo fix for 2.6.1/2.7
test case for IN6_IS_ADDR_V4COMPAT

Description Petr Baudis 2007-08-29 17:03:56 UTC
On Nov 20 a change in nss/nss_files/files-hosts.c:LINE_PARSER was
introduced to treat ::1 the same way as 127.0.0.1. A lot of Linux systems have

        127.0.0.1       localhost
        ::1             localhost

in their /etc/hosts (though most have ip6-localhost for ::1 instead).

The new behavior appears not to be mandated by any standard nor does it seem as
a particularily useful change.

The trouble is that now gethostbyname() (gethostbyname2(), getaddrinfo(), ...)
will return duplicate 127.0.0.1 records in h_addr_list[] and some applications
do not explect duplicate entries in this array (e.g. OpenLDAP). The new
behaviour does not seem to gain anything so the old behavior should be restored.
Comment 1 Ulrich Drepper 2007-08-29 17:31:57 UTC
Of course it gains something, otherwise it would not have been added.  And
programs which don't handle multiple addresses are simply broken and must be
fixed anyway.  Stop defending broken code.
Comment 2 Petr Baudis 2007-09-05 00:56:51 UTC
I'm not trying to defend broken code and application fix makes sense if this
change brings benefits. However, even if I trust your judgement, you didn't
explain the gain of the change in the changelog entry, commit message, in-code
comment, or anywhere else I've searched. Can you please at least explain it in
this bug entry?
Comment 3 Ulrich Drepper 2007-09-23 16:07:13 UTC
Stop reopening bugs.  Search the web if you want an explanation, I don't have
anything handy and certainly have no interest in writing it up.
Comment 4 Petr Baudis 2007-09-23 20:59:16 UTC
I have tried to search the web already and found nothing. If you want to close
bugs as INVALID/WORKSFORME, please provide a proper explanation.
Comment 5 Ulrich Drepper 2007-09-23 22:42:21 UTC
Strange, I never saw your name on my paycheck.  Since if that's not the case you
cannot order me around.
Comment 6 Petr Baudis 2007-09-24 00:33:03 UTC
But you cannot order me either.

The bug still exists. getaddrinfo() returns fabricated records for AF_INET
localhost that aren't specified in /etc/hosts at all.
Comment 7 Ulrich Drepper 2007-09-24 03:04:38 UTC
There is no bug.  Stop reopening.
Comment 8 Howard Chu 2007-12-01 20:09:51 UTC
(In reply to comment #3)
> Stop reopening bugs.  Search the web if you want an explanation, I don't have
> anything handy and certainly have no interest in writing it up.

I've found no discussion of this change on any of the glibc mailing list
archives, after searching through September-November 2006 on libc-announce,
libc-hacker, libc-alpha, glibc-cvs, or glibc-bugs. I think it's fair to say that
if you don't want people to keep asking stupid questions, a little more
documentation of your rationale will help.

The CVS log entry is useful, at least:

Support IPv6-style addresses for IPv4 queries if they
can be mapped.

But your implementation violates RFC2553: http://www.ietf.org/rfc/rfc2553.txt
Page 25:

      Also note that the
   IPv6 hex addresses "::" and "::1" MUST NOT be treated as IPv4-
   compatible addresses, ...

   Also for the macro in section 6.7 IN6_IS_ADDR_V4COMPAT MUST return
   false for "::" and "::1".

I.e., the RFC specifically forbids the mapping of the IPV6 loopback address to
IPv4. As far as I can see, the current glibc behavior here is a bug.
Comment 9 Howard Chu 2007-12-14 03:31:15 UTC
Treating the IPv6 loopback address this way violates RFC2553.
Comment 10 Ulrich Drepper 2007-12-14 03:52:57 UTC
Stop reopening the bug.  If you want explanations pay somebody.
Comment 11 Mike Frysinger 2008-04-09 19:12:17 UTC
i could have sworn glibc was an FSF/GNU project which meant open source.  but
apparently i'm mistaken.  if you want anything out of glibc, you've got to pay
for it.  awesome!
Comment 12 Sylvain BERTRAND 2008-04-10 09:36:26 UTC
If I understand well, and since firefox 3 gave me trouble with this, I reckon
that the fix should go in firefox 3:
When using the glibc resolver for a name resolution, firefox has to parse all
the entries returned and look explicitely for the entries with the address
family it wants to use (and being careful of IPv6 mapped IPv4 addresses!).
Comment 13 Tero Pelander 2008-04-15 06:13:33 UTC
Created attachment 2693 [details]
getaddrinfo fix for 2.6.1/2.7

>Of course it gains something, otherwise it would not have been added.	And
>programs which don't handle multiple addresses are simply broken and must be
>fixed anyway.	Stop defending broken code.

Seems you haven't cheked the code lately. I'll give you real life example
explaining why the mistake of thinking that all hostnames that resolve to ::1
also resolve to 127.0.0.1 is causing big problems to users.

I have ldap hosts defined as:
	localldap.example.org ldap1.example.org ldap2.example.org
As I'm using TLS I must use hostname instead of ip-number.
File /etc/hosts contains following
	::1		localhost localldap.example.org
	127.0.0.1	localhost
As ldap services contain important data it is protected by internal 
firewall. The firewall accepts connection to ldap port from  ldap-master 
and ::1. The reason for using localhost with ldap is that ldap is 
started as early as possible in boot to provide user information. It is 
started before any network other then localhost.

Now as glibc-implementation of getaddrinfo() was changed the first 
connection is done to 127.0.0.1. Firewall blocks this connection and 
after timeout of 15 seconds the connection is tried to ::1. At that 
time it succeeds.

As you can see the program definately can support multiple addresses 
form getaddrinfo() and can hardly be considered buggy.

As OSS camp often says: "talk is cheep, show the code". I have added a fix that
I have verified to work under 2.6.1. The code in question is identical in 2.7.
Comment 14 Tero Pelander 2008-04-15 06:20:01 UTC
Program that is specifically bound to "::1" can't be connected by calling
"127.0.0.1". Check the attachement.
Comment 15 Ulrich Drepper 2008-04-15 14:20:09 UTC
Stop reopening bugs.  There is nothing which is going to change here until we
have unified lookups.
Comment 16 Howard Chu 2008-06-18 19:26:14 UTC
(In reply to comment #10)
> Stop reopening the bug.  If you want explanations pay somebody.

I don't need an explanation at this point, your position here clearly goes
against established standards (RFC2553). There is no valid justification that
you could give. At this point you just have to commit the fixes that have been
provided for you.
Comment 17 Dave Houston 2008-07-07 05:05:25 UTC
Paid $1 via paypal.  Trans ID 3H4989806A1962407

Please fix.
Comment 18 Ulrich Drepper 2008-07-07 05:57:12 UTC
Dammit, stop opening the bug.  It is obvious that you know *NOTHING* about the
issue at hand.  Otherwise you would have noticed that this code has been
entirely rewritten in the current code.  It uses a very different implementation
which allows to handle this situation differently.
Comment 19 Thorsten Glaser 2008-07-07 20:30:01 UTC
So is this a good representation of the GNU project's style of
development, quality control, etc? I don't know if this has good
PR effects for you.

To an outsider, this looks like:

- I bind to localhost, AF_INET6. Someone tries to contact me via
  a symbolic hostname "localhost" and fails because AF_INET is tried
  first. (What if both are bound by DIFFERENT programmes?)
- I ask GNU libc for the contents of /etc/hosts, and it lies to me
- This breaks an RFC, deliberately
- without explanation
- the author of the breakage admits "it's fixed in the current
  development version" yet claims it's no bug (nōn sequitur!)

Nice style, too: break something, say "we fix it by rewriting the code
soon anyway". Why did you then break it in a released(!) version in the
first place? Does GNU libc not care about preserving compatibility at all?
Comment 20 CH 2008-07-07 20:58:59 UTC
FYI: A) This bug is has made it to reddit, your famous! and B) Everyone's gonna
think Ulrich Drepper is an arse who refuses to actually explain why he broke
something. Coming at this completely from outside with no knowledge of what is
going on, it seems obvious ulrich has an attitude problem. As to why, I can only
suppose that faced with the possibility that he made a mistake, he has chosen to
defend to the end of time rather than accept and fix it.

Anyways, best of luck resolving this.
Comment 21 Chris F Ravenscroft 2008-07-07 22:07:06 UTC
Guys,
Wait a minute. It is quite unfair to jump into a conversation like this and take
sides without having the whole picture.

Ulrich Drepper wrote several times that there's an explanation and it would
require work to give it to us.
Sometimes, programmers can be a bit gruff. Doesn't make them wrong :)

This bug report's new-found fame is quite unfortunate but it looks like if
Ulrich now takes a few minutes to educate us (and it looks like he will have to
if he wishes to keep his sanity!), the whole situation can be easily defused.
Comment 22 phelix 2008-07-07 23:19:39 UTC
http://www.ietf.org/rfc/rfc3056.txt
RFC 3056
Connection of IPv6 Domains via IPv4 Clouds
February 2001
   In any case, any 6to4 traffic whose source or destination address
   embeds a V4ADDR which is not in the format of a global unicast
   address MUST be silently discarded by both encapsulators and
   decapsulators.  Specifically, this means that IPv4 addresses defined
   in [RFC 1918], broadcast, subnet broadcast, multicast and loopback
   addresses are unacceptable.
Comment 23 Ulrich Drepper 2008-07-08 00:42:23 UTC
Stop reopening.
Comment 24 mangmang 2008-07-08 01:30:57 UTC
Seems obvious to me.
Comment 25 Matt Mullins 2008-07-08 02:04:13 UTC
Created attachment 2816 [details]
test case for IN6_IS_ADDR_V4COMPAT

This does not appear to violate any RFCs.

Howard Chu claims that this behavior violates RFC 2553.  First of all,
"IPv4-compatible addresses" have been deprecated by RFC 4291, section 2.5.5.1. 
Even if it had not been, this is an incorrect assumption.  "IPv4-compatible
addresses" would have implied that you could send an IPv6 packet over the wire
addressed to, say ::209.132.176.174, and a router would then encapsulate it in
an IPv4 packet to 209.132.176.174.  This has been superceded by the 6to4
dynamic tunneling scheme, which instead gives each IPv4 address a /48 in
IPv6-space.  But I digress.

What RFC 2553 means by 'IPv6 hex addresses "::" and "::1" MUST NOT be treated
as IPv4-compatible addresses' is that a router may not encapsulate ::1 in an
IPv4 packet to 0.0.0.1.  This behavior does not happen, because a host will
drop packets to ::1 if it did not come through the "lo" loopback interface. 
Even if this were to happen, it would be beyond the scope of libc; it would be
a kernel IP stack issue instead.

As for the macro behavior quoted from RFC 2553, I wrote some test code (see
attachment), and I get:
IN6_IS_ADDR_V4COMPAT( ::1 ) = false
IN6_IS_ADDR_V4COMPAT( :: ) = false

There is nothing in the RFCs that specifies how /etc/hosts should behave, since
that is not something that belongs in a protocol specification.  If glibc
decides to have "::1 localhost" implicitly act as if you had also typed
"127.0.0.1 localhost", then so be it.  None of the function behavior that I
have tested violates what is described in the RFCs.

That is not to say that I don't find this behavior a bit odd.  I would love to
hear from Ulrich what problem this functionality was intended to fix, but I
don't believe that this is in any way a violation of spec.  It's just a bit
different from the way soe people might interpret it.

phelix, this has nothing whatsoever to do with 6to4 tunneling.	6to4 tunneling
describes embedding IPv6 packets within IPv4 packets.  In Linux, that is
handled completely by the kernel, and all applications, including libc, know is
that they are opening an IPv6 socket.  The RFC that you quote is saying that an
IPv6 packet within an IPv4 packet sent to, for example, 127.0.0.1 is invalid.

For the record, I tested this against glibc 2.7 on Ubuntu hardy.
Comment 26 Ulrich Drepper 2008-07-08 03:28:22 UTC
Stop reopening the bug.  And this is also no discussion forum.  Go somewhere else.
Comment 27 Paul Wankadia 2008-07-08 04:48:02 UTC
I concur, Ulrich.  This bug has been discussed to death and only the trolls are
reopening it.  If anyone wishes to "me too" this bug, please open a new bug. 
Thanks.
Comment 28 Ulrich Drepper 2008-07-08 05:08:23 UTC
Stop commenting.
Comment 29 Bevan Anderson 2008-07-08 05:59:36 UTC
(In reply to comment #28)
> Stop commenting.

This bug is resolved.
Comment 30 Bevan Anderson 2008-07-08 06:02:38 UTC
(In reply to comment #28)
> Stop commenting.

This bug is resolved.
Comment 31 Tonnerre Lombard 2008-07-08 06:28:49 UTC
Please stop reopening for a while, SyGroup GmbH and Redhat are negotiating for a
solution. Please invest your time into patches fixing the lookup code of
affected applications instead.
Comment 32 Mantari Damacy 2008-07-08 07:08:15 UTC
(In reply to comment #31)
> Please stop reopening for a while, SyGroup GmbH and Redhat are negotiating for a
> solution. Please invest your time into patches fixing the lookup code of
> affected applications instead.

i THINK THIS IS A BUG?
Comment 33 Tonnerre Lombard 2008-07-08 07:41:11 UTC
Yes, but not in glibc. Please file the bug with the affected applications.

If these are fixed, the issue will disappear all by itself. Thus, your time is
better invested spotting the affected applications and fixing them.

Now pass along please, there's nothing to see here.
Comment 34 Γριφεγ 2008-07-08 17:02:06 UTC
So, if it has been "discussed to death" (or was that a troll?) could we get an
explanation for what the problem with the original behaviour was?

The only thing I can think of is if the hosts file had the ::1 entry before the
127. one, it could cause delays? Is that it?
Comment 35 Osama bin Drepper 2008-07-08 18:08:02 UTC
Is this open source terrorism?  "Pay us money or the bug stays!"
Comment 36 Ulrich Drepper 2008-07-08 18:28:11 UTC
(In reply to comment #35)
> Is this open source terrorism?  "Pay us money or the bug stays!"

Idiot.  There is no bug.  Don't reopen.
Comment 37 doot 2008-07-08 18:50:45 UTC
(In reply to comment #36)
> (In reply to comment #35)
> > Is this open source terrorism?  "Pay us money or the bug stays!"
> 
> Idiot.  There is no bug.  Don't reopen.

Will you reopen it for.. one MEEEEEEEEELLION dollars?
Comment 38 Ulrich Drepper 2008-07-08 18:54:02 UTC
There is nothing to reopen.  Period.
Comment 39 Regis Philbin 2008-07-08 19:11:00 UTC
(In reply to comment #38)
> There is nothing to reopen.  Period.

Would you say that's your FINAL ANSWER?
Comment 40 Unknown Impersonator 2008-07-08 19:21:52 UTC
Fine.  Whatever.  I'll revert it, assholes.
Comment 41 Bobby Tables 2008-07-08 19:23:02 UTC
I love DrPepper!
Comment 42 Petr Baudis 2008-07-08 19:38:09 UTC
Can all the random people finally stop spamming this bug with irrelevant stuff,
pretty please? Ulrich implied in comment 18 that this the current code does not
do this anymore; so please don't reopen the bug unless *you* verified that this
issue still exists in *current* code. Thank you.
Comment 43 Γριφεγ 2008-07-08 22:26:35 UTC
Petr,
To be fair, you set this off by repeatedly reopening this issue like a naughty brat.

Anyways, you guys may want to edit the CheckCanChangeField function in
process_bug.cgi and add something like:

if ($bugid eq 4980) { return 0; }
Comment 44 David Georgeman 2009-05-07 01:02:48 UTC
(In reply to comment #40)
> Fine.  Whatever.  I'll revert it, assholes.
> 

Wow, you are a bastard. I hope you die alone. :D
Comment 45 Mike Frysinger 2009-05-07 01:46:26 UTC
please refrain from adding garbage on top of garbage.  regardless of the
original garbage, adding more will gain nothing.
Comment 46 Ulfar Headder 2009-05-07 05:58:47 UTC
Fix your fucking shit.  Do I need to come to your office and slap some sense
into you?
Comment 47 Petr Baudis 2009-05-07 09:09:52 UTC
This is not slashdot. :(
Comment 48 passwhtt 2009-05-09 19:44:13 UTC
(In reply to comment #47)
> This is not slashdot. :(

No. But it is now on the home page of http://www.promotinglinux.com/
Comment 49 Dedé Santana 2009-05-15 01:15:14 UTC
Hello!!

I didn\'t test anything but Ulrich didn\'t convince me that it was working, so I\'m
reopening the bug!
Comment 50 Petr Baudis 2009-05-15 01:17:53 UTC
Someone really should lock this bug.
Comment 51 inuyasha.exe 2009-05-15 22:36:46 UTC
it doesnt work
Comment 52 Petr Baudis 2009-05-16 05:45:26 UTC
Please provide detailed information why, in what version and how doesn't it work
if you reopen the bug.
Comment 53 Óëüðèõ 2009-07-25 01:18:00 UTC
Just can't live with this being "closed". It breaks too much bugs and violates 
RFC2553. Please fix soon!
Comment 54 Petr Baudis 2009-08-20 11:47:43 UTC
no info provided about exactly what is still broken
Comment 55 nat.4200 2010-01-21 12:57:37 UTC
"Fine.  Whatever.  I'll revert it, assholes." -Comment #40 From Ulrich Drepper 
2008-07-08 19:21

Changing bug status to VERIFIED, notes make it clear Dev team are "assholes" &
no evidence that status of Dev team has been updated to remedy this.

Suggested bug fix: Devs should attempt not to be "assholes"
Comment 56 Shriramana Sharma 2010-04-23 02:09:14 UTC
(In reply to comment #55)
> "Fine.  Whatever.  I'll revert it, assholes." -Comment #40 From Ulrich Drepper 
> 2008-07-08 19:21

You should know that comment #37 and comment #40 were not made by Drepper but
someone impersonating him, check the mail addresses by hovering over the name
there. That said, it would certainly be better if everyone were polite to each
other and merely say things like "Sorry I don't have time to explain this right
now, can you please wait and I'll do it when I can" which would not have incited
all the negativity in the comments on this bug. Maybe a hint or two would also
have sufficed to direct the person who wants to know the reason for the breakage
to find it out for himself... Anyway, that should all be water under the bridge now.
Comment 57 My small pet dwarf 2012-03-31 21:00:10 UTC
Just saying hello from Slashdot: http://linux.slashdot.org/comments.pl?sid=2758641&cid=39535903
Comment 58 Mike Frysinger 2012-04-01 04:10:29 UTC
please take your trolling elsewhere
Comment 59 Alexa 2014-02-03 01:14:46 UTC
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen live from the domain http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.
Comment 60 Mediot Listo 2015-05-17 17:55:12 UTC
https://software.sandia.gov/trac/pyomo/ticket/3808
Comment 61 Mediot Listo 2015-05-17 17:56:46 UTC
Comment on attachment 2816 [details]
test case for IN6_IS_ADDR_V4COMPAT

https://software.sandia.gov/trac/pyomo/ticket/3808
Comment 62 Mike Frysinger 2015-05-18 02:11:38 UTC
stop spamming/messing with bugs
Comment 63 Ulrlch Dfepper 2016-03-18 11:59:58 UTC
Instructions too confusing. Got my dick caught in the ceiling fan.
Comment 64 Ulrich Drepper 2016-03-18 12:03:31 UTC
You always do this!
Comment 65 Mike Frysinger 2016-03-18 13:29:13 UTC
again, stop spamming/messing with bugs