Hi, On Wed, Aug 15, 2018 at 11:33:47PM +0200, Florian Westphal wrote: > Phil Sutter <phil@xxxxxx> wrote: > > Hi Pablo, > > > > On Wed, Aug 15, 2018 at 12:17:28PM +0200, Pablo Neira Ayuso wrote: > > > On Tue, Aug 14, 2018 at 08:16:11PM +0200, Phil Sutter wrote: > > > > Hi Arturo, > > > > > > > > I see that in your commit[1] you explicitly disable policy setting for > > > > user-defined ebtables chains. Is this because ebtables-nft can't support > > > > them or was it a design decision? I'm asking because it leads to > > > > unexpected results for people using ebtables-nft as a drop-in > > > > replacement of the legacy ebtables tool. > > > > > > Kernel side currently doesn't support default policy for non-base > > > chains, we would need a patch to support this. > > Ugh. Can't we handle this in userspace? > Conceptually -P DROP|ACCEPT on non-base chain is just same as adding > unconditional DROP or ACCEPT rule. > > We could add a 'policy' comment to make it clear that it was added > as result of legacy ebtables -P support. > > Its more work (ebtables-nft has to check last rule and "soft-remove" it > in case its a policy rule to make sure ebtables -A ... continues to > append at the correct location ...). That's funny, I had the exact same idea (including the policy comment) yesterday for how this could be fixed without having to change kernel code. > Not pretty but I'd find it much better than adding this to the kernel. I think Eric can work around this limitation by inserting such rules from firewalld. The question is whether we still want to have it in ebtables-nft for sake of consistency with legacy ebtables. If so, I would have a look at the hidden last rule idea. What are your opinions? Cheers, Phil
