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 > [email protected] > https://www.redhat.com/mailman/listinfo/linux-audit -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
