[PATCH] IPC_SET_PERM cleanup

[Dustin Kirkland]

On 5/10/06, Klaus Weidner <klaus at atsec.com> wrote:
> 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".

What about a new field in the audit records that is a bitmask, wherein
bits are flipped on for each field being a "new" or "updated" field?

Example:

type=IPC_SET_PERM msg=audit(1146863632.117:98): new_qbytes=0 new_iuid=501
new_igid=0 new_mode=0

becomes:

type=IPC_SET_PERM msg=audit(1146863632.117:98) new=1111: qbytes=0 iuid=501
igid=0 mode=0

or in hex

type=IPC_SET_PERM msg=audit(1146863632.117:98) new=0xF: qbytes=0 iuid=501
igid=0 mode=0

And it's assumed to be 0 in most cases (where it's not explicitly
mentioned.  This way, we don't lose information where a record should
indicate that some or all fields have been updated.  And the searching
mechanisms can continue to operate as expected.

Just a thought.

:-Dustin