From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13006 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: getaddrinfo(3) / AI_ADDRCONFIG Date: Mon, 9 Jul 2018 18:38:05 -0400 Message-ID: <20180709223805.GS1392@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1531175775 29865 195.159.176.226 (9 Jul 2018 22:36:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 9 Jul 2018 22:36:15 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-13022-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jul 10 00:36:11 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1fcelN-0007cN-5s for gllmg-musl@m.gmane.org; Tue, 10 Jul 2018 00:36:09 +0200 Original-Received: (qmail 3514 invoked by uid 550); 9 Jul 2018 22:38:18 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 3496 invoked from network); 9 Jul 2018 22:38:17 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:13006 Archived-At: 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