Hide Forgot
Description of problem: When I work with network interfaces through D-bus using methods defined in org.fedoraproject.FirewallD1.zone I'm getting inconsistent results. Some methods (queryInterface, getZoneOfInterface, changeZoneOfInterface, changeZone, addInterface) returns just false and empty string, but removeInterface returns UNKNOWN_INTERFACE error. This is little bit inconsistent and I think, that non-existing interface should be treated the same way in all the methods if they are not known to firewalld (there should be some list of interfaces know to firewall and user shouldn't add new interface from nowhere using these methods). This also opens the question, how should firewalld treat interfaces, which doesn't exist in system. Where are they bounded or what happens to them and the zones bounded to them? To come up with some use-case, I can say, that someone will need to setup new interface, he will make a typo in interface name, all the configuration will go as expected but it will not work, because he wrote "ethl" instead of "eth1" for example. Version-Release number of selected component (if applicable): upstream git How reproducible: deterministic Steps to Reproduce: dbus-send --system --dest=org.fedoraproject.FirewallD1 --print-reply --type=method_call /org/fedoraproject/FirewallD1 org.fedoraproject.FirewallD1.zone.removeInterface string:"work" string:"my_ifc0" > Error org.freedesktop.DBus.Python.dbus.exceptions.DBusException: UNKNOWN_INTERFACE: my_ifc0 dbus-send --system --dest=org.fedoraproject.FirewallD1 --print-reply --type=method_call /org/fedoraproject/FirewallD1 org.fedoraproject.FirewallD1.zone.queryInterface string:"work" string:"my_ifc0" > method return sender=:1.1908 -> dest=:1.1911 reply_serial=2 > boolean false dbus-send --system --dest=org.fedoraproject.FirewallD1 --print-reply --type=method_call /org/fedoraproject/FirewallD1 org.fedoraproject.FirewallD1.zone.getZoneOfInterface string:"my_ifc0" > method return sender=:1.1908 -> dest=:1.1912 reply_serial=2 > string "" dbus-send --system --dest=org.fedoraproject.FirewallD1 --print-reply --type=method_call /org/fedoraproject/FirewallD1 org.fedoraproject.FirewallD1.zone.addInterface string:"work" string:"my_ifc0" > method return sender=:1.1983 -> dest=:1.1991 reply_serial=2 > string "work" dbus-send --system --dest=org.fedoraproject.FirewallD1 --print-reply --type=method_call /org/fedoraproject/FirewallD1 org.fedoraproject.FirewallD1.zone.changeZoneOfInterface string:"work" string:"my_ifc0" > method return sender=:1.1983 -> dest=:1.1984 reply_serial=2 > string "work" Expected results: Every mentioned method should fail with the same error as the first one. or Mention in documentation that this is also not checked nowhere?
- removeInterface is removing interfaces that are added before.. if the interface has not been added, there is a UNKNOWN_INTERFACE error. - queryInterface is returning if the interface is bound to the zone, therefore the return value is bool. - getZoneOfInterface should result in the UNKNOWN_INTERFACE error if the interface is not bound to any zone - but I think there has been a bug to not report this error - but maybe I am wrong with this, it needs to be checked. - addInterface is just adding the interface to the zone mentioned (or default zone if zone="") and return the zone it has been added to - the return value is needed in the case of zone="" to know which zone it ended up without doing an extra call to getDefaultZone. Same for changeZoneOfInterface.
Yes, it is possible (and needed) to bind interfaces to zones that do not exist in the system. Interfaces should be bound to zones before they are created, otherwise there could be a time frame without (proper) firewall rules in place.
Similar problem is in interface org.fedoraproject.FirewallD1.config when calling these functions with non-existing interface/source: * getZoneOfInterface * getZoneOfSource firewalld returns also empty string here (as mentioned in documentation).
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.