We will need access to these attributes of the object from outside
virfirewall.c.
Signed-off-by: Laine Stump
---
src/libvirt_private.syms | 3 +++
src/util/virfirewall.c | 30 ++
src/util/virfirewall.h | 10 ++
3 files changed, 43 insertions(+)
diff
Long long ago (commit fd5b15ff in July 2010), we determined that the
combination of virtio-net + vhost packet handling (i.e. handling
packets in the kernel rather than userspace) + very old guest OSes
(e.g. RHEL5, but not even RHEL6) would result in the checksum of dhcp
packets being unset, which
These function are all moved into virnetfilter.[ch]. The only
functions from viriptables.[ch] that are still called from the
consumer (network bridge driver) are iptablesSetupPrivateChains()
(which creates the private chains that all iptables rules will be
added to), and
We know at the time a virFirewallRule is created (with
virFirewallAddRule*()) whether or not we will later want to ignore
errors encountered when attempting to apply that rule - if
ignoreErrors is set in the AddRule or if the group has already had
VIR_FIREWALL_TRANSACTION_IGNORE_ERRORS set, then
It still can have only one useful value ("iptables"), but once a 2nd
value is supported, it will be selectable by setting
"firewall_backend=nftables" in /etc/libvirt/network.conf.
If firewall_backend isn't set in network.conf, then libvirt will check
to see if the iptables binary is present on
In the past virFirewall required all rollback rules for a group (those
commands necessary to "undo" any rules that had been added in that
group in case of a later failure) to be manually added by switching
into "rollback mode" and then re-calling the inverse of the exact
virFirewallAddRule*() APIs
We will already need a separate function for virFirewallApplyRule for
iptables vs. nftables, but the only reason for needing a separate
function for virFirewallAddRule* is that iptables/ebtables need to
have an extra arg added for locking (to prevent multiple iptables
commands from running at the
These functions convert a virFirewall object to/from XML so that it
can be serialized to disk (in a virNetworkObj's status file) and
restored later (e.g. after libvirtd/virtnetworkd is restarted).
Signed-off-by: Laine Stump
---
src/libvirt_private.syms | 2 +
src/util/virfirewall.c | 220
Determining the correct rollback rule for nftables is more complicated
than iptables - nftables give each new table/chain/rule a handle, and
the nft delete command to delete the object must contain that handle
(rather than just replicating the entire original commandline as is
done for iptables).
Run all the networkxml2firewall tests twice - once with iptables
backend, and once with the nftables backend.
The results files for the existing iptables tests were previously
named *.args. That has been changed to *.iptables, and the results
files for the new nftables tests are named *.nftables.
This patch series enables libvirt to use nftables rules rather than
iptables *when setting up virtual networks* (it does *not* add
nftables support to the nwfilter driver). It accomplishes this by
abstracting several iptables functions (from viriptables.[ch] called
by the virtual network driver
Many of the functions in virnetfilter.c are nearly identical to one or
more other functions (e.g. they just call the same iptables function,
but with INSERT|DELETE action). Rather than adding a switch(backend)
into all 24 of these functions, make small wrappers for the 10
iptables* functions that
These toplevel functions have no iptables-specific code, except that
they each call a lower-level internal function that *is* iptables
specific. As a preparation to supporting use of either iptables or
nftables, rename these functions from iptablesXXX to virNetfilterXXX.
Signed-off-by: Laine
When destroying a network, the network driver has always assumed that
it knew what firewall rules had been added as the network was
started. This was usually correct, but if the exact rules used for a
network were ever changed from one build/version of libvirt to
another, then we would end up
Signed-off-by: Laine Stump
---
src/conf/virnetworkobj.c| 1 +
src/network/bridge_driver.c | 8 +++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/conf/virnetworkobj.c b/src/conf/virnetworkobj.c
index ae26f6fab1..ce39ab5250 100644
--- a/src/conf/virnetworkobj.c
+++
This is the only iptables-specific function in all of
virfirewall.c. By moving it to viriptables.c (with appropriate
renaming), and calling it indirectly through a similarly named wrapper
function in virnetfilter.c, we have made virfirewall.c backend
agnostic (the new wrapper function will soon be
This is done so that we can be sure we're using the same chain name
for iptables and nftables. Not strictly necessary, but it will make
documentation and troubleshooting simpler.
Signed-off-by: Laine Stump
---
src/util/viriptables.c | 44 -
virFirewallNewFromRollback() creates a new virFirewall object that
contains a copy of the "rollback" rules from an existing virFirewall
object, but in reverse order. The intent is that this virFirewall be
saved and used later to remove the firewall rules that were added for
a network.
So far this will only affect what happens if there is some failure
while applying the firewall rules; the rollback rules aren't yet
persistent beyond that time. More work is needed to remember the
rollback rules while the network is active, and use those rules to
remove the firewall for the
This virFirewall object will store the list of actions required to
remove the firewall that was added for the currently active instance
of the network, so it has been named "fwRemoval".
There are no uses of the fwRemoval object in the virNetworkObj yet,
but everything is in place to add it to the
Instead of calling iptableSetupPrivateChains(), the network driver now
calls virNetfilterSetupPrivateChains() (which right now always calls
the iptables version of the function, but in the future might instead
call the nftables version).
virNetFilterSetupPrivateChains() needs an argument to know
Signed-off-by: Laine Stump
---
libvirt.spec.in | 3 ++
src/network/libvirtd_network.aug | 36
src/network/meson.build | 11
src/network/network.conf | 3 ++
and include it in BuildRequires and Requires of the rpm specfile to
make sure it's available when doing official distro builds.
Signed-off-by: Laine Stump
---
libvirt.spec.in | 2 ++
meson.build | 1 +
2 files changed, 3 insertions(+)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index
In the past, virFirewallBackend was 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 normal practice a firewall rule should never have 0 args by the
time it gets to the Apply stage, but at some time while debugging
auto-rollback exactly that happened (due to a bug that was since
squashed), and having a check for it helped debugging, so let's
permanently check for it (the
It's not always iptables rules that are being reloaded, could be
nftables. Also the message previously didn't clarify that this is only
reloading the rules for active virtual networks (and not for nwfilter,
for example).
Signed-off-by: Laine Stump
---
src/network/bridge_driver.c | 2 +-
1 file
and take advantage of this to replace all the ternary operators when
calling virFirewallAddRule() with virIptablesActionTypeToString().
(NB: the VIR_ENUM declaration uses "virIptablesAction" rather than
"virFirewallAction" because the string it produces is specific to the
iptables backend. A
Signed-off-by: Laine Stump
---
po/POTFILES | 1 +
src/network/bridge_driver_conf.c | 4 +
src/network/network.conf | 17 +-
src/util/meson.build | 1 +
src/util/virfirewall.c | 3 +-
src/util/virfirewall.h | 1 +
This isn't yet used anywhere, since
VIR_FIREWALL_TRANSACTION_AUTO_ROLLBACK isn't being set.
Signed-off-by: Laine Stump
---
src/util/viriptables.c | 49 +++---
1 file changed, 46 insertions(+), 3 deletions(-)
diff --git a/src/util/viriptables.c
29 matches
Mail list logo
