Re: [PATCH] IPC_SET_PERM cleanup
>How it is easier/better?
Much easier for the user. For example, the user might be searching for uid.
Should the user have to specify new_uid ? Would they also need to search for
old_uid? Would they have to know all the possible variations on uid?
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?
Picking up something with the new_uid wouldn't be correct in my opinion
since its data relating, really an argument for the syscall, not related
to who caused the audit record to be emitted.
We had this discussion on the audit list back in March while
discussing the
Audit Parsing Library.
https://www.redhat.com/archives/linux-audit/2006-March/msg00186.html
I thought it was settled at that time. If this was brought up on the LSPP
telecon I missed it.
It didn't seem setttled, although you were the last to reply. I think
the discussion on the LSPP list is what initiated the mail exchange.
Might make it tougher too. For example, suppose someone wanted to
find auid =
520. The user space object manager, dbus, has a auid of -1, and is not what
we want. The sender auid is what we want. So, by having a space, we still
match the sender auid = 520. The word to the left is to give context to a
human reading the raw record, but the search utility should still match the
auid value even if it has sender before it. If we combine field names, I
think I'll have to maintain a table of field names to types so that ausearch
can make sense of the field's contents no matter what the name is.
The auid is an interesting case where the auid in the record isn't very
interesting and we're relying on something in the user message. I think
it still could be interesting to distinguish between the two types of
auid.
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?
-- ljk