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 -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit