Re: [RFC PATCH] specs: update message dictionary with source column

On Tue, Jul 25, 2017 at 10:51 PM, Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: > On 2017-07-25 14:14, Paul Moore wrote: >> On Mon, Jul 24, 2017 at 11:48 PM, Richard Guy Briggs <rgb(a)redhat.com&gt;

>> > On 2017-07-24 11:52, Steve Grubb wrote: >> >> On Monday, July 24, 2017 10:40:08 AM EDT Richard Guy Briggs wrote: >> >> > Add a column to indicate the source of the message, including >> >> > indicating >> >> > whether or not it is related to syscalls. >> >> > >> >> > Column name: SOURCE >> >> > >> >> > Key: >> >> > CTL Control messages, usually initiated by audit daemon. >> >> >> >> Most of these come from auditctl. Auditd only sends enable and setpid. >> > >> > I had considered auditctl as part of the audit daemon, as opposed to >> > pam, systemd, vsftpd et al that supply user event messages, though I >> > suppose even systemd wants to play audit controller too ... >> >> I think trying to chase down which application is trying to manage the >> audit subsystem is a losing battle. In fact, I honestly would >> probably shrink this "source" list down to just a few possible values: >> kernel, userspace, and control. I'm not convinced that granularity >> below this level is particularly useful, and could be confusing. > > So I'm guessing from this comment that you think one column is sufficient? To specify the source, yes. If you want to classify the messages that is best done in a second column, IMHO. > I'd really like to further break "kernel" down into "syscall" and > "independent/autonomous". Two thoughts: 1) Is this important? I know this is front in your mind as you are dealing with issues around this at the moment, but outside of your recent experience I don't see a lot of value in this information, only overhead in keeping it updated/correct.

2) Is this "source" information? I would argue "no" as they all come from the kernel. *If* you feel this is truly important (see thought #1) then I would rather see this in a separate column.