netfilter buglog - Jul 2023 - [Bug 1696] New: "nft -s list ruleset" should include "flush ruleset" as first line

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

            Bug ID: 1696
           Summary: "nft -s list ruleset" should include "flush
ruleset"
                    as first line
           Product: nftables
           Version: 1.0.x
          Hardware: x86_64
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: nft
          Assignee: pablo at netfilter.org
          Reporter: apachez at gmail.com

Doing a backup using:

# nft -s list ruleset > /path/backup.nft

will often fail to restore because a first line of "flush ruleset" is
missing.

Request that when doing "nft -s" that should include "flush
ruleset" as the
first line of its output.

If that is not possible due to legacy or other reasons then perhaps a new
switch could be added that will include "flush ruleset" as its first
line?

Such as:

# -b, --backup   Create backup of current ruleset.

Example of suggested full syntax:

# nft -b /path/backup.nft

Which then can be restored with (for example):

# nft -o -f /path/backup.nft

The above would then not bring the errors one otherwise would get if you try to
restore a nft-file created by "-s list ruleset".

-- 
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/20230731/119be9e9/attachment.html>

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

Phil Sutter <phil at nwl.cc> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |phil at nwl.cc

--- Comment #1 from Phil Sutter <phil at nwl.cc> ---
Well, first of all the requested behaviour is unrelated to what '-s'
flag does,
so it doesn't make much sense to combine them.

Next, a ruleset dumped via 'nft list ruleset' will restore fine after a
reboot,
so dumping into a file and loading it via 'nft -f <file>' works
fine for a
service to make a ruleset persistent.

Then, creating a flushing dump is trivial using '(echo 'flush
ruleset' && nft
list ruleset) > /path/to/dump'. Another alternative for a service is to
run
'nft "flush ruleset; include /path/to/dump;"'. Fedora's
nftables service does
that, for instance.

I really don't see why nft should assist in this simple task.

-- 
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/20230731/028931b4/attachment.html>

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

--- Comment #2 from Apachez <apachez at gmail.com> ---
Because when taking a backup I would expect it to be able to restore without
having to reboot the full box, and also be able to restore without throwing out
all sort of hard to troubleshoot errors such as:

# BUG: invalid input descriptor type 1634164560
# nft: erec.c:161: erec_print: Assertion `0' failed.

Another option would be to implement a "save" and "restore"
option such as:

# nft save ruleset /path/backup.nft

and

# nft restore ruleset /path/backup.nft

The "save ruleset" would add "flush ruleset" as first line
to the output file
(and whatever other commands might be needed).

While "restore ruleset" would use "flush ruleset" as the
first line if that
doesnt exists in the input file.

This way doing something like this would work without getting odd errors:

# nft save ruleset /path/backup.nft
# nft -o -f /path/backup.nft

-- 
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/20230731/72fbaccd/attachment-0001.html>

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

--- Comment #3 from Pablo Neira Ayuso <pablo at netfilter.org> ---
(In reply to Phil Sutter from comment #1)
> Then, creating a flushing dump is trivial using '(echo 'flush
ruleset' &&
> nft list ruleset) > /path/to/dump'. Another alternative for a
service is to
> run 'nft "flush ruleset; include /path/to/dump;"'.
Fedora's nftables service
> does that, for instance.
Another possibility is to add a new command:

   nft save ruleset

which prepends 'flush ruleset' in the ruleset listing.

-- 
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/20230731/20c52a46/attachment.html>

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

