On Wed, Mar 02, 2022 at 11:34:56AM +0300, Nikolay Shirokovskiy wrote:
In order to delete or rename tree of chains in netfilter we use
generic
code that inspect current state of netfilter and traverse the tree
accordingly. I found the way traverse is done a bit hard to think about.
As an example I'll take ebtable rules generated by
ebiptablesTearOldRules for input chains only. Common arguments like '-t
nat' and '--concurrent' are also filtered. To illustrate the point
libvirt-I-vnet1 has one subchain I-vnet1-mac.
Let's look at ebtablesRemoveSubChainsFW[1] work. It make a recursive
deletion of chains. I marked below the ebtables calls that it generates
in the whole list of commands that generates ebiptablesTearOldRules. One
can see that the rules perplex with the ebtablesRenameTmpSubAndRootChainsFW[2]
rules and this looks a bit hard to manage. I'd prefer that the order of
ebtables commands will be aligned with code.
ebtables -D PREROUTING -i vnet1 -j libvirt-I-vnet1
ebtables -L libvirt-I-vnet1 # listing to detect subchains[1]
ebtables -F libvirt-I-vnet1
ebtables -X libvirt-I-vnet1
ebtables -L libvirt-J-vnet1 # [2]
ebtables -E libvirt-J-vnet1 libvirt-I-vnet1 # [2]
ebtables -L I-vnet1-mac # listing to detect subchains[1]
ebtables -F I-vnet1-mac # flushing to unlink subchains[1]
ebtables -X I-vnet1-mac # deleting chain itself[1]
ebtables -L J-vnet1-mac # [2]
ebtables -F I-vnet1-mac # [2]
ebtables -X I-vnet1-mac # [2]
ebtables -E J-vnet1-mac I-vnet1-mac # [2]
Notice also that we need to flush libvirt-I-vnet1 to unlink subchains in
order to be able to delete them. And again code look like reversed:
ebtablesRemoveSubChainsFW(fw, ifname);
ebtablesRemoveRootChainFW(fw, true, ifname);
ebtablesRemoveRootChainFW(fw, false, ifname);
This is because ebtablesRemoveSubChainsFW only adds listing call and
makes actual subchains cleanup in the the process of virFirewallApply.
So to make it more manageble/straightforward I propose here to list and
add resulted commands inplace. Note that in the process we need:
1. Move ebtablesRemoveTmpRootChainFW rules to the _ebtablesRemoveSubChainsFW
to keep correct order - first flush parent and then delete subchains.
2. Avoid using virFirewallStartRollback as otherwise there will be
unnesseary listing call done in ebtablesRemoveTmpSubChainsFW.
The fact we can't use virFirewallStartRollback in this approach can be
seen as a donwside. However it is not a real rollback - you need to code
all the steps to rollback on you own so it can be easily replaced by
same virFirewallApply. Not only in this place but in all the other places.
Now compare the commands order in ebiptablesTearOldRules after patch:
ebtables -L libvirt-I-vnet1 # listing to detect subchains [1]
ebtables -L I-vnet1-mac # listing to detect subchains [1]
ebtables -D PREROUTING -i vnet1 -j libvirt-I-vnet1
ebtables -F libvirt-I-vnet1 # flushing and deleting of chain [1]
ebtables -X libvirt-I-vnet1
ebtables -F I-vnet1-mac # flushing and deleting of subchain [1]
ebtables -X I-vnet1-mac
ebtables -L libvirt-J-vnet1
ebtables -E libvirt-J-vnet1 libvirt-I-vnet1
ebtables -L J-vnet1-mac
ebtables -F I-vnet1-mac
ebtables -X I-vnet1-mac
ebtables -E J-vnet1-mac I-vnet1-mac
Notice that listing commands from ebtablesRemoveSubChainsFW pop up to
the top of the list. This may seen again as perplexing but it is of
a different kind. It only moves nonmodifying listing commands to the top
which does not perplexing understanding command flow much. Also if the
calls will be optimized we have only one listing command on the
top.
---
src/nwfilter/nwfilter_ebiptables_driver.c | 154 +++++++++++-----------
1 file changed, 75 insertions(+), 79 deletions(-)
diff --git a/src/nwfilter/nwfilter_ebiptables_driver.c
b/src/nwfilter/nwfilter_ebiptables_driver.c
index 54065a0f75..6952ebc059 100644
--- a/src/nwfilter/nwfilter_ebiptables_driver.c
+++ b/src/nwfilter/nwfilter_ebiptables_driver.c
@@ -148,6 +148,42 @@ static char chainprefixes_host_temp[3] = {
0
};
+
+static int
+ebiptablesQueryCallback(virFirewall *fw G_GNUC_UNUSED,
+ virFirewallLayer layer G_GNUC_UNUSED,
+ const char *const *lines,
+ void *opaque)
+{
+ GStrv *capture = opaque;
+
+ *capture = g_strdupv((gchar **)lines);
+ return 0;
+}
+
+
+static GStrv
+ebiptablesQuery(virFirewallLayer layer,
+ ...)
+{
+ g_autoptr(virFirewall) fw = virFirewallNew();
+ g_auto(GStrv) capture = NULL;
+ va_list args;
+
+ virFirewallStartTransaction(fw, 0);
+
+ va_start(args, layer);
+ virFirewallAddRuleFullV(fw, layer, true,
+ ebiptablesQueryCallback, &capture, args);
+ va_end(args);
+
+ if (virFirewallApply(fw) < 0)
+ return NULL;
+
+ return g_steal_pointer(&capture);
+}
This method illustrates why we didn't take this approach in the
first place. The intention of the current design is to have
clean separation between deciding what iptables commands to
invoke, and when we actually invoke them.
This breaks that separation, because now in the middle of
populating the virFirewall rules we want to run, we have
to actually invoke the firewall tools multiple times to
query current state.
@@ -2649,10 +2644,9 @@ static int
ebtablesRemoveSubChainsQuery(virFirewall *fw,
virFirewallLayer layer,
const char *const *lines,
- void *opaque)
+ const char *chainprefixes)
{
size_t i, j;
- const char *chainprefixes = opaque;
for (i = 0; lines[i] != NULL; i++) {
char *tmp = strstr(lines[i], "-j ");
@@ -2665,17 +2659,21 @@ ebtablesRemoveSubChainsQuery(virFirewall *fw,
for (j = 0; chainprefixes[j]; j++) {
if (tmp[0] == chainprefixes[j] &&
tmp[1] == '-') {
+ g_auto(GStrv) capture = NULL;
+
VIR_DEBUG("Processing chain '%s'", tmp);
- virFirewallAddRuleFull(fw, layer,
- false, ebtablesRemoveSubChainsQuery,
- (void *)chainprefixes,
- "-t", "nat", "-L",
tmp, NULL);
+ capture = ebiptablesQuery(layer,
+ "-t", "nat",
"-L", tmp, NULL);
virFirewallAddRuleFull(fw, layer,
true, NULL, NULL,
"-t", "nat", "-F",
tmp, NULL);
virFirewallAddRuleFull(fw, layer,
true, NULL, NULL,
"-t", "nat", "-X",
tmp, NULL);
+ if (capture)
+ ebtablesRemoveSubChainsQuery(fw, layer,
+ (const char *const *)capture,
+ chainprefixes);
}
....here we're still populating the 'fw' object, but actually
also running firewall commands at the same time inside the
ebtablesRemoveSubChainsQuery method.
The current implementation on the backend of virFirewallApply
is not technically transactional, but the intent behind the
design is that we would be able to serialize execution of the
virFirewallApply method. This wouldn't be possible with the
way this patch changes things, as now we're dealing with
multiple virFirewall object instances.
Regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|