From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id BBC8DC433EF for ; Thu, 3 Mar 2022 22:23:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1646346212; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=Dcy0tEHg604CNdEsZrGhdINhTTgxfdC7/CD8W7scREw=; b=HhjKjDibHVZ7JXrr+2lm2Uh60G84gs9HzDePar9F+V8/BAhUQPrJXOKMcfvqjDF6HhMUk9 uomOEisDAWLM73wAs7gtc3SSun9Gnat8pBNY15ymTgj+Y8oJJTGdf5a1ZdhcAn7Ysm+dZZ a2Ma2OHxJveU9BJjcM3Z6+7CiDhRytM= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-453-nc6l9CWrPa2eU9rMF7ptOw-1; Thu, 03 Mar 2022 17:23:29 -0500 X-MC-Unique: nc6l9CWrPa2eU9rMF7ptOw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 863261006AA5; Thu, 3 Mar 2022 22:23:25 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 91EBF56F6A; Thu, 3 Mar 2022 22:23:24 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 186E14BB40; Thu, 3 Mar 2022 22:23:22 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 223MNL2K001830 for ; Thu, 3 Mar 2022 17:23:21 -0500 Received: by smtp.corp.redhat.com (Postfix) id E789045305; Thu, 3 Mar 2022 22:23:21 +0000 (UTC) Received: from x2.localnet (unknown [10.22.34.61]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8F28E452F0; Thu, 3 Mar 2022 22:23:18 +0000 (UTC) From: Steve Grubb To: linux-audit@redhat.com, Amjad Gabbar Subject: Re: Bug in Queue Statistics? Date: Thu, 03 Mar 2022 17:23:17 -0500 Message-ID: <4855331.GXAFRqVoOG@x2> Organization: Red Hat In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-loop: linux-audit@redhat.com X-BeenThere: linux-audit@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Linux Audit Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=linux-audit-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, On Wednesday, March 2, 2022 4:45:07 PM EST Amjad Gabbar wrote: > Had a couple of concerns that I wanted to discuss: > > 1. > > I was getting a few "auditd queue full" messages in syslog. I had > previously faced similar issues after which I had increased the q_depth and > modified my ruleset to reduce the number of events logged which had > brought down these errors significantly. > I am not sure but the only way I can think that max plugin queue depth used > can be 4294967295 (despite the maxlimit being set to 25000) is if we > dequeue an event before it has been enqueued. Also, the current plugin > queue depth suggests that events are being dequeued continuously leading > to the value decreasing from 4294967295 to 4294967240? I have a feeling this is hard to get into, but is something like the queue gets suspended, reconfigure gets rid of plugins, another reconfigure adds back plugins and this resets the queue depth to 0, but there are events. As it dequeues them it starts getting negative numbers, but the variable is undined int hence the very large numbers. I changed the way that init and reconfigure interact in commit 514d2bd. When the queue is destroyed, it resets all the numbers. Otherwise it will now leave them alone unless q_depth is zero - which means we need to reallocate a queue. > 2. > > Another update that I would like to make is currently, if we reload the > auditd configuration instead of restarting, although the configuration > changes, we do not reset some of the queue statistic variables which I feel > is incorrect. > > https://github.com/linux-audit/audit-userspace/blob/770e4f538103f8a055f46c0 > 4a9e2514f88f175c3/src/auditd-event.c#L1466 > > Ex- If q_depth=400 and the queue overflows, the overflowed variable is set > to 1. On changing the q_depth value to say 10000 and doing a reload, the > queue size has changed and basically so has the queue. I feel here we > should reset some of the queue statistic variables like overflowed as it is > incorrect to say that in it's current form the queue has overflown. This > variable is not reset and I feel that it should be. This sounds reasonable. Commit a8d7515 should fix this. > If agreed that this is a reasonable change, would it be ok if I submit a PR > for the same? It's a 1 liner. Thanks, though. > Also, is it possible that point 2 is causing issues leading to point 1 > errors? No. > 3. Would also like to improve the manpage documentation related to > /var/run/auditd.state. Currently it states that it is a dump of the > internal state. I would like to change that to provide a little more > detail about what the internal state contains - such as queue statistics, > priority etc. That might be a lot to document. I don't know if anything else will get added, but if that happens, we'll have to document that. If this was done, I'd say it should go in the auditd man page. > Apart from that I feel that we can also add an additonal field to the > auditd.state file as to when the queue has overflown which may make it > easier to perform ausearch related queries with start time and end time. Would having it record down to the second be enough? IOW, no sub-second time stamp. If just the second is good enough, I can add that. It's only a couple lines of code. > If any of the changes are worth contributing to I would be happy to make > the said changes. I don't plan to write a description of the state report. I'll take a PR, though. Best, -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit