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

[Paul Moore <pmoore@redhat.com>]

On Wednesday, October 22, 2014 05:18:37 PM Steve Grubb wrote:
> On Wednesday, October 22, 2014 05:00:03 PM Paul Moore wrote:
> > On Wednesday, October 22, 2014 04:39:49 PM Steve Grubb wrote:
> > > Except you can have problems when the event is like this
> > > auid= pid= old uid= new uid= res=
> > 
> > I honestly don't see the problem here.
> 
> You'll never get new uid which is really the one you want.

Once again, I honestly don't see the problem here as I think we should be able 
to write a parser to handle this.
 
> > > > I disagree about the priority.  Eric disagrees about the priority.
> > > > Richard hasn't explicitly stated he disagrees with the priority but he
> > > > has  made several comments on this list about ordering being an issue
> > > > (Richard, my apologies if I am putting words in your mouth).
> 
> I thought it was a question of what to put in an event.

It is an issue of code reuse/duplication and how the fixed field ordering is 
turning the kernel code into a mess.

> > > What events do people need to change and why? There's not been any
> > > discussion that I know of saying we need to add fields or change them
> > > around.
> > 
> > See the earlier comments on Richard's patch.
> 
> He's making a new event. Its not changing things around.

See above.

> > > > What would we need to change in the userspace to eliminate the
> > > > reliance on field ordering?
> > > 
> > > Many of the utilities. ausyscall & autrace might be the only ones not
> > > affected.
> > 
> > So we would need to change ausyscall and autrace, possibly others.
> 
> Exactly the opposite, those are about the only ones clean because they are
> the only ones not parsing logs.

Gotcha, I misread that sentence.

> > Do you expect to need any changes to the deamon or audit libraries?
> 
> Not the daemon or library directly for this. But if you want to look into
> this, you'll need some really big logs for testing. You'll need at least
> 100MB to see performance variations. If we can keep performance reasonably
> close, I'd take patches. I know it will be slower.

Define "reasonably close".  Also, do you have any "really big" logs you use 
for testing?

-- 
paul moore
security and virtualization @ redhat