Re: audit_pid with multiple userspace auditd processes
Steve Grubb wrote:
On Wednesday 07 January 2009 06:11:37 pm Linda Knippers wrote:
> The first makes more sense to me. If an auditd is happily running,
> starting a second one is an error.
Yes, but how can you detect that on an async protocol? The kernel would have
to look and verify the original pid is alive, then look to see if there is a
matching netlink socket for that pid.
Eric said that if you start the auditd using the init script, the right
thing happened (the auditd didn't start?). Couldn't auditd do the same
check itself, whatever that check is?
At some point in the past, the kernel only knew that an auditd was dead on
attempting to use the socket. I don't know if its still the same way, but if
it were, then you don't really know if the audit daemon is alive so you may
as well trust the second one under the assumption that its a restarted daemon
to replace the crashed one the kernel didn't know about yet.
> Disconnecting a running auditd seems problematic. What happens to audit
> messages in flight?
It just won't get anything and will error out next time it tries to read
events.
> Is there a race where both auditds will be writing to
> the log?
Yes, that is why the first needs to go away.
I think the second shouldn't start.
I was actually talking about the case where:
auditd 1 reads record A
auditd 2 starts and takes over
auditd 2 reads record B
auditd 2 writes record B
auditd 1 writes record A
If auditd 2 can start while auditd 1 is still alive, that seems
bad. You either get records out of order or, if you kill auditd 1,
you lose record A.
-- ljk