From mboxrd@z Thu Jan 1 00:00:00 1970 From: LC Bruzenak Subject: Re: audit-1.7.16 released Date: Fri, 13 Nov 2009 19:14:22 -0600 Message-ID: <1258161262.5355.214.camel@lcb> References: <200910171155.43836.sgrubb@redhat.com> <1256568393.3515.4.camel@lcb> <200910301056.20700.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200910301056.20700.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 List-Id: linux-audit@redhat.com On Fri, 2009-10-30 at 10:56 -0400, Steve Grubb wrote: > On Monday 26 October 2009 10:46:33 am LC Bruzenak wrote: > > On Sat, 2009-10-17 at 11:55 -0400, Steve Grubb wrote: > ... > > > > > > - If audisp-remote plugin has a queue at exit, use non-zero exit code > > > - In auditd, tell libev to stop processing a connection when idle timeout > > > - In auditd, tell libev to stop processing a connection when shutting > > > down > > > > > > This release fixes a bug introduced in the 1.7.15 release. The main > > > problem was that the idle timeout was not telling libev to stop > > > processing the associated socket when it closed an idle connection. > > > Subsequent reconnects would go into an error state and libev would > > > immediately close the new connection. This update fixes that problem. I > > > also applied a patch from trunk that checks the queue size on exit of > > > audisp-remote to decide if it was successful or not. > > > > > > Please let me know if you run across any problems with this release. > > > > Is there any indication that this event has happened being logged? > > This was a bugfix where libev was not being told that the connection was closed > by the auditd code. The fix is right below the syslog message saying this > happened. > > -Steve Steve, Thinking about the client network connection timeout... I am wondering if this is a serious enough condition to warrant inserting an audit event in addition to the syslog. For me it is, because sending a termination event from the client is both difficult and unreliable, and I am supposed to provide client (sender) startup/shutdown data. For me, the connection termination is a good indication, so I will probably patch mine. I wonder if it would be helpful for others as well. Thx, LCB. -- LC (Lenny) Bruzenak lenny@magitekltd.com