mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Markus Wichmann <nullplan@gmx.net>
To: musl@lists.openwall.com
Subject: Re: [musl] getaddrinfo/AI_ADDRCONFIG with ipv6 disabled
Date: Fri, 30 Apr 2021 20:49:17 +0200	[thread overview]
Message-ID: <20210430184917.GC2031@voyager> (raw)
In-Reply-To: <CAH8yC8nTwTST1YP_tteuEFOk0aqEwsg-+ptjjQp9zS4DpPuxDw@mail.gmail.com>

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".

Ciao,
Markus

  reply	other threads:[~2021-04-30 18:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-05  2:44 Bob Richmond
2021-04-30  0:13 ` [musl] " Rich Felker
2021-04-30 12:38   ` Rich Felker
2021-04-30 16:40     ` Bastian Bittorf
2021-04-30 16:52       ` Rich Felker
2021-04-30 17:59         ` Julian Squires
2021-04-30 16:59     ` Jeffrey Walton
2021-04-30 18:49       ` Markus Wichmann [this message]
2021-04-30 19:50         ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210430184917.GC2031@voyager \
    --to=nullplan@gmx.net \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).