Richard Guy Briggs <rgb(a)redhat.com> wrote:
On 2021-02-11 23:09, Florian Westphal wrote:
> So, if just a summary is needed a single audit_log_nfcfg()
> after 'step 3' and outside of the list_for_each_entry_safe() is all
> that is needed.
Ok, so it should not matter if it is before or after that
list_for_each_entry_safe(), which could be used to collect that summary.
Right, it won't matter.
> If a summary is wanted as well one could fe. count the number
of
> transaction types in the batch, e.g. table adds, chain adds, rule
> adds etc. and then log a summary count instead.
The current fields are "table", "family", "entries",
"op".
Could one batch change more than one table? (I think it could?)
Yes.
It appears it can change more than one family.
"family" is currently a single integer, so that might need to be changed
to a list, or something to indicate multi-family.
Yes, it can also affect different families.
Listing all the ops seems a bit onerous. Is there a hierarchy to
the
ops and if so, are they in that order in a batch or in nf_tables_commit()?
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.
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.