From nobody Sun Sep 7 23:51:05 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.libvirt.org designates 8.43.85.245 as permitted sender) client-ip=8.43.85.245; envelope-from=devel-bounces@lists.libvirt.org; helo=lists.libvirt.org; Authentication-Results: mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of lists.libvirt.org designates 8.43.85.245 as permitted sender) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=fail(p=none dis=none) header.from=canonical.com Return-Path: Received: from lists.libvirt.org (lists.libvirt.org [8.43.85.245]) by mx.zohomail.com with SMTPS id 1755629298462570.7399468413889; Tue, 19 Aug 2025 11:48:18 -0700 (PDT) Received: by lists.libvirt.org (Postfix, from userid 996) id 5ED68E72; Tue, 19 Aug 2025 14:48:17 -0400 (EDT) Received: from lists.libvirt.org (localhost [IPv6:::1]) by lists.libvirt.org (Postfix) with ESMTP id 60E73E6B; Tue, 19 Aug 2025 14:47:10 -0400 (EDT) Received: by lists.libvirt.org (Postfix, from userid 996) id 5BE83E39; Tue, 19 Aug 2025 14:47:07 -0400 (EDT) Received: from smtp-relay-canonical-0.canonical.com (smtp-relay-canonical-0.canonical.com [185.125.188.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.libvirt.org (Postfix) with ESMTPS id 77114D3D for ; Tue, 19 Aug 2025 14:47:03 -0400 (EDT) Received: from pchector.. (unknown [171.251.54.92]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-canonical-0.canonical.com (Postfix) with ESMTPSA id 9E7593FA64 for ; Tue, 19 Aug 2025 18:47:00 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on lists.libvirt.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED, SPF_HELO_NONE autolearn=unavailable autolearn_force=no version=3.4.4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1755629221; bh=WC/aZJ22qC49KRWw8k8Y4QrY6gP5LshNOhjT65NdPWo=; h=From:To:Subject:Date:Message-Id:MIME-Version; b=QNVC1LGcK9lOSOMdG+nne2qlrTmPdMkELykjk7NgtQGVKIMko3SfKVJ8fwyFb9jIE lCJXf6huq/qVEBGExgWU7iT2YGxTXmJcWn05qvD9VSxJIq/aN2s5/ESLxH2JEz7I3n MDu3rKne2hvuRYL/TS3beR+4ADD9AIwnceyz/JUZWmsIi5cno+OuUH+81/86bYdONg zToAZFHomMS4dyT1B3IReBNsbTkVvD7SsmZYSwOd4OSKQ3+HmfMXWwhWtCRpO0V4Q/ EMD0uvZruJe/FqdZGBmghKPllWcpQbZT38sQwF3nQZV4a6JKdF9W9Czg2B5a0xpK3w 8dD+R4MPo15Iw== From: Hector CAO To: devel@lists.libvirt.org Subject: [PATCH] virt-aa-helper: Avoid duplicate when append rule Date: Tue, 19 Aug 2025 20:46:54 +0200 Message-Id: <20250819184654.29083-1-hector.cao@canonical.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: 2HIZC2EK72NBLMCNGT54XIVGJEGG7YNN X-Message-ID-Hash: 2HIZC2EK72NBLMCNGT54XIVGJEGG7YNN X-MailFrom: hector.cao@canonical.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-config-1; header-match-config-2; header-match-config-3; header-match-devel.lists.libvirt.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header X-Mailman-Version: 3.2.2 Precedence: list List-Id: Development discussions about the libvirt library & tools Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-ZohoMail-DKIM: fail (Computed bodyhash is different from the expected one) X-ZM-MESSAGEID: 1755629300381116600 Content-Type: text/plain; charset="utf-8" From: Hector Cao when a device is dynamically attached to a VM, and it needs a special system access for apparmor, libvirt calls virt-aa-helper (with argument -F) to append a new rule to the apparmor profile of the VM. virt-aa-helper does not check for duplicate and blindly appends the rule to the profile. since there is no rule removal when a device is detached, this can make the profi= le grow in size if a big number of attach/detach operations are done and the profile might hit the size limit and futur attach operations might dysfunct= ion because no rule can be added into the apparmor profile. this patch tries to mitigate this issue by doing a duplicate check when rules are appended into the profile. this fix does not guarantee the absence of duplicates but should be enough to prevent the profile to grow significantly in size and reach its size limit. Signed-off-by: Hector CAO --- src/security/virt-aa-helper.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/src/security/virt-aa-helper.c b/src/security/virt-aa-helper.c index b662d971cb..a003c6dd9e 100644 --- a/src/security/virt-aa-helper.c +++ b/src/security/virt-aa-helper.c @@ -208,9 +208,20 @@ update_include_file(const char *include_file, const ch= ar *included_files, return -1; } =20 - if (append && virFileExists(include_file)) - pcontent =3D g_strdup_printf("%s%s", existing, included_files); - else + if (append && virFileExists(include_file)) { + /* duplicate check: include_files might contain multiple rules + * the best is to check for each rule (separated by \n) but + * it might be overkilled, just do the check for the whole + * include_files. + * most of the time, include_files contains only one rule + * so this check is ok to avoid the overflow of the profile + * duplicates might still exist though. + */ + if (!strstr(existing, included_files)) { + pcontent =3D g_strdup_printf("%s%s", existing, included_files); + } else + pcontent =3D g_strdup(existing); + } else pcontent =3D g_strdup_printf("%s%s", warning, included_files); =20 plen =3D strlen(pcontent); --=20 2.34.1