From nobody Wed May 8 01:52:32 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) client-ip=209.132.183.28; envelope-from=libvir-list-bounces@redhat.com; helo=mx1.redhat.com; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1552293530766734.279753761358; Mon, 11 Mar 2019 01:38:50 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BA9293082E58; Mon, 11 Mar 2019 08:38:48 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5C8A3648AB; Mon, 11 Mar 2019 08:38:48 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 5F813249A1; Mon, 11 Mar 2019 08:38:47 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id x2B8c32T029523 for ; Mon, 11 Mar 2019 04:38:03 -0400 Received: by smtp.corp.redhat.com (Postfix) id 850365D70E; Mon, 11 Mar 2019 08:38:03 +0000 (UTC) Received: from moe.brq.redhat.com (unknown [10.43.2.30]) by smtp.corp.redhat.com (Postfix) with ESMTP id 095B75D706 for ; Mon, 11 Mar 2019 08:38:00 +0000 (UTC) From: Michal Privoznik To: libvir-list@redhat.com Date: Mon, 11 Mar 2019 09:37:52 +0100 Message-Id: <534ca7e33c367e8133775e32c77f75fe46263cd8.1552293274.git.mprivozn@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH] iptablesSetupPrivateChains: Be forgiving if a table does not exist X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.46]); Mon, 11 Mar 2019 08:38:49 +0000 (UTC) Content-Type: text/plain; charset="utf-8" The way this function works is that for both iptables and ip6tables (or their firewalld friends) and for every table ("filter", "nat", "mangle") it lists chains defined for the table and then calls iptablesPrivateChainCreate() over the list. The callback is then supposed to find libvirt private chains and if not found create rules to add them. So far so good. Problem is if one of the tables doesn't exist (e.g. due to a module missing). For instance, on my system I don't have CONFIG_IP6_NF_MANGLE enabled therefore I'm lacking "mangle" table for ip6tables. This means that the whole operation of setting up private chains fails because the whole transaction is run as "do not ignore errors". The solution is to have two transactions, the first one which just lists chains can run ignoring errors, and the second one which then installs the private chains will run normally. In the code, this approach is pushed to another level - every table for which private chains are created is run as a separate transaction. The reason is that it saves us one more variable where we would track if the second transaction was started already or not; and also, it doesn't matter. Signed-off-by: Michal Privoznik --- src/util/viriptables.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/src/util/viriptables.c b/src/util/viriptables.c index d67b640a3b..ea24b03ec8 100644 --- a/src/util/viriptables.c +++ b/src/util/viriptables.c @@ -101,6 +101,16 @@ iptablesPrivateChainCreate(virFirewallPtr fw, tmp++; } =20 + /* This function is running in the context of the very first transacti= on, + * which does nothing more than just lists current tables and chains. = But + * since some tables might not be there (e.g. because of a module miss= ing), + * the transaction is run with IGNORE_ERRORS flag. But obviously, we d= on't + * want to ignore errors here, where we are constructing our own chain= s and + * rules. The only way to resolve this is to start a new transaction so + * that all those AddRule() calls below add rules to new transaction/g= roup. + */ + virFirewallStartTransaction(fw, 0); + for (i =3D 0; i < data->nchains; i++) { const char *from; if (!virHashLookup(chains, data->chains[i].child)) { @@ -160,7 +170,7 @@ iptablesSetupPrivateChains(void) =20 fw =3D virFirewallNew(); =20 - virFirewallStartTransaction(fw, 0); + virFirewallStartTransaction(fw, VIR_FIREWALL_TRANSACTION_IGNORE_ERRORS= ); =20 for (i =3D 0; i < ARRAY_CARDINALITY(data); i++) virFirewallAddRuleFull(fw, data[i].layer, --=20 2.19.2 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list