netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).