netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH] netfilter: nf_tables: fix rule batch with anonymous set and module autoload
Date: Sun, 16 Feb 2014 11:23:56 +0000	[thread overview]
Message-ID: <20140216112355.GA1016@macbook.localnet> (raw)
In-Reply-To: <20140216111450.GA3647@localhost>

On Sun, Feb 16, 2014 at 12:14:50PM +0100, Pablo Neira Ayuso wrote:
> On Sun, Feb 16, 2014 at 10:44:09AM +0000, Patrick McHardy wrote:
> > > 
> > > That can be done, but I don't see why we allow the creation of
> > > anonymous sets out of the scope of a rule since:
> > > 
> > > * They can only be used by one single rule.
> > > * You cannot update them by adding/deleting elements.
> > > 
> > > The current API allows creating an anonymous set that can be left
> > > unused. I think we should only allow the creation of non-anonymous
> > > sets via NFT_MSG_NEWSET at some point.
> > 
> > The two main reasons are:
> > 
> > - it keeps the API simpler
> > - members might not fit into a single message and currently we can keep
> >   adding members as long as the set is not bound
> 
> I don't find a reason why not to use a non-anonymous (named) set in
> the "we need to add more elements" scenario.

Its not that we add to add more elements later. Its simply that the
amount of elements specified while creating the rule exceeds the
possible size we can squash into a nested attribute.

Simply:

nft filter output ip daddr { 10000 addresses } => fail

There's no reason to introduce this limitation.

> Going back to your proposal of using internal set ids to the
> transaction, we'll need to keep a temporary list of sets that has been
> created in that transaction, then once they are bound to the rule,
> we'll have to move the per-table set lists.

Yes, similar to the expressions lists. But that seems to be independant
of whether we use IDs or not, we simply have to be able to abort a
failed transaction.

> > I don't think we should change this.
> > 
> > It actually also is possible to use anonymous sets with more than one
> > rule, just nft doesn't provide a way to do it. The definition of an
> > anonymous set it (anonymous isn't the best name) a set that is automatically
> > destroyed once the last rule unbinds.
> 
> I like the "release set when unused" feature, but I think we can add
> that to named sets at some point. We can just add a different flag so
> named sets also benefit from this feature. I'm seeing different
> features that can be combined:
> 
> * Dynamically allocate the name, this is useful in case the user
>   wants to avoid a clash when allocating the set name.

This only works for literal sets though since we need a way to reference
them. Speaking of nft of course.

> * Release after set is unused, so the user doesn't need to release the
>   set from its application, which can be good in the dynamic rule-set
>   case.

Might be useful, I agree.

> * Don't allow updates, so the user makes sure nobody from userspace
>   can updates the content of that set anymore.

This is already possible for non-anonymous sets by specifying the
"constant" flag. I'll change that syntax though with the set descriptions.

> So anonymous sets will stand for the combination in which those three
> are set.

      reply	other threads:[~2014-02-16 11:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-14 11:27 [PATCH] netfilter: nf_tables: fix rule batch with anonymous set and module autoload Pablo Neira Ayuso
2014-02-14 11:37 ` Patrick McHardy
2014-02-14 12:34   ` Pablo Neira Ayuso
2014-02-15  9:38     ` Patrick McHardy
2014-02-16 10:33       ` Pablo Neira Ayuso
2014-02-16 10:44         ` Patrick McHardy
2014-02-16 11:14           ` Pablo Neira Ayuso
2014-02-16 11:23             ` Patrick McHardy [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140216112355.GA1016@macbook.localnet \
    --to=kaber@trash.net \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).