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.1 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,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 20698 invoked from network); 30 Apr 2021 17:00:12 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 30 Apr 2021 17:00:12 -0000 Received: (qmail 24419 invoked by uid 550); 30 Apr 2021 17:00:10 -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 24400 invoked from network); 30 Apr 2021 17:00:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=mnK8ChflOtv6u2thx33OivfemVfi+Y61DMWM3ObsoDE=; b=LTSj5vDSa3eGrqjvYJOVPQGs5hblF0WpC9dzPQUCIAaqopuL74yU0iJ914oUkbtZFW ynCSNi3f29402B+xPTBr9yAmcj7lirumZ6gbudqHc2fVFJKuY6ae35ccBjv+L2zOMiVZ cxME2CXslv/zzKMBYQhioLySGG39gqexIo6RYgyXEi/Yj5UJOm72hw63PFxPApnXW5W5 eex72j88KkMX6bqzDDgS9XnIfFSYGt73ThIOLUqukTXRnOroIFPlukP+dIqiDeVKwuoF Zek7GvPVKecPhxqUavQAmYbUs0Ke2xfYofq+/pp16UO4+/nQKyzc5p7baLOq42BRnxAP ITZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=mnK8ChflOtv6u2thx33OivfemVfi+Y61DMWM3ObsoDE=; b=qXLZQx18yacu8mKRy5f1NmQIVNY3tDf20x6j8pqmO2h+gm4yciLk8+W4D3wMr4wmS8 JJnHDRHJxb50tZuM84dg8de4JCdCf7r4kw0btLsaJMl+CyBcBLHTQkVVhMmD9OO0sPIB gPaWDhU0twuYaO4itVBLEJXt+vdVa4w/OLcf28eCHObQPufn50y4WQZvUOEKgHVIIloP HQsYv6ZkRhOb3XXofvVh1plhQ6Rbuj3wRrfylGE81I8tOBZ/sLCb2V0DMgCHz8zNbLWI Zk5iWDf2DDa7utHzcGja7u+GJ5yDH4vHyhTFfo+JMe5q+sWADNeP4DXD5DowYXzQq8hA ELPA== X-Gm-Message-State: AOAM532nP1aTV2EJbEKzVsMDv99r+x3Ns2tbv5E3IhtG9mAlkjPhCn1X 0VhxVZ3GCKA5J3xjsznQ7OfnclP80DmJV757RGR50eMedqI= X-Google-Smtp-Source: ABdhPJzE+sFuLbMo3HUYwqmMyPJFVYJcfoM1tcKF8dXtrDhMsu2gqcjQ9KDGjaHfx6y6FBL8gJqNsSr+oU3IjGn8cXA= X-Received: by 2002:a6b:d20e:: with SMTP id q14mr4507652iob.200.1619801997381; Fri, 30 Apr 2021 09:59:57 -0700 (PDT) MIME-Version: 1.0 References: <3b4d958a-f00e-564a-7715-c92d7592ce3f@greenwavesystems.com> <20210430001301.GW2546@brightrain.aerifal.cx> <20210430123803.GX2546@brightrain.aerifal.cx> In-Reply-To: <20210430123803.GX2546@brightrain.aerifal.cx> From: Jeffrey Walton Date: Fri, 30 Apr 2021 12:59:39 -0400 Message-ID: To: musl@lists.openwall.com Cc: Bob Richmond Content-Type: text/plain; charset="UTF-8" Subject: Re: [musl] getaddrinfo/AI_ADDRCONFIG with ipv6 disabled On Fri, Apr 30, 2021 at 8:38 AM Rich Felker wrote: > .... > 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. The kernel has been doing that stupid thing for ages. They have no interest in fixing it. (I brought it up on one of the kernel mailing lists). It gets worse with components like SELinux. They hijack error codes there, too. You can waste hours trying to track down an EACCESS on a web server only to find out the kernel hijacked the return code in SELinux. God forbid they actually provide a selinux_errno to check for SELinux errors... Jeff