Re: [PATCH ghak124 v3] audit: log nftables configuration change events
Richard Guy Briggs <rgb(a)redhat.com> wrote:
On 2021-02-18 09:22, Florian Westphal wrote:
> No. There is a hierarchy, e.g. you can't add a chain without first
> adding a table, BUT in case the table was already created by an earlier
> transaction it can also be stand-alone.
Ok, so there could be a stand-alone chain mod with one table, then a
table add of a different one with a "higher ranking" op...
Yes, that can happen.
> > It seems I'd need to filter out the NFT_MSG_GET_* ops.
>
> No need, the GET ops do not cause changes and will not trigger a
> generation id change.
Ah, so it could trigger on generation change. Would GET ops be included
in any other change
No, GET ops are standalone, they cannot be part of a transaction.
If you look at
static const struct nfnl_callback nf_tables_cb[NFT_MSG_MAX] = {
array in nf_tables_api.c, then those ops with a '.call_batch' can
appear in transaction (i.e., can cause modification).
The other ones (.call_rcu) are read-only.
If they appear in a batch tehy will be ignored, if the batch consists of
such non-modifying ops only then nf_tables_commit() returns early
because the transaction list is empty (nothing to do/change).
such that it would be desirable to filter them out
to reduce noise in that single log line if it is attempted to list all
the change ops? It almost sounds like it would be better to do one
audit log line for each table for each family, and possibly for each op
to avoid the need to change userspace. This would already be a
significant improvement picking the highest ranking op.
I think i understand what you'd like to do. Yes, that would reduce
the log output a lot.