Message-ID: <871udfmmkx.fsf@xmission.com>
Date:	Sun, 20 Jan 2013 16:00:46 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Carlos O'Donell <carlos@...temhalted.org>
Cc:	Eric Paris <eparis@...hat.com>, Jakub Jelinek <jakub@...hat.com>,
	Casey Schaufler <casey@...aufler-ca.com>,
	linux-kernel@...r.kernel.org, libc-alpha@...rceware.org,
	dwalsh@...hat.com, dmalcolm@...hat.com, sds@...ho.nsa.gov,
	segoon@...nwall.com, linux-security-module@...r.kernel.org
Subject: Re: Friendlier EPERM - Request for input

Carlos O'Donell <carlos@...temhalted.org> writes:

> On 01/09/2013 04:09 PM, Eric Paris wrote:
>> On Wed, 2013-01-09 at 21:59 +0100, Jakub Jelinek wrote:
>>> On Wed, Jan 09, 2013 at 12:53:40PM -0800, Casey Schaufler wrote:
>>>> I'm suggesting that the string returned by get_extended_error_info()
>>>> ought to be the audit record the system call would generate, regardless
>>>> of whether the audit system would emit it or not.
>>>
>>> What system call would that info be for and would it be reset on next
>>> syscall that succeeded, or also failed?
>>>
>>> The thing is, various functions e.g. perform some syscall, save errno, do
>>> some other syscall, and if they decide that the first syscall should be what
>>> determines the whole function's errno, just restore errno from the saved
>>> value and return.  Similarly, various functions just set errno upon
>>> detecting some error condition in userspace.
>>> There is no 1:1 mapping between many libc library calls and syscalls.
>>> So, when would it be safe to call this new get_extended_error_info function
>>> and how to determine to which syscall it was relevant?
>
> I asked the same questions as Jakub asked but in a slightly different
> formulation (http://cygwin.com/ml/libc-alpha/2013-01/msg00267.html).
>  
>> I was thinking of it to be the last kernel error.  So if the first and
>> that second operation caused the kernel to want to make available
>> extended errno information you would end up with the second.  I see this
>> is an informative piece of information, not normative.  Not a
>> replacement for errno.  I'm hoping for a best effort way to provide
>> extended errno information.
>
> IMO Casey's answer is the right solution i.e. whatever the errno
> behaviour was.

Let me propose a different mechanism for getting this to user space
that gives you a save/restore ability.

When a system call returns with an error we return the error code
in one register and leave the rest of the registers that calling
conventions allow us to stomp unchanged.

On i386 (probabaly our most constraint architecture) that gives us
4 32bit registers or 16 bytes/characters to play with.

Returning either an exteneded error number or a short
string in those extra bytes should be very doable, and largely
backwards compatible.

Then in userspace for those applications who care you can
have a "struct exteneded_error" that holds the extra information.

To use that information I expect you want something like:

char *explain_error(int (*failed_func)(...), int errno, struct extended_error *error);

Where explain_error could possibly deduce things even if there
is no side channel information in the kernel. (i.e. You got EPERM
because the permissions are 0700 and you don't own the file.)

Having the core information returned in registers (that are saved by
signal handling) and having a structure of a fixed size that you can
save and restore should help.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists