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

Richard Guy Briggs
2014-10-29T21:09:59Z

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