From: trentbuck@gmail.com (Trent W. Buck)
To: netfilter@vger.kernel.org
Subject: idempotent nft delete table? (or: why does "flush table" delete rules but keep chains?)
Date: Thu, 30 Apr 2020 14:26:19 +1000 [thread overview]
Message-ID: <87368l38gk.fsf@goll.lan> (raw)
A typical ruleset looks like
flush ruleset
table filter { ... }
That works fine until I have several partial rulesets (e.g. the
sysadmin, libvirtd, and sshguard) that manage their own tables in
parallel, e.g.
foo.nft:
flush ruleset
table foo { ... }
bar.nft:
flush ruleset
table bar { ... }
If I reload either file, both tables are removed, and only one table is
readded.
The obvious thing to try is this:
flush table foo
table foo { ... }
However this doesn't flush the chains, only the rules.
So if you make an edit like this:
flush table foo
table x {
- chain y {
+ chain z {
type filter hook input priority filter; policy drop
tcp dport ssh accept
}
}
What you end up with is a ruleset that looks like this:
table x {
chain y {
type filter hook input priority filter; policy drop;
}
chain z {
type filter hook input priority filter; policy drop;
tcp dport ssh accept
}
}
...and your SSH stops working.
I also considered this, but it will error out if the table doesn't exist yet:
flush table foo
table foo { ... }
I suppose I could use add table (which is idempotent) and then delete
table (which isn't), so ending up with
table foo
flush table foo
table foo { ... }
Is this sensible? Have I missed something obvious?
PS: I think the way normal people handle this is with a middleware layer
like firewalld (Fedora) or ufw (Ubuntu), but those are a bit too
heavyweight for my taste.
next reply other threads:[~2020-04-30 4:26 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-30 4:26 Trent W. Buck [this message]
2020-04-30 15:12 ` idempotent nft delete table? (or: why does "flush table" delete rules but keep chains?) John Haxby
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87368l38gk.fsf@goll.lan \
--to=trentbuck@gmail.com \
--cc=netfilter@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.