Re: audit_pid with multiple userspace auditd processes
Steve Grubb wrote:
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.
The first makes more sense to me. If an auditd is happily running,
starting a second one is an error. Disconnecting a running auditd
seems problematic. What happens to audit messages in flight? Is
there a race where both auditds will be writing to the log?
-- ljk
-Steve
--
Linux-audit mailing list
Linux-audit(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit