Re: [RFC][PATCH] audit: log join and part events to the read-only multicast log socket
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