From: Pablo Neira Ayuso <pablo@netfilter.org>
To: netfilter-devel@vger.kernel.org
Subject: [PATCH nf-next 0/5] nf_tables: rule deletion by description
Date: Thu, 9 Feb 2017 17:13:45 +0100 [thread overview]
Message-ID: <1486656830-3245-1-git-send-email-pablo@netfilter.org> (raw)
Hi,
Rule deletion by description is a feature missing these days in
nf_tables that has been requested already several times by different
people.
I'm talking specifically of this feature that is available in iptables:
# iptables -D INPUT -p tcp --dport 22 -j DROP
that allows us to delete the first rule matching this description.
So far, nf_tables allows users to delete rules through unique handle
numbers that you can list via -a option.
The approach I decided to follow adds most of this logic to userspace.
Basically, if the user wants to delete a given rule, the idea is to dump
the ruleset and compare if this rule matches any of the existing ones.
In case of matching found, annotate the rule handle and use it to delete
it from the kernel.
I noticed two corner cases that are problematic though:
1) A robot performs a rule deletion-after-addition from the same batch.
This rule has no public u64 handle yet, therefore we cannot
reference it. Add a new NFTA_RULE_ID, which is similar to NFTA_SET_ID
in essence, that indicates an unique rule identifier inside the batch.
This can be used to delete this rule not yet with the public handle.
1) Two threads compete to delete duplicated a rule. Even if duplicated
rules make no sense, since the first rule would shadow the duplicated
one, two robots inserting rules may lead us to this situation. Then,
if robot A and robot B race to delete these duplicated rules, they may
end up pointing to the same rule handle, so the one losing race will
indicate that rule doesn't exist, while one of the two rules will
still remain there, leaving the ruleset in inconsistent state.
To catch this rare case, this patch introduces a way to validate
what ruleset generation userspace expects to operate with. In case,
kernel notices that userspace operates with a stale generation
number, the kernel returns -ERESTART so userspace can transparently
relookup for the rule handle.
I have a userspace patchset to implement rule deletion by description
for nft, still incomplete (I may push it to a branch though for
previous). Main problem so far is that rule comparisons require that
the representation in both linearize and delinearize paths are the same.
This feature needs quite a bit of several userspace patches still
because there are a number of asymmetries in the rule representation
that need to be fixed, eg. I had to split bitfield transformations that
we're performing in the evaluation phase into a new specific step
between evaluation and linearization.
Another solution for this problem is to handle this entirely from
kernelspace. However, this is specifically cumbersome with anonymous
sets, that require a full comparison of all elements given that name are
meaningless. Moreover, on top of that, elements need to be ordered which
is not guaranteed when iterating over set backends such as hashtable. So
solving this from kernel look even more complex to me.
Let me know if you have any comment on these, thanks.
Pablo Neira Ayuso (5):
netfilter: nfnetlink: get rid of u_intX_t types
netfilter: nfnetlink: add nfnetlink_rcv_skb_batch()
netfilter: nfnetlink: allow to check for generation ID
netfilter: nf_tables: add check_genid to the nfnetlink subsystem
netfilter: nf_tables: add NFTA_RULE_ID attribute
include/linux/netfilter/nfnetlink.h | 1 +
include/net/netfilter/nf_tables.h | 3 ++
include/uapi/linux/netfilter/nf_tables.h | 2 +
include/uapi/linux/netfilter/nfnetlink.h | 12 +++++
net/netfilter/nf_tables_api.c | 32 ++++++++++++
net/netfilter/nfnetlink.c | 90 +++++++++++++++++++++-----------
6 files changed, 109 insertions(+), 31 deletions(-)
--
2.1.4
next reply other threads:[~2017-02-09 16:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-09 16:13 Pablo Neira Ayuso [this message]
2017-02-09 16:13 ` [PATCH nf-next 1/5] netfilter: nfnetlink: get rid of u_intX_t types Pablo Neira Ayuso
2017-02-09 16:13 ` [PATCH nf-next 2/5] netfilter: nfnetlink: add nfnetlink_rcv_skb_batch() Pablo Neira Ayuso
2017-02-09 16:13 ` [PATCH nf-next 3/5] netfilter: nfnetlink: allow to check for generation ID Pablo Neira Ayuso
2017-02-09 16:13 ` [PATCH nf-next 4/5] netfilter: nf_tables: add check_genid to the nfnetlink subsystem Pablo Neira Ayuso
2017-02-09 16:13 ` [PATCH nf-next 5/5] netfilter: nf_tables: add NFTA_RULE_ID attribute Pablo Neira Ayuso
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=1486656830-3245-1-git-send-email-pablo@netfilter.org \
--to=pablo@netfilter.org \
--cc=netfilter-devel@vger.kernel.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).