You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
NetworkManager can override an interface's zone configuration, even if the interface is permanently attributed in firewalld's zone file. This causes some issues that were mitigated by also configuring the zone in NetworkManager when the running firewall-cmd --permanent, using NetworkManager's configuration API, back in commit e83ae42. However, this action is only performed when running firewall-cmd in the CLI. Tools that instead use the firewall Python module directly do not get the same results - the issue has been reported to both in this repository (in #1088) and in the Ansible posix module library (ansible-collections/ansible.posix#357, ansible-collections/ansible.posix#75).
For example on a CentOS Stream 9 (or another RHEL derivative) system, use the Ansible firewalld module to permanently assign an interface's zone - e.g. ansible localhost -m firewalld -a 'zone=work interface=eth0 state=enabled permanent=yes immediate=yes'.
The interface is assigned to the zone correctly in the runtime configuration, but the configuration does not persist across reboots (or NetworkManager service restarts), even if firewall-cmd --permanent --list-all-zones mentions the interface as part of the new zone. However, when using firewall-cmd --permanent --add-interface=eth0 --zone=work && firewall-cmd --reload, firewall-cmd also configures the interface's zone in NetworkManager, so the configuration persists across reboots.
What you expected to happen
The NetworkManager configuration should be performed in the firewall Python module, not just as part of the CLI script, as the issue is not specific to the CLI. Other tools that use the library (e.g. the firewalld Ansible module) that do not explicitly call the NetworkManager functions should get the same results from the firewall library as the firewall-cmd tool.
How to reproduce it (as minimally and precisely as possible)
ansible localhost -m firewalld -a 'zone=work interface=eth0 state=enabled permanent=yes immediate=yes'
The NetworkManager configuration should be performed in the firewall Python module, not just as part of the CLI script, as the issue is not specific to the CLI.
The nuance here is polkit authorization. If the request is done by the firewalld daemon, then it's not representative of the user making the request via firewall-cmd (or ansible). This means NetworkManager can't apply any reasonable policy for modifying the connections (ZONE) setting; it would always appear to come from the user firewalld runs as, i.e. root.
My guess is the above is why it's done by the UI and not the daemon.
So the question becomes, does it make sense to allow firewalld the daemon to modify NetworkManager's connection profiles. It may side-step NM's existing polkit policies.
I'm not sure it makes sense for firewalld (client or daemon) to forward these requests to NM on behalf of the user. It would be better to configure them through NetworkManager directly, but then users are confused because NM will alter the interface to zone assignment at runtime; overriding firewalld's own configuration. This NM integration has been in firewalld for a long time. We can't just drop it.
Is it possible to run the firewall Python module without root access? If not, I don't see a reason why firewalld wouldn't go through with the changes at library level, instead of CLI level, since in the end the result would be the same, as you'd still have to run the firewalld commands as root. You also wouldn't violate NetworkManager's polkit policies, since they cannot offer capabilities that root does not have (as far as I know, there might be some niche interactions in SELinux or other other security modules).
What happened
NetworkManager can override an interface's zone configuration, even if the interface is permanently attributed in firewalld's zone file. This causes some issues that were mitigated by also configuring the zone in NetworkManager when the running
firewall-cmd --permanent
, using NetworkManager's configuration API, back in commit e83ae42. However, this action is only performed when running firewall-cmd in the CLI. Tools that instead use the firewall Python module directly do not get the same results - the issue has been reported to both in this repository (in #1088) and in the Ansible posix module library (ansible-collections/ansible.posix#357, ansible-collections/ansible.posix#75).For example on a CentOS Stream 9 (or another RHEL derivative) system, use the Ansible firewalld module to permanently assign an interface's zone - e.g.
ansible localhost -m firewalld -a 'zone=work interface=eth0 state=enabled permanent=yes immediate=yes'
.The interface is assigned to the zone correctly in the runtime configuration, but the configuration does not persist across reboots (or NetworkManager service restarts), even if
firewall-cmd --permanent --list-all-zones
mentions the interface as part of the new zone. However, when usingfirewall-cmd --permanent --add-interface=eth0 --zone=work && firewall-cmd --reload
,firewall-cmd
also configures the interface's zone in NetworkManager, so the configuration persists across reboots.What you expected to happen
The NetworkManager configuration should be performed in the firewall Python module, not just as part of the CLI script, as the issue is not specific to the CLI. Other tools that use the library (e.g. the firewalld Ansible module) that do not explicitly call the NetworkManager functions should get the same results from the firewall library as the
firewall-cmd
tool.How to reproduce it (as minimally and precisely as possible)
has a different restult from
Anything else we need to know?
No response
Firewalld Version
1.2.5
Firewalld Backend
nftables
Linux distribution
Centos Stream 9
Linux kernel version
5.14.0-391.el9.x86_64
Other information
No response
The text was updated successfully, but these errors were encountered: