[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210430184917.GC2031@voyager>
Date: Fri, 30 Apr 2021 20:49:17 +0200
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Subject: Re: 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 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
