Re: [RFC][PATCH] audit: log join and part events to the read-only multicast log socket
On 14/10/22, Paul Moore wrote:
On Tuesday, October 21, 2014 09:24:05 PM Richard Guy Briggs wrote:
> On 14/10/21, Paul Moore wrote:
> > Before we go to much farther, I'd really like us to agree that ordering is
> > not important, can we do that? As a follow up, what do we need to do to
> > make that happen in the userspace tools?
>
> At the very least, as I've suggested, agree on at least one more order,
> a canonical one, that can provide a much more firm guide how to present
> the keywords so that we're not stuck with an arbitrary order that turns
> out not to make sense for some reason or another.
No, we're already seeing that a single fixed ordering is bad, adding an
alternate fixed ordering just kicks the can down the road a bit further and
sets a bad precedence for future development. It is time to get rid of the
fixed ordering in the audit records.
The problem is that we don't just have a single fixed ordering. We have
a different fixed ordering for each type of audit log message. This
makes refactoring pretty much impossible or very inefficient at best.
I agree that eliminating that dependency on ordering would be a great
thing. This sounds like a great time to reference Postel's Law or
Robustness Principle first introduced in IETF RFC760 and reworded in
RFC1122: "Be conservative in what you send, be liberal in what you
accept".
paul moore
- RGB
--
Richard Guy Briggs <rbriggs(a)redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545