Re: [PATCH] improved xfrm_audit_log() patch
On Wed, 2007-08-22 at 20:05 -0700, David Miller wrote:
I would suggest, at this point, to make purpose built situation
specific interfaces that pass specific objects (the ones being
operated upon) to the audit layer.
Let the audit layer pick out the bits it actually wants in the
format it likes.
For example, if we're creating a template, pass the policy and
the templace to the audit layer via a function called:
xfrm_audit_template_add()
or something like that. That function only needs two arguments.
All of these call sites will rarely need more than 2 or 3 arguments in
any given situation, and the on-stack audit thing will be gone too.
This is the suggestion I made to you over a month ago, but you choose
to do the on-stack thing.
I misunderstood. My bad.
For clarification, I plan on removing xfrm_audit_log() and replacing it
with more specific ipsec audit interfaces.
For example, when auditing the addition of a policy, either
xfrm_user_audit_policy_add(xp, result, skb) or
pfkey_audit_policy_add(xp, result) will get called.
I need two because xfrm_user gets loginuid/secid from netlink/skb
and pfkey gets it from audit_get_loginuid().
Each will setup and format audit buffer according
to what they want.
Also, for deleting, there will be pfkey_audit_policy_delete(xp, result)
and xfrm_user_audit_policy_delete(xp, result, skb).
You must make this cost absolutely nothing when it is either
not configured, and have next to no cost when not enabled at
run time. And it is very doable.
The new ipsec audit functions can be ifdef'd with CONFIG_AUDITSYSCALL
just as xfrm_audit_log() was so that there is no cost when
audit is not configured.
Let me know if this is better.
Regards,
Joy