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

[Richard Guy Briggs <rgb@redhat.com>]

On 14/10/21, Steve Grubb wrote:
> On Tuesday, October 21, 2014 05:08:22 PM Richard Guy Briggs wrote:
> > On 14/10/21, Steve Grubb wrote:
> > > > super crazy yuck.  audit_log_task_info() ??
> > > 
> > > Its a shame we don't have a audit_log_task_info_light function which only
> > > records:
> > 
> > We already have audit_log_task() which gives:
> 
> > And while we are at it, refactor audit_log_task_info() to call
> > audit_log_task()?
> 
> That will cause problems at this point.

Yup.  We already have problems caused by not having this.

> > Yes, it will be in a different order because we don't have a canonical
> > order yet.  Can we accept two orders of keywords so we can start
> > canonicalizing, please?
> 
> I don't understand what you are getting at.

To clarify, if two orders are permitted per message type, one can be the
old one per message type, the second can be a standard order for all
messages, so that any given fields/keywords can be expected eventually
to found in this order, regardless of whether or not they are included
in that particular message type.

If we have a standard order in which keywords/fields are to be presented
then there will be no need to have as much duplicitous code in the
kernel and it will be much easier to get the order "right" in new
messages, but also much easier to scan any message to see if there is
information missing, similar, duplicated or superfluous.

> -Steve
> 
> > > -Steve
> > 
> > - RGB

- 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