On Wed, Sep 6, 2023 at 5:39 PM Phil Sutter <phil@xxxxxx> wrote: > On Wed, Sep 06, 2023 at 03:56:41PM -0400, Paul Moore wrote: > > On Wed, Sep 6, 2023 at 2:46 PM Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > > On Wed, Sep 06, 2023 at 07:08:40PM +0200, Phil Sutter wrote: > > > [...] > > > > The last six come from the 'reset rules table t1' command. While on one > > > > hand it looks like nftables fits only three rules into a single skb, > > > > your fix seems to have a problem in that it doesn't subtract s_idx from > > > > *idx. > > > > > > Please, feel free to follow up to refine, thanks. > > > > Forgive me if I'm wrong, but it sounds as though Phil was pointing out > > a bug and not an area of refinement, is that correct Phil? > > From my point of view, yes. Though the third parameter "nentries" to > audit_log_nfcfg() is sometimes used in rather creative ways, > nf_tables_dump_obj() for instance passes the handle of the object being > reset instead of a count. So I assume whoever parses audit logs won't > rely too much upon the 'entries=NNN' part, anyway. > > > If it is a bug, please submit a fix for this as soon as possible Pablo. > > Thanks for your support, but I can take over, too. That works too. The only thing I really care about is making sure the code is correct and the kernel is behaving the way one would expect. Who gets it back to that state isn't much of a concern, so long as it does get fixed ;) > The number of > notifications emitted even for a small ruleset is not ideal, also. Understood. Let's first make sure that the audit records are correct, then we can work on improving the frequency. -- paul-moore.com
