Re: [PATCH v2] audit: report audit wait metric in audit status reply
On Fri, Dec 4, 2020 at 3:41 PM Paul Moore <paul(a)paul-moore.com> wrote:
On Thu, Dec 3, 2020 at 9:47 PM Steve Grubb <sgrubb(a)redhat.com>
wrote:
> On Thursday, December 3, 2020 9:16:52 PM EST Paul Moore wrote:
> > > > > Author: Richard Guy Briggs <rgb(a)redhat.com>
> > > > > AuthorDate: 2014-11-17 15:51:01 -0500
> > > > > Commit: Paul Moore <pmoore(a)redhat.com>
> > > > > CommitDate: 2014-11-17 16:53:51 -0500
> > > > > ("audit: convert status version to a feature bitmap")
> > > > > It was introduced specifically to enable distributions to
selectively
> > > > > backport features. It was converted away from AUDIT_VERSION.
> > > > >
> > > > > There are other ways to detect the presence of
> > > > > backlog_wait_time_actual
> > > > > as I mentioned above.
> > > >
> > > > Let me be blunt - I honestly don't care what Steve's audit
userspace
> > > > does to detect this. I've got my own opinion, but Steve's
audit
> > > > userspace is not my project to manage and I think we've
established
> > > > over the years that Steve and I have very different views on what
> > > > constitutes good design.
> > >
> > > And guessing what might be in buffers of different sizes is good
design?
> > > The FEATURE_BITMAP was introduced to get rid of this ambiguity.
> >
> > There is just soo much to unpack in your comment Steve, but let me
> > keep it short ...
> >
> > - This is an enterprise distro problem, not an upstream problem. The
> > problems you are talking about are not a problem for upstream.
>
> You may look at it that way. I do not. Audit -userspace is also an
upstream
> for a lot of distros and I need to make this painless for them. So,
while you
> may think of this being a backport problem for Red Hat to solve, I think
of
> this as a generic problem that I'd like to solve for Debian, Suse,
Ubuntu,
> Arch, Gentoo, anyone using audit. We both are upstream.
I intentionally said "enterprise Linux distributions", I never singled
out RH/IBM. Contrary to what RH/IBM marketing may have me believe, I
don't consider RHEL to be the only "enterprise Linux distribution" :)
Beyond that, while I haven't looked at all of the distros you list
above, I know a few of them typically only backport fixes, not new
features. Further, as I mentioned previously in this thread, there is
a way to backport this feature in a safe manner without using the
feature bits. Eeeeeven further, if there wasn't a way to backport
this feature safely (and let me stress agai that you can backport this
safely), I would still consider that to be a distro problem and not an
upstream kernel problem. The upstream kernel is not responsible for
enabling or supporting arbitrary combinations of patches.
--
paul moore
www.paul-moore.com
--
Linux-audit mailing list
Linux-audit(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
Hi Steve, Paul,
I'm replying with the Gmail UI since I don't have my Mutt setup handy, so
apologies for any formatting which doesn't align with the mailing list best
practices!
First off, my apologies for being late to the thread, and for submitting
code
to the kernel and user space which aren't playing nicely with each other.
It sounds like there's a decision to be made around whether or not to use
the bitmap feature flags which I probably am probably not in a position to
help decide. However, I'm more than happy to fix my userspace PR so
that it does not rely on the feature flag space using the approach Paul
outlined, in spite of the drawbacks, if that ends up being the decision.
Steve, I understand your preference to rely on the feature bitmap since it
is a more reliable way to determine the availability of a feature than
key size, but if you're open to Paul's recommendations in spite of the
drawbacks, I'll make the changes to my patch as soon as I can to unblock
your work.
Separately, since there is tension between these two approaches
(structure size and bitmap), I wonder if Paul/Steve you would be open
to a third way.
For example, I can imagine adding additional bitmap
spaces (FEATURE_BITMAP_2, FEATURE_BITMAP_3, etc.).
Alternately, I can imagine each feature being assigned a unique u64
ID, and user space programs querying the kernel to see whether a
a particular feature is enabled.
I'm not familiar enough with the kernel to be able to judge how sound
either idea is (or if these have been considered and rejected in the past)
but if you all think a third way is viable, I'd be happy to start a separate
mailing thread to try to thread the competing requirements of the kernel
and userspace, and contribute code if we can find a solution.
Max
Attachments:
- attachment.html (text/html — 6.3 KB)