This is the mail archive of the
mailing list for the glibc project.
Re: Friendlier EPERM - Request for input
- From: ebiederm at xmission dot com (Eric W. Biederman)
- To: Carlos O'Donell <carlos at systemhalted dot org>
- Cc: Eric Paris <eparis at redhat dot com>, Jakub Jelinek <jakub at redhat dot com>, Casey Schaufler <casey at schaufler-ca dot com>, linux-kernel at vger dot kernel dot org, libc-alpha at sourceware dot org, dwalsh at redhat dot com, dmalcolm at redhat dot com, sds at tycho dot nsa dot gov, segoon at openwall dot com, linux-security-module at vger dot kernel dot org
- Date: Sun, 20 Jan 2013 16:59:35 -0800
- Subject: Re: Friendlier EPERM - Request for input
- References: <1357747463.2593.28.camel@localhost><1357760637.2593.55.camel@localhost><50EDCFC0.firstname.lastname@example.org><1357763560.1342.7.camel@localhost> <50EDD8D4.email@example.com><20130109205947.GE26036@sunsite.ms.mff.cuni.cz><1357765795.1342.21.camel@localhost><50EDEC85.firstname.lastname@example.org> <email@example.com>
firstname.lastname@example.org (Eric W. Biederman) writes:
> Carlos O'Donell <email@example.com> 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.
Certainly I would suggest starting there for better explanaitions of why
If you want good error messages certainly some amount of help from user
space appears necessary.