From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Paris Subject: Re: [PATCH] Audit: EINTR instead of kernel private return codes in audit records Date: Sat, 17 Nov 2007 20:58:33 -0500 Message-ID: <1195351113.2924.120.camel@localhost.localdomain> References: <1195071728.2924.40.camel@localhost.localdomain> <200711141530.56256.sgrubb@redhat.com> <1195074462.2924.46.camel@localhost.localdomain> <200711141618.00090.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200711141618.00090.sgrubb@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: linux-audit@redhat.com, pmoore@hp.com List-Id: linux-audit@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 > > > > 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