ausearch question

[Burn Alting]

On Mon, 2014-04-07 at 09:59 -0400, Steve Grubb wrote:
> On Monday, April 07, 2014 04:29:34 PM Burn Alting wrote:
> > All,
> > 
> > I note when interpreting raw audit with the ausearch --interpret option,
> > the code in src/ausearch-report.c:output_interpreted_node(), when
> > parsing key value pairs which are not enclosed in double or single
> > quotes, looks for embedded comma's in the value part and, if found,
> > effectively terminates the value at the comma. This in effect, makes the
> > data after the comma the start of the next key (if any). There are some
> > exceptions in the code (audit_type == AUDIT_VIRT_MACHINE_ID,
> > AUDIT_OBJ_PID, AUDIT_PATH and AUDIT_IPC).
> 
> I presume we are talking about this area of code:
> https://fedorahosted.org/audit/browser/trunk/src/ausearch-report.c#L276

Yep.

> 
> > What sort of input is this addressing?
> 
> The audit system has migrated its events slowly over time. The current code 
> base can read/search/report/interpret audit events all the way back to about 
> the 2004 time frame. So, sometimes you find things that are left over from long 
> ago. But you might need this legacy support if the tools are on an aggregating 
> server.

Understood.

> 
> 
> > Are there examples?
> 
> type=USER_ACCT msg=audit(1223987805.696:8): user pid=4885 uid=0 
> auid=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='PAM: 
> accounting acct="sgrubb" : exe="/usr/sbin/gdm-binary" (hostname=?, addr=?, 
> terminal=:0 res=success)'
> 
> Up until around 2010, all user space originating events had commas between the 
> last 4 fields which also including being inside parenthesis. This was later 
> decided to be a waste of bytes and slowed down parsing to handle the comma for 
> matching/translating purposes. Current events do not have this.

Which is exactly the information I was after.
> 
> If you see any current events that are mishandled by this legacy code, let me 
> know and I'll see how we can fix it.

A very, very quick glance through the current kernel and Linux-PAM code
showed, happily, nothing containing the offending format.

> 
> -Steve
> 

Thanks.

Burn