Possible performance bug

[Chris Wright]

* Linda Knippers (linda.knippers at hp.com) wrote:
> Chris Wright wrote:
> > * Linda Knippers (linda.knippers at hp.com) wrote:
> > 
> >>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.
> > 
> > That would also mean you can't disable dynamically (as it would be
> > a reboot to turn it back on).  This sounds overally restrictive.
> 
> You could turn things off dynamically.  At least the admin would
> see the expected behavior, and hopefully without continuing to pay
> the performance penalty.  Its turning things on that's a problem
> if the system is in a state where some processes are audited and
> some aren't.

Understood, it's arguably violating the principle of least surprise to
allow disable but not enable.

> If someone wants auditing, then I assume they want
> correct behavior.  Has anyone checked to make sure that auditd is
> really started early enough that the current behavior is ok?  Maybe
> it is for CAPP but is it for a random admin who wants auditing?

Should be OK if you use kernel boot param.

> > I'd vote for documented and left up to admin (with sane default).
> 
> What's the sane default?

Same as audit=1 bootparam.

> > It's pretty useful (at least from development perspective ;-) to disable,
> > then re-enable.
> 
> Yep, its been useful, but I've also not testing what I thought I was
> testing because of the current behavior.  Bummer.

Heh, good point.