[Bug 1758] Design flaw in chain traversal

[bugzilla-daemon at netfilter.org]

https://bugzilla.netfilter.org/show_bug.cgi?id=1758

Phil Sutter <phil at nwl.cc> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |phil at nwl.cc
         Resolution|---                         |WONTFIX

--- Comment #1 from Phil Sutter <phil at nwl.cc> ---
Hi,

Please note that iptables works exactly the same way, you just don't have the
flexibility to add arbitrary base chains.

Take security table for instance: A drop rule in its INPUT chain can't be
overridden from filter table, no matter what. Vice-versa: An accept rule in
security table's INPUT chain will not see any packet if filter table's INPUT
chain dropped them already.

All this is hard to change: Nobody would expect a packet to no longer appear in
filter's INPUT chain after mangle's PREROUTING chain had an ACCEPT verdict for
it.

You're free to design the basic ruleset layout of base and non-base chains in
nftables. But you also have to define (and enforce) the rules of how different
actors add their ruleset snippets to it. A simpler way may be to use a
coordinating daemon such as firewalld.

The "major design flaw" is expecting nftables to implement coordination between
concurrent users because its design supports them in the first place. We've
discussed this misunderstanding pretty extensively at netfilter workshops in
the past and haven't even found a feasible way to please users falling for
this, let alone compatibility to existing rulesets.

The substantial problem with the suggested "proceed" verdict is that one has to
change the "accept" one which is not compatible. The alternative of
implementing a "really accept" is flawed in that it will only lead to requests
for support of overriding it and thus back to square one.

We may continue discussing why things are the way they are, but please don't
expect this to change.

Cheers, Phil

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20240715/c0529b50/attachment.html>