linux-audit
Unrelated: AUDIT_FEATURE_VERSION and AUDIT_FEATURE_BITMAP
Looking through the userspace audit code when trying to debug a new feature, I came across a compiler directive that was used a number of times and I don't understand why.
In particular, in lib/libaudit.c, lib/netlink.c, src/auditctl-listing.c, src/auditctl.c, I see:
#if defined(HAVE_DECL_AUDIT_FEATURE_VERSION) &&
defined(HAVE_STRUCT_AUDIT_STATUS_FEATURE_BITMAP)
used together which does not make sense since they are unrelated.
The AUDIT_FEATURE_BITMAP has nothing to do with AUDIT_FEATURE_VERSION.
This naming was short-sighted in retrospect.
AUDIT_SET_FEATURE (audit_set_feature()), AUDIT_GET_FEATURE (audit_request_features()) and AUDIT_FEATURE_LOGINID_IMMUTABLE (and unused AUDIT_FEATURE_ONLY_UNSET_LOGINUID) are related and present when AUDIT_FEATURE_VERSION is present and positive. They allow a kernel feature named in audit_feature_names[] to be turned off or oon and unlocked or locked.
AUDIT_VERSION_* (deprecated), AUDIT_FEATURE_BITMAP_* along with the struct audit_status.feature_bitmap (STRUCT_AUDIT_STATUS_FEATURE_BITMAP) are used to simply determine if the kernel supports such a feature, extracted by audit_get_features() via load_feature_bitmap() and stored in features_bitmap (AUDIT_FEATURES_UNSET, AUDIT_FEATURES_UNSUPPORTED).
Most (if not all) of the uses of the compiler directive above should be just the first half, HAVE_DECL_AUDIT_FEATURE_VERSION.
The use in lib/libaudit.h of AUDIT_FEATURE_BITMAP_ALL in struct audit_reply->features should instead be HAVE_DECL_AUDIT_FEATURE_VERSION.
The test in configure was modified a while back and some #ifdefs changed. It wasn't a complete fix as requested here but seemed to be enough to solve some kernel patch backporting issues. Do we still have any problems that needs addressing at this point?
On 2019-01-24 03:32, Steve Grubb wrote:
The test in configure was modified a while back and some #ifdefs changed. It wasn't a complete fix as requested here but seemed to be enough to solve some kernel patch backporting issues. Do we still have any problems that needs addressing at this point?
I'll take a fresh look to see if it has been addressed, but the main issue was the two ideas are not related and it was coded as if they were.
On 2019-01-24 11:50, Richard Guy Briggs wrote:
On 2019-01-24 03:32, Steve Grubb wrote:
The test in configure was modified a while back and some #ifdefs changed. It wasn't a complete fix as requested here but seemed to be enough to solve some kernel patch backporting issues. Do we still have any problems that needs addressing at this point?
I'll take a fresh look to see if it has been addressed, but the main issue was the two ideas are not related and it was coded as if they were.
Nope, a fresh look at this comes to the exact same conclusion. Stuff was added to fix things, but the bits to which they were added weren't deleted that were unrelated. And the lib/libaudit.h struct audit_reply fix was the wrong one.
Posted v1: https://www.redhat.com/archives/linux-audit/2020-December/msg00012.html