Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 790014 - net-firewall/nftables: rules are saved with numeric values which break in some cases
Summary: net-firewall/nftables: rules are saved with numeric values which break in som...
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Matthew Thode ( prometheanfire )
Keywords: PullRequest
Depends on:
Reported: 2021-05-13 19:25 UTC by Ogelpre
Modified: 2021-07-26 16:50 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Ogelpre 2021-05-13 19:25:23 UTC
The nftables scripts uses SAVE_OPTIONS="-n". This breaks rule loading in some cases.

Reproducible: Always

Steps to Reproduce:
Add the following rule:

nft add rule inet filter input reject with icmpx type admin-prohibited

Save it with /etc/init.d/nftables save and try to load the saved ruleset.
Actual Results:  
/var/lib/nftables/rules-save:5:26-26: Error: syntax error, unexpected number, expecting string
                reject with icmpx type 3

Expected Results:  
Rules should be loaded.

I don't know if this is a upstream bug or if the behavior is expected. I suppose to remove the -n flag from SAVE_OPTIONS for now. Alternatively we can add a hint to the default config that remove -n can avoid this problem.
Comment 1 Francisco Blas Izquierdo Riera gentoo-dev 2021-05-14 19:24:36 UTC
This seems to be an upstream bug. We could try using "-T -y -p" instead to prevent the issue, but I suspect nft should be able to load rules saved using -n.

Checking the YAML description it says it expects a string though.
Comment 2 Ogelpre 2021-06-28 14:07:05 UTC
Using "-T -y -p" as workaround works for me.
Comment 3 Francisco Blas Izquierdo Riera gentoo-dev 2021-07-26 16:18:09 UTC
I have backported Pablo's patch instead to 0.9.9 (which is a better solution). Had to make a new Pull Request instead.

This change will be on the next release too, so for my side it may be valid to close it as resolved upstream and wait for the next release.

Keep in mind that the first commit in my PR still needs to be applied nevertheless.