[PATCH] IPC_SET_PERM cleanup
Linda Knippers
linda.knippers at hp.com
Tue May 9 17:47:26 UTC 2006
>>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
More information about the Linux-audit
mailing list