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: Tue, 9 May 2006 15:10:14 -0500 [thread overview]
Message-ID: <20060509201014.GA31028@w-m-p.com> (raw)
In-Reply-To: <200605091511.25780.sgrubb@redhat.com>
On Tue, May 09, 2006 at 03:11:25PM -0400, Steve Grubb wrote:
> Bottom line, for the search API, I want all similar types to have a common
> field name. They can have a modifier adjacent to them.
If that's the way you want to do it, there needs to be a way to get the
modifier to disambiguate them.
Is adding "new " modifiers the best way to do that? You could also
keep the field names the same and look at the syscall record type to find
out which context they get used in.
> On Tuesday 09 May 2006 14:27, Linda Knippers wrote:
> >Maybe I should use a5, a6, ...,
> Please no. Let's keep it as iuid or ouid.
Naming them "a5" etc. would be terrible. The chown way of doing it wasn't
intended as a role model, the point was just that since the information
was present (even though obfuscated) there was no requirement to add
special case logic to audit that call. A userspace reporting tool could
fix this up if it wanted to. If you need new code to get the information,
you may as well make it less obfuscated.
> I'd personally prefer to drop iuid so we can consolidate field types.
> ouid means "owner's uid".
A consolidated field type "ouid" for the object owner makes sense
(assuming that since the IPC records are changing anyway, we might as
well make this additional change).
This still leaves the independent problem that you have a single syscall
which wants to report both the current ouid and the proposed new ouid
it's trying to set it to.
-Klaus
next prev parent reply other threads:[~2006-05-09 20:10 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 [this message]
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
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=20060509201014.GA31028@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