Re: [PATCH] IPC_SET_PERM cleanup

[Linda Knippers <linda.knippers@hp.com>]

>>If someone is looking for the records for a particular uid, wouldn't
>>> they expect to get the records generated by someone with that uid?
> 
> Not necessarily. I would like to present all matches of uid and let them 
> decide what is relavent.

It seems to me like you could be generating alot of noise.  What will
an ausearch -ui <uid> give you?  The manpage says:

>  -ui <user id>
>               Search for an event with the given user ID.

I wouldn't expect that to include events generated by other users
that used the user id as an argument.

>>At this point there are already a bunch of uid fields (auid, uid, euid,
>>> suid, fsuid, iuid, ouid) in various audit records, and a similar set
>>> of guid files, so would you be happier with nuid, ngid, etc?
> 
> 
> Does ouid and ogid not fit? I'd like us to define what we need in the parser 
> API and then use it in the audit messages. Ancilliary words like new, old, 
> last, first should not be tied with an underscore. If you find any, let me 
> know.

According to your spec, ouid means file owner uid, so that doesn't seem
to fit.

I'm starting to wonder whether we actually need the IPC_NEW_PERMS
record.  We don't spell out similar information for chown, for
example.  In that case, the new owner is a1 field.  Do we treat IPC's
differently because their argument is a structure pointer?

In any case, if someone truly wanted to get all audit records that
had the uid either as part of the subject/object identity and also
included all records that had the uid as an argument, they'd need
to look at the a* fields for other system calls as well.  Since we
don't look at the a* arguments for other syscalls, it doesn't seem
like we should include the arguments for the IPC syscalls if someone
is searching for the records generated by a uid.

-- ljk