[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Possible performance bug



On Friday 09 September 2005 17:36, Linda Knippers wrote:
> Chris Wright wrote:
> > * Steve Grubb (sgrubb redhat com) wrote:
> > 
> >>So, what about re-enabling these for existing processes when audit_enabled 
> >>changes to 1 again? That's the part I was kinda stuck at. I don't think we 
> >>constantly want to set the thread info.
> > 
> > 
> > fresh out of good ideas ;-)
> > 
> > that's partly why i'm curious if that patch makes a difference.  if it
> > doesn't then we can go with current method.  same issue for lsm, and the
> > rule of thumb is to make sure you're enabled from bootup, otherwise you
> > have to check every process either at load time or lazily at syscall
> > entrance.  doing it at load time is ugly and discouraged (requires
> > walking tasklist), and lazy method undoes the benefits of the patch.
> 
> Would it be better to not allow auditing to be enabled after boot
> then?  I'm concerned about the case where auditing isn't started
> at boot time but enabled later.  There could be alot of processes
> that won't be audited.  If things can't be both dynamic and correct
> then I vote for correct.
> 
> -- ljk
> 
> --
> Linux-audit mailing list
> Linux-audit redhat com
> http://www.redhat.com/mailman/listinfo/linux-audit
> 
> 

Why not always enable the audit subsystem at boot (if it's configured)
always and then in rc.local or whatever, disable it via auditctl.  That 
way if you re-enable later, those processes can be audited.

-tim




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]