Linux-audit Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Linda Knippers <linda.knippers@hp.com>
To: Steve Grubb <sgrubb@redhat.com>
Cc: linux-audit@redhat.com
Subject: Re: [PATCH] IPC_SET_PERM cleanup
Date: Wed, 10 May 2006 14:05:33 -0400	[thread overview]
Message-ID: <44622B6D.5060503@hp.com> (raw)
In-Reply-To: <200605101328.36108.sgrubb@redhat.com>

Steve Grubb wrote:
> On Wednesday 10 May 2006 12:29, Klaus Weidner wrote:
> 
>>>This is at the wrong level. There may be people that are writing programs
>>>that want any ouid. I want to stop the proliferation of field names and
>>>follow a convention. Forget whether or not you think people will ever
>>>want the information. We need a convention and then to follow it.
>>
>>Yes - but "new ouid" is also a different field name from "ouid", and
>>unnecessarily hard to parse,
> 
> 
> I am writing the parser. No one else should have to worry about it. 

That assumes everyone uses your parser.  We have existing code we're
supporting that doesn't use your parser and we're not planning to
re-write our code.  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.

> Besides, 
> we already do this *everywhere* except in this patch. I am just trying to 
> keep the whole thing consistent. If you see anywhere that has new_something 
> or old_something, please let me know. 
> 
> In all the places I looked, the value given is considered the new value. The 
> old value is given as old=

I think what these examples show is that there is no consistency.

> Some examples:
> "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?

> But then there is this:
> audit_log_format(ab, "login pid=%d uid=%u " "old auid=%u new auid=%u",
> 
> Arguably, that could be re-written as:
> audit_log_format(ab, "login pid=%d uid=%u " "auid=%u old auid=%u"

If the middle example used an underscore instead of a space, that would
make lots of people happier.
> 
>>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?

> 
> -Steve

  reply	other threads:[~2006-05-10 18:05 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 [this message]
2006-05-10 18:20                                     ` Steve Grubb
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=44622B6D.5060503@hp.com \
    --to=linda.knippers@hp.com \
    --cc=linux-audit@redhat.com \
    --cc=sgrubb@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox