Re: [PATCH v2] audit: report audit wait metric in audit status reply

From: Steve Grubb <sgrubb@redhat.com>
To: Max Englander <max.englander@gmail.com>,
	linux-audit@redhat.com, Paul Moore <paul@paul-moore.com>
Subject: Re: [PATCH v2] audit: report audit wait metric in audit status reply
Date: Wed, 02 Dec 2020 22:52:34 -0500	[thread overview]
Message-ID: <11647352.O9o76ZdvQC@x2> (raw)
In-Reply-To: <CAHC9VhTctHCCrm4Q1cPdFX-6NXEtmjEPmw6rvUoxOq8UUmycxA@mail.gmail.com>

Hello Paul,

On Thursday, July 2, 2020 4:42:13 PM EST Paul Moore wrote:
> > #define AUDIT_FEATURE_BITMAP_BACKLOG_LIMIT     0x00000001
> > #define AUDIT_FEATURE_BITMAP_BACKLOG_WAIT_TIME 0x00000002
> > @@ -348,6 +349,7 @@ enum {
> > #define AUDIT_FEATURE_BITMAP_SESSIONID_FILTER  0x00000010
> > #define AUDIT_FEATURE_BITMAP_LOST_RESET                0x00000020
> > #define AUDIT_FEATURE_BITMAP_FILTER_FS         0x00000040
> > +#define AUDIT_FEATURE_BITMAP_BACKLOG_WAIT_SUM  0x00000080
> 
> In an effort not to exhaust the feature bitmap too quickly, I've been
> restricting it to only those features that would cause breakage with
> userspace.  I haven't looked closely at Steve's userspace in quite a
> while, but I'm guessing it can key off the structure size and doesn't
> need this entry in the bitmap, right?  Let me rephrase, if userspace
> needs to key off anything, it *should* key off the structure size and
> not a new flag in the bitmask 
> 
> Also, I'm assuming that older userspace doesn't blow-up if it sees the
> larger structure size?  That's even more important.

We need this FEATURE_BITMAP to do anything in userspace. Max's instinct was 
right. Anything that changes the user space API needs to have a 
FEATURE_BITMAP so that user space can do the right thing. The lack of this is 
blocking acceptance of the pull request for the user space piece.

I am in a need of publishing the 3.0 release. This is the only blocker.

-Steve

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit