[RFC][PATCH] audit: log join and part events to the read-only multicast log socket

[Richard Guy Briggs]

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 at 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