| Summary: | getaddrinfo(NULL) with AI_PASSIVE returns 0.0.0.0 (IPv4-only) and :: (IPv6+IPv4) in this order | ||
|---|---|---|---|
| Product: | glibc | Reporter: | Aurelien Jarno <aurelien> |
| Component: | network | Assignee: | Florian Weimer <fweimer> |
| Status: | ASSIGNED --- | ||
| Severity: | normal | CC: | allan, aoliva, bugzilla.sourceware.simon, carlos, fweimer, glibc-bugs, hans, luke, mmeier, psimerda, vapier |
| Priority: | P2 | Flags: | fweimer:
security-
|
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Host: | x86_64-unknown-linux-gnu | Target: | x86_64-unknown-linux-gnu |
| Build: | x86_64-unknown-linux-gnu | Last reconfirmed: | |
| Attachments: |
test program
Don't sort passive localhost addresses, so that IPv6+IPvv4 remains first and IPv4-only, last |
||
Created attachment 3835 [details]
test program
I have just done a test build on the current CVS, and the bug is still present. The sort ipv4 and then ipv6 is done by rule 5, when matching the label. It seems this rule should be ignored when dealing with wildcard addresses. Maybe got_source_addr should not be set to true for wildcard addresses. Comment from a newer duplicate: Pavel Šimerda 2012-12-16 16:08:35 UTC On Linux, with net.ipv6.bindv6only = 0 (the default), getaddrinfo(NULL) with AI_PASSIVE returns 0.0.0.0 and :: (in this order). AI_PASSIVE was meant to return a list of addresses to listen on, but it is impossible to listen on 0.0.0.0 and :: at the same time, if :: implies dualstack mode. Even the order is wrong, as listening on :: would work for both protocols, while listening on 0.0.0.0 does not. If the order is fixed, applications could just spit out a warning but still work correctly. The only proper fix I can think of, is test for net.ipv6.bindv6only and return only :: if this is 0, otherwise return both addresses (preferably IPv6 first). Upstream bug report: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/673708 More information: https://fedoraproject.org/wiki/Networking/NameResolution#Binding_to_the_INADDR_ANY_and.2For_in6addr_any_addresses Cheers, Pavel *** Bug 14211 has been marked as a duplicate of this bug. *** *** Bug 14967 has been marked as a duplicate of this bug. *** Created attachment 7624 [details]
Don't sort passive localhost addresses, so that IPv6+IPvv4 remains first and IPv4-only, last
I don't think it ever makes any sense for us to ever try to sort passive addresses: we always generate them IPv6+IPv4 first and IPv4-only last, with at most two adresses and possibly only one if we asked for a specific family. Since the former is always preferred, it doesn't make sense to try to sort them.
The only doubt is whether to generate both when the first covers both; I'm not when dropping the latter is safe, so I'm leaving that unrelated decision out for now.
Any reason to not go with this patch?
On Sat, May 31, 2014 at 12:52:45AM +0000, aoliva at sourceware dot org wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=9981
>
> Alexandre Oliva <aoliva at sourceware dot org> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> CC| |aoliva at sourceware dot org
>
> --- Comment #7 from Alexandre Oliva <aoliva at sourceware dot org> ---
> Created attachment 7624 [details]
> --> https://sourceware.org/bugzilla/attachment.cgi?id=7624&action=edit
> Don't sort passive localhost addresses, so that IPv6+IPvv4 remains first and
> IPv4-only, last
>
> I don't think it ever makes any sense for us to ever try to sort passive
> addresses: we always generate them IPv6+IPv4 first and IPv4-only last, with at
> most two adresses and possibly only one if we asked for a specific family.
> Since the former is always preferred, it doesn't make sense to try to sort
> them.
>
> The only doubt is whether to generate both when the first covers both; I'm not
> when dropping the latter is safe, so I'm leaving that unrelated decision out
> for now.
>
> Any reason to not go with this patch?
>
Possible, you should send this to libc-alpha to get comments.
> The only doubt is whether to generate both when the first covers both;
> I'm not when dropping the latter is safe, so I'm leaving that unrelated
> decision out for now.
It's not safe because the global sysctl net.ipv6.bindv6only could be set to 1 at any time, or the application could use IPV6_V6ONLY=1 on the socket (expecting to receive an IPv4 address too).
(In reply to Simon Arlott from comment #9) > It's not safe because the global sysctl net.ipv6.bindv6only could be set to > 1 at any time, or the application could use IPV6_V6ONLY=1 on the socket > (expecting to receive an IPv4 address too). Do you see a better way? (In reply to Pavel Šimerda from comment #10) > (In reply to Simon Arlott from comment #9) > > It's not safe because the global sysctl net.ipv6.bindv6only could be set to > > 1 at any time, or the application could use IPV6_V6ONLY=1 on the socket > > (expecting to receive an IPv4 address too). > > Do you see a better way? There is nothing getaddrinfo() can do about this. It would have been better to not have the bindv6only sysctl and require an explicit IPV6_V6ONLY=0 on the socket, but it's too late for that now. (In reply to Simon Arlott from comment #11) > There is nothing getaddrinfo() can do about this. It would have been better > to not have the bindv6only sysctl and require an explicit IPV6_V6ONLY=0 on > the socket, but it's too late for that now. Then I would say we should assume bindv6only won't change between the call to getaddrinfo() and bind(). I know it's not 100% perfect but most systems don't change the setting at runtime at all. It certainly better than the current situation. (In reply to Pavel Šimerda from comment #12) > Then I would say we should assume bindv6only won't change between the call > to getaddrinfo() and bind(). I know it's not 100% perfect but most systems > don't change the setting at runtime at all. It certainly better than the > current situation. You're making an assumption that the application hasn't been developed to work around this already. The default is usually bindv6only=0 in the sysctl but I've written code that sets the IPV6_V6ONLY=1 socket flag specifically so that all of the getaddrinfo() addresses will bind successfully. I'd suggest documenting this non-AF-independent behaviour in the man page or pushing for an AF-independent "I'm using getaddrinfo() so don't try to second guess what I mean by bind()" socket flag. This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".
The branch, lxoliva/getaddrinfo has been created
at d4139de660d1f25ad34ab023b13ec3cad78986d2 (commit)
- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=d4139de660d1f25ad34ab023b13ec3cad78986d2
commit d4139de660d1f25ad34ab023b13ec3cad78986d2
Author: Alexandre Oliva <aoliva@redhat.com>
Date: Sun Jun 1 16:51:57 2014 -0300
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=91bbe1798129768e77cffecf324400fa4d31ad10
commit 91bbe1798129768e77cffecf324400fa4d31ad10
Author: Alexandre Oliva <aoliva@redhat.com>
Date: Sun Jun 1 16:51:44 2014 -0300
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=bc3ac8b1779e8b180762841048601b90f469d6e5
commit bc3ac8b1779e8b180762841048601b90f469d6e5
Author: Alexandre Oliva <aoliva@redhat.com>
Date: Sun Jun 1 16:48:15 2014 -0300
for ChangeLog
PR network/9981
* sysdeps/posix/getaddrinfo.c (getaddrinfo): Do not sort
AI_PASSIVE addresses.
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=7875573cbe52eabe78f1cab91c8a046d0bd5ed5a
commit 7875573cbe52eabe78f1cab91c8a046d0bd5ed5a
Author: Alexandre Oliva <aoliva@redhat.com>
Date: Sat Sep 27 07:13:20 2014 -0300
drop address family conversions from /etc/hosts parser
for ChangeLog
* nss/nss_files/files-hosts.c (LINE_PARSER): Drop all address
family conversions.
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=393207b6a74aeed6227d88174b8b37e4ee095260
commit 393207b6a74aeed6227d88174b8b37e4ee095260
Author: Alexandre Oliva <aoliva@redhat.com>
Date: Sat Sep 27 07:13:20 2014 -0300
drop v4-to-v6 conversions of loopback addresses from /etc/hosts
for ChangeLog
* nss/nss_files/files-hosts.c (LINE_PARSER): Drop family
conversion of loopback addresses from IPv4 to IPv6.
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=2e8a3341f470d8fa0dce69b8cf83e346a0017ada
commit 2e8a3341f470d8fa0dce69b8cf83e346a0017ada
Author: Alexandre Oliva <aoliva@redhat.com>
Date: Sat Sep 27 07:13:18 2014 -0300
drop v6-to-v4 conversions of loopback addresses from /etc/hosts
for ChangeLog
* nss/nss_files/files-hosts.c (LINE_PARSER): Drop family
conversion of loopback addresses from IPv6 to IPv4.
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=901aad32edcbd1cfd57ee904ada6dcc56a53b385
commit 901aad32edcbd1cfd57ee904ada6dcc56a53b385
Author: Alexandre Oliva <aoliva@redhat.com>
Date: Sat Sep 27 07:23:39 2014 -0300
resolv: skip leading dot in domain to search
This should only happen if the domain to search is the root,
represented as . rather than by an empty string. Skipping it here
prevents libc_res_nquerydomain from duplicating the trailing dot,
which would cause the domain name compression to fail.
for ChangeLog
PR 16469
* resolv/res_query.c (__libc_res_nsearch): Skip leading dot in
search domain names.
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=ba878d017e6b65f5d2880ac8262bc68224ee3a53
commit ba878d017e6b65f5d2880ac8262bc68224ee3a53
Author: Alexandre Oliva <aoliva@redhat.com>
Date: Wed Oct 15 03:52:43 2014 -0300
don't drop trailing dot in res_nquerydomain(..., name, NULL, ...)
If we drop it here, we will fail to detect a duplicate trailing dot
later on. Retaining, OTOH, has no ill effects whatsoever, and it even
saves us the trouble of copying the domain name minus the trailing
dot, like we used to do.
for ChangeLog
PR 16469
* resolv/res_query.c (__libc_res_nquerydomain): Retain
trailing dot.
* NEWS: Fixes 16469.
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=ff9a1b7dce77c43235e11cda103698078cf44a45
commit ff9a1b7dce77c43235e11cda103698078cf44a45
Author: Alexandre Oliva <aoliva@redhat.com>
Date: Mon Nov 3 18:51:40 2014 -0200
Do not continue in nss_db_getservbyname
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=6286965b02069369beeb893833c34f01dc919ffb
commit 6286965b02069369beeb893833c34f01dc919ffb
Author: Alexandre Oliva <aoliva@redhat.com>
Date: Mon Nov 3 18:51:40 2014 -0200
create all sockets with SOCK_CLOEXEC
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=c83b8a87170cda275a5c591fe2a1d3657d2a6711
commit c83b8a87170cda275a5c591fe2a1d3657d2a6711
Author: Alexandre Oliva <aoliva@redhat.com>
Date: Mon Nov 3 18:51:39 2014 -0200
introduce internal function to ease poll retry with timeout
-----------------------------------------------------------------------
Adding Florian Weimer to CC since this issue might be of interest to him as network subsystem maintainer. |
The current getaddrinfo code prefers listening on ipv4-only instead of ipv4+ipv6 as previously. The gaitest.c file demonstrates the problem. On a machine with both ipv4 and ipv6 connectivity, it returns: * ipv4 (only) * ipv6+ipv4 Listening for ipv6 connections never hurts, even if no one will ever reach the server via ipv6.