Re: [PATCH] IPC_SET_PERM cleanup
>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