audit_pid with multiple userspace auditd processes

[Linda Knippers]

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 at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit