+++ This bug was initially created as a clone of Bug #1138731 +++

Description of problem:

VDSM component of oVirt project is used (among many other tasks) to manage and monitor select network devices of a virtualization slave. To do so, it currently uses initscripts (/sbin/ifup and /sbin/ifdown), although alternative approaches are in development.

When asked to create a network on an interface (here, 'dummy_x') VDSM first prepares ifcfg-* file(s) and runs ifup/ifdown under its root-privileged supervdsm service.

For a reason unknown, firewall-cmd (run by ifup/ifdown scripts) takes forever when run under VSDM with firewalld service running. ifup/ifdown alone terminate successfully and promptly.

/sbin/ifdown dummy_x results in calling 'firewall-cmd --zone= --remove-interface=dummy_x'. Processes at the time supervdsm's ifdown is stuck are the following:

  ├─supervdsmd.service
  │ ├─144709 /usr/bin/python /usr/share/vdsm/supervdsmServer --sockfile /var/run/vdsm/svdsm.sock
  │ ├─145326 /bin/bash /etc/sysconfig/network-scripts/ifdown-eth ifcfg-dummy_x
  │ ├─145373 /bin/sh /etc/sysconfig/network-scripts/ifdown-post ifcfg-dummy_x
  │ └─145386 /usr/bin/python -Es /usr/bin/firewall-cmd --remove-interface=dummy_x

When debugging firewall-cmd with winpdb remotely I reached a blocking D-Bus call to method getDefaultZone on org.fedoraproject.FirewallD1 interface (/org/fedoraproject/FirewallD1 object).

In /usr/bin/firewall-cmd this was the trigger:
676 if options_zone_ops and not zone:
677     default = fw.getDefaultZone()

firewalld apparently never manages to receive or process or reply to the call. Maybe the call is even not actually made by firewall-cmd (but by stepping through firewall-cmd's code I have found no indication for this claim, even though D-Bus introspection fails for the method).

dbus-monitor --system shows the following output for ifdown dummy_x when invoked alone:

signal sender=:1.1996 -> dest=(null destination) serial=265 path=/org/fedoraproject/FirewallD1; interface=org.fedoraproject.FirewallD1.zone; member=InterfaceRemoved
   string "public"
   string "dummy_x"

No communication is shown between firewall-cmd and firewalld when run under supervdsm.

Do you have any hints what apparently causes firewall-cmd to block on calls to firewalld? Could privileges be capped by supervdsmd, D-Bus, PolicyKit, systemd?

I can offer access to my host and any assistance/information necessary.

Thanks!

Version-Release number of selected component (if applicable):
firewalld-0.3.9-7.el7.noarch
vdsm Git master

How reproducible:
100%

Steps to Reproduce:

1. Create the dummy network interface.

ip link add name dummy_x type dummy

2. Let VDSM create the ifcfg file and ifdown it (in preparation for ifup'ing it again).

vdsClient -s 0 setupNetworks networks='{test-firewalld:{nic:dummy_x,bridged:false}}'

Actual results:

supervdsmd is blocked by firewall-cmd, which never finishes.

Expected results:

firewall-cmd contacts firewalld and exits successfully.

Additional info:

Running /usr/sbin/ifdown dummy_x with the following ifcfg file is successful.

[root@localhost network-scripts]# cat ifcfg-dummy_x
# Generated by VDSM version 4.16.0-278.git189f68c.el7
DEVICE=dummy_x
HWADDR=f6:6e:b6:1e:1e:71
ONBOOT=no
DEFROUTE=no
NM_CONTROLLED=no