Description of problem: Running this command should fail, with message that this chain is reserved for firewalld > firewall-cmd --direct --add-chain ipv4 filter INPUT_direct Version-Release number of selected component (if applicable): firewalld-0.3.10-1.fc20.noarch How reproducible: deterministic Steps to Reproduce: 1. run firewall-cmd --direct --add-chain ipv4 filter INPUT_direct Actual results: Error: COMMAND_FAILED: '/sbin/iptables -t filter -N INPUT_direct' Expected results: Message about reserved chain (or chain used by firewalld) Additional info:
For this specific case I have a question about firewalld behavior: Let's have this example: addChain(ipv4, filter, INPUT_direct) > should fail with above mentioned error message queryChain(ipv4, filter, INPUT_direct) > should return TRUE ???? removeChain(ipv4, filter, INPUT_direct) > should fail with above mentioned error message Currently addChain fails: "Chain already exists" queryChain returns FALSE removeChain fails: "NOT_ENABLED: chain 'INPUT_direct' is not in 'ipv4:filter'" which is totally non-consistent ...
On 07/15/2014 05:50 PM, Thomas Woerner wrote: > With "firewall-cmd --direct --add-chain ipv4 filter INPUT_direct" call > you found a bug. There has been a check that prevented to create chains > that collide with chain names that firewalld is using. This needs to be > fixed. Checking whether the specified chain collides with any chain used by firewalld is more code (I'd need to somehow extract used chains from ipXtables.DEFAULT_RULES and perhaps from some other structures) and more CPU cycles (processing direct rules will be slower). And for what ? different error message ? hmm :-( I don't think I want to do that.
(In reply to Jakub Jelen from comment #1) > addChain fails: "Chain already exists" that fails underlying iptables command because INPUT_direct really exists > queryChain returns FALSE because INPUT_direct was not previously added via --add-chain > removeChain fails: "NOT_ENABLED: chain 'INPUT_direct' is not in > 'ipv4:filter'" the same as queryChain above It makes sense when you realize that the 'direct' interface does know/handle only chains that have previously been added via this 'direct' interface. It doesn't know all the other chains that firewalld creates. So when you start firewalld and run # firewall-cmd --direct --get-chains ipv4 filter you'll see that there are no chains. After you add some chain via 'direct': # firewall-cmd --direct --add-chain ipv4 filter ABC and run the --get-chains again it will show the newly added ABC chain. These --[add/query/remove]-chain operations are not intended for handling all existing ip[6]tables chains, but only for creating/handling new chains. For 'really direct' operations with ip[6]tables chains there's '--direct --passthrough' operation. We should perhaps emphasize this in man pages.
This should be at least mentioned in man, that 'direct' interface does handle ONLY chains added through this interface. And preferably to mention this in addChain error message, when iptables fails with above mentioned message. "Chain already exists" should mean that the chain is reserved by firewalld or added in other way and you can't use it through the firewalld. Current behavior is inconsistent, because addChain says that chain exists, queryChain says that it doesn't exists (also removeChain). This is what I don't like on this behavior. But the resolution is also on Thomas's point of view.
(In reply to Jakub Jelen from comment #4) > Current behavior is inconsistent, because addChain says that chain exists, > queryChain says that it doesn't exists (also removeChain). Should be fixed upstream with: https://git.fedorahosted.org/cgit/firewalld.git/commit/?id=d72384cfc3eba7db5739f83a28f3476b9553c856
(In reply to Jakub Jelen from comment #4) > This should be at least mentioned in man, that 'direct' interface does > handle ONLY chains added through this interface. Should be fixed upstream with: https://git.fedorahosted.org/cgit/firewalld.git/commit/?id=fe8e7530cc1eb34370af444568a7444671878759
Thank you. This is great and it works fine. I updated my test case to pass on current version. But ... I see that there is some new problem with ebtables. This is probably related to recent commits. In 4023972b087efc399b049a08fc8d44e18164952e it still works: Example: dbus-send --system --dest=org.fedoraproject.FirewallD1 --print-reply --type=method_call /org/fedoraproject/FirewallD1 org.fedoraproject.FirewallD1.direct.addChain string:"eb" string:"filter" string:"MY_INPUT_FIRST" firewalld-0.3.10-1.fc20.noarch: (works fine) method return sender=:1.2449 -> dest=:1.2451 reply_serial=2 upstream: (error from nowhere) Error org.freedesktop.DBus.Python.dbus.exceptions.DBusException: 'filter' ... but chain is inserted. (just investigating test cases and this caught my eye)
Should be ok with https://git.fedorahosted.org/cgit/firewalld.git/commit/?id=d8485f6b1d1201b2643a19ecdc6287eb3bd65228
Tested again and it works fine for me. Thanks for your fix. :: [ 13:21:06 ] :: :::::::: Direct example :: [ BEGIN ] :: Running 'dbus-send --system --dest=org.fedoraproject.FirewallD1 --print-reply --type=method_call /org/fedoraproject/FirewallD1 org.fedoraproject.FirewallD1.direct.addChain string:"ipv4" string:"filter" string:"INPUT_direct"' Error org.freedesktop.DBus.Python.dbus.exceptions.DBusException: BUILTIN_CHAIN: chain 'INPUT_direct' is reserved :: [ PASS ] :: Command 'dbus-send --system --dest=org.fedoraproject.FirewallD1 --print-reply --type=method_call /org/fedoraproject/FirewallD1 org.fedoraproject.FirewallD1.direct.addChain string:"ipv4" string:"filter" string:"INPUT_direct"' (Expected 1, got 1) :: [ PASS ] :: File '/var/tmp/tmp.oMy1wqomkm' should contain 'BUILTIN_CHAIN: chain 'INPUT_direct' is reserved' :: [ BEGIN ] :: Running 'dbus-send --system --dest=org.fedoraproject.FirewallD1 --print-reply --type=method_call /org/fedoraproject/FirewallD1 org.fedoraproject.FirewallD1.direct.queryChain string:"ipv4" string:"filter" string:"INPUT_direct"' Error org.freedesktop.DBus.Python.dbus.exceptions.DBusException: BUILTIN_CHAIN: chain 'INPUT_direct' is reserved :: [ PASS ] :: Command 'dbus-send --system --dest=org.fedoraproject.FirewallD1 --print-reply --type=method_call /org/fedoraproject/FirewallD1 org.fedoraproject.FirewallD1.direct.queryChain string:"ipv4" string:"filter" string:"INPUT_direct"' (Expected 1, got 1) :: [ PASS ] :: File '/var/tmp/tmp.m5Mdqn3sPi' should contain 'BUILTIN_CHAIN: chain 'INPUT_direct' is reserved' :: [ BEGIN ] :: Running 'dbus-send --system --dest=org.fedoraproject.FirewallD1 --print-reply --type=method_call /org/fedoraproject/FirewallD1 org.fedoraproject.FirewallD1.direct.removeChain string:"ipv4" string:"filter" string:"INPUT_direct"' Error org.freedesktop.DBus.Python.dbus.exceptions.DBusException: BUILTIN_CHAIN: chain 'INPUT_direct' is reserved :: [ PASS ] :: Command 'dbus-send --system --dest=org.fedoraproject.FirewallD1 --print-reply --type=method_call /org/fedoraproject/FirewallD1 org.fedoraproject.FirewallD1.direct.removeChain string:"ipv4" string:"filter" string:"INPUT_direct"' (Expected 1, got 1) :: [ PASS ] :: File '/var/tmp/tmp.0ruEhx2az9' should contain 'BUILTIN_CHAIN: chain 'INPUT_direct' is reserved' :: [ BEGIN ] :: Running 'iptables-save -t filter | grep ":INPUT_direct - \[0:0\]"' :INPUT_direct - [0:0] :: [ PASS ] :: Command 'iptables-save -t filter | grep ":INPUT_direct - \[0:0\]"' (Expected 0, got 0)
firewalld-0.3.11-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/firewalld-0.3.11-1.fc20
Package firewalld-0.3.11-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing firewalld-0.3.11-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-9609/firewalld-0.3.11-1.fc20 then log in and leave karma (feedback).
Package firewalld-0.3.11-2.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing firewalld-0.3.11-2.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-9609/firewalld-0.3.11-2.fc20 then log in and leave karma (feedback).
Package firewalld-0.3.11-3.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing firewalld-0.3.11-3.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-9609/firewalld-0.3.11-3.fc20 then log in and leave karma (feedback).
firewalld-0.3.11-3.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.