There were two formats of the audit MAC_STATUS record, one of which was morestandard than the other. One listed enforcing status changes and theother listed enabled status changes with a non-standard label. Inaddition, the record was missing information about which LSM wasresponsible and the operation's completion status. While this record isonly issued on success, the parser expects the res= field to be present.

It needs to be said again that I'm opposed to changes like this:inserting new fields, removing fields, or otherwise changing theformat in ways that aren't strictly the addition of new fields to theend of a record is a Bad Thing. However, there are exceptions (thereare *always* exceptions), and this seems like a reasonable change thatshouldn't negatively affect anyone.

I'll merge this once the merge window comes to a close (we are goingto need to base selinux/next on v4.17-rc1).

inserting new fields, removing fields, or otherwise changing theformat in ways that aren't strictly the addition of new fields to theend of a record is a Bad Thing. However, there are exceptions (thereare *always* exceptions), and this seems like a reasonable change thatshouldn't negatively affect anyone.I'll merge this once the merge window comes to a close (we are goingto need to base selinux/next on v4.17-rc1).

Merged into selinux/next, although I should mention that there weresome actual code changes because of the SELinux state consolidationpatches that went into v4.17. The changes were small but please takea look and make sure everything still looks okay to you.

inserting new fields, removing fields, or otherwise changing theformat in ways that aren't strictly the addition of new fields to theend of a record is a Bad Thing. However, there are exceptions (thereare *always* exceptions), and this seems like a reasonable change thatshouldn't negatively affect anyone.I'll merge this once the merge window comes to a close (we are goingto need to base selinux/next on v4.17-rc1).

Merged into selinux/next, although I should mention that there weresome actual code changes because of the SELinux state consolidationpatches that went into v4.17. The changes were small but please takea look and make sure everything still looks okay to you.

inserting new fields, removing fields, or otherwise changing theformat in ways that aren't strictly the addition of new fields to theend of a record is a Bad Thing. However, there are exceptions (thereare *always* exceptions), and this seems like a reasonable change thatshouldn't negatively affect anyone.I'll merge this once the merge window comes to a close (we are goingto need to base selinux/next on v4.17-rc1).

Merged into selinux/next, although I should mention that there weresome actual code changes because of the SELinux state consolidationpatches that went into v4.17. The changes were small but please takea look and make sure everything still looks okay to you.

Ok, that was a bit disruptive, but looks ok to me.

Yes, it was a pretty big change, but it sets the stage for a fewthings we are trying to do with SELinux.