Re: [PATCH] IPC_SET_PERM cleanup
On 5/10/06, Klaus Weidner <klaus(a)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