4980 2007-08-29 17:03:00 +0000 gethostbyname() etc break for /etc/hosts with both ::1 and 127.0.0.1 localhost entries 2012-04-01 04:10:29 +0000 1 1 1 Unclassified glibc libc unspecified All All RESOLVED FIXED P2 normal --- 5460 1 pasky drepper.fsp aurelien glibc-bugs halcy0n mokomull slashtrooll tonnerre tpeland vapier 18845 pasky 2007-08-29 17:03:56 +0000 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. 18849 drepper.fsp 2007-08-29 17:31:57 +0000 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. 18892 pasky 2007-09-05 00:56:51 +0000 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? 19238 drepper.fsp 2007-09-23 16:07:13 +0000 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. 19245 pasky 2007-09-23 20:59:16 +0000 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. 19248 drepper.fsp 2007-09-23 22:42:21 +0000 Strange, I never saw your name on my paycheck. Since if that's not the case you cannot order me around. 19255 pasky 2007-09-24 00:33:03 +0000 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. 19257 drepper.fsp 2007-09-24 03:04:38 +0000 There is no bug. Stop reopening. 20520 hyc 2007-12-01 20:09:51 +0000 (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. 20685 hyc 2007-12-14 03:31:15 +0000 Treating the IPv6 loopback address this way violates RFC2553. 20686 drepper.fsp 2007-12-14 03:52:57 +0000 Stop reopening the bug. If you want explanations pay somebody. 22740 vapier 2008-04-09 19:12:17 +0000 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! 22747 sylvain.bertrand 2008-04-10 09:36:26 +0000 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!). 22713 2693 tpeland 2008-04-15 06:13:33 +0000 Created attachment 2693 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. 22712 tpeland 2008-04-15 06:20:01 +0000 Program that is specifically bound to "::1" can't be connected by calling "127.0.0.1". Check the attachement. 23121 drepper.fsp 2008-04-15 14:20:09 +0000 Stop reopening bugs. There is nothing which is going to change here until we have unified lookups. 24042 hyc 2008-06-18 19:26:14 +0000 (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. 24266 dave.houston 2008-07-07 05:05:25 +0000 Paid $1 via paypal. Trans ID 3H4989806A1962407 Please fix. 24267 drepper.fsp 2008-07-07 05:57:12 +0000 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. 24275 tg 2008-07-07 20:30:01 +0000 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? 24277 carterhawk 2008-07-07 20:58:59 +0000 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. 24278 chris.f.ravenscroft 2008-07-07 22:07:06 +0000 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. 24279 phelix_dacat 2008-07-07 23:19:39 +0000 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. 24280 drepper.fsp 2008-07-08 00:42:23 +0000 Stop reopening. 24281 mangmang 2008-07-08 01:30:57 +0000 Seems obvious to me. 24282 2816 mokomull 2008-07-08 02:04:13 +0000 Created attachment 2816 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. 24283 drepper.fsp 2008-07-08 03:28:22 +0000 Stop reopening the bug. And this is also no discussion forum. Go somewhere else. 24285 junyer 2008-07-08 04:48:02 +0000 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. 24287 drepper.fsp 2008-07-08 05:08:23 +0000 Stop commenting. 24294 robotdevice 2008-07-08 05:59:36 +0000 (In reply to comment #28) > Stop commenting. This bug is resolved. 24295 robotdevice 2008-07-08 06:02:38 +0000 (In reply to comment #28) > Stop commenting. This bug is resolved. 24296 tonnerre 2008-07-08 06:28:49 +0000 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. 24299 mantari.damacy 2008-07-08 07:08:15 +0000 (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? 24301 tonnerre 2008-07-08 07:41:11 +0000 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. 24322 grfgguvf 2008-07-08 17:02:06 +0000 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? 24324 M8R-ycntwi 2008-07-08 18:08:02 +0000 Is this open source terrorism? "Pay us money or the bug stays!" 24325 drepper.fsp 2008-07-08 18:28:11 +0000 (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. 24326 doot 2008-07-08 18:50:45 +0000 (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? 24327 drepper.fsp 2008-07-08 18:54:02 +0000 There is nothing to reopen. Period. 24329 regis.philbin 2008-07-08 19:11:00 +0000 (In reply to comment #38) > There is nothing to reopen. Period. Would you say that's your FINAL ANSWER? 24330 M8R-1weoa31 2008-07-08 19:21:52 +0000 Fine. Whatever. I'll revert it, assholes. 24331 sourceware 2008-07-08 19:23:02 +0000 I love DrPepper! 24333 pasky 2008-07-08 19:38:09 +0000 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. 24336 grfgguvf 2008-07-08 22:26:35 +0000 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; } 36067 zugok8 2009-05-07 01:02:48 +0000 (In reply to comment #40) > Fine. Whatever. I'll revert it, assholes. > Wow, you are a bastard. I hope you die alone. :D 36070 vapier 2009-05-07 01:46:26 +0000 please refrain from adding garbage on top of garbage. regardless of the original garbage, adding more will gain nothing. 36072 ufarkhead 2009-05-07 05:58:47 +0000 Fix your fucking shit. Do I need to come to your office and slap some sense into you? 36074 pasky 2009-05-07 09:09:52 +0000 This is not slashdot. :( 36096 whtt 2009-05-09 19:44:13 +0000 (In reply to comment #47) > This is not slashdot. :( No. But it is now on the home page of http://www.promotinglinux.com/ 36142 dedesantana 2009-05-15 01:15:14 +0000 Hello!! I didn\'t test anything but Ulrich didn\'t convince me that it was working, so I\'m reopening the bug! 36143 pasky 2009-05-15 01:17:53 +0000 Someone really should lock this bug. 36146 inuyasha.exe 2009-05-15 22:36:46 +0000 it doesnt work 36147 pasky 2009-05-16 05:45:26 +0000 Please provide detailed information why, in what version and how doesn't it work if you reopen the bug. 37345 b501512 2009-07-25 01:18:00 +0000 Just can't live with this being "closed". It breaks too much bugs and violates RFC2553. Please fix soon! 37835 pasky 2009-08-20 11:47:43 +0000 no info provided about exactly what is still broken 41042 nat.4200 2010-01-21 12:57:37 +0000 "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" 42828 samjnaa 2010-04-23 02:09:14 +0000 (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. 54320 slashtrooll 2012-03-31 21:00:10 +0000 Just saying hello from Slashdot: http://linux.slashdot.org/comments.pl?sid=2758641&cid=39535903 54322 vapier 2012-04-01 04:10:29 +0000 please take your trolling elsewhere 2693 2008-04-15 06:13:00 +0000 2008-04-15 06:13:33 +0000 getaddrinfo fix for 2.6.1/2.7 getaddrinfo-2.6.1.patch text/plain 584 tpeland LS0tIGdsaWJjLTIuNi4xL25zcy9uc3NfZmlsZXMvZmlsZXMtaG9zdHMuYy5PUklHCTIwMDgtMDQt MTIgMTg6NTU6MDguMjgxNTA2NjE2ICswMzAwCisrKyBnbGliYy0yLjYuMS9uc3MvbnNzX2ZpbGVz L2ZpbGVzLWhvc3RzLmMJMjAwOC0wNC0xMiAxODo1Nzo0My40NDk2NTY4NjYgKzAzMDAKQEAgLTY3 LDExICs2Nyw2IEBACiAJIHsKIAkgICBpZiAoSU42X0lTX0FERFJfVjRNQVBQRUQgKGVudGRhdGEt Pmhvc3RfYWRkcikpCiAJICAgICBtZW1jcHkgKGVudGRhdGEtPmhvc3RfYWRkciwgZW50ZGF0YS0+ aG9zdF9hZGRyICsgMTIsIElOQUREUlNaKTsKLQkgICBlbHNlIGlmIChJTjZfSVNfQUREUl9MT09Q QkFDSyAoZW50ZGF0YS0+aG9zdF9hZGRyKSkKLQkgICAgIHsKLQkgICAgICAgaW5fYWRkcl90IGxv Y2FsaG9zdCA9IGh0b25sIChJTkFERFJfTE9PUEJBQ0spOwotCSAgICAgICBtZW1jcHkgKGVudGRh dGEtPmhvc3RfYWRkciwgJmxvY2FsaG9zdCwgc2l6ZW9mIChsb2NhbGhvc3QpKTsKLQkgICAgIH0K IAkgICBlbHNlCiAJICAgICAvKiBJbGxlZ2FsIGFkZHJlc3M6IGlnbm9yZSBsaW5lLiAgKi8KIAkg ICAgIHJldHVybiAwOwo= 2816 2008-07-08 02:04:00 +0000 2008-07-08 02:04:13 +0000 test case for IN6_IS_ADDR_V4COMPAT v6_compat.c text/plain 505 mokomull I2luY2x1ZGUgPHN5cy90eXBlcy5oPgojaW5jbHVkZSA8c3lzL3NvY2tldC5oPgojaW5jbHVkZSA8 bmV0aW5ldC9pbi5oPgojaW5jbHVkZSA8c3RkaW8uaD4KI2luY2x1ZGUgPHN0ZGxpYi5oPgoKdm9p ZCBkb2l0KCBjb25zdCBjaGFyICpzdHJfbmFtZSApIHsKCWludCByZXQ7CglzdHJ1Y3QgaW42X2Fk ZHIgYWRkcmVzczsKCXJldCA9IGluZXRfcHRvbiggQUZfSU5FVDYsIHN0cl9uYW1lLCAmYWRkcmVz cyApOwoJaWYgKHJldCA8PSAwKSB7CgkJZnByaW50Ziggc3RkZXJyLCAiaW5ldF9wdG9uIGZhaWxl ZCwgc3RyX25hbWUgPSAlcywgcmV0ID0gJWRcbiIsIHN0cl9uYW1lLCByZXQgKTsKCQlleGl0KDEp OwoJfQoKCXByaW50ZiggIklONl9JU19BRERSX1Y0Q09NUEFUKCAlcyApID0gJXNcbiIsIHN0cl9u YW1lLCBJTjZfSVNfQUREUl9WNENPTVBBVCggJmFkZHJlc3MgKSA/ICJ0cnVlIiA6ICJmYWxzZSIg KTsKfQoKaW50IG1haW4gKCkgewoJZG9pdCgiOjoxIik7Cglkb2l0KCI6OiIpOwp9Cg==