Re: Friendlier EPERM - Request for input

[Casey Schaufler <casey@schaufler-ca.com>]

On 1/9/2013 12:59 PM, 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?

It ought to be the same system call that generated the contents of errno.

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

Whichever system call generated the content of errno. If that means
the functions that currently save away errno have to save away the
audit text, that's what it would have to do. Simple. Not necessarily
pleasant, but simple.


> Similarly, various functions just set errno upon
> detecting some error condition in userspace.

Then get_extended_error_info should return NULL.
Or, if the library code prefers, creates its own
audit record in valid audit record format.

> There is no 1:1 mapping between many libc library calls and syscalls.

Truth. I'm suggesting the get_extended_error_info behavior
match the errno behavior.

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

Any time you could look at errno you should be able to get a matching
explanation from get_extended_error_info.


>
> 	Jakub
>