Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Eric Paris <eparis <at> redhat.com>
Subject: Re: Friendlier EPERM - Request for input
Newsgroups: gmane.linux.kernel.lsm
Date: Wednesday 9th January 2013 21:09:55 UTC (over 4 years ago)
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

--
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
CD: 3ms