Re: Friendlier EPERM - Request for input

[Eric Paris <eparis@redhat.com>]

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

It would be really neat for libc to have a way to save and restore the
extended errno information, maybe even supply its own if it made the
choice in userspace, but that sounds really hard for the first pass.

I mean it would be great if we could rewrite every system call with a
cookie so userspace could reliably match things back up, but I just
don't see that as practical.  Instead we do the best we can and help
admins and developers most of the time, instead of none of the time.

-Eric