--- Comment #4 from Pablo Neira Ayuso <pablo at netfilter.org> ---
(In reply to Apachez from comment #2)
> Because when taking a backup I would expect it to be able to restore
without
> having to reboot the full box, and also be able to restore without throwing
> out all sort of hard to troubleshoot errors such as:
> 
> # BUG: invalid input descriptor type 1634164560
> # nft: erec.c:161: erec_print: Assertion `0' failed.
For the record, there is a fix for this issue:

https://patchwork.ozlabs.org/project/netfilter-devel/patch/20230731112424.69600-1-pablo
at netfilter.org/

-- 
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/20230731/1db5a479/attachment.html>

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

--- Comment #5 from Phil Sutter <phil at nwl.cc> ---
(In reply to Apachez from comment #2)
> Because when taking a backup I would expect it to be able to restore
without
> having to reboot the full box, and also be able to restore without throwing
> out all sort of hard to troubleshoot errors such as:
> 
> # BUG: invalid input descriptor type 1634164560
> # nft: erec.c:161: erec_print: Assertion `0' failed.
That's a bug, but you will see "funny" things like duplicate
rules. Basically,
doing 'nft list ruleset | nft -f -' is doing a non-flushing restore.
Ignoring
this detail while implementing or simulating a system service is a problem
software shouldn't solve IMHO.

-- 
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/20230731/5a658fbb/attachment.html>

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

--- Comment #6 from Apachez <apachez at gmail.com> ---
(In reply to Phil Sutter from comment #5)
> (In reply to Apachez from comment #2)
> > Because when taking a backup I would expect it to be able to restore
without
> > having to reboot the full box, and also be able to restore without
throwing
> > out all sort of hard to troubleshoot errors such as:
> > 
> > # BUG: invalid input descriptor type 1634164560
> > # nft: erec.c:161: erec_print: Assertion `0' failed.
> 
> That's a bug, but you will see "funny" things like duplicate
rules.
> Basically,
> doing 'nft list ruleset | nft -f -' is doing a non-flushing
restore. Ignoring
> this detail while implementing or simulating a system service is a problem
> software shouldn't solve IMHO.
Hence why a "save" and "restore" option should exist in the
nft binary.

-- 
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/20230731/bdf5b1a1/attachment.html>

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

--- Comment #7 from Phil Sutter <phil at nwl.cc> ---
(In reply to Apachez from comment #6)
> (In reply to Phil Sutter from comment #5)
> > (In reply to Apachez from comment #2)
> > > Because when taking a backup I would expect it to be able to
restore without
> > > having to reboot the full box, and also be able to restore
without throwing
> > > out all sort of hard to troubleshoot errors such as:
> > > 
> > > # BUG: invalid input descriptor type 1634164560
> > > # nft: erec.c:161: erec_print: Assertion `0' failed.
> > 
> > That's a bug, but you will see "funny" things like
duplicate rules.
> > Basically,
> > doing 'nft list ruleset | nft -f -' is doing a non-flushing
restore. Ignoring
> > this detail while implementing or simulating a system service is a
problem
> > software shouldn't solve IMHO.
> 
> Hence why a "save" and "restore" option should exist in
the nft binary.
We could ship an nft-save shell script:

| #!/bin/sh
| 
| echo "flush ruleset"
| exec nft "$@" list ruleset

What would a "restore option" do from your perspective?

-- 
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/20230731/edd94595/attachment.html>

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

--- Comment #8 from Apachez <apachez at gmail.com>
---
> We could ship an nft-save shell script:
> 
> | #!/bin/sh
> | 
> | echo "flush ruleset"
> | exec nft "$@" list ruleset
> 
> What would a "restore option" do from your perspective?
To me a "restore option" would do the same as -f but with the addition
that it
would append "flush ruleset" if that doesnt already exists as the
first line in
the file thats being read as input (I guess it could do this blindly because it
wouldnt matter if the file already had one "flush ruleset" so the
result is two
"flush ruleset" after each other?).

This way it doesnt matter if the file you restore from have that "flush
ruleset" as first line or not.

That is restore from these two outputs would work equally well:

# nft -s list ruleset > /path/backup1.nft

# nft save ruleset /path/backup2.nft

# nft restore /path/backup1.nft

# nft restore /path/backup2.nft

-- 
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/20230801/8042cd80/attachment.html>