Re: audit_pid with multiple userspace auditd processes
On Wednesday 07 January 2009 05:54:14 pm Eric Paris wrote:
> Well, what if the first crashed and the kernel didn't know
it yet? It
> might be better to forcibly break the connection to the original auditd.
I'm only talking about allowing userspace to "cleanly" unset it's
belief
there is an auditd out there if the message comes from that process.
We'll still handle death by means of the usual netlink socket
failures...
If auditd number 2 is the auditd the kernel knows about why should
auditd number 1 be allowed to "cleanly" say there is no auditd?
Ok, I see what you mean. We can either leave both running but disallow
resetting the pid or forcibly disconnect the first in the kernel. Either way
solves the problem. But doing the second might be cleaner for user space so
two daemons aren't trying to write to the same file.
-Steve