[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 9 Jul 2018 18:38:05 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: getaddrinfo(3) / AI_ADDRCONFIG
On Mon, Jul 09, 2018 at 11:16:04AM -0400, Christopher Friedt wrote:
> Hi list,
>
> I have a patch for getaddrinfo(3) so that AI_ADDRCONFIG is properly
> supported. Currently, if user code passes in the aforementioned flag,
> there is no check to see whether a non-loopback network interface is
> configured with the specified (or unspecified) address family before
> returning results, which is what getaddrinfo(3) should do according to
> [1].
>
> As a result of the current behaviour, musl's getaddrinfo(3) would
> return e.g. "::1" to user code even when no interfaces (including lo)
> were configured with IPv6 addresses. I've documented this to some
> extent here [2].
>
> Please see the patch at [3] for my fix. Any feedback is welcome. The
> patch It applies against master and 1.1.19, but possibly other
> releases.
>
> C
>
> [1] http://man7.org/linux/man-pages/man3/getaddrinfo.3.html
> [2] https://issues.apache.org/jira/browse/THRIFT-4594
> [3] https://patch-diff.githubusercontent.com/raw/cfriedt/musl/pull/1
> https://patch-diff.githubusercontent.com/raw/cfriedt/musl/pull/1.diff
AI_ADDRCONFIG was discussed in 2014 as part of the "Remaining tasks on
resolver overhaul" thread:
http://openwall.com/lists/musl/2014/06/02/1
The consensus at the time was that it should be left as-is, in
accordance with "Current implementation of AI_ADDRCONFIG considered
harmful" (re: glibc implementation):
https://fedoraproject.org/wiki/QA/Networking/NameResolution/ADDRCONFIG
POSIX does not clearly specify how "only if an IPv6 address is
configured on the local system" is determined, but the glibc behavior
of ignoring ::1 on lo seems clearly non-conforming. My assumption at
the time was that ::1 would always be configured and available unless
IPv6 support was omitted from the kernel, so that any test involving
iteration of interfaces would be meaningless; at most probing ::1, or
probably just trying socket(AF_INET6,...) would suffice to determine
what to do.
It's unclear to me (and I think to everyone) what an application
actually wants when it uses AI_ADDRCONFIG. Neither knowing whether
IPv6 is supported at all on the host, nor whether there happens to be
*some* interface or non-lo interface with an IPv6 address (think: it
might just be a private-network VPN), tells you anything about whether
the IPv6 addresses for the particular hostname you're looking up with
getaddrinfo is routable. The more likely thing an application might
want is to request whichever result is routable, but THAT ALREADY
HAPPENS without AI_ADDRCONFIG: the results are sorted such that
routable ones come before non-routable ones, so if you try them in
order, you'll never hit a non-routable address family unless all the
results for the other family fail to be reachable.
So at this point my leaning is somewhere between:
1. Saying it's 2018 and having a system without IPv6 support (at least
::1) is an unsupported configuration.
2. Implementing AI_ADDRCONFIG as detection for the case where IPv6 has
been completely disabled at the kernel or container level.
I'm not sure what option 2 entails if IPv6 is disabled at the
container level but socket(AF_INET6,...) still succeeds, so we should
perhaps look into that if you or other users feel strongly that
AI_ADDRCONFIG should do something here. But it shouldn't involve any
O(n) iteration of interfaces, allocation, or pulling in other heavy
code.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
