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 6563 invoked from network); 30 Apr 2021 19:50:41 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 30 Apr 2021 19:50:41 -0000 Received: (qmail 1194 invoked by uid 550); 30 Apr 2021 19:50:39 -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 1176 invoked from network); 30 Apr 2021 19:50:38 -0000 Date: Fri, 30 Apr 2021 15:50:26 -0400 From: Rich Felker To: Markus Wichmann Cc: musl@lists.openwall.com Message-ID: <20210430195026.GZ2546@brightrain.aerifal.cx> References: <3b4d958a-f00e-564a-7715-c92d7592ce3f@greenwavesystems.com> <20210430001301.GW2546@brightrain.aerifal.cx> <20210430123803.GX2546@brightrain.aerifal.cx> <20210430184917.GC2031@voyager> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210430184917.GC2031@voyager> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] getaddrinfo/AI_ADDRCONFIG with ipv6 disabled On Fri, Apr 30, 2021 at 08:49:17PM +0200, Markus Wichmann wrote: > On Fri, Apr 30, 2021 at 12:59:39PM -0400, Jeffrey Walton wrote: > > God forbid they actually provide a selinux_errno to check for SELinux errors... > > > > Jeff > > Well, that would be difficult. Although the concept of "nicer" errors > has been floated in the past, and having some kind of parametrization > for errno would be helpful (e.g. if ENOENT is returned, actually saying > which file could not be found would be helpful. Because it's not always > obvious). But right now, errno is the only error handling mechanism > established in the ABI, and it is transported by having the system call > return a value between -1 and -4096 (though I'm not sure if that lower > bound is general or just AMD64). Having a second errno would require > either establishing a new system call to read it out, or modifying the > ABI to allow for the information to be transported. There are many > hurdles in the way of the latter (can't use return value, can't use > registers, can only use memory on an opt-in basis, but then you can also > just add another system call directly), so it's going to be the former. > > Then the question arrises whether the abstraction is even correct. > Technically, SELinux is just a plug-in security module, and a given > Linux kernel may have many of those. Shall each get their own errno? > Where does it end? > > So yeah, it's not as simple as"just add another variable". Yes, the underlying issue is just SELinux, LSMs, firewall/routing policy, seccomp, etc. producing wrong error codes (or letting the user configure it to produce wrong error codes), rather than hard-coding the cause. For example in the case here, nobody needs to know EACCES. The important piece of information to the application is that the connection is not routeable, and this is ENETUNREACH or EHOSTUNREACH. Routing is always a matter of some sort of policy, so "this was blocked by fib6 [vs iptables vs just not having a route, etc.]" is not meaningful to the application. If there were a secondary way to give more detailed error information, it might be nice to give it, but in the absence of that, the right solution is just "don't replace well-specified general error codes the application knows to handle with overly specific ones it can't (and that might even mean something else to it, in the case of EINVAL). Rich