Re: [nft PATCH RFC] monitor: Support printing processes which caused the event

[Florian Westphal <fw@strlen.de>]

Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> What is the usecase for this? Please don't tell me the obvious the
> answer: I just want to know what process has modified what.
> 
> If the point is to know if someone else, not myself as a process, has
> modified the ruleset, that is very easy to know with the netlink
> infrastructure.

Yes, thats in fact more important than 'know what process has modified
what', although I think it would be nice from a debug-point of view,
i.e.

$self adds a rule
something else adds a rule at same time

How can $self learn/know the handle assigned by kernel?

The larger picture is to start thinking in direction of libnft,
i.e. get the groundwork going so we don't have to tell 3rd party tools
like firewalld to parse nft text output.

Ideally, I'd like to see a mechanism where the 3rd party tool can:
1. queue an arbitrary amount of updates (add/delete of rules, set
   elements etc.)
2. learn the unique handles assigned to these rules
   so that it can identifiy/remove each one of these rules.

Thomas Woerner suggested a way where userspace can assign unique handles
instead of the kernel but I don't like it because i found no way how the
kernel could enforce that such user-handles are unique without walking
all rules of a table for every transaction.

But currently its impossible to delete a rule again without parsing
'nft -a list table'.  'delete-by-name' is good of course, but, has
the same problems we have with iptables.  I like that we have unique
handles that would allow to 1:1 map every rule to a uniqeue identifier.

But right now its more of a guessing game as the inserting program
doesn't see the handle(s) synchronously, just via monitor.

[ I suspect I now see where you're going with this as the notifications
  contain the nlportid so at least a tool that inserts + listens for
  updates will know if a notification is due to changes by someone else
  or not ...].

Do all of these patches make more sense now?

But, ideally, I'd like to see traction in direction of libnft (I'd
prefer to split nft for this, i.e. gplv2-licensed library).