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
X-Spam-Level:
X-Spam-Status: No, score=-0.8 required=3.0 tests=BAYES_00,
HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI,SPF_HELO_NONE,
SPF_PASS autolearn=no autolearn_force=no version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
by smtp.lore.kernel.org (Postfix) with ESMTP id C916AC433E0
for ; Tue, 26 Jan 2021 00:12:33 +0000 (UTC)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits))
(No client certificate requested)
by mail.kernel.org (Postfix) with ESMTPS id 1DCDA225AB
for ; Tue, 26 Jan 2021 00:12:32 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1DCDA225AB
Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=iinet.net.au
Authentication-Results: mail.kernel.org; spf=tempfail smtp.mailfrom=linux-audit-bounces@redhat.com
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
[209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
us-mta-26-Zm6PgY18MyOKxakoltP1YA-1; Mon, 25 Jan 2021 19:12:29 -0500
X-MC-Unique: Zm6PgY18MyOKxakoltP1YA-1
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 75CA8180A093;
Tue, 26 Jan 2021 00:12:26 +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 5169E5D74E;
Tue, 26 Jan 2021 00:12:26 +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 A6C5B4A7C6;
Tue, 26 Jan 2021 00:12:07 +0000 (UTC)
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com
[10.11.54.5])
by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
id 10Q0C5Eq013140 for ;
Mon, 25 Jan 2021 19:12:05 -0500
Received: by smtp.corp.redhat.com (Postfix)
id 641367D4E3; Tue, 26 Jan 2021 00:12:05 +0000 (UTC)
Received: from mimecast-mx02.redhat.com
(mimecast02.extmail.prod.ext.rdu2.redhat.com [10.11.55.18])
by smtp.corp.redhat.com (Postfix) with ESMTPS id 5E32A7C4E
for ; Tue, 26 Jan 2021 00:12:03 +0000 (UTC)
Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com
[207.211.31.120])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits))
(No client certificate requested)
by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 1EBB582DFE1
for ; Tue, 26 Jan 2021 00:12:03 +0000 (UTC)
Received: from icp-osb-irony-out8.external.iinet.net.au
(icp-osb-irony-out8.external.iinet.net.au [203.59.1.225]) by
relay.mimecast.com with ESMTP id us-mta-407-5gh0zg5LNBGtWfueyvqyDw-1;
Mon, 25 Jan 2021 19:11:57 -0500
X-MC-Unique: 5gh0zg5LNBGtWfueyvqyDw-1
X-SMTP-MATCH: 1
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2DLBgDnXQ9g/3zSRWpiHAEBAQEBAQc?=
=?us-ascii?q?BARIBAQQEAQFHgUiDeIUiiQSGP4IWAziDbJZBgVwLAQEBAQEBAQEBNQECBAE?=
=?us-ascii?q?BhEQEAgKBeSY4EwIQAQEBBQEBAQEBBgMBhl6FdAEFIzMjEAsEBAYKHA4CAlc?=
=?us-ascii?q?GgzmCVgEBLrJPgTKFRxOCJAaBDYFEgTiGewGGQjWBTT+BR4JjPodXgmAEgj4?=
=?us-ascii?q?GgV2BIRUEDRlBApAsgnqIfopzkRMsB4J6gRgFC4ZRk3YioniGJRixTYF6Mxo?=
=?us-ascii?q?fghYYgRBPGQ2cfjBnAgYKAQEDCVkBAYs6AQE?=
X-IPAS-Result: =?us-ascii?q?A2DLBgDnXQ9g/3zSRWpiHAEBAQEBAQcBARIBAQQEAQFHg?=
=?us-ascii?q?UiDeIUiiQSGP4IWAziDbJZBgVwLAQEBAQEBAQEBNQECBAEBhEQEAgKBeSY4E?=
=?us-ascii?q?wIQAQEBBQEBAQEBBgMBhl6FdAEFIzMjEAsEBAYKHA4CAlcGgzmCVgEBLrJPg?=
=?us-ascii?q?TKFRxOCJAaBDYFEgTiGewGGQjWBTT+BR4JjPodXgmAEgj4GgV2BIRUEDRlBA?=
=?us-ascii?q?pAsgnqIfopzkRMsB4J6gRgFC4ZRk3YioniGJRixTYF6MxofghYYgRBPGQ2cf?=
=?us-ascii?q?jBnAgYKAQEDCVkBAYs6AQE?=
X-IronPort-AV: E=Sophos;i="5.79,375,1602518400";
d="scan'208,217";a="344782267"
Received: from 106-69-210-124.dyn.iinet.net.au (HELO swtf.swtf.dyndns.org)
([106.69.210.124]) by icp-osb-irony-out8.iinet.net.au with ESMTP;
26 Jan 2021 08:11:48 +0800
Message-ID: <702bbf002465236ec84ff4f90b9e159ccc3f327d.camel@iinet.net.au>
Subject: Re: Occasional delayed output of events
From: Burn Alting
To: Steve Grubb
Date: Tue, 26 Jan 2021 11:11:45 +1100
In-Reply-To: <11685937.O9o76ZdvQC@x2>
References: <30c5dbc14368a1919717e2f39d2d4c29463c3108.camel@iinet.net.au>
<6484d9c52b66405ecbe76096fd5e896e5626b216.camel@iinet.net.au>
<11685937.O9o76ZdvQC@x2>
Mime-Version: 1.0
X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection
Definition; Similar Internal Domain=false;
Similar Monitored External Domain=false;
Custom External Domain=false; Mimecast External Domain=false;
Newly Observed Domain=false; Internal User Name=false;
Custom Display Name List=false; Reply-to Address Mismatch=false;
Targeted Threat Dictionary=false;
Mimecast Threat Dictionary=false; Custom Threat Dictionary=false
X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5
X-loop: linux-audit@redhat.com
Cc: Richard Guy Briggs , Linux Audit
X-BeenThere: linux-audit@redhat.com
X-Mailman-Version: 2.1.12
Precedence: junk
Reply-To: burn@swtf.dyndns.org
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.15
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: multipart/mixed; boundary="===============2469345156917520552=="
--===============2469345156917520552==
Content-Type: multipart/alternative; boundary="=-11QS7PlRodL4IsKkLriq"
--=-11QS7PlRodL4IsKkLriq
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
On Mon, 2021-01-25 at 18:53 -0500, Steve Grubb wrote:
> On Saturday, January 23, 2021 5:55:44 PM EST Burn Alting wrote:
> > > > How is the following for a way forward.
> > > > a. I will author a patch to the user space code to correctly parse this
> > > > condition and submit it on the weekend. It will be via a new
> > > > configuration item to auditd.conf just in case placing a fixed
> > > > extended timeout (15-20 secs) affects memory usage for users of the
> > > > auparse library. This solves the initial problem of ausearch/auparse
> > > > failing to parse generated audit.b. I am happy to instrument what ever
> > > > is recommended on my hosts at home (vm's and bare metal) to provide
> > > > more information, should we want to 'explain' the occurrence, given I
> > > > see this every week or two and report back.
> > >
> > > Seems reasonable to me.
> >
> > I can implement the 'end_of_event_timeout' change either as
> > i. a command line argument to ausearch/aureport (say --eoetmo secs) and a
> > new pair of library functions within the auparse() stable (say
> > auparse_set_eoe_timeout() and auparse_get_eoe_timeout())
> > or
> > ii. a configuration item in /etc/audit/auditd.conf, or
> >
> >
> > Which is your preference? Mine is i. as this is a user space processing
> > change, not a demon change.
>
> To be honest, I'm not entirely sure what we're seeing. I run some tests today
> on my system. It's seeing issues also. I'd still like to treat the root cause
> of this. But we do need to change the default. That I what I'm trying to
> figure out.
>
> Back to your question, I'm wondering if we should do both? A changeable
> default in auditd.conf and an override on the command line.
So far, all items in /etc/audit/auditd.conf appear to only affect the daemon. Is
this the right location to start adding non-daemon configuration items? (I accept
there is no other place).
Happy to do both, if required.
> -Steve
>
>
--=-11QS7PlRodL4IsKkLriq
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
On Mon, 2021-01-25 at 18:53 -0500, Steve Grubb wrote:
On Saturday, January 23, 2021 5:55:44 PM EST Burn =
Alting wrote:
How is the following for a way forward.
=
a. I will author a patch to the user space code to correctly parse thi=
s
condition and submit it on the weekend. It will be via a new
configuration item to auditd.conf just in case placing a fixed
extended timeout (15-20 secs) affects memory usage for users of the=
pre>auparse library. This solves the initial problem of ausearch/aupar=
se
failing to parse generated audit.b. I am happy to instrument w=
hat ever
is recommended on my hosts at home (vm's and bare metal)=
to provide
more information, should we want to 'explain' the occ=
urrence, given I
see this every week or two and report back.
Seems reasonable to me.
I can implement the 'end_of_event_timeout' change eith=
er as
i. a command line argument to ausearch/aureport (say --eoet=
mo secs) and a
new pair of library functions within the auparse(=
) stable (say
auparse_set_eoe_timeout() and auparse_get_eoe_timeo=
ut())
or
ii. a configuration item in /etc/audit/auditd.=
conf, or
Which is your preference? =
Mine is i. as this is a user space processing
change, not a demon=
change.
To be honest, I'm not entire=
ly sure what we're seeing. I run some tests today
on my system. =
It's seeing issues also. I'd still like to treat the root cause
=
of this. But we do need to change the default. That I what I'm trying to =
pre>figure out.
Back to your question, I'm wo=
ndering if we should do both? A changeable
default in auditd.con=
f and an override on the command line.
So far, all items in /etc/audit/auditd.conf appear to only affect the dae=
mon. Is this the right location to start adding non-daemon configuration it=
ems? (I accept there is no other place).
Happy to =
do both, if required.
-Steve
--=-11QS7PlRodL4IsKkLriq--
--===============2469345156917520552==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
--===============2469345156917520552==--