External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-07-06 09:55:46 +00:00
Code Issues Packages Projects Releases Wiki Activity
92ca314695
libvirt/tests/virfirewalltest.c

1113 lines
36 KiB
C
Raw Normal View History

Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
/*
* Copyright (C) 2013-2014 Red Hat, Inc.
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library. If not, see
* <http://www.gnu.org/licenses/>.
*/
#include <config.h>
#include "testutils.h"
tests: skip virfirewalltest on non-Linux systems Currently firewalling is supported on Linux only, so skip the virfirewalltest on other platforms.
2014-05-01 18:43:58 +00:00
#if defined(__linux__)
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
src/util/virfirewalld: convert to use GLib DBus Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-09-15 12:00:53 +00:00
# include <gio/gio.h>
tests: skip virfirewalltest on non-Linux systems Currently firewalling is supported on Linux only, so skip the virfirewalltest on other platforms.
2014-05-01 18:43:58 +00:00
# include "virbuffer.h"
Enforce a standard header file guard symbol name Require that all headers are guarded by a symbol named LIBVIRT_$FILENAME where $FILENAME is the uppercased filename, with all characters outside a-z changed into '_'. Note we do not use a leading __ because that is technically a namespace reserved for the toolchain. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-12-13 14:53:50 +00:00
# define LIBVIRT_VIRCOMMANDPRIV_H_ALLOW
tests: skip virfirewalltest on non-Linux systems Currently firewalling is supported on Linux only, so skip the virfirewalltest on other platforms.
2014-05-01 18:43:58 +00:00
# include "vircommandpriv.h"
Enforce a standard header file guard symbol name Require that all headers are guarded by a symbol named LIBVIRT_$FILENAME where $FILENAME is the uppercased filename, with all characters outside a-z changed into '_'. Note we do not use a leading __ because that is technically a namespace reserved for the toolchain. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-12-13 14:53:50 +00:00
# define LIBVIRT_VIRFIREWALLPRIV_H_ALLOW
tests: skip virfirewalltest on non-Linux systems Currently firewalling is supported on Linux only, so skip the virfirewalltest on other platforms.
2014-05-01 18:43:58 +00:00
# include "virfirewallpriv.h"
util: move all firewalld-specific stuff into its own files In preparation for adding several other firewalld-specific functions, separate the code that's unique to firewalld from the more-generic "firewall" file. Signed-off-by: Laine Stump <laine@laine.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-01-09 19:11:32 +00:00
# define LIBVIRT_VIRFIREWALLDPRIV_H_ALLOW
# include "virfirewalldpriv.h"
tests: skip virfirewalltest on non-Linux systems Currently firewalling is supported on Linux only, so skip the virfirewalltest on other platforms.
2014-05-01 18:43:58 +00:00
# include "virmock.h"
# define VIR_FROM_THIS VIR_FROM_FIREWALL
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
static bool fwDisabled = true;
static virBufferPtr fwBuf;
static bool fwError;
Remove backslash alignment attempts Right-aligning backslashes when defining macros or using complex commands in Makefiles looks cute, but as soon as any changes is required to the code you end up with either distractingly broken alignment or unnecessarily big diffs where most of the changes are just pushing all backslashes a few characters to one side. Generated using $ git grep -El '[[:blank:]][[:blank:]]\\$' | \ grep -E '*\.([chx]|am|mk)$$' | \ while read f; do \ sed -Ei 's/[[:blank:]]*[[:blank:]]\\$/ \\/g' "$f"; \ done Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2017-11-03 12:09:47 +00:00
# define TEST_FILTER_TABLE_LIST \
"Chain INPUT (policy ACCEPT)\n" \
"target prot opt source destination\n" \
"\n" \
"Chain FORWARD (policy ACCEPT)\n" \
"target prot opt source destination\n" \
"\n" \
"Chain OUTPUT (policy ACCEPT)\n" \
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"target prot opt source destination\n"
Remove backslash alignment attempts Right-aligning backslashes when defining macros or using complex commands in Makefiles looks cute, but as soon as any changes is required to the code you end up with either distractingly broken alignment or unnecessarily big diffs where most of the changes are just pushing all backslashes a few characters to one side. Generated using $ git grep -El '[[:blank:]][[:blank:]]\\$' | \ grep -E '*\.([chx]|am|mk)$$' | \ while read f; do \ sed -Ei 's/[[:blank:]]*[[:blank:]]\\$/ \\/g' "$f"; \ done Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2017-11-03 12:09:47 +00:00
# define TEST_NAT_TABLE_LIST \
"Chain PREROUTING (policy ACCEPT)\n" \
"target prot opt source destination\n" \
"\n" \
"Chain INPUT (policy ACCEPT)\n" \
"target prot opt source destination\n" \
"\n" \
"Chain OUTPUT (policy ACCEPT)\n" \
"target prot opt source destination\n" \
"\n" \
"Chain POSTROUTING (policy ACCEPT)\n" \
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"target prot opt source destination\n"
src/util/virfirewalld: convert to use GLib DBus Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-09-15 12:00:53 +00:00
VIR_MOCK_WRAP_RET_ARGS(g_dbus_connection_call_sync,
GVariant *,
GDBusConnection *, connection,
const gchar *, bus_name,
const gchar *, object_path,
const gchar *, interface_name,
const gchar *, method_name,
GVariant *, parameters,
const GVariantType *, reply_type,
GDBusCallFlags, flags,
gint, timeout_msec,
GCancellable *, cancellable,
GError **, error)
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
{
src/util/virfirewalld: convert to use GLib DBus Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-09-15 12:00:53 +00:00
GVariant *reply = NULL;
g_autoptr(GVariant) params = parameters;
tests: fix incorrect free of GVariant in our GLib mock functions GLib implementation of g_dbus_connection_call_sync() calls g_variant_ref_sink() on the passed @parameters to make sure they have proper reference. If the original reference is floating the g_dbus_connection_call_sync() consumes it, but if it's normal reference it will just add another one. Our mock functions were only freeing the @parameters which is incorrect and doesn't reflect how the real implementation works. Reported-by: Cole Robinson <crobinso@redhat.com> Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-10-02 10:11:45 +00:00
if (params)
g_variant_ref_sink(params);
src/util/virfirewalld: convert to use GLib DBus Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-09-15 12:00:53 +00:00
VIR_MOCK_REAL_INIT(g_dbus_connection_call_sync);
if (STREQ(bus_name, "org.freedesktop.DBus") &&
STREQ(method_name, "ListNames")) {
GVariantBuilder builder;
g_variant_builder_init(&builder, G_VARIANT_TYPE("(as)"));
g_variant_builder_open(&builder, G_VARIANT_TYPE("as"));
g_variant_builder_add(&builder, "s", "org.foo.bar.wizz");
if (!fwDisabled)
g_variant_builder_add(&builder, "s", VIR_FIREWALL_FIREWALLD_SERVICE);
g_variant_builder_close(&builder);
reply = g_variant_builder_end(&builder);
} else if (STREQ(bus_name, VIR_FIREWALL_FIREWALLD_SERVICE) &&
STREQ(method_name, "passthrough")) {
g_autoptr(GVariantIter) iter = NULL;
virfirewalltest: Avoid use of 'virStringListAdd' To allow later removal of 'virStringListAdd' add an arbitrary upper limit on the number of args we care about and don't store more than that until necessary later. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-02-04 21:43:40 +00:00
static const size_t maxargs = 5;
lib: Replace VIR_AUTOSTRINGLIST with GStrv Glib provides g_auto(GStrv) which is in-place replacement of our VIR_AUTOSTRINGLIST. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-12-01 08:21:32 +00:00
g_auto(GStrv) args = NULL;
src/util/virfirewalld: convert to use GLib DBus Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-09-15 12:00:53 +00:00
size_t nargs = 0;
char *type = NULL;
char *item = NULL;
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
bool isAdd = false;
bool doError = false;
src/util/virfirewalld: convert to use GLib DBus Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-09-15 12:00:53 +00:00
g_variant_get(params, "(&sas)", &type, &iter);
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
virfirewalltest: Avoid use of 'virStringListAdd' To allow later removal of 'virStringListAdd' add an arbitrary upper limit on the number of args we care about and don't store more than that until necessary later. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-02-04 21:43:40 +00:00
args = g_new0(char *, maxargs);
src/util/virfirewalld: convert to use GLib DBus Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-09-15 12:00:53 +00:00
virfirewalltest: Shuffle the code around to remove a loop We are already looping over the arguments to construct the list, so we can add them to fwBuf right away rather than in an extra loop if we move some of the 'fwBuf' parts earlier and merge the two loops. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-02-05 14:45:52 +00:00
if (fwBuf) {
if (STREQ(type, "ipv4"))
virBufferAddLit(fwBuf, IPTABLES_PATH);
else if (STREQ(type, "ipv6"))
virBufferAddLit(fwBuf, IP6TABLES_PATH);
else
virBufferAddLit(fwBuf, EBTABLES_PATH);
}
src/util/virfirewalld: convert to use GLib DBus Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-09-15 12:00:53 +00:00
while (g_variant_iter_loop(iter, "s", &item)) {
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
/* Fake failure on the command with this IP addr */
src/util/virfirewalld: convert to use GLib DBus Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-09-15 12:00:53 +00:00
if (STREQ(item, "-A")) {
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
isAdd = true;
src/util/virfirewalld: convert to use GLib DBus Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-09-15 12:00:53 +00:00
} else if (isAdd && STREQ(item, "192.168.122.255")) {
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
doError = true;
}
src/util/virfirewalld: convert to use GLib DBus Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-09-15 12:00:53 +00:00
virfirewalltest: Avoid use of 'virStringListAdd' To allow later removal of 'virStringListAdd' add an arbitrary upper limit on the number of args we care about and don't store more than that until necessary later. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-02-04 21:43:40 +00:00
if (nargs < maxargs)
args[nargs] = g_strdup(item);
nargs++;
src/util/virfirewalld: convert to use GLib DBus Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-09-15 12:00:53 +00:00
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
if (fwBuf) {
virBufferAddLit(fwBuf, " ");
virfirewalltest: Shuffle the code around to remove a loop We are already looping over the arguments to construct the list, so we can add them to fwBuf right away rather than in an extra loop if we move some of the 'fwBuf' parts earlier and merge the two loops. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-02-05 14:45:52 +00:00
virBufferEscapeShell(fwBuf, item);
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
}
}
src/util/virfirewalld: convert to use GLib DBus Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-09-15 12:00:53 +00:00
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
if (fwBuf)
virBufferAddLit(fwBuf, "\n");
src/util/virfirewalld: convert to use GLib DBus Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-09-15 12:00:53 +00:00
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
if (doError) {
src/util/virfirewalld: convert to use GLib DBus Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-09-15 12:00:53 +00:00
if (error)
*error = g_dbus_error_new_for_dbus_error("org.firewalld.error",
"something bad happened");
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
} else {
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 00:20:53 +00:00
if (nargs == 2 &&
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
STREQ(type, "ipv4") &&
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 00:20:53 +00:00
STREQ(args[0], "-w") &&
STREQ(args[1], "-L")) {
src/util/virfirewalld: convert to use GLib DBus Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-09-15 12:00:53 +00:00
reply = g_variant_new("(s)", TEST_FILTER_TABLE_LIST);
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 00:20:53 +00:00
} else if (nargs == 4 &&
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
STREQ(type, "ipv4") &&
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 00:20:53 +00:00
STREQ(args[0], "-w") &&
STREQ(args[1], "-t") &&
STREQ(args[2], "nat") &&
STREQ(args[3], "-L")) {
src/util/virfirewalld: convert to use GLib DBus Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-09-15 12:00:53 +00:00
reply = g_variant_new("(s)", TEST_NAT_TABLE_LIST);
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
} else {
src/util/virfirewalld: convert to use GLib DBus Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-09-15 12:00:53 +00:00
reply = g_variant_new("(s)", "success");
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
}
}
} else {
src/util/virfirewalld: convert to use GLib DBus Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-09-15 12:00:53 +00:00
reply = g_variant_new("()");
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
}
return reply;
}
struct testFirewallData {
virFirewallBackend tryBackend;
virFirewallBackend expectBackend;
bool fwDisabled;
};
static int
testFirewallSingleGroup(const void *opaque)
{
tests: use g_auto for all virBuffers Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-07-02 23:35:41 +00:00
g_auto(virBuffer) cmdbuf = VIR_BUFFER_INITIALIZER;
use g_autoptr() for all usages of virFirewallNew/Free Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-07-04 20:35:10 +00:00
g_autoptr(virFirewall) fw = virFirewallNew();
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
int ret = -1;
const char *actual = NULL;
const char *expected =
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
IPTABLES_PATH " -w -A INPUT --source 192.168.122.1 --jump ACCEPT\n"
IPTABLES_PATH " -w -A INPUT --source '!192.168.122.1' --jump REJECT\n";
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
const struct testFirewallData *data = opaque;
fwDisabled = data->fwDisabled;
if (virFirewallSetBackend(data->tryBackend) < 0)
goto cleanup;
util: call iptables directly rather than via firewalld When libvirt added support for firewalld, we were unable to use firewalld's higher level rules, because they weren't detailed enough and could not be applied to the iptables FORWARD or OUTPUT chains (only to the INPUT chain). Instead we changed our code so that rather than running the iptables/ip6tables/ebtables binaries ourselves, we would send these commands to firewalld as "passthrough commands", and firewalld would run the appropriate program on our behalf. This was done under the assumption that firewalld was somehow tracking all these rules, and that this tracking was benefitting proper operation of firewalld and the system in general. Several years later this came up in a discussion on IRC, and we learned from the firewalld developers that, in fact, adding iptables and ebtables rules with firewalld's passthrough commands actually has *no* advantage; firewalld doesn't keep track of these rules in any way, and doesn't use them to tailor the construction of its own rules. Meanwhile, users have been complaining for some time that whenever firewalld is restarted on a system with libvirt virtual networks and/or nwfilter rules active, the system logs would be flooded with warning messages whining that [lots of different rules] could not be deleted because they didn't exist. For example: firewalld[3536040]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -w --table filter --delete LIBVIRT_OUT --out-interface virbr4 --protocol udp --destination-port 68 --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?). (See https://bugzilla.redhat.com/1790837 for many more examples and a discussion) Note that these messages are created by iptables, but are logged by firewalld - when an iptables/ebtables command fails, firewalld grabs whatever is in stderr of the program, and spits it out to the system log as a warning. We've requested that firewalld not do this (and instead leave it up to the calling application to do the appropriate logging), but this request has been respectfully denied. But combining the two problems above ( 1) firewalld doesn't do anything useful when you use it as a proxy to add/remove iptables rules, 2) firewalld often insists on logging lots of annoying/misleading/useless "error" messages when you use it as a proxy to remove iptables rules that don't already exist), leads to a solution - simply stop using firewalld to add and remove iptables rules. Instead, exec iptables/ip6tables/ebtables directly in the same way we do when firewalld isn't active. We still need to keep track of whether or not firewalld is active, as there are some things that must be done, e.g. we need to add some actual firewalld rules in the firewalld "libvirt" zone, and we need to take notice when firewalld restarts, so that we can reload all our rules. This patch doesn't remove the infrastructure that allows having different firewall backends that perform their functions in different ways, as that will very possibly come in handy in the future when we want to have an nftables direct backend, and possibly a "pure" firewalld backend (now that firewalld supports more complex rules, and can add those rules to the FORWARD and OUTPUT chains). Instead, it just changes the action when the selected backend is "firewalld" so that it adds rules directly rather than through firewalld, while leaving as much of the existing code intact as possible. In order for tests to still pass, virfirewalltest also had to be modified to behave in a different way (i.e. by capturing the generated commandline as it does for the DIRECT backend, rather than capturing dbus messages using a mocked dbus API). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 15:55:12 +00:00
if (data->expectBackend == VIR_FIREWALL_BACKEND_DIRECT ||
data->expectBackend == VIR_FIREWALL_BACKEND_FIREWALLD)
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
virCommandSetDryRun(&cmdbuf, NULL, NULL);
else
fwBuf = &cmdbuf;
virFirewallStartTransaction(fw, 0);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "192.168.122.1",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "ACCEPT", NULL);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "!192.168.122.1",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "REJECT", NULL);
if (virFirewallApply(fw) < 0)
goto cleanup;
actual = virBufferCurrentContent(&cmdbuf);
if (STRNEQ_NULLABLE(expected, actual)) {
Fix minor typos in messages and docs Signed-off-by: Yuri Chornoivan <yurchor@ukr.net> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2018-12-04 17:08:14 +00:00
fprintf(stderr, "Unexpected command execution\n");
Rename virtTestDifference to virTestDifference. This function doesn't follow our convention of naming functions.
2016-05-26 15:01:51 +00:00
virTestDifference(stderr, expected, actual);
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
goto cleanup;
}
ret = 0;
cleanup:
fwBuf = NULL;
virCommandSetDryRun(NULL, NULL, NULL);
return ret;
}
static int
testFirewallRemoveRule(const void *opaque)
{
tests: use g_auto for all virBuffers Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-07-02 23:35:41 +00:00
g_auto(virBuffer) cmdbuf = VIR_BUFFER_INITIALIZER;
use g_autoptr() for all usages of virFirewallNew/Free Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-07-04 20:35:10 +00:00
g_autoptr(virFirewall) fw = virFirewallNew();
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
int ret = -1;
const char *actual = NULL;
const char *expected =
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
IPTABLES_PATH " -w -A INPUT --source 192.168.122.1 --jump ACCEPT\n"
IPTABLES_PATH " -w -A INPUT --source '!192.168.122.1' --jump REJECT\n";
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
const struct testFirewallData *data = opaque;
virFirewallRulePtr fwrule;
fwDisabled = data->fwDisabled;
if (virFirewallSetBackend(data->tryBackend) < 0)
goto cleanup;
util: call iptables directly rather than via firewalld When libvirt added support for firewalld, we were unable to use firewalld's higher level rules, because they weren't detailed enough and could not be applied to the iptables FORWARD or OUTPUT chains (only to the INPUT chain). Instead we changed our code so that rather than running the iptables/ip6tables/ebtables binaries ourselves, we would send these commands to firewalld as "passthrough commands", and firewalld would run the appropriate program on our behalf. This was done under the assumption that firewalld was somehow tracking all these rules, and that this tracking was benefitting proper operation of firewalld and the system in general. Several years later this came up in a discussion on IRC, and we learned from the firewalld developers that, in fact, adding iptables and ebtables rules with firewalld's passthrough commands actually has *no* advantage; firewalld doesn't keep track of these rules in any way, and doesn't use them to tailor the construction of its own rules. Meanwhile, users have been complaining for some time that whenever firewalld is restarted on a system with libvirt virtual networks and/or nwfilter rules active, the system logs would be flooded with warning messages whining that [lots of different rules] could not be deleted because they didn't exist. For example: firewalld[3536040]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -w --table filter --delete LIBVIRT_OUT --out-interface virbr4 --protocol udp --destination-port 68 --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?). (See https://bugzilla.redhat.com/1790837 for many more examples and a discussion) Note that these messages are created by iptables, but are logged by firewalld - when an iptables/ebtables command fails, firewalld grabs whatever is in stderr of the program, and spits it out to the system log as a warning. We've requested that firewalld not do this (and instead leave it up to the calling application to do the appropriate logging), but this request has been respectfully denied. But combining the two problems above ( 1) firewalld doesn't do anything useful when you use it as a proxy to add/remove iptables rules, 2) firewalld often insists on logging lots of annoying/misleading/useless "error" messages when you use it as a proxy to remove iptables rules that don't already exist), leads to a solution - simply stop using firewalld to add and remove iptables rules. Instead, exec iptables/ip6tables/ebtables directly in the same way we do when firewalld isn't active. We still need to keep track of whether or not firewalld is active, as there are some things that must be done, e.g. we need to add some actual firewalld rules in the firewalld "libvirt" zone, and we need to take notice when firewalld restarts, so that we can reload all our rules. This patch doesn't remove the infrastructure that allows having different firewall backends that perform their functions in different ways, as that will very possibly come in handy in the future when we want to have an nftables direct backend, and possibly a "pure" firewalld backend (now that firewalld supports more complex rules, and can add those rules to the FORWARD and OUTPUT chains). Instead, it just changes the action when the selected backend is "firewalld" so that it adds rules directly rather than through firewalld, while leaving as much of the existing code intact as possible. In order for tests to still pass, virfirewalltest also had to be modified to behave in a different way (i.e. by capturing the generated commandline as it does for the DIRECT backend, rather than capturing dbus messages using a mocked dbus API). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 15:55:12 +00:00
if (data->expectBackend == VIR_FIREWALL_BACKEND_DIRECT ||
data->expectBackend == VIR_FIREWALL_BACKEND_FIREWALLD)
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
virCommandSetDryRun(&cmdbuf, NULL, NULL);
else
fwBuf = &cmdbuf;
virFirewallStartTransaction(fw, 0);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "192.168.122.1",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "ACCEPT", NULL);
fwrule = virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT", NULL);
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
virFirewallRuleAddArg(fw, fwrule, "--source");
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
virFirewallRemoveRule(fw, fwrule);
fwrule = virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT", NULL);
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
virFirewallRuleAddArg(fw, fwrule, "--source");
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
virFirewallRuleAddArgFormat(fw, fwrule, "%s", "!192.168.122.1");
virFirewallRuleAddArgList(fw, fwrule, "--jump", "REJECT", NULL);
if (virFirewallApply(fw) < 0)
goto cleanup;
actual = virBufferCurrentContent(&cmdbuf);
if (STRNEQ_NULLABLE(expected, actual)) {
Fix minor typos in messages and docs Signed-off-by: Yuri Chornoivan <yurchor@ukr.net> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2018-12-04 17:08:14 +00:00
fprintf(stderr, "Unexpected command execution\n");
Rename virtTestDifference to virTestDifference. This function doesn't follow our convention of naming functions.
2016-05-26 15:01:51 +00:00
virTestDifference(stderr, expected, actual);
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
goto cleanup;
}
ret = 0;
cleanup:
fwBuf = NULL;
virCommandSetDryRun(NULL, NULL, NULL);
return ret;
}
static int
tests: use G_GNUC_UNUSED Use G_GNUC_UNUSED from GLib instead of ATTRIBUTE_UNUSED. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-14 12:45:03 +00:00
testFirewallManyGroups(const void *opaque G_GNUC_UNUSED)
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
{
tests: use g_auto for all virBuffers Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-07-02 23:35:41 +00:00
g_auto(virBuffer) cmdbuf = VIR_BUFFER_INITIALIZER;
use g_autoptr() for all usages of virFirewallNew/Free Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-07-04 20:35:10 +00:00
g_autoptr(virFirewall) fw = virFirewallNew();
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
int ret = -1;
const char *actual = NULL;
const char *expected =
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
IPTABLES_PATH " -w -A INPUT --source 192.168.122.1 --jump ACCEPT\n"
IPTABLES_PATH " -w -A INPUT --source '!192.168.122.1' --jump REJECT\n"
IPTABLES_PATH " -w -A OUTPUT --source 192.168.122.1 --jump ACCEPT\n"
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 00:20:53 +00:00
IPTABLES_PATH " -w -A OUTPUT --jump DROP\n";
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
const struct testFirewallData *data = opaque;
fwDisabled = data->fwDisabled;
if (virFirewallSetBackend(data->tryBackend) < 0)
goto cleanup;
util: call iptables directly rather than via firewalld When libvirt added support for firewalld, we were unable to use firewalld's higher level rules, because they weren't detailed enough and could not be applied to the iptables FORWARD or OUTPUT chains (only to the INPUT chain). Instead we changed our code so that rather than running the iptables/ip6tables/ebtables binaries ourselves, we would send these commands to firewalld as "passthrough commands", and firewalld would run the appropriate program on our behalf. This was done under the assumption that firewalld was somehow tracking all these rules, and that this tracking was benefitting proper operation of firewalld and the system in general. Several years later this came up in a discussion on IRC, and we learned from the firewalld developers that, in fact, adding iptables and ebtables rules with firewalld's passthrough commands actually has *no* advantage; firewalld doesn't keep track of these rules in any way, and doesn't use them to tailor the construction of its own rules. Meanwhile, users have been complaining for some time that whenever firewalld is restarted on a system with libvirt virtual networks and/or nwfilter rules active, the system logs would be flooded with warning messages whining that [lots of different rules] could not be deleted because they didn't exist. For example: firewalld[3536040]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -w --table filter --delete LIBVIRT_OUT --out-interface virbr4 --protocol udp --destination-port 68 --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?). (See https://bugzilla.redhat.com/1790837 for many more examples and a discussion) Note that these messages are created by iptables, but are logged by firewalld - when an iptables/ebtables command fails, firewalld grabs whatever is in stderr of the program, and spits it out to the system log as a warning. We've requested that firewalld not do this (and instead leave it up to the calling application to do the appropriate logging), but this request has been respectfully denied. But combining the two problems above ( 1) firewalld doesn't do anything useful when you use it as a proxy to add/remove iptables rules, 2) firewalld often insists on logging lots of annoying/misleading/useless "error" messages when you use it as a proxy to remove iptables rules that don't already exist), leads to a solution - simply stop using firewalld to add and remove iptables rules. Instead, exec iptables/ip6tables/ebtables directly in the same way we do when firewalld isn't active. We still need to keep track of whether or not firewalld is active, as there are some things that must be done, e.g. we need to add some actual firewalld rules in the firewalld "libvirt" zone, and we need to take notice when firewalld restarts, so that we can reload all our rules. This patch doesn't remove the infrastructure that allows having different firewall backends that perform their functions in different ways, as that will very possibly come in handy in the future when we want to have an nftables direct backend, and possibly a "pure" firewalld backend (now that firewalld supports more complex rules, and can add those rules to the FORWARD and OUTPUT chains). Instead, it just changes the action when the selected backend is "firewalld" so that it adds rules directly rather than through firewalld, while leaving as much of the existing code intact as possible. In order for tests to still pass, virfirewalltest also had to be modified to behave in a different way (i.e. by capturing the generated commandline as it does for the DIRECT backend, rather than capturing dbus messages using a mocked dbus API). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 15:55:12 +00:00
if (data->expectBackend == VIR_FIREWALL_BACKEND_DIRECT ||
data->expectBackend == VIR_FIREWALL_BACKEND_FIREWALLD)
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
virCommandSetDryRun(&cmdbuf, NULL, NULL);
else
fwBuf = &cmdbuf;
virFirewallStartTransaction(fw, 0);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "192.168.122.1",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "ACCEPT", NULL);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "!192.168.122.1",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "REJECT", NULL);
virFirewallStartTransaction(fw, 0);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "OUTPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "192.168.122.1",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "ACCEPT", NULL);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "OUTPUT",
"--jump", "DROP", NULL);
if (virFirewallApply(fw) < 0)
goto cleanup;
actual = virBufferCurrentContent(&cmdbuf);
if (STRNEQ_NULLABLE(expected, actual)) {
Fix minor typos in messages and docs Signed-off-by: Yuri Chornoivan <yurchor@ukr.net> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2018-12-04 17:08:14 +00:00
fprintf(stderr, "Unexpected command execution\n");
Rename virtTestDifference to virTestDifference. This function doesn't follow our convention of naming functions.
2016-05-26 15:01:51 +00:00
virTestDifference(stderr, expected, actual);
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
goto cleanup;
}
ret = 0;
cleanup:
fwBuf = NULL;
virCommandSetDryRun(NULL, NULL, NULL);
return ret;
}
static void
testFirewallRollbackHook(const char *const*args,
tests: use G_GNUC_UNUSED Use G_GNUC_UNUSED from GLib instead of ATTRIBUTE_UNUSED. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-14 12:45:03 +00:00
const char *const*env G_GNUC_UNUSED,
const char *input G_GNUC_UNUSED,
char **output G_GNUC_UNUSED,
char **error G_GNUC_UNUSED,
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
int *status,
tests: use G_GNUC_UNUSED Use G_GNUC_UNUSED from GLib instead of ATTRIBUTE_UNUSED. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-14 12:45:03 +00:00
void *opaque G_GNUC_UNUSED)
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
{
bool isAdd = false;
while (*args) {
/* Fake failure on the command with this IP addr */
if (STREQ(*args, "-A")) {
isAdd = true;
} else if (isAdd && STREQ(*args, "192.168.122.255")) {
*status = 127;
break;
}
args++;
}
}
static int
tests: use G_GNUC_UNUSED Use G_GNUC_UNUSED from GLib instead of ATTRIBUTE_UNUSED. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-14 12:45:03 +00:00
testFirewallIgnoreFailGroup(const void *opaque G_GNUC_UNUSED)
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
{
tests: use g_auto for all virBuffers Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-07-02 23:35:41 +00:00
g_auto(virBuffer) cmdbuf = VIR_BUFFER_INITIALIZER;
use g_autoptr() for all usages of virFirewallNew/Free Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-07-04 20:35:10 +00:00
g_autoptr(virFirewall) fw = virFirewallNew();
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
int ret = -1;
const char *actual = NULL;
const char *expected =
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
IPTABLES_PATH " -w -A INPUT --source 192.168.122.1 --jump ACCEPT\n"
IPTABLES_PATH " -w -A INPUT --source 192.168.122.255 --jump REJECT\n"
IPTABLES_PATH " -w -A OUTPUT --source 192.168.122.1 --jump ACCEPT\n"
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 00:20:53 +00:00
IPTABLES_PATH " -w -A OUTPUT --jump DROP\n";
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
const struct testFirewallData *data = opaque;
fwDisabled = data->fwDisabled;
if (virFirewallSetBackend(data->tryBackend) < 0)
goto cleanup;
util: call iptables directly rather than via firewalld When libvirt added support for firewalld, we were unable to use firewalld's higher level rules, because they weren't detailed enough and could not be applied to the iptables FORWARD or OUTPUT chains (only to the INPUT chain). Instead we changed our code so that rather than running the iptables/ip6tables/ebtables binaries ourselves, we would send these commands to firewalld as "passthrough commands", and firewalld would run the appropriate program on our behalf. This was done under the assumption that firewalld was somehow tracking all these rules, and that this tracking was benefitting proper operation of firewalld and the system in general. Several years later this came up in a discussion on IRC, and we learned from the firewalld developers that, in fact, adding iptables and ebtables rules with firewalld's passthrough commands actually has *no* advantage; firewalld doesn't keep track of these rules in any way, and doesn't use them to tailor the construction of its own rules. Meanwhile, users have been complaining for some time that whenever firewalld is restarted on a system with libvirt virtual networks and/or nwfilter rules active, the system logs would be flooded with warning messages whining that [lots of different rules] could not be deleted because they didn't exist. For example: firewalld[3536040]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -w --table filter --delete LIBVIRT_OUT --out-interface virbr4 --protocol udp --destination-port 68 --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?). (See https://bugzilla.redhat.com/1790837 for many more examples and a discussion) Note that these messages are created by iptables, but are logged by firewalld - when an iptables/ebtables command fails, firewalld grabs whatever is in stderr of the program, and spits it out to the system log as a warning. We've requested that firewalld not do this (and instead leave it up to the calling application to do the appropriate logging), but this request has been respectfully denied. But combining the two problems above ( 1) firewalld doesn't do anything useful when you use it as a proxy to add/remove iptables rules, 2) firewalld often insists on logging lots of annoying/misleading/useless "error" messages when you use it as a proxy to remove iptables rules that don't already exist), leads to a solution - simply stop using firewalld to add and remove iptables rules. Instead, exec iptables/ip6tables/ebtables directly in the same way we do when firewalld isn't active. We still need to keep track of whether or not firewalld is active, as there are some things that must be done, e.g. we need to add some actual firewalld rules in the firewalld "libvirt" zone, and we need to take notice when firewalld restarts, so that we can reload all our rules. This patch doesn't remove the infrastructure that allows having different firewall backends that perform their functions in different ways, as that will very possibly come in handy in the future when we want to have an nftables direct backend, and possibly a "pure" firewalld backend (now that firewalld supports more complex rules, and can add those rules to the FORWARD and OUTPUT chains). Instead, it just changes the action when the selected backend is "firewalld" so that it adds rules directly rather than through firewalld, while leaving as much of the existing code intact as possible. In order for tests to still pass, virfirewalltest also had to be modified to behave in a different way (i.e. by capturing the generated commandline as it does for the DIRECT backend, rather than capturing dbus messages using a mocked dbus API). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 15:55:12 +00:00
if (data->expectBackend == VIR_FIREWALL_BACKEND_DIRECT ||
data->expectBackend == VIR_FIREWALL_BACKEND_FIREWALLD) {
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
virCommandSetDryRun(&cmdbuf, testFirewallRollbackHook, NULL);
} else {
fwBuf = &cmdbuf;
fwError = true;
}
virFirewallStartTransaction(fw, VIR_FIREWALL_TRANSACTION_IGNORE_ERRORS);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "192.168.122.1",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "ACCEPT", NULL);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "192.168.122.255",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "REJECT", NULL);
virFirewallStartTransaction(fw, 0);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "OUTPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "192.168.122.1",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "ACCEPT", NULL);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "OUTPUT",
"--jump", "DROP", NULL);
if (virFirewallApply(fw) < 0)
goto cleanup;
actual = virBufferCurrentContent(&cmdbuf);
if (STRNEQ_NULLABLE(expected, actual)) {
Fix minor typos in messages and docs Signed-off-by: Yuri Chornoivan <yurchor@ukr.net> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2018-12-04 17:08:14 +00:00
fprintf(stderr, "Unexpected command execution\n");
Rename virtTestDifference to virTestDifference. This function doesn't follow our convention of naming functions.
2016-05-26 15:01:51 +00:00
virTestDifference(stderr, expected, actual);
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
goto cleanup;
}
ret = 0;
cleanup:
fwBuf = NULL;
virCommandSetDryRun(NULL, NULL, NULL);
return ret;
}
static int
tests: use G_GNUC_UNUSED Use G_GNUC_UNUSED from GLib instead of ATTRIBUTE_UNUSED. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-14 12:45:03 +00:00
testFirewallIgnoreFailRule(const void *opaque G_GNUC_UNUSED)
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
{
tests: use g_auto for all virBuffers Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-07-02 23:35:41 +00:00
g_auto(virBuffer) cmdbuf = VIR_BUFFER_INITIALIZER;
use g_autoptr() for all usages of virFirewallNew/Free Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-07-04 20:35:10 +00:00
g_autoptr(virFirewall) fw = virFirewallNew();
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
int ret = -1;
const char *actual = NULL;
const char *expected =
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
IPTABLES_PATH " -w -A INPUT --source 192.168.122.1 --jump ACCEPT\n"
IPTABLES_PATH " -w -A INPUT --source 192.168.122.255 --jump REJECT\n"
IPTABLES_PATH " -w -A OUTPUT --source 192.168.122.1 --jump ACCEPT\n"
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 00:20:53 +00:00
IPTABLES_PATH " -w -A OUTPUT --jump DROP\n";
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
const struct testFirewallData *data = opaque;
fwDisabled = data->fwDisabled;
if (virFirewallSetBackend(data->tryBackend) < 0)
goto cleanup;
util: call iptables directly rather than via firewalld When libvirt added support for firewalld, we were unable to use firewalld's higher level rules, because they weren't detailed enough and could not be applied to the iptables FORWARD or OUTPUT chains (only to the INPUT chain). Instead we changed our code so that rather than running the iptables/ip6tables/ebtables binaries ourselves, we would send these commands to firewalld as "passthrough commands", and firewalld would run the appropriate program on our behalf. This was done under the assumption that firewalld was somehow tracking all these rules, and that this tracking was benefitting proper operation of firewalld and the system in general. Several years later this came up in a discussion on IRC, and we learned from the firewalld developers that, in fact, adding iptables and ebtables rules with firewalld's passthrough commands actually has *no* advantage; firewalld doesn't keep track of these rules in any way, and doesn't use them to tailor the construction of its own rules. Meanwhile, users have been complaining for some time that whenever firewalld is restarted on a system with libvirt virtual networks and/or nwfilter rules active, the system logs would be flooded with warning messages whining that [lots of different rules] could not be deleted because they didn't exist. For example: firewalld[3536040]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -w --table filter --delete LIBVIRT_OUT --out-interface virbr4 --protocol udp --destination-port 68 --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?). (See https://bugzilla.redhat.com/1790837 for many more examples and a discussion) Note that these messages are created by iptables, but are logged by firewalld - when an iptables/ebtables command fails, firewalld grabs whatever is in stderr of the program, and spits it out to the system log as a warning. We've requested that firewalld not do this (and instead leave it up to the calling application to do the appropriate logging), but this request has been respectfully denied. But combining the two problems above ( 1) firewalld doesn't do anything useful when you use it as a proxy to add/remove iptables rules, 2) firewalld often insists on logging lots of annoying/misleading/useless "error" messages when you use it as a proxy to remove iptables rules that don't already exist), leads to a solution - simply stop using firewalld to add and remove iptables rules. Instead, exec iptables/ip6tables/ebtables directly in the same way we do when firewalld isn't active. We still need to keep track of whether or not firewalld is active, as there are some things that must be done, e.g. we need to add some actual firewalld rules in the firewalld "libvirt" zone, and we need to take notice when firewalld restarts, so that we can reload all our rules. This patch doesn't remove the infrastructure that allows having different firewall backends that perform their functions in different ways, as that will very possibly come in handy in the future when we want to have an nftables direct backend, and possibly a "pure" firewalld backend (now that firewalld supports more complex rules, and can add those rules to the FORWARD and OUTPUT chains). Instead, it just changes the action when the selected backend is "firewalld" so that it adds rules directly rather than through firewalld, while leaving as much of the existing code intact as possible. In order for tests to still pass, virfirewalltest also had to be modified to behave in a different way (i.e. by capturing the generated commandline as it does for the DIRECT backend, rather than capturing dbus messages using a mocked dbus API). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 15:55:12 +00:00
if (data->expectBackend == VIR_FIREWALL_BACKEND_DIRECT ||
data->expectBackend == VIR_FIREWALL_BACKEND_FIREWALLD) {
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
virCommandSetDryRun(&cmdbuf, testFirewallRollbackHook, NULL);
} else {
fwBuf = &cmdbuf;
fwError = true;
}
virFirewallStartTransaction(fw, 0);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "192.168.122.1",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "ACCEPT", NULL);
virFirewallAddRuleFull(fw, VIR_FIREWALL_LAYER_IPV4,
true, NULL, NULL,
"-A", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "192.168.122.255",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "REJECT", NULL);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "OUTPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "192.168.122.1",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "ACCEPT", NULL);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "OUTPUT",
"--jump", "DROP", NULL);
if (virFirewallApply(fw) < 0)
goto cleanup;
actual = virBufferCurrentContent(&cmdbuf);
if (STRNEQ_NULLABLE(expected, actual)) {
Fix minor typos in messages and docs Signed-off-by: Yuri Chornoivan <yurchor@ukr.net> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2018-12-04 17:08:14 +00:00
fprintf(stderr, "Unexpected command execution\n");
Rename virtTestDifference to virTestDifference. This function doesn't follow our convention of naming functions.
2016-05-26 15:01:51 +00:00
virTestDifference(stderr, expected, actual);
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
goto cleanup;
}
ret = 0;
cleanup:
fwBuf = NULL;
virCommandSetDryRun(NULL, NULL, NULL);
return ret;
}
static int
tests: use G_GNUC_UNUSED Use G_GNUC_UNUSED from GLib instead of ATTRIBUTE_UNUSED. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-14 12:45:03 +00:00
testFirewallNoRollback(const void *opaque G_GNUC_UNUSED)
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
{
tests: use g_auto for all virBuffers Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-07-02 23:35:41 +00:00
g_auto(virBuffer) cmdbuf = VIR_BUFFER_INITIALIZER;
use g_autoptr() for all usages of virFirewallNew/Free Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-07-04 20:35:10 +00:00
g_autoptr(virFirewall) fw = virFirewallNew();
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
int ret = -1;
const char *actual = NULL;
const char *expected =
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
IPTABLES_PATH " -w -A INPUT --source 192.168.122.1 --jump ACCEPT\n"
IPTABLES_PATH " -w -A INPUT --source 192.168.122.255 --jump REJECT\n";
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
const struct testFirewallData *data = opaque;
fwDisabled = data->fwDisabled;
if (virFirewallSetBackend(data->tryBackend) < 0)
goto cleanup;
util: call iptables directly rather than via firewalld When libvirt added support for firewalld, we were unable to use firewalld's higher level rules, because they weren't detailed enough and could not be applied to the iptables FORWARD or OUTPUT chains (only to the INPUT chain). Instead we changed our code so that rather than running the iptables/ip6tables/ebtables binaries ourselves, we would send these commands to firewalld as "passthrough commands", and firewalld would run the appropriate program on our behalf. This was done under the assumption that firewalld was somehow tracking all these rules, and that this tracking was benefitting proper operation of firewalld and the system in general. Several years later this came up in a discussion on IRC, and we learned from the firewalld developers that, in fact, adding iptables and ebtables rules with firewalld's passthrough commands actually has *no* advantage; firewalld doesn't keep track of these rules in any way, and doesn't use them to tailor the construction of its own rules. Meanwhile, users have been complaining for some time that whenever firewalld is restarted on a system with libvirt virtual networks and/or nwfilter rules active, the system logs would be flooded with warning messages whining that [lots of different rules] could not be deleted because they didn't exist. For example: firewalld[3536040]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -w --table filter --delete LIBVIRT_OUT --out-interface virbr4 --protocol udp --destination-port 68 --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?). (See https://bugzilla.redhat.com/1790837 for many more examples and a discussion) Note that these messages are created by iptables, but are logged by firewalld - when an iptables/ebtables command fails, firewalld grabs whatever is in stderr of the program, and spits it out to the system log as a warning. We've requested that firewalld not do this (and instead leave it up to the calling application to do the appropriate logging), but this request has been respectfully denied. But combining the two problems above ( 1) firewalld doesn't do anything useful when you use it as a proxy to add/remove iptables rules, 2) firewalld often insists on logging lots of annoying/misleading/useless "error" messages when you use it as a proxy to remove iptables rules that don't already exist), leads to a solution - simply stop using firewalld to add and remove iptables rules. Instead, exec iptables/ip6tables/ebtables directly in the same way we do when firewalld isn't active. We still need to keep track of whether or not firewalld is active, as there are some things that must be done, e.g. we need to add some actual firewalld rules in the firewalld "libvirt" zone, and we need to take notice when firewalld restarts, so that we can reload all our rules. This patch doesn't remove the infrastructure that allows having different firewall backends that perform their functions in different ways, as that will very possibly come in handy in the future when we want to have an nftables direct backend, and possibly a "pure" firewalld backend (now that firewalld supports more complex rules, and can add those rules to the FORWARD and OUTPUT chains). Instead, it just changes the action when the selected backend is "firewalld" so that it adds rules directly rather than through firewalld, while leaving as much of the existing code intact as possible. In order for tests to still pass, virfirewalltest also had to be modified to behave in a different way (i.e. by capturing the generated commandline as it does for the DIRECT backend, rather than capturing dbus messages using a mocked dbus API). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 15:55:12 +00:00
if (data->expectBackend == VIR_FIREWALL_BACKEND_DIRECT ||
data->expectBackend == VIR_FIREWALL_BACKEND_FIREWALLD) {
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
virCommandSetDryRun(&cmdbuf, testFirewallRollbackHook, NULL);
} else {
fwBuf = &cmdbuf;
fwError = true;
}
virFirewallStartTransaction(fw, 0);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "192.168.122.1",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "ACCEPT", NULL);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "192.168.122.255",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "REJECT", NULL);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "!192.168.122.1",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "REJECT", NULL);
if (virFirewallApply(fw) == 0) {
fprintf(stderr, "Firewall apply unexpectedly worked\n");
goto cleanup;
}
actual = virBufferCurrentContent(&cmdbuf);
if (STRNEQ_NULLABLE(expected, actual)) {
Fix minor typos in messages and docs Signed-off-by: Yuri Chornoivan <yurchor@ukr.net> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2018-12-04 17:08:14 +00:00
fprintf(stderr, "Unexpected command execution\n");
Rename virtTestDifference to virTestDifference. This function doesn't follow our convention of naming functions.
2016-05-26 15:01:51 +00:00
virTestDifference(stderr, expected, actual);
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
goto cleanup;
}
ret = 0;
cleanup:
fwBuf = NULL;
virCommandSetDryRun(NULL, NULL, NULL);
return ret;
}
static int
tests: use G_GNUC_UNUSED Use G_GNUC_UNUSED from GLib instead of ATTRIBUTE_UNUSED. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-14 12:45:03 +00:00
testFirewallSingleRollback(const void *opaque G_GNUC_UNUSED)
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
{
tests: use g_auto for all virBuffers Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-07-02 23:35:41 +00:00
g_auto(virBuffer) cmdbuf = VIR_BUFFER_INITIALIZER;
use g_autoptr() for all usages of virFirewallNew/Free Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-07-04 20:35:10 +00:00
g_autoptr(virFirewall) fw = virFirewallNew();
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
int ret = -1;
const char *actual = NULL;
const char *expected =
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
IPTABLES_PATH " -w -A INPUT --source 192.168.122.1 --jump ACCEPT\n"
IPTABLES_PATH " -w -A INPUT --source 192.168.122.255 --jump REJECT\n"
IPTABLES_PATH " -w -D INPUT --source 192.168.122.1 --jump ACCEPT\n"
IPTABLES_PATH " -w -D INPUT --source 192.168.122.255 --jump REJECT\n"
IPTABLES_PATH " -w -D INPUT --source '!192.168.122.1' --jump REJECT\n";
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
const struct testFirewallData *data = opaque;
fwDisabled = data->fwDisabled;
if (virFirewallSetBackend(data->tryBackend) < 0)
goto cleanup;
util: call iptables directly rather than via firewalld When libvirt added support for firewalld, we were unable to use firewalld's higher level rules, because they weren't detailed enough and could not be applied to the iptables FORWARD or OUTPUT chains (only to the INPUT chain). Instead we changed our code so that rather than running the iptables/ip6tables/ebtables binaries ourselves, we would send these commands to firewalld as "passthrough commands", and firewalld would run the appropriate program on our behalf. This was done under the assumption that firewalld was somehow tracking all these rules, and that this tracking was benefitting proper operation of firewalld and the system in general. Several years later this came up in a discussion on IRC, and we learned from the firewalld developers that, in fact, adding iptables and ebtables rules with firewalld's passthrough commands actually has *no* advantage; firewalld doesn't keep track of these rules in any way, and doesn't use them to tailor the construction of its own rules. Meanwhile, users have been complaining for some time that whenever firewalld is restarted on a system with libvirt virtual networks and/or nwfilter rules active, the system logs would be flooded with warning messages whining that [lots of different rules] could not be deleted because they didn't exist. For example: firewalld[3536040]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -w --table filter --delete LIBVIRT_OUT --out-interface virbr4 --protocol udp --destination-port 68 --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?). (See https://bugzilla.redhat.com/1790837 for many more examples and a discussion) Note that these messages are created by iptables, but are logged by firewalld - when an iptables/ebtables command fails, firewalld grabs whatever is in stderr of the program, and spits it out to the system log as a warning. We've requested that firewalld not do this (and instead leave it up to the calling application to do the appropriate logging), but this request has been respectfully denied. But combining the two problems above ( 1) firewalld doesn't do anything useful when you use it as a proxy to add/remove iptables rules, 2) firewalld often insists on logging lots of annoying/misleading/useless "error" messages when you use it as a proxy to remove iptables rules that don't already exist), leads to a solution - simply stop using firewalld to add and remove iptables rules. Instead, exec iptables/ip6tables/ebtables directly in the same way we do when firewalld isn't active. We still need to keep track of whether or not firewalld is active, as there are some things that must be done, e.g. we need to add some actual firewalld rules in the firewalld "libvirt" zone, and we need to take notice when firewalld restarts, so that we can reload all our rules. This patch doesn't remove the infrastructure that allows having different firewall backends that perform their functions in different ways, as that will very possibly come in handy in the future when we want to have an nftables direct backend, and possibly a "pure" firewalld backend (now that firewalld supports more complex rules, and can add those rules to the FORWARD and OUTPUT chains). Instead, it just changes the action when the selected backend is "firewalld" so that it adds rules directly rather than through firewalld, while leaving as much of the existing code intact as possible. In order for tests to still pass, virfirewalltest also had to be modified to behave in a different way (i.e. by capturing the generated commandline as it does for the DIRECT backend, rather than capturing dbus messages using a mocked dbus API). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 15:55:12 +00:00
if (data->expectBackend == VIR_FIREWALL_BACKEND_DIRECT ||
data->expectBackend == VIR_FIREWALL_BACKEND_FIREWALLD) {
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
virCommandSetDryRun(&cmdbuf, testFirewallRollbackHook, NULL);
} else {
fwError = true;
fwBuf = &cmdbuf;
}
virFirewallStartTransaction(fw, 0);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "192.168.122.1",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "ACCEPT", NULL);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "192.168.122.255",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "REJECT", NULL);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "!192.168.122.1",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "REJECT", NULL);
virFirewallStartRollback(fw, 0);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-D", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "192.168.122.1",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "ACCEPT", NULL);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-D", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "192.168.122.255",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "REJECT", NULL);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-D", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "!192.168.122.1",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "REJECT", NULL);
if (virFirewallApply(fw) == 0) {
fprintf(stderr, "Firewall apply unexpectedly worked\n");
goto cleanup;
}
actual = virBufferCurrentContent(&cmdbuf);
if (STRNEQ_NULLABLE(expected, actual)) {
Fix minor typos in messages and docs Signed-off-by: Yuri Chornoivan <yurchor@ukr.net> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2018-12-04 17:08:14 +00:00
fprintf(stderr, "Unexpected command execution\n");
Rename virtTestDifference to virTestDifference. This function doesn't follow our convention of naming functions.
2016-05-26 15:01:51 +00:00
virTestDifference(stderr, expected, actual);
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
goto cleanup;
}
ret = 0;
cleanup:
fwBuf = NULL;
virCommandSetDryRun(NULL, NULL, NULL);
return ret;
}
static int
tests: use G_GNUC_UNUSED Use G_GNUC_UNUSED from GLib instead of ATTRIBUTE_UNUSED. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-14 12:45:03 +00:00
testFirewallManyRollback(const void *opaque G_GNUC_UNUSED)
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
{
tests: use g_auto for all virBuffers Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-07-02 23:35:41 +00:00
g_auto(virBuffer) cmdbuf = VIR_BUFFER_INITIALIZER;
use g_autoptr() for all usages of virFirewallNew/Free Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-07-04 20:35:10 +00:00
g_autoptr(virFirewall) fw = virFirewallNew();
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
int ret = -1;
const char *actual = NULL;
const char *expected =
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
IPTABLES_PATH " -w -A INPUT --source 192.168.122.1 --jump ACCEPT\n"
IPTABLES_PATH " -w -A INPUT --source 192.168.122.255 --jump REJECT\n"
IPTABLES_PATH " -w -D INPUT --source 192.168.122.255 --jump REJECT\n"
IPTABLES_PATH " -w -D INPUT --source '!192.168.122.1' --jump REJECT\n";
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
const struct testFirewallData *data = opaque;
fwDisabled = data->fwDisabled;
if (virFirewallSetBackend(data->tryBackend) < 0)
goto cleanup;
util: call iptables directly rather than via firewalld When libvirt added support for firewalld, we were unable to use firewalld's higher level rules, because they weren't detailed enough and could not be applied to the iptables FORWARD or OUTPUT chains (only to the INPUT chain). Instead we changed our code so that rather than running the iptables/ip6tables/ebtables binaries ourselves, we would send these commands to firewalld as "passthrough commands", and firewalld would run the appropriate program on our behalf. This was done under the assumption that firewalld was somehow tracking all these rules, and that this tracking was benefitting proper operation of firewalld and the system in general. Several years later this came up in a discussion on IRC, and we learned from the firewalld developers that, in fact, adding iptables and ebtables rules with firewalld's passthrough commands actually has *no* advantage; firewalld doesn't keep track of these rules in any way, and doesn't use them to tailor the construction of its own rules. Meanwhile, users have been complaining for some time that whenever firewalld is restarted on a system with libvirt virtual networks and/or nwfilter rules active, the system logs would be flooded with warning messages whining that [lots of different rules] could not be deleted because they didn't exist. For example: firewalld[3536040]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -w --table filter --delete LIBVIRT_OUT --out-interface virbr4 --protocol udp --destination-port 68 --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?). (See https://bugzilla.redhat.com/1790837 for many more examples and a discussion) Note that these messages are created by iptables, but are logged by firewalld - when an iptables/ebtables command fails, firewalld grabs whatever is in stderr of the program, and spits it out to the system log as a warning. We've requested that firewalld not do this (and instead leave it up to the calling application to do the appropriate logging), but this request has been respectfully denied. But combining the two problems above ( 1) firewalld doesn't do anything useful when you use it as a proxy to add/remove iptables rules, 2) firewalld often insists on logging lots of annoying/misleading/useless "error" messages when you use it as a proxy to remove iptables rules that don't already exist), leads to a solution - simply stop using firewalld to add and remove iptables rules. Instead, exec iptables/ip6tables/ebtables directly in the same way we do when firewalld isn't active. We still need to keep track of whether or not firewalld is active, as there are some things that must be done, e.g. we need to add some actual firewalld rules in the firewalld "libvirt" zone, and we need to take notice when firewalld restarts, so that we can reload all our rules. This patch doesn't remove the infrastructure that allows having different firewall backends that perform their functions in different ways, as that will very possibly come in handy in the future when we want to have an nftables direct backend, and possibly a "pure" firewalld backend (now that firewalld supports more complex rules, and can add those rules to the FORWARD and OUTPUT chains). Instead, it just changes the action when the selected backend is "firewalld" so that it adds rules directly rather than through firewalld, while leaving as much of the existing code intact as possible. In order for tests to still pass, virfirewalltest also had to be modified to behave in a different way (i.e. by capturing the generated commandline as it does for the DIRECT backend, rather than capturing dbus messages using a mocked dbus API). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 15:55:12 +00:00
if (data->expectBackend == VIR_FIREWALL_BACKEND_DIRECT ||
data->expectBackend == VIR_FIREWALL_BACKEND_FIREWALLD) {
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
virCommandSetDryRun(&cmdbuf, testFirewallRollbackHook, NULL);
} else {
fwBuf = &cmdbuf;
fwError = true;
}
virFirewallStartTransaction(fw, 0);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "192.168.122.1",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "ACCEPT", NULL);
virFirewallStartRollback(fw, 0);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-D", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "192.168.122.1",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "ACCEPT", NULL);
virFirewallStartTransaction(fw, 0);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "192.168.122.255",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "REJECT", NULL);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "!192.168.122.1",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "REJECT", NULL);
virFirewallStartRollback(fw, 0);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-D", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "192.168.122.255",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "REJECT", NULL);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-D", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "!192.168.122.1",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "REJECT", NULL);
if (virFirewallApply(fw) == 0) {
fprintf(stderr, "Firewall apply unexpectedly worked\n");
goto cleanup;
}
actual = virBufferCurrentContent(&cmdbuf);
if (STRNEQ_NULLABLE(expected, actual)) {
Fix minor typos in messages and docs Signed-off-by: Yuri Chornoivan <yurchor@ukr.net> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2018-12-04 17:08:14 +00:00
fprintf(stderr, "Unexpected command execution\n");
Rename virtTestDifference to virTestDifference. This function doesn't follow our convention of naming functions.
2016-05-26 15:01:51 +00:00
virTestDifference(stderr, expected, actual);
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
goto cleanup;
}
ret = 0;
cleanup:
fwBuf = NULL;
virCommandSetDryRun(NULL, NULL, NULL);
return ret;
}
static int
tests: use G_GNUC_UNUSED Use G_GNUC_UNUSED from GLib instead of ATTRIBUTE_UNUSED. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-14 12:45:03 +00:00
testFirewallChainedRollback(const void *opaque G_GNUC_UNUSED)
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
{
tests: use g_auto for all virBuffers Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-07-02 23:35:41 +00:00
g_auto(virBuffer) cmdbuf = VIR_BUFFER_INITIALIZER;
use g_autoptr() for all usages of virFirewallNew/Free Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-07-04 20:35:10 +00:00
g_autoptr(virFirewall) fw = virFirewallNew();
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
int ret = -1;
const char *actual = NULL;
const char *expected =
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
IPTABLES_PATH " -w -A INPUT --source 192.168.122.1 --jump ACCEPT\n"
IPTABLES_PATH " -w -A INPUT --source 192.168.122.127 --jump REJECT\n"
IPTABLES_PATH " -w -A INPUT --source '!192.168.122.1' --jump REJECT\n"
IPTABLES_PATH " -w -A INPUT --source 192.168.122.255 --jump REJECT\n"
IPTABLES_PATH " -w -D INPUT --source 192.168.122.127 --jump REJECT\n"
IPTABLES_PATH " -w -D INPUT --source '!192.168.122.1' --jump REJECT\n"
IPTABLES_PATH " -w -D INPUT --source 192.168.122.255 --jump REJECT\n"
IPTABLES_PATH " -w -D INPUT --source '!192.168.122.1' --jump REJECT\n";
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
const struct testFirewallData *data = opaque;
fwDisabled = data->fwDisabled;
if (virFirewallSetBackend(data->tryBackend) < 0)
goto cleanup;
util: call iptables directly rather than via firewalld When libvirt added support for firewalld, we were unable to use firewalld's higher level rules, because they weren't detailed enough and could not be applied to the iptables FORWARD or OUTPUT chains (only to the INPUT chain). Instead we changed our code so that rather than running the iptables/ip6tables/ebtables binaries ourselves, we would send these commands to firewalld as "passthrough commands", and firewalld would run the appropriate program on our behalf. This was done under the assumption that firewalld was somehow tracking all these rules, and that this tracking was benefitting proper operation of firewalld and the system in general. Several years later this came up in a discussion on IRC, and we learned from the firewalld developers that, in fact, adding iptables and ebtables rules with firewalld's passthrough commands actually has *no* advantage; firewalld doesn't keep track of these rules in any way, and doesn't use them to tailor the construction of its own rules. Meanwhile, users have been complaining for some time that whenever firewalld is restarted on a system with libvirt virtual networks and/or nwfilter rules active, the system logs would be flooded with warning messages whining that [lots of different rules] could not be deleted because they didn't exist. For example: firewalld[3536040]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -w --table filter --delete LIBVIRT_OUT --out-interface virbr4 --protocol udp --destination-port 68 --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?). (See https://bugzilla.redhat.com/1790837 for many more examples and a discussion) Note that these messages are created by iptables, but are logged by firewalld - when an iptables/ebtables command fails, firewalld grabs whatever is in stderr of the program, and spits it out to the system log as a warning. We've requested that firewalld not do this (and instead leave it up to the calling application to do the appropriate logging), but this request has been respectfully denied. But combining the two problems above ( 1) firewalld doesn't do anything useful when you use it as a proxy to add/remove iptables rules, 2) firewalld often insists on logging lots of annoying/misleading/useless "error" messages when you use it as a proxy to remove iptables rules that don't already exist), leads to a solution - simply stop using firewalld to add and remove iptables rules. Instead, exec iptables/ip6tables/ebtables directly in the same way we do when firewalld isn't active. We still need to keep track of whether or not firewalld is active, as there are some things that must be done, e.g. we need to add some actual firewalld rules in the firewalld "libvirt" zone, and we need to take notice when firewalld restarts, so that we can reload all our rules. This patch doesn't remove the infrastructure that allows having different firewall backends that perform their functions in different ways, as that will very possibly come in handy in the future when we want to have an nftables direct backend, and possibly a "pure" firewalld backend (now that firewalld supports more complex rules, and can add those rules to the FORWARD and OUTPUT chains). Instead, it just changes the action when the selected backend is "firewalld" so that it adds rules directly rather than through firewalld, while leaving as much of the existing code intact as possible. In order for tests to still pass, virfirewalltest also had to be modified to behave in a different way (i.e. by capturing the generated commandline as it does for the DIRECT backend, rather than capturing dbus messages using a mocked dbus API). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 15:55:12 +00:00
if (data->expectBackend == VIR_FIREWALL_BACKEND_DIRECT ||
data->expectBackend == VIR_FIREWALL_BACKEND_FIREWALLD) {
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
virCommandSetDryRun(&cmdbuf, testFirewallRollbackHook, NULL);
} else {
fwBuf = &cmdbuf;
fwError = true;
}
virFirewallStartTransaction(fw, 0);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "192.168.122.1",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "ACCEPT", NULL);
virFirewallStartRollback(fw, 0);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-D", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "192.168.122.1",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "ACCEPT", NULL);
virFirewallStartTransaction(fw, 0);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "192.168.122.127",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "REJECT", NULL);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "!192.168.122.1",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "REJECT", NULL);
virFirewallStartRollback(fw, 0);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-D", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "192.168.122.127",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "REJECT", NULL);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-D", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "!192.168.122.1",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "REJECT", NULL);
virFirewallStartTransaction(fw, 0);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "192.168.122.255",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "REJECT", NULL);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "!192.168.122.1",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "REJECT", NULL);
virFirewallStartRollback(fw, VIR_FIREWALL_ROLLBACK_INHERIT_PREVIOUS);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-D", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "192.168.122.255",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "REJECT", NULL);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-D", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "!192.168.122.1",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "REJECT", NULL);
if (virFirewallApply(fw) == 0) {
fprintf(stderr, "Firewall apply unexpectedly worked\n");
goto cleanup;
}
actual = virBufferCurrentContent(&cmdbuf);
if (STRNEQ_NULLABLE(expected, actual)) {
Fix minor typos in messages and docs Signed-off-by: Yuri Chornoivan <yurchor@ukr.net> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2018-12-04 17:08:14 +00:00
fprintf(stderr, "Unexpected command execution\n");
Rename virtTestDifference to virTestDifference. This function doesn't follow our convention of naming functions.
2016-05-26 15:01:51 +00:00
virTestDifference(stderr, expected, actual);
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
goto cleanup;
}
ret = 0;
cleanup:
fwBuf = NULL;
virCommandSetDryRun(NULL, NULL, NULL);
return ret;
}
static const char *expectedLines[] = {
"Chain INPUT (policy ACCEPT)",
"target prot opt source destination",
"",
"Chain FORWARD (policy ACCEPT)",
"target prot opt source destination",
"",
"Chain OUTPUT (policy ACCEPT)",
"target prot opt source destination",
"",
"Chain PREROUTING (policy ACCEPT)",
"target prot opt source destination",
"",
"Chain INPUT (policy ACCEPT)",
"target prot opt source destination",
"",
"Chain OUTPUT (policy ACCEPT)",
"target prot opt source destination",
"",
"Chain POSTROUTING (policy ACCEPT)",
"target prot opt source destination",
"",
};
static size_t expectedLineNum;
static bool expectedLineError;
static void
testFirewallQueryHook(const char *const*args,
tests: use G_GNUC_UNUSED Use G_GNUC_UNUSED from GLib instead of ATTRIBUTE_UNUSED. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-14 12:45:03 +00:00
const char *const*env G_GNUC_UNUSED,
const char *input G_GNUC_UNUSED,
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
char **output,
tests: use G_GNUC_UNUSED Use G_GNUC_UNUSED from GLib instead of ATTRIBUTE_UNUSED. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-14 12:45:03 +00:00
char **error G_GNUC_UNUSED,
tests: use g_strdup instead of VIR_STRDUP Replace all occurrences of if (VIR_STRDUP(a, b) < 0) /* effectively dead code */ with: a = g_strdup(b); Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-20 11:49:46 +00:00
int *status G_GNUC_UNUSED,
tests: use G_GNUC_UNUSED Use G_GNUC_UNUSED from GLib instead of ATTRIBUTE_UNUSED. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-14 12:45:03 +00:00
void *opaque G_GNUC_UNUSED)
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
{
if (STREQ(args[0], IPTABLES_PATH) &&
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 00:20:53 +00:00
STREQ(args[1], "-w") &&
STREQ(args[2], "-L")) {
tests: use g_strdup instead of VIR_STRDUP Replace all occurrences of if (VIR_STRDUP(a, b) < 0) /* effectively dead code */ with: a = g_strdup(b); Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-20 11:49:46 +00:00
*output = g_strdup(TEST_FILTER_TABLE_LIST);
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
} else if (STREQ(args[0], IPTABLES_PATH) &&
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 00:20:53 +00:00
STREQ(args[1], "-w") &&
STREQ(args[2], "-t") &&
STREQ(args[3], "nat") &&
STREQ(args[4], "-L")) {
tests: use g_strdup instead of VIR_STRDUP Replace all occurrences of if (VIR_STRDUP(a, b) < 0) /* effectively dead code */ with: a = g_strdup(b); Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-20 11:49:46 +00:00
*output = g_strdup(TEST_NAT_TABLE_LIST);
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
}
}
static int
testFirewallQueryCallback(virFirewallPtr fw,
util: pass layer into firewall query callback Some of the query callbacks want to know the firewall layer that was being used for triggering the query to avoid duplicating that data. Reviewed-by: Laine Stump <laine@laine.org> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-12-04 16:33:28 +00:00
virFirewallLayer layer,
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
const char *const *lines,
tests: use G_GNUC_UNUSED Use G_GNUC_UNUSED from GLib instead of ATTRIBUTE_UNUSED. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-14 12:45:03 +00:00
void *opaque G_GNUC_UNUSED)
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
{
size_t i;
util: pass layer into firewall query callback Some of the query callbacks want to know the firewall layer that was being used for triggering the query to avoid duplicating that data. Reviewed-by: Laine Stump <laine@laine.org> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-12-04 16:33:28 +00:00
virFirewallAddRule(fw, layer,
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"-A", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "!192.168.122.129",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "REJECT", NULL);
for (i = 0; lines[i] != NULL; i++) {
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
if (expectedLineNum >= G_N_ELEMENTS(expectedLines)) {
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
expectedLineError = true;
break;
}
if (STRNEQ(expectedLines[expectedLineNum], lines[i])) {
fprintf(stderr, "Mismatch '%s' vs '%s' at %zu, %zu\n",
expectedLines[expectedLineNum], lines[i],
expectedLineNum, i);
expectedLineError = true;
break;
}
expectedLineNum++;
}
return 0;
}
static int
tests: use G_GNUC_UNUSED Use G_GNUC_UNUSED from GLib instead of ATTRIBUTE_UNUSED. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-14 12:45:03 +00:00
testFirewallQuery(const void *opaque G_GNUC_UNUSED)
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
{
tests: use g_auto for all virBuffers Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-07-02 23:35:41 +00:00
g_auto(virBuffer) cmdbuf = VIR_BUFFER_INITIALIZER;
use g_autoptr() for all usages of virFirewallNew/Free Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-07-04 20:35:10 +00:00
g_autoptr(virFirewall) fw = virFirewallNew();
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
int ret = -1;
const char *actual = NULL;
const char *expected =
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
IPTABLES_PATH " -w -A INPUT --source 192.168.122.1 --jump ACCEPT\n"
IPTABLES_PATH " -w -A INPUT --source 192.168.122.127 --jump REJECT\n"
util/tests: enable locking on iptables/ebtables commandlines in unit tests All the unit tests that use iptables/ip6tables/ebtables have been written to omit the locking/exclusive use primitive on the generated commandlines. Even though none of the tests actually execute those commands (and so it doesn't matter for purposes of the test whether or not the commands support these options), it still made sense when some systems had these locking options and some didn't. We are now at a point where every supported Linux distro has supported the locking options on these commands for quite a long time, and are going to make their use non-optional. As a first step, this patch uses the virFirewallSetLockOverride() function, which is called at the beginning of all firewall-related tests, to set all the bools controlling whether or not the locking options are used to true. This means that all the test cases must be updated to include the proper locking option in their commandlines. The change to make actual execs of the commands unconditionally use the locking option will be in an upcoming patch - this one affects only the unit tests. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 00:20:53 +00:00
IPTABLES_PATH " -w -L\n"
IPTABLES_PATH " -w -t nat -L\n"
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
IPTABLES_PATH " -w -A INPUT --source 192.168.122.130 --jump REJECT\n"
IPTABLES_PATH " -w -A INPUT --source '!192.168.122.129' --jump REJECT\n"
IPTABLES_PATH " -w -A INPUT --source '!192.168.122.129' --jump REJECT\n"
IPTABLES_PATH " -w -A INPUT --source 192.168.122.128 --jump REJECT\n"
IPTABLES_PATH " -w -A INPUT --source '!192.168.122.1' --jump REJECT\n";
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
const struct testFirewallData *data = opaque;
expectedLineNum = 0;
expectedLineError = false;
fwDisabled = data->fwDisabled;
if (virFirewallSetBackend(data->tryBackend) < 0)
goto cleanup;
util: call iptables directly rather than via firewalld When libvirt added support for firewalld, we were unable to use firewalld's higher level rules, because they weren't detailed enough and could not be applied to the iptables FORWARD or OUTPUT chains (only to the INPUT chain). Instead we changed our code so that rather than running the iptables/ip6tables/ebtables binaries ourselves, we would send these commands to firewalld as "passthrough commands", and firewalld would run the appropriate program on our behalf. This was done under the assumption that firewalld was somehow tracking all these rules, and that this tracking was benefitting proper operation of firewalld and the system in general. Several years later this came up in a discussion on IRC, and we learned from the firewalld developers that, in fact, adding iptables and ebtables rules with firewalld's passthrough commands actually has *no* advantage; firewalld doesn't keep track of these rules in any way, and doesn't use them to tailor the construction of its own rules. Meanwhile, users have been complaining for some time that whenever firewalld is restarted on a system with libvirt virtual networks and/or nwfilter rules active, the system logs would be flooded with warning messages whining that [lots of different rules] could not be deleted because they didn't exist. For example: firewalld[3536040]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -w --table filter --delete LIBVIRT_OUT --out-interface virbr4 --protocol udp --destination-port 68 --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?). (See https://bugzilla.redhat.com/1790837 for many more examples and a discussion) Note that these messages are created by iptables, but are logged by firewalld - when an iptables/ebtables command fails, firewalld grabs whatever is in stderr of the program, and spits it out to the system log as a warning. We've requested that firewalld not do this (and instead leave it up to the calling application to do the appropriate logging), but this request has been respectfully denied. But combining the two problems above ( 1) firewalld doesn't do anything useful when you use it as a proxy to add/remove iptables rules, 2) firewalld often insists on logging lots of annoying/misleading/useless "error" messages when you use it as a proxy to remove iptables rules that don't already exist), leads to a solution - simply stop using firewalld to add and remove iptables rules. Instead, exec iptables/ip6tables/ebtables directly in the same way we do when firewalld isn't active. We still need to keep track of whether or not firewalld is active, as there are some things that must be done, e.g. we need to add some actual firewalld rules in the firewalld "libvirt" zone, and we need to take notice when firewalld restarts, so that we can reload all our rules. This patch doesn't remove the infrastructure that allows having different firewall backends that perform their functions in different ways, as that will very possibly come in handy in the future when we want to have an nftables direct backend, and possibly a "pure" firewalld backend (now that firewalld supports more complex rules, and can add those rules to the FORWARD and OUTPUT chains). Instead, it just changes the action when the selected backend is "firewalld" so that it adds rules directly rather than through firewalld, while leaving as much of the existing code intact as possible. In order for tests to still pass, virfirewalltest also had to be modified to behave in a different way (i.e. by capturing the generated commandline as it does for the DIRECT backend, rather than capturing dbus messages using a mocked dbus API). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 15:55:12 +00:00
if (data->expectBackend == VIR_FIREWALL_BACKEND_DIRECT ||
data->expectBackend == VIR_FIREWALL_BACKEND_FIREWALLD) {
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
virCommandSetDryRun(&cmdbuf, testFirewallQueryHook, NULL);
} else {
fwBuf = &cmdbuf;
fwError = true;
}
virFirewallStartTransaction(fw, 0);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "192.168.122.1",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "ACCEPT", NULL);
virFirewallStartTransaction(fw, 0);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "192.168.122.127",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "REJECT", NULL);
virFirewallAddRuleFull(fw, VIR_FIREWALL_LAYER_IPV4,
false,
testFirewallQueryCallback,
NULL,
"-L", NULL);
virFirewallAddRuleFull(fw, VIR_FIREWALL_LAYER_IPV4,
false,
testFirewallQueryCallback,
NULL,
"-t", "nat", "-L", NULL);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "192.168.122.130",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "REJECT", NULL);
virFirewallStartTransaction(fw, 0);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "192.168.122.128",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "REJECT", NULL);
virFirewallAddRule(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
tests: fix iptables test case commandline options in virfirewalltest.c This test was created with all the commandlines erroneously having "--source-host", which is not a valid iptables option. The correct name for the option is "--source". However, since the test is just checking that the generated commandline matches what we told it to generate (and never actually runs iptables, as that would be a "Really Bad Idea"(tm)), the test has always succeeded. I only found it because I made a change to the code that caused the test to incorrectly try to run iptables during the test, and the error message I received was "odd" (it complained about the bad option, rather than complaining that I had insufficient privilege to run the command). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-11-17 18:51:45 +00:00
"--source", "!192.168.122.1",
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
"--jump", "REJECT", NULL);
if (virFirewallApply(fw) < 0)
goto cleanup;
actual = virBufferCurrentContent(&cmdbuf);
if (expectedLineError) {
fprintf(stderr, "Got some unexpected query data\n");
goto cleanup;
}
if (STRNEQ_NULLABLE(expected, actual)) {
Fix minor typos in messages and docs Signed-off-by: Yuri Chornoivan <yurchor@ukr.net> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2018-12-04 17:08:14 +00:00
fprintf(stderr, "Unexpected command execution\n");
Rename virtTestDifference to virTestDifference. This function doesn't follow our convention of naming functions.
2016-05-26 15:01:51 +00:00
virTestDifference(stderr, expected, actual);
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
goto cleanup;
}
ret = 0;
cleanup:
fwBuf = NULL;
virCommandSetDryRun(NULL, NULL, NULL);
return ret;
}
Prevent test failures with ebtables/iptables/ip6tables are missing When running tests in a restricted container (as opposed to a full OS install), we can't assume ebtables/iptbles/ip6tables are going to be installed. We must check this and mark the tests as skipped. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2017-04-07 14:11:14 +00:00
static bool
hasNetfilterTools(void)
{
return virFileIsExecutable(IPTABLES_PATH) &&
virFileIsExecutable(IP6TABLES_PATH) &&
virFileIsExecutable(EBTABLES_PATH);
}
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
static int
mymain(void)
{
int ret = 0;
Prevent test failures with ebtables/iptables/ip6tables are missing When running tests in a restricted container (as opposed to a full OS install), we can't assume ebtables/iptbles/ip6tables are going to be installed. We must check this and mark the tests as skipped. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2017-04-07 14:11:14 +00:00
if (!hasNetfilterTools()) {
fprintf(stderr, "iptables/ip6tables/ebtables tools not present");
return EXIT_AM_SKIP;
}
Remove backslash alignment attempts Right-aligning backslashes when defining macros or using complex commands in Makefiles looks cute, but as soon as any changes is required to the code you end up with either distractingly broken alignment or unnecessarily big diffs where most of the changes are just pushing all backslashes a few characters to one side. Generated using $ git grep -El '[[:blank:]][[:blank:]]\\$' | \ grep -E '*\.([chx]|am|mk)$$' | \ while read f; do \ sed -Ei 's/[[:blank:]]*[[:blank:]]\\$/ \\/g' "$f"; \ done Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2017-11-03 12:09:47 +00:00
# define RUN_TEST_DIRECT(name, method) \
do { \
struct testFirewallData data; \
data.tryBackend = VIR_FIREWALL_BACKEND_AUTOMATIC; \
data.expectBackend = VIR_FIREWALL_BACKEND_DIRECT; \
data.fwDisabled = true; \
if (virTestRun(name " auto direct", method, &data) < 0) \
ret = -1; \
data.tryBackend = VIR_FIREWALL_BACKEND_DIRECT; \
data.expectBackend = VIR_FIREWALL_BACKEND_DIRECT; \
data.fwDisabled = true; \
if (virTestRun(name " manual direct", method, &data) < 0) \
ret = -1; \
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
} while (0)
src/util/virfirewalld: convert to use GLib DBus Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-09-15 12:00:53 +00:00
# define RUN_TEST_FIREWALLD(name, method) \
Remove backslash alignment attempts Right-aligning backslashes when defining macros or using complex commands in Makefiles looks cute, but as soon as any changes is required to the code you end up with either distractingly broken alignment or unnecessarily big diffs where most of the changes are just pushing all backslashes a few characters to one side. Generated using $ git grep -El '[[:blank:]][[:blank:]]\\$' | \ grep -E '*\.([chx]|am|mk)$$' | \ while read f; do \ sed -Ei 's/[[:blank:]]*[[:blank:]]\\$/ \\/g' "$f"; \ done Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2017-11-03 12:09:47 +00:00
do { \
struct testFirewallData data; \
data.tryBackend = VIR_FIREWALL_BACKEND_AUTOMATIC; \
data.expectBackend = VIR_FIREWALL_BACKEND_FIREWALLD; \
data.fwDisabled = false; \
if (virTestRun(name " auto firewalld", method, &data) < 0) \
ret = -1; \
data.tryBackend = VIR_FIREWALL_BACKEND_FIREWALLD; \
data.expectBackend = VIR_FIREWALL_BACKEND_FIREWALLD; \
data.fwDisabled = false; \
if (virTestRun(name " manual firewalld", method, &data) < 0) \
ret = -1; \
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
} while (0)
src/util/virfirewalld: convert to use GLib DBus Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-09-15 12:00:53 +00:00
# define RUN_TEST(name, method) \
Remove backslash alignment attempts Right-aligning backslashes when defining macros or using complex commands in Makefiles looks cute, but as soon as any changes is required to the code you end up with either distractingly broken alignment or unnecessarily big diffs where most of the changes are just pushing all backslashes a few characters to one side. Generated using $ git grep -El '[[:blank:]][[:blank:]]\\$' | \ grep -E '*\.([chx]|am|mk)$$' | \ while read f; do \ sed -Ei 's/[[:blank:]]*[[:blank:]]\\$/ \\/g' "$f"; \ done Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2017-11-03 12:09:47 +00:00
RUN_TEST_DIRECT(name, method); \
Introduce an object for managing firewall rulesets The network and nwfilter drivers both have a need to update firewall rules. The currently share no code for interacting with iptables / firewalld. The nwfilter driver is fairly tied to the concept of creating shell scripts to execute which makes it very hard to port to talk to firewalld via DBus APIs. This patch introduces a virFirewallPtr object which is able to represent a complete sequence of rule changes, with the ability to have multiple transactional checkpoints with rollbacks. By formally separating the definition of the rules to be applied from the mechanism used to apply them, it is also possible to write a firewall engine that uses firewalld DBus APIs natively instead of via the slow firewalld-cmd. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-03-04 16:30:40 +00:00
RUN_TEST_FIREWALLD(name, method)
RUN_TEST("single group", testFirewallSingleGroup);
RUN_TEST("remove rule", testFirewallRemoveRule);
RUN_TEST("many groups", testFirewallManyGroups);
RUN_TEST("ignore fail group", testFirewallIgnoreFailGroup);
RUN_TEST("ignore fail rule", testFirewallIgnoreFailRule);
RUN_TEST("no rollback", testFirewallNoRollback);
RUN_TEST("single rollback", testFirewallSingleRollback);
RUN_TEST("many rollback", testFirewallManyRollback);
RUN_TEST("chained rollback", testFirewallChainedRollback);
RUN_TEST("query transaction", testFirewallQuery);
return ret == 0 ? EXIT_SUCCESS : EXIT_FAILURE;
}
src/util/virfirewalld: convert to use GLib DBus Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-09-15 12:00:53 +00:00
VIR_TEST_MAIN_PRELOAD(mymain, VIR_TEST_MOCK("virgdbus"))
tests: skip virfirewalltest on non-Linux systems Currently firewalling is supported on Linux only, so skip the virfirewalltest on other platforms.
2014-05-01 18:43:58 +00:00
#else /* ! defined (__linux__) */
int main(void)
{
return EXIT_AM_SKIP;
}
#endif /* ! defined(__linux__) */
Reference in New Issue Copy Permalink