From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: [PATCH] audit: add feature audit_lost reset Date: Thu, 12 Jan 2017 09:58:56 -0500 Message-ID: <3167746.B3SAJDMsd0@x2> References: <8c740656caee622c9a9f8642ac48f22e1bf6933c.1481869063.git.rgb@redhat.com> <5855056.HprDjFpM62@x2> <20170112041942.GQ7816@madcap2.tricolour.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20170112041942.GQ7816@madcap2.tricolour.ca> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Richard Guy Briggs Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Wednesday, January 11, 2017 11:19:42 PM EST Richard Guy Briggs wrote: > > OK. the code to support this is in svn. However, since we didn't use a > > feature bit like we normally do, there is absolutely no way to report > > that the underlying kernel does not support this. It quietly fails and > > pretends everything is fine. I'd prefer that we had a feature bit to > > output a proper error message. > > Do you still want to switch to CONFIG_CHANGE? (I think that is a good > idea.) Sure. > I agree detecting this feature is a destructive operation requiring an > existing lost count and checking the positive return code, but not > impossible, and would prefer a feature bit. I'd prefer a feature bit so that I can tell people your kernel doesn't support this. Audit runs on a large variety of kernels. > As for audit being immutable, I could see an argument to have this > feature usable even though the config is locked. What's your take? I can see value in resetting the count even when immutable. Perhaps just use its logging function. So we don't have a new record type. -Steve