Message-ID: <871udfl5ag.fsf@xmission.com>
Date:	Sun, 20 Jan 2013 16:59:35 -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

ebiederm@...ssion.com (Eric W. Biederman) writes:

> 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);

Hmm.  It seems it seems someone else has already written libexplain.
http://libexplain.sourceforge.net/

Certainly I would suggest starting there for better explanaitions of why
things fail.

If you want good error messages certainly some amount of help from user
space appears necessary.

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