On Thu, May 04, 2017 at 03:44:19PM +0200, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote:
> > On Thu, May 04, 2017 at 02:34:21PM +0200, Phil Sutter wrote:
> > > Being able to retrieve an added rule's handle atomically is a crucial
> > > feature for scripts invoking nft command: Without it, there is no way to
> > > be sure a handle extracted from 'nft list ruleset' command actually
> > > refers to the rule one has added before or that of another process which
> > > ran in between.
> > >
> > > Extracting an added rule's handle itself is not an easy task already,
> > > since there is a chance that a given rule is printed differently than
> > > when it was added before. A simple example is port number vs. service
> > > name:
> > >
> > > | nft add rule ip t c tcp dport { ssh, 80 } accept
> > >
> > > There is no way to make 'nft list ruleset' return the rule just like
> > > this as depending on whether '-nn' was given or not, it either prints
> > > the set as '{ ssh, http }' or '{ 22, 80 }' but never in the mixed form
> > > that was used when adding it.
> > >
> > > This patch prints an identifying string for each added rule which may be
> > > used as single parameter to a later 'nft delete rule' command. So a
> > > simple scripting example looks like this:
> > >
> > > | handle=$(nft add rule ip t c counter)
> >
> > This is a hack.
> >
> > We should follow the rule description path.
>
> You mean delete-by-name?
>
> Its just as ugly, just a different kind of ugly.
Ugly?
This kernel patch is seriouly broken. It's sending a message to
userspace from the preparation phase of the commit protocol, where
things are not even confirmed at all...
> Will you delete the first match? The last one? All of them?
I already explained this Florian. Please, look at the mail archive.
--
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
