From: Klaus Weidner <klaus@atsec.com>
To: Steve Grubb <sgrubb@redhat.com>
Cc: linux-audit@redhat.com
Subject: Re: [PATCH] IPC_SET_PERM cleanup
Date: Wed, 10 May 2006 11:29:02 -0500 [thread overview]
Message-ID: <20060510162902.GG31457@w-m-p.com> (raw)
In-Reply-To: <200605101002.31857.sgrubb@redhat.com>
On Wed, May 10, 2006 at 10:02:31AM -0400, Steve Grubb wrote:
> On Tuesday 09 May 2006 16:46, Linda Knippers wrote:
> > > The original patches by Dustin and Linda had used "new_iuid=501" to
> > > differentiate the values, which I personally think was fine since it's
> > > unlikely that people want to be searching for those.
> >
> > And if they do, they're easy to find with an ausearch | grep.
>
> 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, especially since there's currently no well
defined concept of name modifiers like "new".
> > > If you absolutely want to avoid adding new tag names, an alternative
> > > would be to get rid of the "new " modifiers, and use the "type=" name to
> > > differentiate them.
>
> I don't want a proliferation of type names either. I think we have a lot of
> them and should try to use existing ones where possible.
A list of existing record types would be useful. In this case, it's a
legitimate difference between "current object attributes" and "requested
new object attributes" sub-records that need to be distinct for the
syscall event, so using different types sounds appropriate.
-Klaus
next prev parent reply other threads:[~2006-05-10 16:29 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 [this message]
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
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=20060510162902.GG31457@w-m-p.com \
--to=klaus@atsec.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