From: Eric Paris <eparis@redhat.com>
To: Steve Grubb <sgrubb@redhat.com>
Cc: linux-audit@redhat.com, pmoore@hp.com
Subject: Re: [PATCH] Audit: EINTR instead of kernel private return codes in audit records
Date: Sat, 17 Nov 2007 20:58:33 -0500 [thread overview]
Message-ID: <1195351113.2924.120.camel@localhost.localdomain> (raw)
In-Reply-To: <200711141618.00090.sgrubb@redhat.com>
On Wed, 2007-11-14 at 16:17 -0500, Steve Grubb wrote:
> On Wednesday 14 November 2007 16:07:42 Eric Paris wrote:
> > It should be slightly faster <snip>
> >
> > We would also be picking up ENOIOCTLCMD but that shoudln't be seen on
> > this code path, so I guess it doesn't matter.
>
> Right, the note in the top of include/linux/errno.h says these should not be
> seen by userspace. So, ENOIOCTLCMD is invalid if we ever saw it. But what
> about the NFSv3 errnos (in the same file)? Do we need to worry about those?
So I started looking at these and I like my patch the way I sent it.
Although ENOIOCTLCMD, ENOTSUPP, ETOOSMALL, ESERVERFAULT, EIOCBQUEUED,
and EIOCBRETRY are not supposed to be valid return codes first glance
leads me to believe they could all slip back into userspace. None of
them are later rewritten after we collect the return code in the audit
system. 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.
I suggest the patch be added exactly the way I sent it, as the speed up
suggested (using >= && <=) could give incorrect audit messages vs what
actually happened.
-Eric
next prev parent reply other threads:[~2007-11-18 1:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-14 20:22 [PATCH] Audit: EINTR instead of kernel private return codes in audit records Eric Paris
2007-11-14 20:29 ` Paul Moore
2007-11-14 20:30 ` Steve Grubb
2007-11-14 21:07 ` Eric Paris
2007-11-14 21:17 ` Steve Grubb
2007-11-18 1:58 ` Eric Paris [this message]
2007-11-18 10:58 ` Steve Grubb
2007-11-18 16:52 ` Eric Paris
2007-11-14 21:13 ` Miloslav Trmac
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1195351113.2924.120.camel@localhost.localdomain \
--to=eparis@redhat.com \
--cc=linux-audit@redhat.com \
--cc=pmoore@hp.com \
--cc=sgrubb@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox