Bug 1123403 - Inconsistent results when working with non-existing interfaces through D-Bus interface
Summary: Inconsistent results when working with non-existing interfaces through D-Bus ...
Alias: None
Product: Fedora
Classification: Fedora
Component: firewalld
Version: 22
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Thomas Woerner
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 1017034
TreeView+ depends on / blocked
Reported: 2014-07-25 14:19 UTC by Jakub Jelen
Modified: 2016-07-19 11:57 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2016-07-19 11:57:52 UTC

Attachments (Terms of Use)

Description Jakub Jelen 2014-07-25 14:19:30 UTC
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:

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.
Mention in documentation that this is also not checked nowhere?

Comment 1 Thomas Woerner 2014-08-21 10:32:41 UTC
- 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.

Comment 2 Thomas Woerner 2014-08-21 10:39:04 UTC
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.

Comment 3 Jakub Jelen 2014-08-21 11:32:34 UTC
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).

Comment 4 Jaroslav Reznik 2015-03-03 16:09:13 UTC
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:

Comment 5 Fedora End Of Life 2016-07-19 11:57:52 UTC
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

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.