Bug 1123403

Summary: Inconsistent results when working with non-existing interfaces through D-Bus interface
Product: [Fedora] Fedora Reporter: Jakub Jelen <jjelen>
Component: firewalldAssignee: Thomas Woerner <twoerner>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 22CC: jpopelka, twoerner
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-07-19 11:57:52 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1017034    

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:
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?

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:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

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
bug.

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