Re: nft cache updates

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Mon, Nov 09, 2015 at 03:30:56PM +0000, Patrick McHardy wrote:
> Hi Pablo,
> 
> I'm wondering what the rational for the current cache update behaviour is.
> The changelog states it is somehow related to the requested command, but
> that doesn't seem to be true.
> 
> Even "nft describe" fails with EPERM as user since the cache appears to be
> initialized unconditionally, which is a bit unfortunate. Also I used to
> test things parsing, evaluation and even netlink generation without actually
> adding those rules as user, which does not work anymore.  This might
> be harder to get working again, but I'm not sure why we do a full
> initialization anyways.  The only thing that appears to be needed
> are sets, and those only in some specific circumstances.

To look up for the existing sets we need the existing tables and
chains, they are essential part of the object hierarchy. So this is
what we're currently dumping.

In general, we need this for incremental updates, in scenarios where
we have objects that are defined in kernelspace but userspace refers
to them.

As you said we can disable the cache in many cases, depending on the
command or if the ruleset file starts by:

flush ruleset

but I have left this out as follow up work, I just wanted to make sure
incremental updates where working, as well as the existing changes.

nft describe should be easy to restore.

Regarding inconditional check for table and chain, we have to make it
from the evaluation step in sets, so leaving other objects without
checking this seems inconsistent to me.

Another side effect of this is better error reporting to the user.