From: Steve Grubb <sgrubb@redhat.com>
To: Linda Knippers <linda.knippers@hp.com>
Cc: linux-audit@redhat.com
Subject: Re: [PATCH] IPC_SET_PERM cleanup
Date: Wed, 10 May 2006 14:20:09 -0400 [thread overview]
Message-ID: <200605101420.10055.sgrubb@redhat.com> (raw)
In-Reply-To: <44622B6D.5060503@hp.com>
On Wednesday 10 May 2006 14:05, Linda Knippers wrote:
> We have existing code we're supporting that doesn't use your parser and
> we're not planning to re-write our code.
You'll have to make some mods to it, things have changed in various places.
> I don't know how many other people are in the same position. I also think
> its helpful if the output of ausearch is easily grepable.
It will be. Nothing has changed here.
> I think what these examples show is that there is no consistency.
It shows that modifiers are not being added to every keyword.
> > "audit_rate_limit=%d old=%d by auid=%u"
> > "audit_backlog_limit=%d old=%d by auid=%u"
>
> What does "by" signify as a modifier?
Its not a modifier, its there for human readability.
> >>especially since there's currently no well defined concept of name
> >> modifiers like "new"
> >
> > Its used in many places, but you are more likely to run across old. The
> > function in the specs that was intended to do this was:
> >
> > const char *auparse_get_field_name_aux(auparse_state_t *au) - return
> > supplemental information about the field's name.
>
> If I used the APIs then I have to look at the aux information for a
> bunch of records I don't want because I can't directly search for the
> ones I do?
Or use reg expr matching.
-Steve
next prev parent reply other threads:[~2006-05-10 18:20 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-05 20:19 [PATCH] IPC_SET_PERM cleanup Linda Knippers
2006-05-05 20:42 ` Steve Grubb
2006-05-05 20:59 ` Linda Knippers
2006-05-09 14:51 ` Klaus Weidner
2006-05-05 21:26 ` Linda Knippers
2006-05-08 18:29 ` Dustin Kirkland
2006-05-08 18:29 ` Dustin Kirkland
2006-05-08 19:06 ` Linda Knippers
2006-05-09 14:59 ` Klaus Weidner
2006-05-09 15:05 ` Steve Grubb
2006-05-09 15:12 ` Linda Knippers
2006-05-09 15:21 ` Steve Grubb
2006-05-09 15:34 ` Linda Knippers
2006-05-09 15:55 ` Steve Grubb
2006-05-09 16:33 ` Klaus Weidner
2006-05-09 17:47 ` Linda Knippers
2006-05-09 18:15 ` Klaus Weidner
2006-05-09 18:27 ` Linda Knippers
2006-05-09 19:11 ` Steve Grubb
2006-05-09 20:10 ` Klaus Weidner
2006-05-09 20:36 ` Klaus Weidner
2006-05-09 20:46 ` Linda Knippers
2006-05-10 14:02 ` Steve Grubb
2006-05-10 16:29 ` Klaus Weidner
2006-05-10 17:02 ` Dustin Kirkland
2006-05-10 17:11 ` Klaus Weidner
2006-05-10 17:22 ` Linda Knippers
2006-05-10 17:29 ` Steve Grubb
2006-05-10 18:10 ` Klaus Weidner
2006-05-10 17:28 ` Steve Grubb
2006-05-10 18:05 ` Linda Knippers
2006-05-10 18:20 ` Steve Grubb [this message]
2006-05-09 15:53 ` Amy Griffis
2006-05-09 15:07 ` 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=200605101420.10055.sgrubb@redhat.com \
--to=sgrubb@redhat.com \
--cc=linda.knippers@hp.com \
--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.