|| ||Jakub Jelinek <jakub-AT-redhat.com> |
|| ||Casey Schaufler <casey-AT-schaufler-ca.com> |
|| ||Re: Friendlier EPERM - Request for input |
|| ||Wed, 9 Jan 2013 21:59:48 +0100|
|| ||Eric Paris <eparis-AT-redhat.com>, linux-kernel-AT-vger.kernel.org,
libc-alpha-AT-sourceware.org, dwalsh-AT-redhat.com, dmalcolm-AT-redhat.com,
|| ||Article, Thread
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?
to post comments)