[PATCH 0/3] fix #7864: allow pool-scoped privileges to create VMs with tags

[PATCH 0/3] fix #7864: allow pool-scoped privileges to create VMs with tags

[jlcusinato]

Pool-scoped automation can create VMs and containers in its pool, but the
create fails as soon as --tags is passed (403 on /vms/<vmid>,
VM.Config.Options); regressed with commit a929b3e ("vm_create: check tag
permissions if setting tags") in qemu-server and its pve-container
counterpart 7a57f63 ("check_ct_modify_config_perm: check for tags
permissions with 'assert_tag_permissions'").

Root cause and reproducer: bug 7864 [0]. These are the patches already
attached there (code by Felix Winterhalter <felix@ranovus.com>, all three
contributors CCed), posted per the maintainers' request (comment #6);
neither has been active on the bug since September 2026 and the list never
received a posting, hence this submission. crandler's fix for the {} -> ''
defect (comment #5) is rolled into the qemu-server patch; the pve-container
message was corrected after dreadfulbunny's data point (comment #7) showed
that container create is affected too. Provenance is preserved in the
commit messages (Signed-off-by / Reported-by); my individual CLA is on
record with Proxmox (October 2026).

Merge order: pve-guest-common first; qemu-server and pve-container then.
Per-patch notes describe deltas from the Bugzilla versions. Not
runtime-tested (no test node); testing feedback welcome.

[0] https://bugzilla.proxmox.com/show_bug.cgi?id=7864

[PATCH pve-guest-common] fix #7864: guest helpers: allow pool-scoped privileges for tag permission checks

[jlcusinato]

From: Jean-Leon CUSINATO <jlcusinato@neverhack.com>

assert_tag_permissions() hardcoded the pool argument of
check_vm_perm() to undef, so the VM.Config.Options check always
resolved against /vms/$vmid.

That is fine for callers acting on an existing guest, because the
pool ACL is resolved onto /vms/$vmid by
RPCEnvironment::compile_acl_path(). It is not fine while a guest is
being created: at that point the guest is not a member of the pool
yet, so a caller whose privileges come solely from /pool/<pool> has
nothing on /vms/$vmid to match against.

Add an optional $pool parameter and forward it, so callers that know
the target pool can opt in. Existing callers pass no pool and keep
the current behaviour.

Signed-off-by: Felix Winterhalter <felix@ranovus.com>
---

Same code as the Bugzilla attachment (2056), rebased onto current
master. Subject now starts with 'fix #7864:' per the developer
documentation, and the commit message is reflowed to the 72-char
line-width guideline; no semantic changes.

Resend note (submitted by Jean-Léon CUSINATO
<jlcusinato@neverhack.com>):

These patches originate from bug 7864 [0]: code by Felix Winterhalter
<felix@ranovus.com> (the versions attached there, informally reviewed
by a Proxmox maintainer in comment #4, who asked for a posting on this
list) plus crandler's follow-up finding (comment #5) and dreadfulbunny's
data point on the container create path (comment #7). Neither original
author has been active on the bug since September 2026, and the list
never received a posting despite that request, so I am submitting them
here with their attribution intact in the commit messages
(Signed-off-by / Reported-by). All contributors are CCed. My individual
CLA has been submitted to and recorded by Proxmox
(office@proxmox.com, October 2026), who asked for the patches to be
posted here. Not runtime-tested (no test node available); verification
is code-level only. Feedback, especially testing, welcome.

Series merge order: 1) pve-guest-common, then 2) qemu-server and
3) pve-container (the latter two only rely on the new optional $pool
parameter introduced in 1).

[0] https://bugzilla.proxmox.com/show_bug.cgi?id=7864

 src/PVE/GuestHelpers.pm | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/PVE/GuestHelpers.pm b/src/PVE/GuestHelpers.pm
index f8d112b..72da542 100644
--- a/src/PVE/GuestHelpers.pm
+++ b/src/PVE/GuestHelpers.pm
@@ -310,11 +310,15 @@ sub get_allowed_tags {
 # checks the permissions for setting/updating/removing tags for guests
 # tagopt_old and tagopt_new expect the tags as they are in the config
 #
+# $pool is optional and only relevant while the guest is being created, where
+# the guest is not a member of the pool yet, so the pool ACL cannot yet be
+# resolved onto /vms/$vmid. Callers acting on an existing guest can omit it.
+#
 # either returns gracefully or raises a permission exception
 sub assert_tag_permissions {
-    my ($vmid, $tagopt_old, $tagopt_new, $rpcenv, $authuser) = @_;
+    my ($vmid, $tagopt_old, $tagopt_new, $rpcenv, $authuser, $pool) = @_;
 
-    $rpcenv->check_vm_perm($authuser, $vmid, undef, ['VM.Config.Options']);
+    $rpcenv->check_vm_perm($authuser, $vmid, $pool, ['VM.Config.Options']);
 
     my $privileged_user = $rpcenv->check($authuser, '/', ['Sys.Modify'], 1) // 0;
 
-- 
2.56.0

[PATCH qemu-server] fix #7864: api: create vm: honour pool privileges when setting tags

[jlcusinato]

From: Jean-Leon CUSINATO <jlcusinato@neverhack.com>

Commit a929b3e ("vm_create: check tag permissions if setting tags")
started checking tag permissions on the create path, but
assert_tag_permissions() resolved VM.Config.Options against a bare
/vms/$vmid.

At that point the VM is not a pool member yet - add_vm_to_pool()
only runs after $realcmd has written the config - so a user or API
token whose privileges are granted solely on /pool/<pool> fails with

  unable to create VM 1021 - 403 Permission check failed
  (/vms/1021, VM.Config.Options)

even though it is allowed to create the VM in that pool, and even
though every other create-time option honours the pool via
$check_vm_modify_config_perm(). Tags are the only exception, because
they are skipped there and checked separately.

Pass the pool through, matching the surrounding checks. Setting the
same tags in a second config update already worked, so this only
removes the need for the caller to hold VM.Config.Options on all of
/vms.

The old-tags argument passed {} rather than an empty string.
PVE::Tools::split_list() stringifies that reference, so with
'user-allow' set to anything but 'free' a pseudo tag like
'HASH(0x...)' enters the per-tag comparison, which no allow list can
ever hold since the address is fresh on every call:

  403 Permission check failed (/, Sys.Modify for modifying tag
  'HASH(0x5c0c4195ab70)')

Pass an empty string instead, as the delete branch of the
config-update path already does; split_list('') returns an empty
list.

Fixes: a929b3e ("vm_create: check tag permissions if setting tags")
Reported-by: crandler <crandler@crandland.de>
Signed-off-by: Felix Winterhalter <felix@ranovus.com>
Signed-off-by: Jean-Léon CUSINATO <jlcusinato@neverhack.com>
---

Compared to the Bugzilla attachment (2057): the old-tags argument
is '' rather than {} per crandler's finding in comment #5 of the
bug (also CCed) - PVE::Tools::split_list() stringifies a hash
reference, so a 'HASH(0x...)' pseudo tag would enter the per-tag
comparison whenever 'user-allow' is not 'free'. Verified against
current pve-common: split_list('') returns () while split_list({})
yields HASH(0x...). Bug reference #7864 already in the subject;
commit message reflowed to the 72-char line-width guideline;
rebased onto current master.

Resend note (submitted by Jean-Léon CUSINATO
<jlcusinato@neverhack.com>):

These patches originate from bug 7864 [0]: code by Felix Winterhalter
<felix@ranovus.com> (the versions attached there, informally reviewed
by a Proxmox maintainer in comment #4, who asked for a posting on this
list) plus crandler's follow-up finding (comment #5) and dreadfulbunny's
data point on the container create path (comment #7). Neither original
author has been active on the bug since September 2026, and the list
never received a posting despite that request, so I am submitting them
here with their attribution intact in the commit messages
(Signed-off-by / Reported-by). All contributors are CCed. My individual
CLA has been submitted to and recorded by Proxmox
(office@proxmox.com, October 2026), who asked for the patches to be
posted here. Not runtime-tested (no test node available); verification
is code-level only. Feedback, especially testing, welcome.

Series merge order: 1) pve-guest-common, then 2) qemu-server and
3) pve-container (the latter two only rely on the new optional $pool
parameter introduced in 1).

[0] https://bugzilla.proxmox.com/show_bug.cgi?id=7864

 src/PVE/API2/Qemu.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/PVE/API2/Qemu.pm b/src/PVE/API2/Qemu.pm
index f4dbd2a..5789f99 100644
--- a/src/PVE/API2/Qemu.pm
+++ b/src/PVE/API2/Qemu.pm
@@ -1568,7 +1568,7 @@ __PACKAGE__->register_method({
 
                     if (defined $conf->{tags}) {
                         assert_tag_permissions(
-                            $vmid, {}, $conf->{tags}, $rpcenv, $authuser,
+                            $vmid, '', $conf->{tags}, $rpcenv, $authuser, $pool,
                         );
                         $conf->{tags} = PVE::GuestHelpers::get_unique_tags($conf->{tags});
                     }
-- 
2.56.0

[PATCH pve-container] fix #7864: lxc: honour pool privileges when creating containers with tags

[jlcusinato]

From: Jean-Leon CUSINATO <jlcusinato@neverhack.com>

check_ct_modify_config_perm() passes $pool to every other
check_vm_perm() call, but the tags branch called
assert_tag_permissions() without it, so the VM.Config.Options check
always resolved against /vms/$vmid.

Unlike for an existing container, where the pool ACL already resolves
onto /vms/$vmid, the create path is hit: the LXC create API accepts
tags as a config property and hands the raw parameters, including
tags, to check_ct_modify_config_perm() before the container joins the
pool. A caller whose privileges come solely from /pool/<pool>
therefore fails to create containers with tags:

  403 Permission check failed (/vms/<vmid>, VM.Config.Options)

Pass the pool through, matching the neighbouring checks.

Fixes: 7a57f63 ("check_ct_modify_config_perm: check for tags permissions with 'assert_tag_permissions'")
Reported-by: dreadfulbunny <dreadfulbunny@proton.me>
Signed-off-by: Felix Winterhalter <felix@ranovus.com>
---

Compared to the Bugzilla attachment (2058): the 'currently latent'
premise in the original message is wrong - the LXC create API does
accept tags and container create fails the same way (data point in
bug comment #7, 2026-10-27), so the subject now starts with
'fix #7864:' and the message describes the create path;
Fixes:/Reported-by: trailers added. Code identical, rebased onto
current master.

Resend note (submitted by Jean-Léon CUSINATO
<jlcusinato@neverhack.com>):

These patches originate from bug 7864 [0]: code by Felix Winterhalter
<felix@ranovus.com> (the versions attached there, informally reviewed
by a Proxmox maintainer in comment #4, who asked for a posting on this
list) plus crandler's follow-up finding (comment #5) and dreadfulbunny's
data point on the container create path (comment #7). Neither original
author has been active on the bug since September 2026, and the list
never received a posting despite that request, so I am submitting them
here with their attribution intact in the commit messages
(Signed-off-by / Reported-by). All contributors are CCed. My individual
CLA has been submitted to and recorded by Proxmox
(office@proxmox.com, October 2026), who asked for the patches to be
posted here. Not runtime-tested (no test node available); verification
is code-level only. Feedback, especially testing, welcome.

Series merge order: 1) pve-guest-common, then 2) qemu-server and
3) pve-container (the latter two only rely on the new optional $pool
parameter introduced in 1).

[0] https://bugzilla.proxmox.com/show_bug.cgi?id=7864

 src/PVE/LXC.pm | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/PVE/LXC.pm b/src/PVE/LXC.pm
index 44ae4fa..f7c9b5b 100644
--- a/src/PVE/LXC.pm
+++ b/src/PVE/LXC.pm
@@ -1743,7 +1743,9 @@ sub check_ct_modify_config_perm {
         } elsif ($opt eq 'tags') {
             my $old = $oldconf->{$opt};
             my $new = $delete ? '' : $newconf->{$opt};
-            PVE::GuestHelpers::assert_tag_permissions($vmid, $old, $new, $rpcenv, $authuser);
+            PVE::GuestHelpers::assert_tag_permissions(
+                $vmid, $old, $new, $rpcenv, $authuser, $pool,
+            );
         } else {
             $rpcenv->check_vm_perm($authuser, $vmid, $pool, ['VM.Config.Options']);
         }
-- 
2.56.0