External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-12-22 13:45:38 +00:00
Code Issues Packages Projects Releases Wiki Activity
f850c2a569
libvirt/tests/virfirewalltest.c

801 lines
26 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"
util: remove currentBackend from virfirewall.c Since the currentBackend (direct vs. firewalld) setting is no longer used for anything, we don't need to set it (either explicitly from tests, or implicitly during init), and can completely remove it. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-16 19:27:00 +00:00
# include "virfirewall.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"
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
# define VIR_FROM_THIS VIR_FROM_FIREWALL
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"
static int
tests: remove firewalld backend tests from virfirewalltest.c When libvirt added support for firewalld, all iptables/ebtables rules were added via the firewalld "passthrough" API when firewalld was enabled (the "firewalld backend"), or run directly by libvirt when firewalld was disabled (the so-called "direct backend"). virfirewalltest.c dutifully ran each test twice, once with the each backend enabled. But commit b19863640d changed the code to *always* directly run iptables/ebtables commands, and never use the firewalld passthrough API, effectively making the direct and firewalld backends identical, except that when libvirt receives notice that firewalld has restarted or reloaded its rules, the firewalld backend sends an extra "iptables -V" command via firewalld's passthrough API (and waits for a response) prior to running all the rest of the iptables commands directly; this assures that a newly-restarted firewalld has finished its work on the filter tables before libvirt starts messing with it. (Because this code is only executed in response to an event from dbus, it isn't tested in the unit tests). In spite of this, we still go through all the virfirewall tests twice though - once for the direct backend, and once for the firewalld backend, even though these take the same codepath. In commit b19863640d I had left this double-testing in thinking that someday we might go back to actually doing something useful with the firewalld backend in the course of adding support for native nftables, but I've now realized that for the case of nftables we will be *even more* divorced from firewalld, so there is really no point in keeping this code around any longer. (It's likely/probable that the tests will be done twice again in the future, but it will be enough different that it is better to remove this code and re-implement from scratch when adding the nftables backend, rather than trying to directly modify the existing code and end up with something even more confusing). This patch eliminates all the test duplication in virfirewalltest.c, including mocking dbus, which is unnecessary since none of the tests use dbus (for now we ensure that by explicitly setting the virfirewall backend to DIRECT before any of the tests have run. Eventually the concept of a "firewalld backend" will disappear completely, but that's for another patch.) Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-14 20:50:26 +00:00
testFirewallSingleGroup(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;
util/network: new virFirewallBackend enum (This paragraph is for historical reference only, described only to avoid confusion of past use of the name with its new use) In a past life, virFirewallBackend had been a private static in virfirewall.c that was set at daemon init time, and used to globally (i.e. for all drivers in the daemon) determine whether to directly execute iptables commands, or to run them indirectly via the firewalld passthrough API. This was removed in commit d566cc55, since we decided that using the firewalld passthrough API is never appropriate. Now the same enum, virFirewallBackend, is being reintroduced, with a different meaning and usage pattern. It will be used to pick between using nftables commands or iptables commands (in either case directly handled by libvirt, *not* via firewalld). Additionally, rather than being a static known only within virfirewall.c and applying to all firewall commands for all drivers, each virFirewall object will have its own backend setting, which will be set during virFirewallNew() by the driver who wants to add a firewall rule. This will allow the nwfilter and network drivers to each have their own backend setting, even when they coexist in a single unified daemon. At least as important as that, it will also allow an instance of the network driver to remove iptables rules that had been added by a previous instance, and then add nftables rules for the new instance (in the case that an admin, or possibly an update, switches the driver backend from iptables to nftable) Initially, the enum will only have one usable value - VIR_FIREWALL_BACKEND_IPTABLES, and that will be hardcoded into all calls to virFirewallNew(). The other enum value (along with a method of setting it for each driver) will be added later, when it can be used (when the nftables backend is in the code). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
g_autoptr(virFirewall) fw = virFirewallNew(VIR_FIREWALL_BACKEND_IPTABLES);
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 *actual = NULL;
const char *expected =
lib: Use $PROG instead of $PROG_PATH Due to the way we detect programs at runtime there's no difference between $PROG and $PROG_PATH macros that come from meson-config.h. Either both are set to the path found during configure or both are set to just "$prog", e.g.: #define EBTABLES "/sbin/ebtables" #define EBTABLES_PATH "/sbin/ebtables" #define FLAKE8 "flake8" #define FLAKE8_PATH "flake8" Change those few places which use _PATH. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-09-14 08:40:42 +00:00
IPTABLES " -w -A INPUT --source 192.168.122.1 --jump ACCEPT\n"
IPTABLES " -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
tests: remove firewalld backend tests from virfirewalltest.c When libvirt added support for firewalld, all iptables/ebtables rules were added via the firewalld "passthrough" API when firewalld was enabled (the "firewalld backend"), or run directly by libvirt when firewalld was disabled (the so-called "direct backend"). virfirewalltest.c dutifully ran each test twice, once with the each backend enabled. But commit b19863640d changed the code to *always* directly run iptables/ebtables commands, and never use the firewalld passthrough API, effectively making the direct and firewalld backends identical, except that when libvirt receives notice that firewalld has restarted or reloaded its rules, the firewalld backend sends an extra "iptables -V" command via firewalld's passthrough API (and waits for a response) prior to running all the rest of the iptables commands directly; this assures that a newly-restarted firewalld has finished its work on the filter tables before libvirt starts messing with it. (Because this code is only executed in response to an event from dbus, it isn't tested in the unit tests). In spite of this, we still go through all the virfirewall tests twice though - once for the direct backend, and once for the firewalld backend, even though these take the same codepath. In commit b19863640d I had left this double-testing in thinking that someday we might go back to actually doing something useful with the firewalld backend in the course of adding support for native nftables, but I've now realized that for the case of nftables we will be *even more* divorced from firewalld, so there is really no point in keeping this code around any longer. (It's likely/probable that the tests will be done twice again in the future, but it will be enough different that it is better to remove this code and re-implement from scratch when adding the nftables backend, rather than trying to directly modify the existing code and end up with something even more confusing). This patch eliminates all the test duplication in virfirewalltest.c, including mocking dbus, which is unnecessary since none of the tests use dbus (for now we ensure that by explicitly setting the virfirewall backend to DIRECT before any of the tests have run. Eventually the concept of a "firewalld backend" will disappear completely, but that's for another patch.) Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-14 20:50:26 +00:00
g_autoptr(virCommandDryRunToken) dryRunToken = virCommandDryRunTokenNew();
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: remove firewalld backend tests from virfirewalltest.c When libvirt added support for firewalld, all iptables/ebtables rules were added via the firewalld "passthrough" API when firewalld was enabled (the "firewalld backend"), or run directly by libvirt when firewalld was disabled (the so-called "direct backend"). virfirewalltest.c dutifully ran each test twice, once with the each backend enabled. But commit b19863640d changed the code to *always* directly run iptables/ebtables commands, and never use the firewalld passthrough API, effectively making the direct and firewalld backends identical, except that when libvirt receives notice that firewalld has restarted or reloaded its rules, the firewalld backend sends an extra "iptables -V" command via firewalld's passthrough API (and waits for a response) prior to running all the rest of the iptables commands directly; this assures that a newly-restarted firewalld has finished its work on the filter tables before libvirt starts messing with it. (Because this code is only executed in response to an event from dbus, it isn't tested in the unit tests). In spite of this, we still go through all the virfirewall tests twice though - once for the direct backend, and once for the firewalld backend, even though these take the same codepath. In commit b19863640d I had left this double-testing in thinking that someday we might go back to actually doing something useful with the firewalld backend in the course of adding support for native nftables, but I've now realized that for the case of nftables we will be *even more* divorced from firewalld, so there is really no point in keeping this code around any longer. (It's likely/probable that the tests will be done twice again in the future, but it will be enough different that it is better to remove this code and re-implement from scratch when adding the nftables backend, rather than trying to directly modify the existing code and end up with something even more confusing). This patch eliminates all the test duplication in virfirewalltest.c, including mocking dbus, which is unnecessary since none of the tests use dbus (for now we ensure that by explicitly setting the virfirewall backend to DIRECT before any of the tests have run. Eventually the concept of a "firewalld backend" will disappear completely, but that's for another patch.) Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-14 20:50:26 +00:00
virCommandSetDryRun(dryRunToken, &cmdbuf, false, false, NULL, 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
virFirewallStartTransaction(fw, 0);
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
"--source", "192.168.122.1",
"--jump", "ACCEPT", 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
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
"--source", "!192.168.122.1",
"--jump", "REJECT", 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
if (virFirewallApply(fw) < 0)
tests: remove unnecessary ret variables and cleanup labels Several functions were simplified to remove the only cleanup code at the cleanup label, making it unnecessary. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-15 01:05:32 +00:00
return -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
actual = virBufferCurrentContent(&cmdbuf);
tests: Use virTestCompareToString() more Instead of using: if (STRNEQ(a, b)) { virTestDifference(stderr, a, b); ... } we can use: if (virTestCompareToString(a, b) < ) { ... } Generated by the following spatch: @@ expression a, b; @@ - if (STRNEQ(a, b)) { + if (virTestCompareToString(a, b) < 0) { ... - virTestDifference(stderr, a, b); ... } and its variations (STRNEQ_NULLABLE() instead of STRNEQ(), then in some cases variables passed to STRNEQ() are in reversed order when compared to virTestCompareToString()). However, coccinelle failed to recognize the pattern in testNWFilterEBIPTablesAllTeardown() so I had to fix it manually. Also, I manually fixed testFormat() in tests/sockettest.c as I didn't bother writing another spatch rule just for that. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
2022-11-30 08:57:49 +00:00
if (virTestCompareToString(expected, actual) < 0) {
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");
tests: remove unnecessary ret variables and cleanup labels Several functions were simplified to remove the only cleanup code at the cleanup label, making it unnecessary. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-15 01:05:32 +00:00
return -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
}
tests: remove unnecessary ret variables and cleanup labels Several functions were simplified to remove the only cleanup code at the cleanup label, making it unnecessary. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-15 01:05:32 +00:00
return 0;
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
tests: remove firewalld backend tests from virfirewalltest.c When libvirt added support for firewalld, all iptables/ebtables rules were added via the firewalld "passthrough" API when firewalld was enabled (the "firewalld backend"), or run directly by libvirt when firewalld was disabled (the so-called "direct backend"). virfirewalltest.c dutifully ran each test twice, once with the each backend enabled. But commit b19863640d changed the code to *always* directly run iptables/ebtables commands, and never use the firewalld passthrough API, effectively making the direct and firewalld backends identical, except that when libvirt receives notice that firewalld has restarted or reloaded its rules, the firewalld backend sends an extra "iptables -V" command via firewalld's passthrough API (and waits for a response) prior to running all the rest of the iptables commands directly; this assures that a newly-restarted firewalld has finished its work on the filter tables before libvirt starts messing with it. (Because this code is only executed in response to an event from dbus, it isn't tested in the unit tests). In spite of this, we still go through all the virfirewall tests twice though - once for the direct backend, and once for the firewalld backend, even though these take the same codepath. In commit b19863640d I had left this double-testing in thinking that someday we might go back to actually doing something useful with the firewalld backend in the course of adding support for native nftables, but I've now realized that for the case of nftables we will be *even more* divorced from firewalld, so there is really no point in keeping this code around any longer. (It's likely/probable that the tests will be done twice again in the future, but it will be enough different that it is better to remove this code and re-implement from scratch when adding the nftables backend, rather than trying to directly modify the existing code and end up with something even more confusing). This patch eliminates all the test duplication in virfirewalltest.c, including mocking dbus, which is unnecessary since none of the tests use dbus (for now we ensure that by explicitly setting the virfirewall backend to DIRECT before any of the tests have run. Eventually the concept of a "firewalld backend" will disappear completely, but that's for another patch.) Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-14 20:50:26 +00:00
testFirewallRemoveRule(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;
util/network: new virFirewallBackend enum (This paragraph is for historical reference only, described only to avoid confusion of past use of the name with its new use) In a past life, virFirewallBackend had been a private static in virfirewall.c that was set at daemon init time, and used to globally (i.e. for all drivers in the daemon) determine whether to directly execute iptables commands, or to run them indirectly via the firewalld passthrough API. This was removed in commit d566cc55, since we decided that using the firewalld passthrough API is never appropriate. Now the same enum, virFirewallBackend, is being reintroduced, with a different meaning and usage pattern. It will be used to pick between using nftables commands or iptables commands (in either case directly handled by libvirt, *not* via firewalld). Additionally, rather than being a static known only within virfirewall.c and applying to all firewall commands for all drivers, each virFirewall object will have its own backend setting, which will be set during virFirewallNew() by the driver who wants to add a firewall rule. This will allow the nwfilter and network drivers to each have their own backend setting, even when they coexist in a single unified daemon. At least as important as that, it will also allow an instance of the network driver to remove iptables rules that had been added by a previous instance, and then add nftables rules for the new instance (in the case that an admin, or possibly an update, switches the driver backend from iptables to nftable) Initially, the enum will only have one usable value - VIR_FIREWALL_BACKEND_IPTABLES, and that will be hardcoded into all calls to virFirewallNew(). The other enum value (along with a method of setting it for each driver) will be added later, when it can be used (when the nftables backend is in the code). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
g_autoptr(virFirewall) fw = virFirewallNew(VIR_FIREWALL_BACKEND_IPTABLES);
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 *actual = NULL;
const char *expected =
lib: Use $PROG instead of $PROG_PATH Due to the way we detect programs at runtime there's no difference between $PROG and $PROG_PATH macros that come from meson-config.h. Either both are set to the path found during configure or both are set to just "$prog", e.g.: #define EBTABLES "/sbin/ebtables" #define EBTABLES_PATH "/sbin/ebtables" #define FLAKE8 "flake8" #define FLAKE8_PATH "flake8" Change those few places which use _PATH. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-09-14 08:40:42 +00:00
IPTABLES " -w -A INPUT --source 192.168.122.1 --jump ACCEPT\n"
IPTABLES " -w -A INPUT --source '!192.168.122.1' --jump REJECT\n";
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallCmd *fwrule;
virCommandSetDryRun: Rework resetting of the dry run data While virCommandSetDryRun is used in tests only, there were some cases when error paths would not call the function with NULL arguments to reset the dry run infrastructure. Introduce virCommandDryRunToken type which must be allocated via virCommandDryRunTokenNew and passed to virCommandSetDryRun. This way we can use automatic variable cleaning to trigger the cleanup of virCommandSetDryRun parameters and also the use of the token variable ensures that all callers of virCommandSetDryRun clean up after themselves and also that the token isn't left unused in the code. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2021-04-01 15:54:09 +00:00
g_autoptr(virCommandDryRunToken) dryRunToken = virCommandDryRunTokenNew();
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: remove firewalld backend tests from virfirewalltest.c When libvirt added support for firewalld, all iptables/ebtables rules were added via the firewalld "passthrough" API when firewalld was enabled (the "firewalld backend"), or run directly by libvirt when firewalld was disabled (the so-called "direct backend"). virfirewalltest.c dutifully ran each test twice, once with the each backend enabled. But commit b19863640d changed the code to *always* directly run iptables/ebtables commands, and never use the firewalld passthrough API, effectively making the direct and firewalld backends identical, except that when libvirt receives notice that firewalld has restarted or reloaded its rules, the firewalld backend sends an extra "iptables -V" command via firewalld's passthrough API (and waits for a response) prior to running all the rest of the iptables commands directly; this assures that a newly-restarted firewalld has finished its work on the filter tables before libvirt starts messing with it. (Because this code is only executed in response to an event from dbus, it isn't tested in the unit tests). In spite of this, we still go through all the virfirewall tests twice though - once for the direct backend, and once for the firewalld backend, even though these take the same codepath. In commit b19863640d I had left this double-testing in thinking that someday we might go back to actually doing something useful with the firewalld backend in the course of adding support for native nftables, but I've now realized that for the case of nftables we will be *even more* divorced from firewalld, so there is really no point in keeping this code around any longer. (It's likely/probable that the tests will be done twice again in the future, but it will be enough different that it is better to remove this code and re-implement from scratch when adding the nftables backend, rather than trying to directly modify the existing code and end up with something even more confusing). This patch eliminates all the test duplication in virfirewalltest.c, including mocking dbus, which is unnecessary since none of the tests use dbus (for now we ensure that by explicitly setting the virfirewall backend to DIRECT before any of the tests have run. Eventually the concept of a "firewalld backend" will disappear completely, but that's for another patch.) Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-14 20:50:26 +00:00
virCommandSetDryRun(dryRunToken, &cmdbuf, false, false, NULL, 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
virFirewallStartTransaction(fw, 0);
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
"--source", "192.168.122.1",
"--jump", "ACCEPT", 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
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
fwrule = virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT", NULL);
virFirewallCmdAddArg(fw, fwrule, "--source");
virFirewallRemoveCmd(fw, fwrule);
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
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
fwrule = virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT", NULL);
virFirewallCmdAddArg(fw, fwrule, "--source");
virFirewallCmdAddArgFormat(fw, fwrule, "%s", "!192.168.122.1");
virFirewallCmdAddArgList(fw, fwrule, "--jump", "REJECT", 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
if (virFirewallApply(fw) < 0)
tests: remove unnecessary ret variables and cleanup labels Several functions were simplified to remove the only cleanup code at the cleanup label, making it unnecessary. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-15 01:05:32 +00:00
return -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
actual = virBufferCurrentContent(&cmdbuf);
tests: Use virTestCompareToString() more Instead of using: if (STRNEQ(a, b)) { virTestDifference(stderr, a, b); ... } we can use: if (virTestCompareToString(a, b) < ) { ... } Generated by the following spatch: @@ expression a, b; @@ - if (STRNEQ(a, b)) { + if (virTestCompareToString(a, b) < 0) { ... - virTestDifference(stderr, a, b); ... } and its variations (STRNEQ_NULLABLE() instead of STRNEQ(), then in some cases variables passed to STRNEQ() are in reversed order when compared to virTestCompareToString()). However, coccinelle failed to recognize the pattern in testNWFilterEBIPTablesAllTeardown() so I had to fix it manually. Also, I manually fixed testFormat() in tests/sockettest.c as I didn't bother writing another spatch rule just for that. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
2022-11-30 08:57:49 +00:00
if (virTestCompareToString(expected, actual) < 0) {
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");
tests: remove unnecessary ret variables and cleanup labels Several functions were simplified to remove the only cleanup code at the cleanup label, making it unnecessary. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-15 01:05:32 +00:00
return -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
}
tests: remove unnecessary ret variables and cleanup labels Several functions were simplified to remove the only cleanup code at the cleanup label, making it unnecessary. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-15 01:05:32 +00:00
return 0;
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
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;
util/network: new virFirewallBackend enum (This paragraph is for historical reference only, described only to avoid confusion of past use of the name with its new use) In a past life, virFirewallBackend had been a private static in virfirewall.c that was set at daemon init time, and used to globally (i.e. for all drivers in the daemon) determine whether to directly execute iptables commands, or to run them indirectly via the firewalld passthrough API. This was removed in commit d566cc55, since we decided that using the firewalld passthrough API is never appropriate. Now the same enum, virFirewallBackend, is being reintroduced, with a different meaning and usage pattern. It will be used to pick between using nftables commands or iptables commands (in either case directly handled by libvirt, *not* via firewalld). Additionally, rather than being a static known only within virfirewall.c and applying to all firewall commands for all drivers, each virFirewall object will have its own backend setting, which will be set during virFirewallNew() by the driver who wants to add a firewall rule. This will allow the nwfilter and network drivers to each have their own backend setting, even when they coexist in a single unified daemon. At least as important as that, it will also allow an instance of the network driver to remove iptables rules that had been added by a previous instance, and then add nftables rules for the new instance (in the case that an admin, or possibly an update, switches the driver backend from iptables to nftable) Initially, the enum will only have one usable value - VIR_FIREWALL_BACKEND_IPTABLES, and that will be hardcoded into all calls to virFirewallNew(). The other enum value (along with a method of setting it for each driver) will be added later, when it can be used (when the nftables backend is in the code). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
g_autoptr(virFirewall) fw = virFirewallNew(VIR_FIREWALL_BACKEND_IPTABLES);
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 *actual = NULL;
const char *expected =
lib: Use $PROG instead of $PROG_PATH Due to the way we detect programs at runtime there's no difference between $PROG and $PROG_PATH macros that come from meson-config.h. Either both are set to the path found during configure or both are set to just "$prog", e.g.: #define EBTABLES "/sbin/ebtables" #define EBTABLES_PATH "/sbin/ebtables" #define FLAKE8 "flake8" #define FLAKE8_PATH "flake8" Change those few places which use _PATH. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-09-14 08:40:42 +00:00
IPTABLES " -w -A INPUT --source 192.168.122.1 --jump ACCEPT\n"
IPTABLES " -w -A INPUT --source '!192.168.122.1' --jump REJECT\n"
IPTABLES " -w -A OUTPUT --source 192.168.122.1 --jump ACCEPT\n"
IPTABLES " -w -A OUTPUT --jump DROP\n";
virCommandSetDryRun: Rework resetting of the dry run data While virCommandSetDryRun is used in tests only, there were some cases when error paths would not call the function with NULL arguments to reset the dry run infrastructure. Introduce virCommandDryRunToken type which must be allocated via virCommandDryRunTokenNew and passed to virCommandSetDryRun. This way we can use automatic variable cleaning to trigger the cleanup of virCommandSetDryRun parameters and also the use of the token variable ensures that all callers of virCommandSetDryRun clean up after themselves and also that the token isn't left unused in the code. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2021-04-01 15:54:09 +00:00
g_autoptr(virCommandDryRunToken) dryRunToken = virCommandDryRunTokenNew();
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: remove firewalld backend tests from virfirewalltest.c When libvirt added support for firewalld, all iptables/ebtables rules were added via the firewalld "passthrough" API when firewalld was enabled (the "firewalld backend"), or run directly by libvirt when firewalld was disabled (the so-called "direct backend"). virfirewalltest.c dutifully ran each test twice, once with the each backend enabled. But commit b19863640d changed the code to *always* directly run iptables/ebtables commands, and never use the firewalld passthrough API, effectively making the direct and firewalld backends identical, except that when libvirt receives notice that firewalld has restarted or reloaded its rules, the firewalld backend sends an extra "iptables -V" command via firewalld's passthrough API (and waits for a response) prior to running all the rest of the iptables commands directly; this assures that a newly-restarted firewalld has finished its work on the filter tables before libvirt starts messing with it. (Because this code is only executed in response to an event from dbus, it isn't tested in the unit tests). In spite of this, we still go through all the virfirewall tests twice though - once for the direct backend, and once for the firewalld backend, even though these take the same codepath. In commit b19863640d I had left this double-testing in thinking that someday we might go back to actually doing something useful with the firewalld backend in the course of adding support for native nftables, but I've now realized that for the case of nftables we will be *even more* divorced from firewalld, so there is really no point in keeping this code around any longer. (It's likely/probable that the tests will be done twice again in the future, but it will be enough different that it is better to remove this code and re-implement from scratch when adding the nftables backend, rather than trying to directly modify the existing code and end up with something even more confusing). This patch eliminates all the test duplication in virfirewalltest.c, including mocking dbus, which is unnecessary since none of the tests use dbus (for now we ensure that by explicitly setting the virfirewall backend to DIRECT before any of the tests have run. Eventually the concept of a "firewalld backend" will disappear completely, but that's for another patch.) Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-14 20:50:26 +00:00
virCommandSetDryRun(dryRunToken, &cmdbuf, false, false, NULL, 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
virFirewallStartTransaction(fw, 0);
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
"--source", "192.168.122.1",
"--jump", "ACCEPT", 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
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
"--source", "!192.168.122.1",
"--jump", "REJECT", 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
virFirewallStartTransaction(fw, 0);
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "OUTPUT",
"--source", "192.168.122.1",
"--jump", "ACCEPT", 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
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "OUTPUT",
"--jump", "DROP", 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
if (virFirewallApply(fw) < 0)
tests: remove unnecessary ret variables and cleanup labels Several functions were simplified to remove the only cleanup code at the cleanup label, making it unnecessary. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-15 01:05:32 +00:00
return -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
actual = virBufferCurrentContent(&cmdbuf);
tests: Use virTestCompareToString() more Instead of using: if (STRNEQ(a, b)) { virTestDifference(stderr, a, b); ... } we can use: if (virTestCompareToString(a, b) < ) { ... } Generated by the following spatch: @@ expression a, b; @@ - if (STRNEQ(a, b)) { + if (virTestCompareToString(a, b) < 0) { ... - virTestDifference(stderr, a, b); ... } and its variations (STRNEQ_NULLABLE() instead of STRNEQ(), then in some cases variables passed to STRNEQ() are in reversed order when compared to virTestCompareToString()). However, coccinelle failed to recognize the pattern in testNWFilterEBIPTablesAllTeardown() so I had to fix it manually. Also, I manually fixed testFormat() in tests/sockettest.c as I didn't bother writing another spatch rule just for that. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
2022-11-30 08:57:49 +00:00
if (virTestCompareToString(expected, actual) < 0) {
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");
tests: remove unnecessary ret variables and cleanup labels Several functions were simplified to remove the only cleanup code at the cleanup label, making it unnecessary. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-15 01:05:32 +00:00
return -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
}
tests: remove unnecessary ret variables and cleanup labels Several functions were simplified to remove the only cleanup code at the cleanup label, making it unnecessary. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-15 01:05:32 +00:00
return 0;
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 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;
util/network: new virFirewallBackend enum (This paragraph is for historical reference only, described only to avoid confusion of past use of the name with its new use) In a past life, virFirewallBackend had been a private static in virfirewall.c that was set at daemon init time, and used to globally (i.e. for all drivers in the daemon) determine whether to directly execute iptables commands, or to run them indirectly via the firewalld passthrough API. This was removed in commit d566cc55, since we decided that using the firewalld passthrough API is never appropriate. Now the same enum, virFirewallBackend, is being reintroduced, with a different meaning and usage pattern. It will be used to pick between using nftables commands or iptables commands (in either case directly handled by libvirt, *not* via firewalld). Additionally, rather than being a static known only within virfirewall.c and applying to all firewall commands for all drivers, each virFirewall object will have its own backend setting, which will be set during virFirewallNew() by the driver who wants to add a firewall rule. This will allow the nwfilter and network drivers to each have their own backend setting, even when they coexist in a single unified daemon. At least as important as that, it will also allow an instance of the network driver to remove iptables rules that had been added by a previous instance, and then add nftables rules for the new instance (in the case that an admin, or possibly an update, switches the driver backend from iptables to nftable) Initially, the enum will only have one usable value - VIR_FIREWALL_BACKEND_IPTABLES, and that will be hardcoded into all calls to virFirewallNew(). The other enum value (along with a method of setting it for each driver) will be added later, when it can be used (when the nftables backend is in the code). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
g_autoptr(virFirewall) fw = virFirewallNew(VIR_FIREWALL_BACKEND_IPTABLES);
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 *actual = NULL;
const char *expected =
lib: Use $PROG instead of $PROG_PATH Due to the way we detect programs at runtime there's no difference between $PROG and $PROG_PATH macros that come from meson-config.h. Either both are set to the path found during configure or both are set to just "$prog", e.g.: #define EBTABLES "/sbin/ebtables" #define EBTABLES_PATH "/sbin/ebtables" #define FLAKE8 "flake8" #define FLAKE8_PATH "flake8" Change those few places which use _PATH. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-09-14 08:40:42 +00:00
IPTABLES " -w -A INPUT --source 192.168.122.1 --jump ACCEPT\n"
IPTABLES " -w -A INPUT --source 192.168.122.255 --jump REJECT\n"
IPTABLES " -w -A OUTPUT --source 192.168.122.1 --jump ACCEPT\n"
IPTABLES " -w -A OUTPUT --jump DROP\n";
virCommandSetDryRun: Rework resetting of the dry run data While virCommandSetDryRun is used in tests only, there were some cases when error paths would not call the function with NULL arguments to reset the dry run infrastructure. Introduce virCommandDryRunToken type which must be allocated via virCommandDryRunTokenNew and passed to virCommandSetDryRun. This way we can use automatic variable cleaning to trigger the cleanup of virCommandSetDryRun parameters and also the use of the token variable ensures that all callers of virCommandSetDryRun clean up after themselves and also that the token isn't left unused in the code. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2021-04-01 15:54:09 +00:00
g_autoptr(virCommandDryRunToken) dryRunToken = virCommandDryRunTokenNew();
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: remove firewalld backend tests from virfirewalltest.c When libvirt added support for firewalld, all iptables/ebtables rules were added via the firewalld "passthrough" API when firewalld was enabled (the "firewalld backend"), or run directly by libvirt when firewalld was disabled (the so-called "direct backend"). virfirewalltest.c dutifully ran each test twice, once with the each backend enabled. But commit b19863640d changed the code to *always* directly run iptables/ebtables commands, and never use the firewalld passthrough API, effectively making the direct and firewalld backends identical, except that when libvirt receives notice that firewalld has restarted or reloaded its rules, the firewalld backend sends an extra "iptables -V" command via firewalld's passthrough API (and waits for a response) prior to running all the rest of the iptables commands directly; this assures that a newly-restarted firewalld has finished its work on the filter tables before libvirt starts messing with it. (Because this code is only executed in response to an event from dbus, it isn't tested in the unit tests). In spite of this, we still go through all the virfirewall tests twice though - once for the direct backend, and once for the firewalld backend, even though these take the same codepath. In commit b19863640d I had left this double-testing in thinking that someday we might go back to actually doing something useful with the firewalld backend in the course of adding support for native nftables, but I've now realized that for the case of nftables we will be *even more* divorced from firewalld, so there is really no point in keeping this code around any longer. (It's likely/probable that the tests will be done twice again in the future, but it will be enough different that it is better to remove this code and re-implement from scratch when adding the nftables backend, rather than trying to directly modify the existing code and end up with something even more confusing). This patch eliminates all the test duplication in virfirewalltest.c, including mocking dbus, which is unnecessary since none of the tests use dbus (for now we ensure that by explicitly setting the virfirewall backend to DIRECT before any of the tests have run. Eventually the concept of a "firewalld backend" will disappear completely, but that's for another patch.) Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-14 20:50:26 +00:00
virCommandSetDryRun(dryRunToken, &cmdbuf, false, false, testFirewallRollbackHook, 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
virFirewallStartTransaction(fw, VIR_FIREWALL_TRANSACTION_IGNORE_ERRORS);
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
"--source", "192.168.122.1",
"--jump", "ACCEPT", 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
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
"--source", "192.168.122.255",
"--jump", "REJECT", 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
virFirewallStartTransaction(fw, 0);
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "OUTPUT",
"--source", "192.168.122.1",
"--jump", "ACCEPT", 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
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "OUTPUT",
"--jump", "DROP", 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
if (virFirewallApply(fw) < 0)
tests: remove unnecessary ret variables and cleanup labels Several functions were simplified to remove the only cleanup code at the cleanup label, making it unnecessary. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-15 01:05:32 +00:00
return -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
actual = virBufferCurrentContent(&cmdbuf);
tests: Use virTestCompareToString() more Instead of using: if (STRNEQ(a, b)) { virTestDifference(stderr, a, b); ... } we can use: if (virTestCompareToString(a, b) < ) { ... } Generated by the following spatch: @@ expression a, b; @@ - if (STRNEQ(a, b)) { + if (virTestCompareToString(a, b) < 0) { ... - virTestDifference(stderr, a, b); ... } and its variations (STRNEQ_NULLABLE() instead of STRNEQ(), then in some cases variables passed to STRNEQ() are in reversed order when compared to virTestCompareToString()). However, coccinelle failed to recognize the pattern in testNWFilterEBIPTablesAllTeardown() so I had to fix it manually. Also, I manually fixed testFormat() in tests/sockettest.c as I didn't bother writing another spatch rule just for that. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
2022-11-30 08:57:49 +00:00
if (virTestCompareToString(expected, actual) < 0) {
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");
tests: remove unnecessary ret variables and cleanup labels Several functions were simplified to remove the only cleanup code at the cleanup label, making it unnecessary. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-15 01:05:32 +00:00
return -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
}
tests: remove unnecessary ret variables and cleanup labels Several functions were simplified to remove the only cleanup code at the cleanup label, making it unnecessary. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-15 01:05:32 +00:00
return 0;
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
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;
util/network: new virFirewallBackend enum (This paragraph is for historical reference only, described only to avoid confusion of past use of the name with its new use) In a past life, virFirewallBackend had been a private static in virfirewall.c that was set at daemon init time, and used to globally (i.e. for all drivers in the daemon) determine whether to directly execute iptables commands, or to run them indirectly via the firewalld passthrough API. This was removed in commit d566cc55, since we decided that using the firewalld passthrough API is never appropriate. Now the same enum, virFirewallBackend, is being reintroduced, with a different meaning and usage pattern. It will be used to pick between using nftables commands or iptables commands (in either case directly handled by libvirt, *not* via firewalld). Additionally, rather than being a static known only within virfirewall.c and applying to all firewall commands for all drivers, each virFirewall object will have its own backend setting, which will be set during virFirewallNew() by the driver who wants to add a firewall rule. This will allow the nwfilter and network drivers to each have their own backend setting, even when they coexist in a single unified daemon. At least as important as that, it will also allow an instance of the network driver to remove iptables rules that had been added by a previous instance, and then add nftables rules for the new instance (in the case that an admin, or possibly an update, switches the driver backend from iptables to nftable) Initially, the enum will only have one usable value - VIR_FIREWALL_BACKEND_IPTABLES, and that will be hardcoded into all calls to virFirewallNew(). The other enum value (along with a method of setting it for each driver) will be added later, when it can be used (when the nftables backend is in the code). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
g_autoptr(virFirewall) fw = virFirewallNew(VIR_FIREWALL_BACKEND_IPTABLES);
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 *actual = NULL;
const char *expected =
lib: Use $PROG instead of $PROG_PATH Due to the way we detect programs at runtime there's no difference between $PROG and $PROG_PATH macros that come from meson-config.h. Either both are set to the path found during configure or both are set to just "$prog", e.g.: #define EBTABLES "/sbin/ebtables" #define EBTABLES_PATH "/sbin/ebtables" #define FLAKE8 "flake8" #define FLAKE8_PATH "flake8" Change those few places which use _PATH. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-09-14 08:40:42 +00:00
IPTABLES " -w -A INPUT --source 192.168.122.1 --jump ACCEPT\n"
IPTABLES " -w -A INPUT --source 192.168.122.255 --jump REJECT\n"
IPTABLES " -w -A OUTPUT --source 192.168.122.1 --jump ACCEPT\n"
IPTABLES " -w -A OUTPUT --jump DROP\n";
virCommandSetDryRun: Rework resetting of the dry run data While virCommandSetDryRun is used in tests only, there were some cases when error paths would not call the function with NULL arguments to reset the dry run infrastructure. Introduce virCommandDryRunToken type which must be allocated via virCommandDryRunTokenNew and passed to virCommandSetDryRun. This way we can use automatic variable cleaning to trigger the cleanup of virCommandSetDryRun parameters and also the use of the token variable ensures that all callers of virCommandSetDryRun clean up after themselves and also that the token isn't left unused in the code. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2021-04-01 15:54:09 +00:00
g_autoptr(virCommandDryRunToken) dryRunToken = virCommandDryRunTokenNew();
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: remove firewalld backend tests from virfirewalltest.c When libvirt added support for firewalld, all iptables/ebtables rules were added via the firewalld "passthrough" API when firewalld was enabled (the "firewalld backend"), or run directly by libvirt when firewalld was disabled (the so-called "direct backend"). virfirewalltest.c dutifully ran each test twice, once with the each backend enabled. But commit b19863640d changed the code to *always* directly run iptables/ebtables commands, and never use the firewalld passthrough API, effectively making the direct and firewalld backends identical, except that when libvirt receives notice that firewalld has restarted or reloaded its rules, the firewalld backend sends an extra "iptables -V" command via firewalld's passthrough API (and waits for a response) prior to running all the rest of the iptables commands directly; this assures that a newly-restarted firewalld has finished its work on the filter tables before libvirt starts messing with it. (Because this code is only executed in response to an event from dbus, it isn't tested in the unit tests). In spite of this, we still go through all the virfirewall tests twice though - once for the direct backend, and once for the firewalld backend, even though these take the same codepath. In commit b19863640d I had left this double-testing in thinking that someday we might go back to actually doing something useful with the firewalld backend in the course of adding support for native nftables, but I've now realized that for the case of nftables we will be *even more* divorced from firewalld, so there is really no point in keeping this code around any longer. (It's likely/probable that the tests will be done twice again in the future, but it will be enough different that it is better to remove this code and re-implement from scratch when adding the nftables backend, rather than trying to directly modify the existing code and end up with something even more confusing). This patch eliminates all the test duplication in virfirewalltest.c, including mocking dbus, which is unnecessary since none of the tests use dbus (for now we ensure that by explicitly setting the virfirewall backend to DIRECT before any of the tests have run. Eventually the concept of a "firewalld backend" will disappear completely, but that's for another patch.) Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-14 20:50:26 +00:00
virCommandSetDryRun(dryRunToken, &cmdbuf, false, false, testFirewallRollbackHook, 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
virFirewallStartTransaction(fw, 0);
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
"--source", "192.168.122.1",
"--jump", "ACCEPT", 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
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmdFull(fw, VIR_FIREWALL_LAYER_IPV4,
true, NULL, NULL,
"-A", "INPUT",
"--source", "192.168.122.255",
"--jump", "REJECT", 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
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "OUTPUT",
"--source", "192.168.122.1",
"--jump", "ACCEPT", 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
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "OUTPUT",
"--jump", "DROP", 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
if (virFirewallApply(fw) < 0)
tests: remove unnecessary ret variables and cleanup labels Several functions were simplified to remove the only cleanup code at the cleanup label, making it unnecessary. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-15 01:05:32 +00:00
return -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
actual = virBufferCurrentContent(&cmdbuf);
tests: Use virTestCompareToString() more Instead of using: if (STRNEQ(a, b)) { virTestDifference(stderr, a, b); ... } we can use: if (virTestCompareToString(a, b) < ) { ... } Generated by the following spatch: @@ expression a, b; @@ - if (STRNEQ(a, b)) { + if (virTestCompareToString(a, b) < 0) { ... - virTestDifference(stderr, a, b); ... } and its variations (STRNEQ_NULLABLE() instead of STRNEQ(), then in some cases variables passed to STRNEQ() are in reversed order when compared to virTestCompareToString()). However, coccinelle failed to recognize the pattern in testNWFilterEBIPTablesAllTeardown() so I had to fix it manually. Also, I manually fixed testFormat() in tests/sockettest.c as I didn't bother writing another spatch rule just for that. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
2022-11-30 08:57:49 +00:00
if (virTestCompareToString(expected, actual) < 0) {
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");
tests: remove unnecessary ret variables and cleanup labels Several functions were simplified to remove the only cleanup code at the cleanup label, making it unnecessary. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-15 01:05:32 +00:00
return -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
}
tests: remove unnecessary ret variables and cleanup labels Several functions were simplified to remove the only cleanup code at the cleanup label, making it unnecessary. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-15 01:05:32 +00:00
return 0;
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
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;
util/network: new virFirewallBackend enum (This paragraph is for historical reference only, described only to avoid confusion of past use of the name with its new use) In a past life, virFirewallBackend had been a private static in virfirewall.c that was set at daemon init time, and used to globally (i.e. for all drivers in the daemon) determine whether to directly execute iptables commands, or to run them indirectly via the firewalld passthrough API. This was removed in commit d566cc55, since we decided that using the firewalld passthrough API is never appropriate. Now the same enum, virFirewallBackend, is being reintroduced, with a different meaning and usage pattern. It will be used to pick between using nftables commands or iptables commands (in either case directly handled by libvirt, *not* via firewalld). Additionally, rather than being a static known only within virfirewall.c and applying to all firewall commands for all drivers, each virFirewall object will have its own backend setting, which will be set during virFirewallNew() by the driver who wants to add a firewall rule. This will allow the nwfilter and network drivers to each have their own backend setting, even when they coexist in a single unified daemon. At least as important as that, it will also allow an instance of the network driver to remove iptables rules that had been added by a previous instance, and then add nftables rules for the new instance (in the case that an admin, or possibly an update, switches the driver backend from iptables to nftable) Initially, the enum will only have one usable value - VIR_FIREWALL_BACKEND_IPTABLES, and that will be hardcoded into all calls to virFirewallNew(). The other enum value (along with a method of setting it for each driver) will be added later, when it can be used (when the nftables backend is in the code). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
g_autoptr(virFirewall) fw = virFirewallNew(VIR_FIREWALL_BACKEND_IPTABLES);
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 *actual = NULL;
const char *expected =
lib: Use $PROG instead of $PROG_PATH Due to the way we detect programs at runtime there's no difference between $PROG and $PROG_PATH macros that come from meson-config.h. Either both are set to the path found during configure or both are set to just "$prog", e.g.: #define EBTABLES "/sbin/ebtables" #define EBTABLES_PATH "/sbin/ebtables" #define FLAKE8 "flake8" #define FLAKE8_PATH "flake8" Change those few places which use _PATH. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-09-14 08:40:42 +00:00
IPTABLES " -w -A INPUT --source 192.168.122.1 --jump ACCEPT\n"
IPTABLES " -w -A INPUT --source 192.168.122.255 --jump REJECT\n";
virCommandSetDryRun: Rework resetting of the dry run data While virCommandSetDryRun is used in tests only, there were some cases when error paths would not call the function with NULL arguments to reset the dry run infrastructure. Introduce virCommandDryRunToken type which must be allocated via virCommandDryRunTokenNew and passed to virCommandSetDryRun. This way we can use automatic variable cleaning to trigger the cleanup of virCommandSetDryRun parameters and also the use of the token variable ensures that all callers of virCommandSetDryRun clean up after themselves and also that the token isn't left unused in the code. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2021-04-01 15:54:09 +00:00
g_autoptr(virCommandDryRunToken) dryRunToken = virCommandDryRunTokenNew();
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: remove firewalld backend tests from virfirewalltest.c When libvirt added support for firewalld, all iptables/ebtables rules were added via the firewalld "passthrough" API when firewalld was enabled (the "firewalld backend"), or run directly by libvirt when firewalld was disabled (the so-called "direct backend"). virfirewalltest.c dutifully ran each test twice, once with the each backend enabled. But commit b19863640d changed the code to *always* directly run iptables/ebtables commands, and never use the firewalld passthrough API, effectively making the direct and firewalld backends identical, except that when libvirt receives notice that firewalld has restarted or reloaded its rules, the firewalld backend sends an extra "iptables -V" command via firewalld's passthrough API (and waits for a response) prior to running all the rest of the iptables commands directly; this assures that a newly-restarted firewalld has finished its work on the filter tables before libvirt starts messing with it. (Because this code is only executed in response to an event from dbus, it isn't tested in the unit tests). In spite of this, we still go through all the virfirewall tests twice though - once for the direct backend, and once for the firewalld backend, even though these take the same codepath. In commit b19863640d I had left this double-testing in thinking that someday we might go back to actually doing something useful with the firewalld backend in the course of adding support for native nftables, but I've now realized that for the case of nftables we will be *even more* divorced from firewalld, so there is really no point in keeping this code around any longer. (It's likely/probable that the tests will be done twice again in the future, but it will be enough different that it is better to remove this code and re-implement from scratch when adding the nftables backend, rather than trying to directly modify the existing code and end up with something even more confusing). This patch eliminates all the test duplication in virfirewalltest.c, including mocking dbus, which is unnecessary since none of the tests use dbus (for now we ensure that by explicitly setting the virfirewall backend to DIRECT before any of the tests have run. Eventually the concept of a "firewalld backend" will disappear completely, but that's for another patch.) Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-14 20:50:26 +00:00
virCommandSetDryRun(dryRunToken, &cmdbuf, false, false, testFirewallRollbackHook, 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
virFirewallStartTransaction(fw, 0);
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
"--source", "192.168.122.1",
"--jump", "ACCEPT", 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
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
"--source", "192.168.122.255",
"--jump", "REJECT", 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
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
"--source", "!192.168.122.1",
"--jump", "REJECT", 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
if (virFirewallApply(fw) == 0) {
fprintf(stderr, "Firewall apply unexpectedly worked\n");
tests: remove unnecessary ret variables and cleanup labels Several functions were simplified to remove the only cleanup code at the cleanup label, making it unnecessary. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-15 01:05:32 +00:00
return -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
}
actual = virBufferCurrentContent(&cmdbuf);
tests: Use virTestCompareToString() more Instead of using: if (STRNEQ(a, b)) { virTestDifference(stderr, a, b); ... } we can use: if (virTestCompareToString(a, b) < ) { ... } Generated by the following spatch: @@ expression a, b; @@ - if (STRNEQ(a, b)) { + if (virTestCompareToString(a, b) < 0) { ... - virTestDifference(stderr, a, b); ... } and its variations (STRNEQ_NULLABLE() instead of STRNEQ(), then in some cases variables passed to STRNEQ() are in reversed order when compared to virTestCompareToString()). However, coccinelle failed to recognize the pattern in testNWFilterEBIPTablesAllTeardown() so I had to fix it manually. Also, I manually fixed testFormat() in tests/sockettest.c as I didn't bother writing another spatch rule just for that. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
2022-11-30 08:57:49 +00:00
if (virTestCompareToString(expected, actual) < 0) {
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");
tests: remove unnecessary ret variables and cleanup labels Several functions were simplified to remove the only cleanup code at the cleanup label, making it unnecessary. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-15 01:05:32 +00:00
return -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
}
tests: remove unnecessary ret variables and cleanup labels Several functions were simplified to remove the only cleanup code at the cleanup label, making it unnecessary. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-15 01:05:32 +00:00
return 0;
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
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;
util/network: new virFirewallBackend enum (This paragraph is for historical reference only, described only to avoid confusion of past use of the name with its new use) In a past life, virFirewallBackend had been a private static in virfirewall.c that was set at daemon init time, and used to globally (i.e. for all drivers in the daemon) determine whether to directly execute iptables commands, or to run them indirectly via the firewalld passthrough API. This was removed in commit d566cc55, since we decided that using the firewalld passthrough API is never appropriate. Now the same enum, virFirewallBackend, is being reintroduced, with a different meaning and usage pattern. It will be used to pick between using nftables commands or iptables commands (in either case directly handled by libvirt, *not* via firewalld). Additionally, rather than being a static known only within virfirewall.c and applying to all firewall commands for all drivers, each virFirewall object will have its own backend setting, which will be set during virFirewallNew() by the driver who wants to add a firewall rule. This will allow the nwfilter and network drivers to each have their own backend setting, even when they coexist in a single unified daemon. At least as important as that, it will also allow an instance of the network driver to remove iptables rules that had been added by a previous instance, and then add nftables rules for the new instance (in the case that an admin, or possibly an update, switches the driver backend from iptables to nftable) Initially, the enum will only have one usable value - VIR_FIREWALL_BACKEND_IPTABLES, and that will be hardcoded into all calls to virFirewallNew(). The other enum value (along with a method of setting it for each driver) will be added later, when it can be used (when the nftables backend is in the code). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
g_autoptr(virFirewall) fw = virFirewallNew(VIR_FIREWALL_BACKEND_IPTABLES);
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 *actual = NULL;
const char *expected =
lib: Use $PROG instead of $PROG_PATH Due to the way we detect programs at runtime there's no difference between $PROG and $PROG_PATH macros that come from meson-config.h. Either both are set to the path found during configure or both are set to just "$prog", e.g.: #define EBTABLES "/sbin/ebtables" #define EBTABLES_PATH "/sbin/ebtables" #define FLAKE8 "flake8" #define FLAKE8_PATH "flake8" Change those few places which use _PATH. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-09-14 08:40:42 +00:00
IPTABLES " -w -A INPUT --source 192.168.122.1 --jump ACCEPT\n"
IPTABLES " -w -A INPUT --source 192.168.122.255 --jump REJECT\n"
IPTABLES " -w -D INPUT --source 192.168.122.1 --jump ACCEPT\n"
IPTABLES " -w -D INPUT --source 192.168.122.255 --jump REJECT\n"
IPTABLES " -w -D INPUT --source '!192.168.122.1' --jump REJECT\n";
virCommandSetDryRun: Rework resetting of the dry run data While virCommandSetDryRun is used in tests only, there were some cases when error paths would not call the function with NULL arguments to reset the dry run infrastructure. Introduce virCommandDryRunToken type which must be allocated via virCommandDryRunTokenNew and passed to virCommandSetDryRun. This way we can use automatic variable cleaning to trigger the cleanup of virCommandSetDryRun parameters and also the use of the token variable ensures that all callers of virCommandSetDryRun clean up after themselves and also that the token isn't left unused in the code. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2021-04-01 15:54:09 +00:00
g_autoptr(virCommandDryRunToken) dryRunToken = virCommandDryRunTokenNew();
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: remove firewalld backend tests from virfirewalltest.c When libvirt added support for firewalld, all iptables/ebtables rules were added via the firewalld "passthrough" API when firewalld was enabled (the "firewalld backend"), or run directly by libvirt when firewalld was disabled (the so-called "direct backend"). virfirewalltest.c dutifully ran each test twice, once with the each backend enabled. But commit b19863640d changed the code to *always* directly run iptables/ebtables commands, and never use the firewalld passthrough API, effectively making the direct and firewalld backends identical, except that when libvirt receives notice that firewalld has restarted or reloaded its rules, the firewalld backend sends an extra "iptables -V" command via firewalld's passthrough API (and waits for a response) prior to running all the rest of the iptables commands directly; this assures that a newly-restarted firewalld has finished its work on the filter tables before libvirt starts messing with it. (Because this code is only executed in response to an event from dbus, it isn't tested in the unit tests). In spite of this, we still go through all the virfirewall tests twice though - once for the direct backend, and once for the firewalld backend, even though these take the same codepath. In commit b19863640d I had left this double-testing in thinking that someday we might go back to actually doing something useful with the firewalld backend in the course of adding support for native nftables, but I've now realized that for the case of nftables we will be *even more* divorced from firewalld, so there is really no point in keeping this code around any longer. (It's likely/probable that the tests will be done twice again in the future, but it will be enough different that it is better to remove this code and re-implement from scratch when adding the nftables backend, rather than trying to directly modify the existing code and end up with something even more confusing). This patch eliminates all the test duplication in virfirewalltest.c, including mocking dbus, which is unnecessary since none of the tests use dbus (for now we ensure that by explicitly setting the virfirewall backend to DIRECT before any of the tests have run. Eventually the concept of a "firewalld backend" will disappear completely, but that's for another patch.) Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-14 20:50:26 +00:00
virCommandSetDryRun(dryRunToken, &cmdbuf, false, false, testFirewallRollbackHook, 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
virFirewallStartTransaction(fw, 0);
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
"--source", "192.168.122.1",
"--jump", "ACCEPT", 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
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
"--source", "192.168.122.255",
"--jump", "REJECT", 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
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
"--source", "!192.168.122.1",
"--jump", "REJECT", 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
virFirewallStartRollback(fw, 0);
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-D", "INPUT",
"--source", "192.168.122.1",
"--jump", "ACCEPT", 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
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-D", "INPUT",
"--source", "192.168.122.255",
"--jump", "REJECT", 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
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-D", "INPUT",
"--source", "!192.168.122.1",
"--jump", "REJECT", 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
if (virFirewallApply(fw) == 0) {
fprintf(stderr, "Firewall apply unexpectedly worked\n");
tests: remove unnecessary ret variables and cleanup labels Several functions were simplified to remove the only cleanup code at the cleanup label, making it unnecessary. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-15 01:05:32 +00:00
return -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
}
actual = virBufferCurrentContent(&cmdbuf);
tests: Use virTestCompareToString() more Instead of using: if (STRNEQ(a, b)) { virTestDifference(stderr, a, b); ... } we can use: if (virTestCompareToString(a, b) < ) { ... } Generated by the following spatch: @@ expression a, b; @@ - if (STRNEQ(a, b)) { + if (virTestCompareToString(a, b) < 0) { ... - virTestDifference(stderr, a, b); ... } and its variations (STRNEQ_NULLABLE() instead of STRNEQ(), then in some cases variables passed to STRNEQ() are in reversed order when compared to virTestCompareToString()). However, coccinelle failed to recognize the pattern in testNWFilterEBIPTablesAllTeardown() so I had to fix it manually. Also, I manually fixed testFormat() in tests/sockettest.c as I didn't bother writing another spatch rule just for that. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
2022-11-30 08:57:49 +00:00
if (virTestCompareToString(expected, actual) < 0) {
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");
tests: remove unnecessary ret variables and cleanup labels Several functions were simplified to remove the only cleanup code at the cleanup label, making it unnecessary. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-15 01:05:32 +00:00
return -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
}
tests: remove unnecessary ret variables and cleanup labels Several functions were simplified to remove the only cleanup code at the cleanup label, making it unnecessary. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-15 01:05:32 +00:00
return 0;
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
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;
util/network: new virFirewallBackend enum (This paragraph is for historical reference only, described only to avoid confusion of past use of the name with its new use) In a past life, virFirewallBackend had been a private static in virfirewall.c that was set at daemon init time, and used to globally (i.e. for all drivers in the daemon) determine whether to directly execute iptables commands, or to run them indirectly via the firewalld passthrough API. This was removed in commit d566cc55, since we decided that using the firewalld passthrough API is never appropriate. Now the same enum, virFirewallBackend, is being reintroduced, with a different meaning and usage pattern. It will be used to pick between using nftables commands or iptables commands (in either case directly handled by libvirt, *not* via firewalld). Additionally, rather than being a static known only within virfirewall.c and applying to all firewall commands for all drivers, each virFirewall object will have its own backend setting, which will be set during virFirewallNew() by the driver who wants to add a firewall rule. This will allow the nwfilter and network drivers to each have their own backend setting, even when they coexist in a single unified daemon. At least as important as that, it will also allow an instance of the network driver to remove iptables rules that had been added by a previous instance, and then add nftables rules for the new instance (in the case that an admin, or possibly an update, switches the driver backend from iptables to nftable) Initially, the enum will only have one usable value - VIR_FIREWALL_BACKEND_IPTABLES, and that will be hardcoded into all calls to virFirewallNew(). The other enum value (along with a method of setting it for each driver) will be added later, when it can be used (when the nftables backend is in the code). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
g_autoptr(virFirewall) fw = virFirewallNew(VIR_FIREWALL_BACKEND_IPTABLES);
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 *actual = NULL;
const char *expected =
lib: Use $PROG instead of $PROG_PATH Due to the way we detect programs at runtime there's no difference between $PROG and $PROG_PATH macros that come from meson-config.h. Either both are set to the path found during configure or both are set to just "$prog", e.g.: #define EBTABLES "/sbin/ebtables" #define EBTABLES_PATH "/sbin/ebtables" #define FLAKE8 "flake8" #define FLAKE8_PATH "flake8" Change those few places which use _PATH. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-09-14 08:40:42 +00:00
IPTABLES " -w -A INPUT --source 192.168.122.1 --jump ACCEPT\n"
IPTABLES " -w -A INPUT --source 192.168.122.255 --jump REJECT\n"
IPTABLES " -w -D INPUT --source 192.168.122.255 --jump REJECT\n"
IPTABLES " -w -D INPUT --source '!192.168.122.1' --jump REJECT\n";
virCommandSetDryRun: Rework resetting of the dry run data While virCommandSetDryRun is used in tests only, there were some cases when error paths would not call the function with NULL arguments to reset the dry run infrastructure. Introduce virCommandDryRunToken type which must be allocated via virCommandDryRunTokenNew and passed to virCommandSetDryRun. This way we can use automatic variable cleaning to trigger the cleanup of virCommandSetDryRun parameters and also the use of the token variable ensures that all callers of virCommandSetDryRun clean up after themselves and also that the token isn't left unused in the code. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2021-04-01 15:54:09 +00:00
g_autoptr(virCommandDryRunToken) dryRunToken = virCommandDryRunTokenNew();
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: remove firewalld backend tests from virfirewalltest.c When libvirt added support for firewalld, all iptables/ebtables rules were added via the firewalld "passthrough" API when firewalld was enabled (the "firewalld backend"), or run directly by libvirt when firewalld was disabled (the so-called "direct backend"). virfirewalltest.c dutifully ran each test twice, once with the each backend enabled. But commit b19863640d changed the code to *always* directly run iptables/ebtables commands, and never use the firewalld passthrough API, effectively making the direct and firewalld backends identical, except that when libvirt receives notice that firewalld has restarted or reloaded its rules, the firewalld backend sends an extra "iptables -V" command via firewalld's passthrough API (and waits for a response) prior to running all the rest of the iptables commands directly; this assures that a newly-restarted firewalld has finished its work on the filter tables before libvirt starts messing with it. (Because this code is only executed in response to an event from dbus, it isn't tested in the unit tests). In spite of this, we still go through all the virfirewall tests twice though - once for the direct backend, and once for the firewalld backend, even though these take the same codepath. In commit b19863640d I had left this double-testing in thinking that someday we might go back to actually doing something useful with the firewalld backend in the course of adding support for native nftables, but I've now realized that for the case of nftables we will be *even more* divorced from firewalld, so there is really no point in keeping this code around any longer. (It's likely/probable that the tests will be done twice again in the future, but it will be enough different that it is better to remove this code and re-implement from scratch when adding the nftables backend, rather than trying to directly modify the existing code and end up with something even more confusing). This patch eliminates all the test duplication in virfirewalltest.c, including mocking dbus, which is unnecessary since none of the tests use dbus (for now we ensure that by explicitly setting the virfirewall backend to DIRECT before any of the tests have run. Eventually the concept of a "firewalld backend" will disappear completely, but that's for another patch.) Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-14 20:50:26 +00:00
virCommandSetDryRun(dryRunToken, &cmdbuf, false, false, testFirewallRollbackHook, 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
virFirewallStartTransaction(fw, 0);
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
"--source", "192.168.122.1",
"--jump", "ACCEPT", 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
virFirewallStartRollback(fw, 0);
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-D", "INPUT",
"--source", "192.168.122.1",
"--jump", "ACCEPT", 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
virFirewallStartTransaction(fw, 0);
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
"--source", "192.168.122.255",
"--jump", "REJECT", 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
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
"--source", "!192.168.122.1",
"--jump", "REJECT", 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
virFirewallStartRollback(fw, 0);
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-D", "INPUT",
"--source", "192.168.122.255",
"--jump", "REJECT", 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
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-D", "INPUT",
"--source", "!192.168.122.1",
"--jump", "REJECT", 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
if (virFirewallApply(fw) == 0) {
fprintf(stderr, "Firewall apply unexpectedly worked\n");
tests: remove unnecessary ret variables and cleanup labels Several functions were simplified to remove the only cleanup code at the cleanup label, making it unnecessary. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-15 01:05:32 +00:00
return -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
}
actual = virBufferCurrentContent(&cmdbuf);
tests: Use virTestCompareToString() more Instead of using: if (STRNEQ(a, b)) { virTestDifference(stderr, a, b); ... } we can use: if (virTestCompareToString(a, b) < ) { ... } Generated by the following spatch: @@ expression a, b; @@ - if (STRNEQ(a, b)) { + if (virTestCompareToString(a, b) < 0) { ... - virTestDifference(stderr, a, b); ... } and its variations (STRNEQ_NULLABLE() instead of STRNEQ(), then in some cases variables passed to STRNEQ() are in reversed order when compared to virTestCompareToString()). However, coccinelle failed to recognize the pattern in testNWFilterEBIPTablesAllTeardown() so I had to fix it manually. Also, I manually fixed testFormat() in tests/sockettest.c as I didn't bother writing another spatch rule just for that. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
2022-11-30 08:57:49 +00:00
if (virTestCompareToString(expected, actual) < 0) {
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");
tests: remove unnecessary ret variables and cleanup labels Several functions were simplified to remove the only cleanup code at the cleanup label, making it unnecessary. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-15 01:05:32 +00:00
return -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
}
tests: remove unnecessary ret variables and cleanup labels Several functions were simplified to remove the only cleanup code at the cleanup label, making it unnecessary. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-15 01:05:32 +00:00
return 0;
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
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;
util/network: new virFirewallBackend enum (This paragraph is for historical reference only, described only to avoid confusion of past use of the name with its new use) In a past life, virFirewallBackend had been a private static in virfirewall.c that was set at daemon init time, and used to globally (i.e. for all drivers in the daemon) determine whether to directly execute iptables commands, or to run them indirectly via the firewalld passthrough API. This was removed in commit d566cc55, since we decided that using the firewalld passthrough API is never appropriate. Now the same enum, virFirewallBackend, is being reintroduced, with a different meaning and usage pattern. It will be used to pick between using nftables commands or iptables commands (in either case directly handled by libvirt, *not* via firewalld). Additionally, rather than being a static known only within virfirewall.c and applying to all firewall commands for all drivers, each virFirewall object will have its own backend setting, which will be set during virFirewallNew() by the driver who wants to add a firewall rule. This will allow the nwfilter and network drivers to each have their own backend setting, even when they coexist in a single unified daemon. At least as important as that, it will also allow an instance of the network driver to remove iptables rules that had been added by a previous instance, and then add nftables rules for the new instance (in the case that an admin, or possibly an update, switches the driver backend from iptables to nftable) Initially, the enum will only have one usable value - VIR_FIREWALL_BACKEND_IPTABLES, and that will be hardcoded into all calls to virFirewallNew(). The other enum value (along with a method of setting it for each driver) will be added later, when it can be used (when the nftables backend is in the code). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
g_autoptr(virFirewall) fw = virFirewallNew(VIR_FIREWALL_BACKEND_IPTABLES);
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 *actual = NULL;
const char *expected =
lib: Use $PROG instead of $PROG_PATH Due to the way we detect programs at runtime there's no difference between $PROG and $PROG_PATH macros that come from meson-config.h. Either both are set to the path found during configure or both are set to just "$prog", e.g.: #define EBTABLES "/sbin/ebtables" #define EBTABLES_PATH "/sbin/ebtables" #define FLAKE8 "flake8" #define FLAKE8_PATH "flake8" Change those few places which use _PATH. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-09-14 08:40:42 +00:00
IPTABLES " -w -A INPUT --source 192.168.122.1 --jump ACCEPT\n"
IPTABLES " -w -A INPUT --source 192.168.122.127 --jump REJECT\n"
IPTABLES " -w -A INPUT --source '!192.168.122.1' --jump REJECT\n"
IPTABLES " -w -A INPUT --source 192.168.122.255 --jump REJECT\n"
IPTABLES " -w -D INPUT --source 192.168.122.127 --jump REJECT\n"
IPTABLES " -w -D INPUT --source '!192.168.122.1' --jump REJECT\n"
IPTABLES " -w -D INPUT --source 192.168.122.255 --jump REJECT\n"
IPTABLES " -w -D INPUT --source '!192.168.122.1' --jump REJECT\n";
virCommandSetDryRun: Rework resetting of the dry run data While virCommandSetDryRun is used in tests only, there were some cases when error paths would not call the function with NULL arguments to reset the dry run infrastructure. Introduce virCommandDryRunToken type which must be allocated via virCommandDryRunTokenNew and passed to virCommandSetDryRun. This way we can use automatic variable cleaning to trigger the cleanup of virCommandSetDryRun parameters and also the use of the token variable ensures that all callers of virCommandSetDryRun clean up after themselves and also that the token isn't left unused in the code. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2021-04-01 15:54:09 +00:00
g_autoptr(virCommandDryRunToken) dryRunToken = virCommandDryRunTokenNew();
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: remove firewalld backend tests from virfirewalltest.c When libvirt added support for firewalld, all iptables/ebtables rules were added via the firewalld "passthrough" API when firewalld was enabled (the "firewalld backend"), or run directly by libvirt when firewalld was disabled (the so-called "direct backend"). virfirewalltest.c dutifully ran each test twice, once with the each backend enabled. But commit b19863640d changed the code to *always* directly run iptables/ebtables commands, and never use the firewalld passthrough API, effectively making the direct and firewalld backends identical, except that when libvirt receives notice that firewalld has restarted or reloaded its rules, the firewalld backend sends an extra "iptables -V" command via firewalld's passthrough API (and waits for a response) prior to running all the rest of the iptables commands directly; this assures that a newly-restarted firewalld has finished its work on the filter tables before libvirt starts messing with it. (Because this code is only executed in response to an event from dbus, it isn't tested in the unit tests). In spite of this, we still go through all the virfirewall tests twice though - once for the direct backend, and once for the firewalld backend, even though these take the same codepath. In commit b19863640d I had left this double-testing in thinking that someday we might go back to actually doing something useful with the firewalld backend in the course of adding support for native nftables, but I've now realized that for the case of nftables we will be *even more* divorced from firewalld, so there is really no point in keeping this code around any longer. (It's likely/probable that the tests will be done twice again in the future, but it will be enough different that it is better to remove this code and re-implement from scratch when adding the nftables backend, rather than trying to directly modify the existing code and end up with something even more confusing). This patch eliminates all the test duplication in virfirewalltest.c, including mocking dbus, which is unnecessary since none of the tests use dbus (for now we ensure that by explicitly setting the virfirewall backend to DIRECT before any of the tests have run. Eventually the concept of a "firewalld backend" will disappear completely, but that's for another patch.) Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-14 20:50:26 +00:00
virCommandSetDryRun(dryRunToken, &cmdbuf, false, false, testFirewallRollbackHook, 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
virFirewallStartTransaction(fw, 0);
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
"--source", "192.168.122.1",
"--jump", "ACCEPT", 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
virFirewallStartRollback(fw, 0);
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-D", "INPUT",
"--source", "192.168.122.1",
"--jump", "ACCEPT", 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
virFirewallStartTransaction(fw, 0);
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
"--source", "192.168.122.127",
"--jump", "REJECT", 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
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
"--source", "!192.168.122.1",
"--jump", "REJECT", 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
virFirewallStartRollback(fw, 0);
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-D", "INPUT",
"--source", "192.168.122.127",
"--jump", "REJECT", 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
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-D", "INPUT",
"--source", "!192.168.122.1",
"--jump", "REJECT", 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
virFirewallStartTransaction(fw, 0);
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
"--source", "192.168.122.255",
"--jump", "REJECT", 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
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
"--source", "!192.168.122.1",
"--jump", "REJECT", 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
virFirewallStartRollback(fw, VIR_FIREWALL_ROLLBACK_INHERIT_PREVIOUS);
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-D", "INPUT",
"--source", "192.168.122.255",
"--jump", "REJECT", 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
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-D", "INPUT",
"--source", "!192.168.122.1",
"--jump", "REJECT", 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
if (virFirewallApply(fw) == 0) {
fprintf(stderr, "Firewall apply unexpectedly worked\n");
tests: remove unnecessary ret variables and cleanup labels Several functions were simplified to remove the only cleanup code at the cleanup label, making it unnecessary. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-15 01:05:32 +00:00
return -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
}
actual = virBufferCurrentContent(&cmdbuf);
tests: Use virTestCompareToString() more Instead of using: if (STRNEQ(a, b)) { virTestDifference(stderr, a, b); ... } we can use: if (virTestCompareToString(a, b) < ) { ... } Generated by the following spatch: @@ expression a, b; @@ - if (STRNEQ(a, b)) { + if (virTestCompareToString(a, b) < 0) { ... - virTestDifference(stderr, a, b); ... } and its variations (STRNEQ_NULLABLE() instead of STRNEQ(), then in some cases variables passed to STRNEQ() are in reversed order when compared to virTestCompareToString()). However, coccinelle failed to recognize the pattern in testNWFilterEBIPTablesAllTeardown() so I had to fix it manually. Also, I manually fixed testFormat() in tests/sockettest.c as I didn't bother writing another spatch rule just for that. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
2022-11-30 08:57:49 +00:00
if (virTestCompareToString(expected, actual) < 0) {
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");
tests: remove unnecessary ret variables and cleanup labels Several functions were simplified to remove the only cleanup code at the cleanup label, making it unnecessary. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-15 01:05:32 +00:00
return -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
}
tests: remove unnecessary ret variables and cleanup labels Several functions were simplified to remove the only cleanup code at the cleanup label, making it unnecessary. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-15 01:05:32 +00:00
return 0;
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 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
{
lib: Use $PROG instead of $PROG_PATH Due to the way we detect programs at runtime there's no difference between $PROG and $PROG_PATH macros that come from meson-config.h. Either both are set to the path found during configure or both are set to just "$prog", e.g.: #define EBTABLES "/sbin/ebtables" #define EBTABLES_PATH "/sbin/ebtables" #define FLAKE8 "flake8" #define FLAKE8_PATH "flake8" Change those few places which use _PATH. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-09-14 08:40:42 +00:00
if (STREQ(args[0], IPTABLES) &&
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);
lib: Use $PROG instead of $PROG_PATH Due to the way we detect programs at runtime there's no difference between $PROG and $PROG_PATH macros that come from meson-config.h. Either both are set to the path found during configure or both are set to just "$prog", e.g.: #define EBTABLES "/sbin/ebtables" #define EBTABLES_PATH "/sbin/ebtables" #define FLAKE8 "flake8" #define FLAKE8_PATH "flake8" Change those few places which use _PATH. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-09-14 08:40:42 +00:00
} else if (STREQ(args[0], IPTABLES) &&
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
lib: Drop internal virXXXPtr typedefs Historically, we declared pointer type to our types: typedef struct _virXXX virXXX; typedef virXXX *virXXXPtr; But usefulness of such declaration is questionable, at best. Unfortunately, we can't drop every such declaration - we have to carry some over, because they are part of public API (e.g. virDomainPtr). But for internal types - we can do drop them and use what every other C project uses 'virXXX *'. This change was generated by a very ugly shell script that generated sed script which was then called over each file in the repository. For the shell script refer to the cover letter: https://listman.redhat.com/archives/libvir-list/2021-March/msg00537.html Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2021-03-11 07:16:13 +00:00
testFirewallQueryCallback(virFirewall *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: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, layer,
"-A", "INPUT",
"--source", "!192.168.122.129",
"--jump", "REJECT", 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
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;
util/network: new virFirewallBackend enum (This paragraph is for historical reference only, described only to avoid confusion of past use of the name with its new use) In a past life, virFirewallBackend had been a private static in virfirewall.c that was set at daemon init time, and used to globally (i.e. for all drivers in the daemon) determine whether to directly execute iptables commands, or to run them indirectly via the firewalld passthrough API. This was removed in commit d566cc55, since we decided that using the firewalld passthrough API is never appropriate. Now the same enum, virFirewallBackend, is being reintroduced, with a different meaning and usage pattern. It will be used to pick between using nftables commands or iptables commands (in either case directly handled by libvirt, *not* via firewalld). Additionally, rather than being a static known only within virfirewall.c and applying to all firewall commands for all drivers, each virFirewall object will have its own backend setting, which will be set during virFirewallNew() by the driver who wants to add a firewall rule. This will allow the nwfilter and network drivers to each have their own backend setting, even when they coexist in a single unified daemon. At least as important as that, it will also allow an instance of the network driver to remove iptables rules that had been added by a previous instance, and then add nftables rules for the new instance (in the case that an admin, or possibly an update, switches the driver backend from iptables to nftable) Initially, the enum will only have one usable value - VIR_FIREWALL_BACKEND_IPTABLES, and that will be hardcoded into all calls to virFirewallNew(). The other enum value (along with a method of setting it for each driver) will be added later, when it can be used (when the nftables backend is in the code). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
g_autoptr(virFirewall) fw = virFirewallNew(VIR_FIREWALL_BACKEND_IPTABLES);
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 *actual = NULL;
const char *expected =
lib: Use $PROG instead of $PROG_PATH Due to the way we detect programs at runtime there's no difference between $PROG and $PROG_PATH macros that come from meson-config.h. Either both are set to the path found during configure or both are set to just "$prog", e.g.: #define EBTABLES "/sbin/ebtables" #define EBTABLES_PATH "/sbin/ebtables" #define FLAKE8 "flake8" #define FLAKE8_PATH "flake8" Change those few places which use _PATH. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-09-14 08:40:42 +00:00
IPTABLES " -w -A INPUT --source 192.168.122.1 --jump ACCEPT\n"
IPTABLES " -w -A INPUT --source 192.168.122.127 --jump REJECT\n"
IPTABLES " -w -L\n"
IPTABLES " -w -t nat -L\n"
IPTABLES " -w -A INPUT --source 192.168.122.130 --jump REJECT\n"
IPTABLES " -w -A INPUT --source '!192.168.122.129' --jump REJECT\n"
IPTABLES " -w -A INPUT --source '!192.168.122.129' --jump REJECT\n"
IPTABLES " -w -A INPUT --source 192.168.122.128 --jump REJECT\n"
IPTABLES " -w -A INPUT --source '!192.168.122.1' --jump REJECT\n";
virCommandSetDryRun: Rework resetting of the dry run data While virCommandSetDryRun is used in tests only, there were some cases when error paths would not call the function with NULL arguments to reset the dry run infrastructure. Introduce virCommandDryRunToken type which must be allocated via virCommandDryRunTokenNew and passed to virCommandSetDryRun. This way we can use automatic variable cleaning to trigger the cleanup of virCommandSetDryRun parameters and also the use of the token variable ensures that all callers of virCommandSetDryRun clean up after themselves and also that the token isn't left unused in the code. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2021-04-01 15:54:09 +00:00
g_autoptr(virCommandDryRunToken) dryRunToken = virCommandDryRunTokenNew();
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
expectedLineNum = 0;
expectedLineError = false;
tests: remove firewalld backend tests from virfirewalltest.c When libvirt added support for firewalld, all iptables/ebtables rules were added via the firewalld "passthrough" API when firewalld was enabled (the "firewalld backend"), or run directly by libvirt when firewalld was disabled (the so-called "direct backend"). virfirewalltest.c dutifully ran each test twice, once with the each backend enabled. But commit b19863640d changed the code to *always* directly run iptables/ebtables commands, and never use the firewalld passthrough API, effectively making the direct and firewalld backends identical, except that when libvirt receives notice that firewalld has restarted or reloaded its rules, the firewalld backend sends an extra "iptables -V" command via firewalld's passthrough API (and waits for a response) prior to running all the rest of the iptables commands directly; this assures that a newly-restarted firewalld has finished its work on the filter tables before libvirt starts messing with it. (Because this code is only executed in response to an event from dbus, it isn't tested in the unit tests). In spite of this, we still go through all the virfirewall tests twice though - once for the direct backend, and once for the firewalld backend, even though these take the same codepath. In commit b19863640d I had left this double-testing in thinking that someday we might go back to actually doing something useful with the firewalld backend in the course of adding support for native nftables, but I've now realized that for the case of nftables we will be *even more* divorced from firewalld, so there is really no point in keeping this code around any longer. (It's likely/probable that the tests will be done twice again in the future, but it will be enough different that it is better to remove this code and re-implement from scratch when adding the nftables backend, rather than trying to directly modify the existing code and end up with something even more confusing). This patch eliminates all the test duplication in virfirewalltest.c, including mocking dbus, which is unnecessary since none of the tests use dbus (for now we ensure that by explicitly setting the virfirewall backend to DIRECT before any of the tests have run. Eventually the concept of a "firewalld backend" will disappear completely, but that's for another patch.) Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-14 20:50:26 +00:00
virCommandSetDryRun(dryRunToken, &cmdbuf, false, false, testFirewallQueryHook, 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
virFirewallStartTransaction(fw, 0);
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
"--source", "192.168.122.1",
"--jump", "ACCEPT", 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
virFirewallStartTransaction(fw, 0);
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
"--source", "192.168.122.127",
"--jump", "REJECT", NULL);
virFirewallAddCmdFull(fw, VIR_FIREWALL_LAYER_IPV4,
false,
testFirewallQueryCallback,
NULL,
"-L", NULL);
virFirewallAddCmdFull(fw, VIR_FIREWALL_LAYER_IPV4,
false,
testFirewallQueryCallback,
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
"-t", "nat", "-L", NULL);
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
"--source", "192.168.122.130",
"--jump", "REJECT", 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
virFirewallStartTransaction(fw, 0);
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
"--source", "192.168.122.128",
"--jump", "REJECT", 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
util: change name of virFirewallRule to virFirewallCmd These objects aren't rules, they are commands that are executed that may create a firewall rule, delete a firewall rule, or simply list the existing firewall rules. It's confusing for the objects to be called "Rule" (especially in the case of the function virFirewallRemoveRule(), which doesn't remove a rule from the firewall, it takes one of the objects out of the list of commands to execute! In order to remove a rule from the host's firewall, you have to Add a "rule" (now "cmd" aka command) to the list that will, when applied/run, remove a rule from the host firewall.) Changing the name to virFirewallCmd makes it all much less confusing. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-04-20 02:19:42 +00:00
virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4,
"-A", "INPUT",
"--source", "!192.168.122.1",
"--jump", "REJECT", 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
if (virFirewallApply(fw) < 0)
tests: remove unnecessary ret variables and cleanup labels Several functions were simplified to remove the only cleanup code at the cleanup label, making it unnecessary. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-15 01:05:32 +00:00
return -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
actual = virBufferCurrentContent(&cmdbuf);
if (expectedLineError) {
fprintf(stderr, "Got some unexpected query data\n");
tests: remove unnecessary ret variables and cleanup labels Several functions were simplified to remove the only cleanup code at the cleanup label, making it unnecessary. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-15 01:05:32 +00:00
return -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
}
tests: Use virTestCompareToString() more Instead of using: if (STRNEQ(a, b)) { virTestDifference(stderr, a, b); ... } we can use: if (virTestCompareToString(a, b) < ) { ... } Generated by the following spatch: @@ expression a, b; @@ - if (STRNEQ(a, b)) { + if (virTestCompareToString(a, b) < 0) { ... - virTestDifference(stderr, a, b); ... } and its variations (STRNEQ_NULLABLE() instead of STRNEQ(), then in some cases variables passed to STRNEQ() are in reversed order when compared to virTestCompareToString()). However, coccinelle failed to recognize the pattern in testNWFilterEBIPTablesAllTeardown() so I had to fix it manually. Also, I manually fixed testFormat() in tests/sockettest.c as I didn't bother writing another spatch rule just for that. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
2022-11-30 08:57:49 +00:00
if (virTestCompareToString(expected, actual) < 0) {
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");
tests: remove unnecessary ret variables and cleanup labels Several functions were simplified to remove the only cleanup code at the cleanup label, making it unnecessary. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-15 01:05:32 +00:00
return -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
}
tests: remove unnecessary ret variables and cleanup labels Several functions were simplified to remove the only cleanup code at the cleanup label, making it unnecessary. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-15 01:05:32 +00:00
return 0;
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
}
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
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;
tests: remove firewalld backend tests from virfirewalltest.c When libvirt added support for firewalld, all iptables/ebtables rules were added via the firewalld "passthrough" API when firewalld was enabled (the "firewalld backend"), or run directly by libvirt when firewalld was disabled (the so-called "direct backend"). virfirewalltest.c dutifully ran each test twice, once with the each backend enabled. But commit b19863640d changed the code to *always* directly run iptables/ebtables commands, and never use the firewalld passthrough API, effectively making the direct and firewalld backends identical, except that when libvirt receives notice that firewalld has restarted or reloaded its rules, the firewalld backend sends an extra "iptables -V" command via firewalld's passthrough API (and waits for a response) prior to running all the rest of the iptables commands directly; this assures that a newly-restarted firewalld has finished its work on the filter tables before libvirt starts messing with it. (Because this code is only executed in response to an event from dbus, it isn't tested in the unit tests). In spite of this, we still go through all the virfirewall tests twice though - once for the direct backend, and once for the firewalld backend, even though these take the same codepath. In commit b19863640d I had left this double-testing in thinking that someday we might go back to actually doing something useful with the firewalld backend in the course of adding support for native nftables, but I've now realized that for the case of nftables we will be *even more* divorced from firewalld, so there is really no point in keeping this code around any longer. (It's likely/probable that the tests will be done twice again in the future, but it will be enough different that it is better to remove this code and re-implement from scratch when adding the nftables backend, rather than trying to directly modify the existing code and end up with something even more confusing). This patch eliminates all the test duplication in virfirewalltest.c, including mocking dbus, which is unnecessary since none of the tests use dbus (for now we ensure that by explicitly setting the virfirewall backend to DIRECT before any of the tests have run. Eventually the concept of a "firewalld backend" will disappear completely, but that's for another patch.) Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-14 20:50:26 +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
do { \
tests: remove firewalld backend tests from virfirewalltest.c When libvirt added support for firewalld, all iptables/ebtables rules were added via the firewalld "passthrough" API when firewalld was enabled (the "firewalld backend"), or run directly by libvirt when firewalld was disabled (the so-called "direct backend"). virfirewalltest.c dutifully ran each test twice, once with the each backend enabled. But commit b19863640d changed the code to *always* directly run iptables/ebtables commands, and never use the firewalld passthrough API, effectively making the direct and firewalld backends identical, except that when libvirt receives notice that firewalld has restarted or reloaded its rules, the firewalld backend sends an extra "iptables -V" command via firewalld's passthrough API (and waits for a response) prior to running all the rest of the iptables commands directly; this assures that a newly-restarted firewalld has finished its work on the filter tables before libvirt starts messing with it. (Because this code is only executed in response to an event from dbus, it isn't tested in the unit tests). In spite of this, we still go through all the virfirewall tests twice though - once for the direct backend, and once for the firewalld backend, even though these take the same codepath. In commit b19863640d I had left this double-testing in thinking that someday we might go back to actually doing something useful with the firewalld backend in the course of adding support for native nftables, but I've now realized that for the case of nftables we will be *even more* divorced from firewalld, so there is really no point in keeping this code around any longer. (It's likely/probable that the tests will be done twice again in the future, but it will be enough different that it is better to remove this code and re-implement from scratch when adding the nftables backend, rather than trying to directly modify the existing code and end up with something even more confusing). This patch eliminates all the test duplication in virfirewalltest.c, including mocking dbus, which is unnecessary since none of the tests use dbus (for now we ensure that by explicitly setting the virfirewall backend to DIRECT before any of the tests have run. Eventually the concept of a "firewalld backend" will disappear completely, but that's for another patch.) Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-14 20:50:26 +00:00
if (virTestRun(name, method, NULL) < 0) \
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
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)
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;
}
tests: remove firewalld backend tests from virfirewalltest.c When libvirt added support for firewalld, all iptables/ebtables rules were added via the firewalld "passthrough" API when firewalld was enabled (the "firewalld backend"), or run directly by libvirt when firewalld was disabled (the so-called "direct backend"). virfirewalltest.c dutifully ran each test twice, once with the each backend enabled. But commit b19863640d changed the code to *always* directly run iptables/ebtables commands, and never use the firewalld passthrough API, effectively making the direct and firewalld backends identical, except that when libvirt receives notice that firewalld has restarted or reloaded its rules, the firewalld backend sends an extra "iptables -V" command via firewalld's passthrough API (and waits for a response) prior to running all the rest of the iptables commands directly; this assures that a newly-restarted firewalld has finished its work on the filter tables before libvirt starts messing with it. (Because this code is only executed in response to an event from dbus, it isn't tested in the unit tests). In spite of this, we still go through all the virfirewall tests twice though - once for the direct backend, and once for the firewalld backend, even though these take the same codepath. In commit b19863640d I had left this double-testing in thinking that someday we might go back to actually doing something useful with the firewalld backend in the course of adding support for native nftables, but I've now realized that for the case of nftables we will be *even more* divorced from firewalld, so there is really no point in keeping this code around any longer. (It's likely/probable that the tests will be done twice again in the future, but it will be enough different that it is better to remove this code and re-implement from scratch when adding the nftables backend, rather than trying to directly modify the existing code and end up with something even more confusing). This patch eliminates all the test duplication in virfirewalltest.c, including mocking dbus, which is unnecessary since none of the tests use dbus (for now we ensure that by explicitly setting the virfirewall backend to DIRECT before any of the tests have run. Eventually the concept of a "firewalld backend" will disappear completely, but that's for another patch.) Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-11-14 20:50:26 +00:00
VIR_TEST_MAIN_PRELOAD(mymain, VIR_TEST_MOCK("virfirewall"))
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