| Summary: | gethostbyname() etc break for /etc/hosts with both ::1 and 127.0.0.1 localhost entries | ||
|---|---|---|---|
| Product: | glibc | Reporter: | Petr Baudis <pasky> |
| Component: | libc | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | 1asfjwejafwea, carlos, gabravier, namboru, netjoker45, petteri.pasila, vapier |
| Priority: | P2 | Flags: | carlos:
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 |
||
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. 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? 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 have tried to search the web already and found nothing. If you want to close bugs as INVALID/WORKSFORME, please provide a proper explanation. Strange, I never saw your name on my paycheck. Since if that's not the case you cannot order me around. 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. There is no bug. Stop reopening. (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. Treating the IPv6 loopback address this way violates RFC2553. Stop reopening the bug. If you want explanations pay somebody. 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! 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!). 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. Program that is specifically bound to "::1" can't be connected by calling "127.0.0.1". Check the attachement. Stop reopening bugs. There is nothing which is going to change here until we have unified lookups. (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. Paid $1 via paypal. Trans ID 3H4989806A1962407 Please fix. 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. 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? 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. 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. 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. Stop reopening. Seems obvious to me. 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.
Stop reopening the bug. And this is also no discussion forum. Go somewhere else. 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. Stop commenting. (In reply to comment #28) > Stop commenting. This bug is resolved. (In reply to comment #28) > Stop commenting. This bug is resolved. 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. (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? 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. 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? Is this open source terrorism? "Pay us money or the bug stays!" (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. (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? There is nothing to reopen. Period. (In reply to comment #38) > There is nothing to reopen. Period. Would you say that's your FINAL ANSWER? Fine. Whatever. I'll revert it, assholes. I love DrPepper! 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. 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; }
(In reply to comment #40) > Fine. Whatever. I'll revert it, assholes. > Wow, you are a bastard. I hope you die alone. :D please refrain from adding garbage on top of garbage. regardless of the original garbage, adding more will gain nothing. Fix your fucking shit. Do I need to come to your office and slap some sense into you? This is not slashdot. :( (In reply to comment #47) > This is not slashdot. :( No. But it is now on the home page of http://www.promotinglinux.com/ Hello!! I didn\'t test anything but Ulrich didn\'t convince me that it was working, so I\'m reopening the bug! Someone really should lock this bug. it doesnt work Please provide detailed information why, in what version and how doesn't it work if you reopen the bug. Just can't live with this being "closed". It breaks too much bugs and violates RFC2553. Please fix soon! no info provided about exactly what is still broken "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" (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. Just saying hello from Slashdot: http://linux.slashdot.org/comments.pl?sid=2758641&cid=39535903 please take your trolling elsewhere *** 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 on attachment 2816 [details] test case for IN6_IS_ADDR_V4COMPAT https://software.sandia.gov/trac/pyomo/ticket/3808 stop spamming/messing with bugs Instructions too confusing. Got my dick caught in the ceiling fan. You always do this! again, stop spamming/messing with bugs This was my spotlight for Glibc's 9/11. Simak harga jasa seo Google di https://seohandal.id |
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.