From: Florian Westphal <fw@strlen.de>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Phil Sutter <phil@nwl.cc>, Florian Westphal <fw@strlen.de>,
netfilter-devel@vger.kernel.org, regit@netfilter.org
Subject: Re: [nft PATCH] List handles of added rules if requested
Date: Fri, 5 May 2017 13:56:45 +0200 [thread overview]
Message-ID: <20170505115645.GA5016@breakpoint.cc> (raw)
In-Reply-To: <20170505104954.GA1676@salvia>
Pablo Neira Ayuso <pablo@netfilter.org> wrote:
[ CC Eric ]
> On Fri, May 05, 2017 at 12:26:12AM +0200, Phil Sutter wrote:
> > While I think it's not a bad idea to allow users experienced with
> > iptables to apply their muscle memory to nftables as well, I don't quite
> > get what should hold us back from leveraging this feature nftables
> > provides over iptables. The existence of a unique identifier is a big
> > plus in my point of view, it's just not really useful yet since users
> > have no safe way to get that handle for the rule they added.
> >
> > Are you OK with providing both alternatives in parallel? If not, why?
>
> 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...
Yes. OTOH I don't think we want programs to parse nft frontend
text output either...
Eric, whats the status wrt libnft?
> 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.
Right.
> 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.
What about (as first step) to extend nft monitor?
f.e. afaics kernels update notifications already contain the netlink
portid of the peer that added a rule, perhaps we can display that?
nft monitor
add rule ip saddr 1.2.3.4 # nlport 123
We could use that to then also display the process that currently owns
this portid, e.g.:
add rule ip saddr 1.2.3.4 # nlportid 123 # nlport 123 (nft?)
delete rule inet filter input handle 5 # nlport 42 (firewalld?)
We might also consider extending it to display/group transaction ids
to the user so its easier to identify batches.
What do you think?
FWIW, I believe that deletion by handle and by textual description
both have their use-cases so its more of a question on how to implement
this in a sensible way.
next prev parent reply other threads:[~2017-05-05 11:57 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-04 12:34 [nft PATCH] List handles of added rules if requested Phil Sutter
2017-05-04 13:36 ` Pablo Neira Ayuso
2017-05-04 13:44 ` Florian Westphal
2017-05-04 14:00 ` Pablo Neira Ayuso
2017-05-04 22:26 ` Phil Sutter
2017-05-05 10:49 ` Pablo Neira Ayuso
2017-05-05 11:18 ` Puustinen, Ismo
2017-05-08 17:35 ` Pablo Neira Ayuso
2017-05-05 11:56 ` Florian Westphal [this message]
2017-05-04 15:37 ` Thomas Woerner
2017-05-04 22:38 ` Phil Sutter
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=20170505115645.GA5016@breakpoint.cc \
--to=fw@strlen.de \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
--cc=phil@nwl.cc \
--cc=regit@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).