On Sun, Feb 16, 2014 at 10:44:09AM +0000, Patrick McHardy wrote: > On Sun, Feb 16, 2014 at 11:33:35AM +0100, Pablo Neira Ayuso wrote: > > On Sat, Feb 15, 2014 at 09:38:23AM +0000, Patrick McHardy wrote: > > > > > > > > The set definition and the elements need to be included in the lookup > > > > expression for anonymous sets, can you think of any better solution? > > > > > > I think we can use some identifiers generated by userspace to tie them > > > both together. Something like a unique numeric identifier (unique within > > > the transaction). > > > > 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. 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. > 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. * 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. * Don't allow updates, so the user makes sure nobody from userspace can updates the content of that set anymore. So anonymous sets will stand for the combination in which those three are set. > The fact that we don't allow to use them in multiple rules is purely > internal to nft. > > On a general note, nft is just meant to be *one* frontend, there's no > reason why someone else couldn't write a different one more suitable for > a specific purpose. F.i. a simple embedded system might only use tuples > of (dst,proto,port) and use a hash for the lookup. Agreed, not only thinking of nft but on the interface that we'll expose to userspace. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
