On Wednesday 18 April 2007 12:47, James Antill wrote: > Does this deal with the case where the application catches SIGSEGV, and > then calls abort() (or just raises SIGABRT).
>From this hook, no. It just doesn't have the visibility for that. > Also in a more general way, I'm pretty sure you'd also want to know > whenever abort()/raise(SIGABORT) is done, at least all the times I've > seen those calls it's the same thing as a SIGSEGV situation from the > applications POV. Not really, there are a surprising number of apps that consider abort() to be a normal way of exiting when there's a minor problem. I've never seen any app catch SIGSEGV and then raise(sigabort). > The only thing I can think against this is that _very rarely_ a > sysadmin will do a "kill -ABRT" to stop a problem application ... which > I assume is why you've filtered it? No, its because you get a lot of programs ending with abort - hald-addon-acpi and dhcdbd to name a couple. > But even then is a "spurious" audit event that bad? It was frequent enough I didn't want that noise in the logs at this point. If those applications get cleaned up, I think we could allow abort() to go through. -Steve -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
