From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linda Knippers Subject: Re: audit_pid with multiple userspace auditd processes Date: Wed, 07 Jan 2009 18:11:37 -0500 Message-ID: <496536A9.3080707@hp.com> References: <1231364199.31089.61.camel@localhost.localdomain> <200901071741.20531.sgrubb@redhat.com> <1231368854.31089.73.camel@localhost.localdomain> <200901071807.45011.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200901071807.45011.sgrubb@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com 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@redhat.com > https://www.redhat.com/mailman/listinfo/linux-audit