Re: [PATCH] Audit: EINTR instead of kernel private return codes in audit records

[Eric Paris <eparis@redhat.com>]

On Sun, 2007-11-18 at 05:58 -0500, Steve Grubb wrote:
> On Saturday 17 November 2007 08:58:33 pm Eric Paris wrote:
> > It would be absolutely wrong for the audit system to translate
> > even ENOIOCTLCMD to anything else if this is what was actually returned
> > to the process.
> 
> The point is, none of the errnos in that file should *ever* go to user space. 
> glibc has no translation (strerror()) for them because they are internal to 
> the kernel. So, they need to get translated to something. My only question is 
> would these extra ones ever get picked up in this code path?

They "should not" get returned to userspace.  I agree.  That doesn't
mean they don't.  All occurences of these error codes being returned to
userspace are bugs, but that has nothing at all to do with this
conversation.  My patch is correct, complete, and the right thing to do.
All syscalls are going to come through here and if they have an
'invalid' return code we need to just audit it, not audit the wrong
thing and then return the 'real' retval to userspace.  Remember this
patch isn't changing what goes back to userspace, its just changing what
we put in the audit log.  Look in any arch/signal.c to see why the 4 I
am dealing with are special and why it is right to audit EINTR even when
at this point it looks like ERESTART*.  

The 4 return codes I am dealing with are changed to be EINTR before they
get back to userspace, thus we should audit EINTR, not ERESTART*.  If
the kernel has a bug which returns ETOOSMALL to userspace the audit
system needs to audit ETOOSMALL, its as simple as that.

A crusade to clean up all of the issues with the 6 things I mentioned in
the last e-mail which may be slipping back to userspace would be a good
thing, heck, I even cleanup up the issue in the audit/selinux system
when they missused ENOTSUPP in a seperate patch, but lying about any of
the 'invalid' return codes in the audit wrong, even if it is a bug they
are there in the first place is flat wrong.

Make sense?

-Eric