From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24044 invoked from network); 30 Apr 2021 12:38:20 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 30 Apr 2021 12:38:20 -0000 Received: (qmail 15974 invoked by uid 550); 30 Apr 2021 12: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: Reply-To: musl@lists.openwall.com Received: (qmail 15948 invoked from network); 30 Apr 2021 12:38:17 -0000 Date: Fri, 30 Apr 2021 08:38:04 -0400 From: Rich Felker To: Bob Richmond Cc: musl@lists.openwall.com Message-ID: <20210430123803.GX2546@brightrain.aerifal.cx> References: <3b4d958a-f00e-564a-7715-c92d7592ce3f@greenwavesystems.com> <20210430001301.GW2546@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210430001301.GW2546@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] getaddrinfo/AI_ADDRCONFIG with ipv6 disabled On Thu, Apr 29, 2021 at 08:13:03PM -0400, Rich Felker wrote: > On Wed, Dec 04, 2019 at 06:44:29PM -0800, Bob Richmond wrote: > > connect() to the IPv6 loopback address can fail with EACCES on Linux > > if IPv6 is disabled on the lo interface, and causes getaddrinfo to > > fail without returning IPv4 addresses. It should be treated as if > > IPv6 is disabled. > > > > echo 1 >/proc/sys/net/ipv6/conf/lo/disable_ipv6 > > > > struct addrinfo hints, *res = NULL; > > hints.ai_family = PF_UNSPEC; > > hints.ai_flags = AI_ADDRCONFIG; > > getaddrinfo("192.168.1.1", "80", &hints, &res); > > > > strace: > > ======start======= > > socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC, IPPROTO_UDP) = 14 > > connect(14, {sa_family=AF_INET, sin_port=htons(65535), > > sin_addr=inet_addr("127.0.0.1")}, 16) = 0 > > close(14) = 0 > > > > socket(AF_INET6, SOCK_DGRAM|SOCK_CLOEXEC, IPPROTO_UDP) = 14 > > > > connect(14, {sa_family=AF_INET6, sin6_port=htons(65535), > > inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=htonl(0), > > sin6_scope_id=0}, 28) = -1 EACCES (Permission denied) > > close(14) = 0 > > writev(2, [{iov_base="[warn] getaddrinfo: Permission denied\n", > > iov_len=38}, {iov_base=NULL, iov_len=0}], 2) = 38 > > ======end========= > > > --- musl-1.1.24/src/network/getaddrinfo.c 2019-10-13 14:58:27.000000000 -0700 > > +++ musl-1.1.24/src/network/getaddrinfo.c 2019-12-04 14:52:11.003784091 -0800 > > @@ -76,6 +76,7 @@ > > case EHOSTUNREACH: > > case ENETDOWN: > > case ENETUNREACH: > > + case EACCES: > > break; > > default: > > return EAI_SYSTEM; > > This patch was overlooked at the time, and another user just stopped > by #musl to ask why it wasn't applied. I'm going to go ahead and apply > it now. Sorry for the long delay! It's been raised that this is NOT a result of echo 1 >/proc/sys/net/ipv6/conf/lo/disable_ipv6 but rather appears to be fib6 policy setup by OpenWRT for some reason, whereby the kernel (net/ipv6/fib6_rules.c: fib6_rule_action) synthesizes error codes for routing policy reasons. This is probably wrong for the kernel to do -- especially their re-appropriation of EINVAL for FR_ACT_BLACKHOLE when POSIX already specifies it for "The address_len argument is not a valid length for the address family; or invalid address family in the sockaddr structure." So in light of this mess, the patch may be correct, despite the problem being misattributed, but it should probably also handle the EINVAL case. Also it's not 100% clear whether we should interpret this as "no IPv6" or ignore it as an access control policy rather than reflection of IPv6 existing. If there are any other ways the kernel can return EACCES or EINVAL here, we would not want to misinterpret that in a way that breaks IPv6. Someone should probably also ping OpenWRT about why they're using this arcane mechanism to block IPv6 to localhost. Rich