Re: [RFC][PATCH] audit: log join and part events to the read-only multicast log socket
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