All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: linux-audit@redhat.com, burn@swtf.dyndns.org
Subject: Re: Refactoring src/ausearch-report.c:output_interpreted_node()
Date: Wed, 01 Oct 2014 14:54:12 -0400	[thread overview]
Message-ID: <74328756.3cWZp6NFET@x2> (raw)
In-Reply-To: <1411958483.2752.33.camel@swtf.swtf.dyndns.org>

On Monday, September 29, 2014 12:41:23 PM Burn Alting wrote:
> In lib/lookup_table.c:audit_name_to_msg_type(), the event type value is
> parsed and converted to an integer as per,
> 
> Given
>         type=<type_value>
> then
>         <type_value>
> is parsed for
>         - a known string
>         - a long integer number, n, found in the specific string
> 		"UNKNOWN[n]"
>         - a long integer number, n, found in the specific string
> 		"n"
> 
> In src/ausearch-report.c:output_interpreted_node() it additionally
> parses for a <type_value> of
>         - a long integer number, n, found in the string "[^\[]*[n].*"
> i.e.
>         type=something[n]something_else

This is specifically a fixup for the UNKNOWN[####] case. There is no other value 
it can be. This originates here:

https://fedorahosted.org/audit/browser/trunk/src/auditd-event.c#L1054


> Is there any reason against adding this additional parsing into
> lib/lookup_table.c:audit_name_to_msg_type()?

Additional parsing should not be needed.

 
> If we can, then output_interpreted_node() can be re-factored so we are
> not parsing the same data twice for every event.

It should be safe to remove the "old code". I don't think 
audit_name_to_msg_type() originally did the fixup. I think it was added when 
libauparse needed the same thing.


> I am uncertain what effect of accepting this additional format would
> have when adding rules to the running audit system - i.e.
> audit_name_to_msg_type() is called by autrace/auditctl when parsing
> rules (ie the msgtype field name).

I think ausearch-report.c might be the place that needs updating.

-Steve

  parent reply	other threads:[~2014-10-01 18:54 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-29  2:41 Refactoring src/ausearch-report.c:output_interpreted_node() Burn Alting
2014-09-29 20:48 ` Burn Alting
2014-10-01 18:54 ` Steve Grubb [this message]
2014-10-01 21:08   ` Burn Alting
2014-10-01 21:19     ` Steve Grubb
2014-10-01 21:24       ` Steve Grubb
2014-10-01 21:54         ` Burn Alting
2014-10-01 21:52       ` Burn Alting
2014-10-01 22:28         ` Steve Grubb
2014-10-02  9:29           ` Burn Alting
2014-10-07  9:31             ` Burn Alting
2014-10-07 15:26               ` Steve Grubb

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=74328756.3cWZp6NFET@x2 \
    --to=sgrubb@redhat.com \
    --cc=burn@swtf.dyndns.org \
    --cc=linux-audit@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.