Re: [PATCH ghak124 v3] audit: log nftables configuration change events

Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: > On 2021-02-18 09:22, Florian Westphal wrote: > > > 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.