On 2020-12-07 16:13, Max Englander wrote: > On Fri, Dec 4, 2020 at 3:41 PM Paul Moore <p...@paul-moore.com> wrote: > > > On Thu, Dec 3, 2020 at 9:47 PM Steve Grubb <sgr...@redhat.com> wrote: > > > On Thursday, December 3, 2020 9:16:52 PM EST Paul Moore wrote: > > > > > > > Author: Richard Guy Briggs <r...@redhat.com> > > > > > > > AuthorDate: 2014-11-17 15:51:01 -0500 > > > > > > > Commit: Paul Moore <pmo...@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@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.
Max, Steve: have you looked at my reply in this thread from 2020-12-03 18:10? There are two solutions in there that should work without relying on the unreliable test for structure size that work without changing the currently commited kernel code. Or have I missed something? > 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 - RGB -- Richard Guy Briggs <r...@redhat.com> Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635 -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit