PolicyKit authentication attempt on startup of firewall-config times out after 25 seconds about firewalld

[erig0]

The 25 seconds you're seeing is the default dbus timeout.

Firewalld calls polkit's dbus method CheckAuthorization. It looks like this accepts a timeout argument that firewalld is not specifying. Unfortunately firewalld is calling this in blocking mode. A long auth/delay would completely block firewalld (it's already blocked for up to 25 seconds!!).

I think it's possible to increase this timeout. Is there functionally a difference between the daemon blocking for 25 seconds or 60 or 120? IMO, 25 is already an eternity.

[AdamWill]

The app is entirely useless if the user doesn't auth, so I think blocking as long as possible is sensible. If you fail the auth, firewall-config just shows a dialog "Error Authorization failed." with OK and Quit buttons (this dialog is also blocking). Quit quits the app. OK re-tries the auth. You cannot use the app unless you auth successfully.

Given that, I think it should just set the timeout to 0 (if that means wait forever) or MAXINT otherwise. This is what wound up happening for a similar issue we happened to also run into recently with the GNOME XDG portal - https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_requests/152 .

[AdamWill]

oh, wait - do you mean this blocks firewalld itself, not just the firewall-config app? Hum. That seems unfortunate...

[AdamWill]

There is definitely a functional difference so far as our tests are concerned, because I can't quite make the test type the password 'very safely' (that's an approach that involves typing slowly and waiting the screen to change between each keypress) within 25 seconds. I've had to make the test type it less safely (still below its max typing rate, but faster than 'very safely', and without the screenshot checks), which is more prone to blip failures if it types too fast for the VM to keep up with, to work around this issue. Bumping the timeout a bit would mean we could have the test go back to typing 'very safely' without running into the timeout.

How significant it is to regular users...I dunno. Not everyone types very fast. people do launch apps then get distracted for a second. 25 secs does seem pretty short. I think there's a case for 60.

[erig0]

Yes. It's unfortunate. I don't know why this code is blocking. It has the effect that firewalld will block any other dbus activity while waiting on auth. That being said, the different between 25 seconds and 120 is... nothing; it's still an eternity for a daemon.

firewalld/src/firewall/server/decorators.py

Lines 232 to 238 in 9bc43fc

	# use polkit if it's available
	if type(self)._interface_polkit:
	(result, _, _) = type(self)._interface_polkit.CheckAuthorization(
	("system-bus-name", {"name": sender}), action_id, {}, 1, ""
	)
	if not result:
	raise NotAuthorizedException(action_id, "polkit")

[erig0]

I would be okay with 60 seconds.

[erig0]

You could try this patch. Based on other code 1 I've seen the timeout keyword should work. I have not tested it though.

diff --git a/src/firewall/server/decorators.py b/src/firewall/server/decorators.py
index 99b30306cfc2..22e607eba445 100644
--- a/src/firewall/server/decorators.py
+++ b/src/firewall/server/decorators.py
@@ -232,7 +232,7 @@ class dbus_polkit_require_auth:
                 # use polkit if it's available
                 if type(self)._interface_polkit:
                     (result, _, _) = type(self)._interface_polkit.CheckAuthorization(
-                        ("system-bus-name", {"name": sender}), action_id, {}, 1, ""
+                        ("system-bus-name", {"name": sender}), action_id, {}, 1, "", timeout=60
                     )
                     if not result:
                         raise NotAuthorizedException(action_id, "polkit")

[erig0]

Long term the auth should be converted to an async call. But that requires other changes to make it work.

[erig0]

Okay. I looked into making this async. It's non-trivial. The problem is the firewalld daemon implements service methods 1 synchronously. Converting those service method handlers to be async is a prerequisite before we can call polkit asynchronously.

Today it looks like this:

[client] sync -- sync [firewalld] sync -- [polkit]

Changing the CheckAuthorization() to async would look like this:

[client] sync -- sync [firewalld] async -- [polkit]

However, this doesn't help because firewalld still has to block waiting on polkit so it can do the synchronous reply to the client.

We'd have to get to this point first:

[client] sync -- async [firewalld] async -- [polkit]

Making all the daemon's dbus handlers async is "step one"... and that's a lot of work.

Edit: I spent some time investigating this. I think it's viable to generically convert all dbus handlers to async via python decorators. However, I don't think we gain much. We would still have to serialize the dbus methods, e.g. addPort(), using the GLib main loop to avoid ordering issues with rule updates. In theory you could allow "get" like dbus calls while rule updates are queued. I also don't think there is much work firewalld could be doing while waiting on polkit auth. The rule execution (packet processing) is happening in kernel so the network is not affected by firewalld blocking on dbus/polkit.

In short, this is a fair amount of work and I don't see a lot of gain.

[erig0]

@AdamWill , I gave up on the async changes for now. I simply bumped the timeout to 60 in #1335. I'll merge it after CI.