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:24:19 -0500 Message-ID: <200901071824.19764.sgrubb@redhat.com> References: <1231364199.31089.61.camel@localhost.localdomain> <200901071807.45011.sgrubb@redhat.com> <496536A9.3080707@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <496536A9.3080707@hp.com> 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: Linda Knippers Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Wednesday 07 January 2009 06:11:37 pm Linda Knippers wrote: > The first makes more sense to me. =C2=A0If 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 h= ave=20 to look and verify the original pid is alive, then look to see if there i= s a=20 matching netlink socket for that pid.=20 At some point in the past, the kernel only knew that an auditd was dead o= n=20 attempting to use the socket. I don't know if its still the same way, but= if=20 it were, then you don't really know if the audit daemon is alive so you m= ay=20 as well trust the second one under the assumption that its a restarted da= emon=20 to replace the crashed one the kernel didn't know about yet. > Disconnecting a running auditd seems problematic. =C2=A0What happens to= audit > messages in flight? It just won't get anything and will error out next time it tries to read=20 events. > Is there a race where both auditds will be writing to=20 > the log?=20 Yes, that is why the first needs to go away. -Steve