Firewalld container and polkit actions


I try to create a firewalld container on fedora coreos. The image is ready (Docker Hub) and it basically works when started privileged:

sudo podman run -d \
                --privileged \
                --name=firewalld \
                -v /run/dbus/system_bus_socket:/run/dbus/system_bus_socket:z \

Besides the DBUS socket, it is necessary to put the FirewallD.conf from a normal Fedora firewalld RPM into /etc/dbus-1/system.d/ directory. This is possible and works.

But there is another dependency on polkit: There are rules and actions in a firewalld RPM, which need to be placed in the appropriate directories in a fedora coreos installation, because polkit is installed as a normal systemd service there. Essentially it are the following files:

$ rpm -ql firewalld | grep polkit

The rules files could presumably be placed in /etc/polkit-1/rules.d/.

But the actions cannot be placed in /usr/share/polkit-1/actions, because this is a readonly directory within the rpm-ostree. I’ve read through the source code of polkit (GitHub - freedesktop/polkit: Authorization Manager) and found out that the actions directory is apparently hard wired and not extensible (e.g. by a /etc/polkit-1/actions.d or so). This leads to the unfortunate situation, that the polkit action files for a firewalld container cannot be merged with the standard polkit installation on fedora coreos :frowning: .

I’ve verified with a normal fedora server installation, that my firewalld container would work (including podman exec -it firewalld firewall-cmd ...), if I could place the firewalld polkit action files into /usr/share/polkit-1/actions/ on the coreos host…

Is there any workaround for this? Or would the polkit sources need to be changed, to allow reading action descriptions from other/additional directories?

Sometimes it is necessary or very helpful to manage ip filter rules in a container-controlled way on coreos hosts… and a firewalld container seems to be a good choice for this.

I’ve stepped into the same shortcoming in the past, this is really an issue in polkit actions lookup logic which should be patched to behave in a smarter way.
The upstream ticket for that is actions: additional lookup path for policy files (#129) · Issues · polkit / polkit.

For the moment, I think that the quickest workaround is to locally produce a small RPM shipping the policies in /usr, and rpm-ostree install it.
You may also try asking the firewalld maintainers to rework the Fedora packaging, so that polkit content can be installed on its through a dedicated binary package. I’m not sure how open they would be to that.