Chris Wright wrote:
Here's an example of what I mean. It's quite rough, doesn't yet eliminate
any of the code that it eventually could, and doesn't deal with broadcast.
I gave it a quick test with audit netlink, and it does what I expect.
thanks,
-chris
It seems that this approach would work for keeping the loginuid in the payload.
The audit handler can then just set the loginuid in the payload - basically
ignoring whatever the application put into this field. This is assuming that we
are dealing with the structures in kernel memory here - I'm not that familiar
with this code...
Regarding an application setting the loginuid: Setting the loginuid is an
operation that is crucial to the reliability of the audit records, and is
appropriately protected with CAP_AUDIT_CONTROL. It is my understanding that the
loginuid associated with an audit record should be the loginuid of the process
that caused the record to be generated. If a userspace application wants to log
messages for another user, it can do so by simply adding that user's
identification information into the message it is writing (it can put anything
it wants to in there), the loginuid associated with the record still needs to be
that of the process which caused the record to be generated - the process
writing the record from userspace.
Are the changes of this method really better than simply adding the loginuid to
the loginuid to the netlink_skb_parms structure? I guess they would be if there
are other netlinkers that could make use of the check function.
--
Darrel