Re: [nft PATCH] List handles of added rules if requested

["Puustinen, Ismo" <ismo.puustinen@intel.com>]

On Fri, 2017-05-05 at 12:49 +0200, Pablo Neira Ayuso wrote:
> This does not integrate at all into the scripting features we have in
> 
> nftables. We don't want people to use bash (or like) shell scripts
> anymore, they are bad, they break atomicity for us. We should extend
> native nftables scripting capabilities to support what user need,
> natively. Look, this will not work with nft -i either...
> 
> And this also will not work for robots using incremental updates via
> nft -f. And we very much want to support such transaction like
> scheme,
> ie. place a bunch of incremental updates in one single file and apply
> that in one single transaction.
> 
> This is just covering one very specific usecase, that is, users have
> a
> quick way to delete the rule that just added. And we have better ways
> to achieve this, and that will work from all the scenarios that I
> described above.

I would be interested in any documentation you might have concerning
the "better ways" of creating modular rulesets, that is, automatically
adding and deleting rules and rule groups. This is a real issue that
I'm currently struggling with.

My use case is  pretty simple: when a service is loaded, it also loads
the firewall rules associated with it. When a service is stopped, the
rules corresponding to the service are unloaded. There is no
interactive user present in the system.

Having "nft add rule ..." return a rule handle would fix this, so I was
happy to see Phil's patches. Currently I have to load the rules in
their own chains (one chain per service) and then use a packet marking
scheme to see if the packet has been marked to be accepted by at least
one service chain. When a service is stopped, I then remove the
corresponding chain. The packet marking scheme is quite ugly though,
and the service chains need to know how the packets need to be marked
so that they get accepted by the final chain.

I can't use the "jump" facility to jump to the service chains, because
then I would need to be able to remove the "jump" rule when the service
is unloaded, which is again not possible without the rule handle.

Ismo