From: Gabriel Goller <g.goller@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH proxmox-firewall v2 1/1] service: flush firewall rules on force disable
Date: Thu, 4 Jul 2024 15:36:21 +0200 [thread overview]
Message-ID: <20240704133621.o2upi4jf7dduvd3b@luna.proxmox.com> (raw)
In-Reply-To: <20240704123648.268894-1-s.hanreich@proxmox.com>
On 04.07.2024 14:36, Stefan Hanreich wrote:
>When disabling the nftables firewall again, there is a race condition
>where the nftables ruleset never gets flushed and persists after
>disabling.
>
>The nftables firewall update loop does a noop when the force disable
>file exists. It only flushes the ruleset when nftables is disabled in
>the configuration file but the force disable file does not yet exist.
>
>This can lead to the following situation:
>
>* nftables is activated and created its ruleset
>* user switches from nftables firewall back to iptables firewall
>* pve-firewall runs and creates the force disable file
>* proxmox-firewall sees that the file exists and does nothing
>
>Reported-by: Hannes Laimer <h.laimer@proxmox.com>
>Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
>---
>Changes from v1 to v2:
>* Removed misleading/wrong section about the probability of this
> happening
>* Added a detailed description of the scenario this commit prevents
>
> proxmox-firewall/src/bin/proxmox-firewall.rs | 4 ++++
> 1 file changed, 4 insertions(+)
>
>diff --git a/proxmox-firewall/src/bin/proxmox-firewall.rs b/proxmox-firewall/src/bin/proxmox-firewall.rs
>index f7e816e..5133cbf 100644
>--- a/proxmox-firewall/src/bin/proxmox-firewall.rs
>+++ b/proxmox-firewall/src/bin/proxmox-firewall.rs
>@@ -91,6 +91,10 @@ fn main() -> Result<(), std::io::Error> {
>
> while !term.load(Ordering::Relaxed) {
> if force_disable_flag.exists() {
>+ if let Err(error) = remove_firewall() {
>+ log::error!("unable to disable firewall: {error:#}");
Note that `std::io::Error` does not handle pretty-printing any different
in `Display`. So this outputs the same as '{error}'. To also print the
`ErrorKind` use either '{error:?}' or '{error:#?}', which produce:
Custom { kind: NotFound, error: "cool" }
or
Custom {
kind: NotFound,
error: "cool",
}
>+ }
>+
> std::thread::sleep(Duration::from_secs(5));
> continue;
> }
>--
>2.39.2
>
>
>_______________________________________________
>pve-devel mailing list
>pve-devel@lists.proxmox.com
>https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>
>
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
prev parent reply other threads:[~2024-07-04 13:36 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-04 12:36 Stefan Hanreich
2024-07-04 13:36 ` Gabriel Goller [this message]
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=20240704133621.o2upi4jf7dduvd3b@luna.proxmox.com \
--to=g.goller@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/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.