Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More regular automatic checks for firewalld rules? #32

Open
nekohayo opened this issue May 23, 2022 · 1 comment
Open

More regular automatic checks for firewalld rules? #32

nekohayo opened this issue May 23, 2022 · 1 comment

Comments

@nekohayo
Copy link

#9 introduced firewall hole poking. This is a nice touch. I see the readme mentions:

If Dragit detects missing port (mDNS or application one), then application can modify configuration of firewalld.
The check is done only on Linux and only on first run of the application.

Why only do it once however, considering that firewall zones can change, etc. and that dragit will always need this to work (if I'm not mistaken)?

Rather, wouldn't it make more sense for dragit to check this automatically on every startup, possibly also on every networkmanager network change (since different firewalld "zones" can be tied to different saved connections), and only notify the user when it encounters a firewalled network/zone where the hole is not already present, using a GtkInfobar widget with action button (or using the main window's UI area, since I doubt it could detect any other computers if it's firewalled...)?

@nekohayo nekohayo mentioned this issue May 23, 2022
@sireliah
Copy link
Owner

My initial plan was exactly as you describe it - to check the firewalld configuration on every boot of the Dragit app. This worked fine (on Fedora), but then when I tested the app on different distros (Ubuntu) I noticed that Ubuntu has different D-Bus policies for the firewalld interface. Namely, you need to type the password on every call to the org.fedoraproject.FirewallD1.

So we have:

  • user friction on one hand (typing password on every start of the app in the popular Linux distro), while it's possibly unlikely that the network rules changed
  • the risk that the app will not discover peers at all

Out of these two choices I decided that the second one is less impactful. Unless there is new, paswordless way to check the zone configuration, I'd ideally keep the current solution. What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants