[PATCH] IPC_SET_PERM cleanup

[Klaus Weidner]

On Mon, May 08, 2006 at 01:29:57PM -0500, Dustin Kirkland wrote:
> On 5/5/06, Linda Knippers <linda.knippers at hp.com> wrote:
> >2. No change to the IPC record type, given no feedback on the backward
> >   compatibility question.
> 
> I'm not one to speak authoritatively about compatibility issues... 
> But I do prefer the more descriptive AUDIT_IPC_SET_PERM type, as it
> more accurately explains what the record is.  Someone might complain
> at some point about changing the record type, but there will be
> considerably more invasive API changes elsewhere between the 2.6.5 and
> the 2.6.16 kernels (and the RHEL4/RHEL5 kernels).

I think having a separate record type would be an alternative to the
"new_" (or "new ") prefix. If the record types are distinct, it would be
possible to use the same field names for current and requested object
properties. 

The most important thing would be that there are sane rules how the
records should be parsed. The dangling "new " is only okay if there's a
well defined mechanism for field modifiers or attributes, but currently
that seems to be completely ad hoc.

> >3. Removed the qbytes field from the IPC record.  It wasn't being
> >   set and when audit_ipc_obj() is called from ipcperms(), the
> >   information isn't available.  If we want the information in the IPC
> >   record, more extensive changes will be necessary.  Since it only
> >   applies to message queues and it isn't really permission related, it
> >   doesn't seem worth it.
> 
> I agree with you here.  However, I resisted the urge to remove the
> qbytes field when I reworked the ipc audit code as I did not know
> __why__ this was being saved.  I assumed this was required by CAPP for
> one reason or another.  I personally don't find it a very interesting
> field to capture.  But I encourage you to review this with Klaus (or
> another of the CAPP/LSPP experts).

I personally don't care about the qbytes field since it's not security
relevant. I agree with Linda's argument from the followup that it makes
sense to audit it where a bad value may cause the call to fail.

-Klaus