Cc'ing audit ML. On Wed, Oct 16, 2024 at 06:10:44PM +0200, Florian Westphal wrote: > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > > This is bad, but I do not know if we can change things to make > > > nft_audit NOT do that. Hence add a new workaround patch that > > > inflates the length based on the number of set elements in the > > > container structure. > > > > It actually shows the number of entries that have been updated, right? > > > > Before this series, there was a 1:1 mapping between transaction and > > objects so it was easier to infer it from the number of transaction > > objects. > > Yes, but... for element add (but not create), we used to not do anything > (no-op), so we did not allocate a new transaction and pretend request > did not exist. You refer to element updates above, those used to be elided, yes. Now they are shown. I think that is correct. > Now we can enter update path, so we do allocate a transaction, hence, > audit record changes. > > What if we add an internal special-case 'flush' op in the future? You mean, if 'flush' does not get expanded to one delete transaction for each element. Yes, that would require to look at ->nelems as in this patch. > It will break, and the workaround added in this series needs to be > extended. > > Same for an other change that could elide a transaction request, or, > add expand something to multiple ones (as flush currently does). > > Its doesn't *break* audit, but it changes the output. My understanding is that audit is exposing the entries that have been added/updated/deleted, which is already sparse: Note that nftables audit works at 'table' granurality. IIRC, one of the audit maintainers mentioned it should be possible to add chain and set to the audit logs in the future, such change would necessarily change the audit logs output. Thanks.
