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