From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: [RFC][PATCH] audit: log join and part events to the read-only multicast log socket Date: Wed, 22 Oct 2014 10:34:40 -0400 Message-ID: <2336639.NQ575CiUBH@x2> References: <30ef5c1ba42b52953e5684a0322975c3f0fadc77.1412706089.git.rgb@redhat.com> <1645943.LlOpH1gJUB@sifl> <20141022012405.GP15532@madcap2.tricolour.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20141022012405.GP15532@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 Tuesday, October 21, 2014 09:24:05 PM Richard Guy Briggs wrote: > On 14/10/21, Paul Moore wrote: > > On Tuesday, October 21, 2014 03:56:10 PM Steve Grubb wrote: > > > audit_log_task_info logs too much information for typical use. There are > > > times when you might want to know everything about what's connecting. > > > But in this case, we don't need anything about groups, saved uids, > > > fsuid, or ppid. > > > > > > Its a shame we don't have a audit_log_task_info_light function which > > > only > > > records: > > > > > > pid= auid= uid= subj= comm= exe= ses= tty= > > > > This is getting back to my earlier concerns/questions about field > > ordering, or at the very least I'm going to hijack this conversation and > > steer it towards field ordering ;) > > Well, I've already been pushing it that way because it interferes with > any sort of refactoring that needs to be done to simplify and clean up > the kernel log code. There really are worse problems to solve. Also, all this changing things will keep me from adding new analytical capabilities to the audit tools because I continue to have to re-do the bottom layers instead of progress towards making things better for admins. > > Before we go to much farther, I'd really like us to agree that ordering is > > not important, can we do that? As a follow up, what do we need to do to > > make that happen in the userspace tools? > > At the very least, as I've suggested, agree on at least one more order, > a canonical one, that can provide a much more firm guide how to present > the keywords so that we're not stuck with an arbitrary order that turns > out not to make sense for some reason or another. I think we can create the audit_log_task_info_lite function and use it for your new events. -Steve