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.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,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 32405 invoked from network); 30 Apr 2021 18:49:32 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 30 Apr 2021 18:49:32 -0000 Received: (qmail 9357 invoked by uid 550); 30 Apr 2021 18:49:30 -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 9333 invoked from network); 30 Apr 2021 18:49:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1619808558; bh=K6SyLdD57DrsGODSP9p+cFrxwO3wD37VFHMvX4joDfA=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=RzgNkzTA9MUTB2Bx7xyPr7LUAHTgsZ8sLHyDK8aGijcKPRQNzNkAmnG6yiZSuQhcs yI8Gmj4X6KKAKSKOFJh3SWDPwmIhQYIHXQUwMnl3k4HWlvb42PJECd5XXAk1i4RZZI DCs+e0noqLv2OcGaI+ygnLy/EgOoj+kreg4afFtY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Date: Fri, 30 Apr 2021 20:49:17 +0200 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: <20210430184917.GC2031@voyager> References: <3b4d958a-f00e-564a-7715-c92d7592ce3f@greenwavesystems.com> <20210430001301.GW2546@brightrain.aerifal.cx> <20210430123803.GX2546@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Provags-ID: V03:K1:ZlzCyxvPGNjV2+eFY/WEgFYKkwobIo2m59/1xnleLtUhWjC0zZ1 wiVojWeDk5/bnldbiPC38ToyHUSec/xJq6MuLwX/MkSmBRvY67Ju3k6Nh2jwGVm0TAYhEEx 0hE/GZLItTPJ5ypdmrxVrswRkbu+99YZxhqkM39eiK3lVWxWTclOvHHnFOoHDHkoLuY9CxZ 5Jc183rAwh/aEfL4CW2oA== X-UI-Out-Filterresults: notjunk:1;V03:K0:jZ1CYB7PnKg=:EV4ru+p6viCQB9rxRv/mpj J5lFhdpRNKlAZu9y4pyZcBxTDATuFmqkyd4aCitUv8ID9fCPAWZHWKuGaPOrt+RGl8z/+DKXz GGzJetGxd0nLMcfv5k8Es/fe+of8cc4IKHXmphYndd5RFdIlE8UNGSUvsnMJkX4KAypDKMtNI nUFKPiBTzozzCziSF2P+4ymiw1+9g4apNp7AgAOex8JdtNoU+qUaW5kILuhqOhxqY4bUprolA jfq9uXh33ww7SlrfYEn1fPP28aHzyiETSZKB92xRGYdBlsT7fzHsJGWvo/v+XfBbU2LMp7szs ioTTkm2QUWPBFS+vi40GKzGqlGNKXBBAjoSYO5I3oBxV1bi2BfLG8X8HxyVcRaVV6fcPY7wgQ UqmGOa7uIB8SBd0ykLlWWDd2WcCQt/HAk2AYOXv11OH3x6FNa1sJ69IIgYOkpoPiCg+LdWS+b hIDkMf1k7mgFOqImG17gUqOm8X75HxWmPxyEy+2GrzIRcETMxEgpDYbSqtQpBDj0XGFwqYTwq jQeCoMXOVKJ/takWyuZpM3dag02NebK2JDLMWFWxI0JTm+vBm4jGrqT/QHdjFbjzzCmGQed69 PO6fKENo7L0Zq1l1kHZyFS9zeLIaJtlZLLiV7My90nGdUjFRTdPnCP3bwczxePqwnEFxaGA1S 0GDSbnkBaxiffwzaaDsxFcjDlDC5O9rBK3nPrbT7keSLoRv8wJ/xL3eg6ua2LA32mMDXdVpb1 1+rLuCWKtuoAzhYZPIA95aC7hNy709iN0SJmOsZQh7lleBmz62i95InwIXIFSwEF47PRgULAm zSGu61yYSdFUF+mzqX6MzjfJDqhpJSNmBFG+k8vBFX/iqbxb2+rj3vYMkYhn/uAM9cVCgDwi1 yUMn4DFOvI4cPkQjfdETB0ASzP34rEKGPMzvLFxv0c5X79rGDL1Yr2wigEUfQr2IjK8ZTYJaN JAaEyI9cYl9D/mkI1KMBS+POXq9ukBqG6pxLoon96uUnW8quyuD8dTmIftaS2pWLMrv+jtjac sq7w/xaRXCHC/jMND3tdGPenHpYe6y4GIx8u/F/jfJacC7Rh7gIcfEhdd+/1ANp/PIxj8tBNO /G65kXLDADyGrWVv84/GChBn/7OTcQBzxA9p0loomqtELaWAjj4fsGS4HHaJZU65RNeFVS7Qg QfSElNRwAsah2O/7PgpyKsnc6oBlPF0wqxZ7PTLH+D1xMR/4hcD0spyxeSa9kM+N89goM= Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] getaddrinfo/AI_ADDRCONFIG with ipv6 disabled 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 er= rors... > > 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". Ciao, Markus