>>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 -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
