Re: [PATCH pve-network 5/9] fix #7294: sdn: register api formats for zones and vnets

[David Riley <d.riley@proxmox.com>]

On 6/12/26 3:46 PM, Gabriel Goller wrote:
> On 2026-06-12 14:51 +0200, David Riley wrote:
>> Thanks for the feedback.
>>
>> The intention behind adding this segment to the ACL path is to allow
>> for fine-grained, hierarchical permission scoping, not to couple the
>> ACL system to specific VNet properties.
>>
>> I used vlan as a placeholder for 'tag', but in retrospect, the naming
>> is a bit confusing, and I'm happy to adapt this in a v2.
>>
>>   From a permission perspective, including the tag in the path makes
>> sense, as it allows us to restrict pool users to a specific VNet and
>> tag combination.
> Maybe I'm a bit dim, but you mean the VNet tag right -- so the tag I configure
> on each VNet?

No, I don't mean the tag configured on the VNet itself. I mean the
VLAN tag configured on the guest's network interface (NIC) when
attaching the VM to a VLAN-aware VNet.

>> So if you have a pool with a VM, storage and VNet + Tag and assign the
>> pool permissions: PVEVMAdmin, PVESDNUser
>>
>> The user can fully manage this VM, including adding a new NIC, but
>> they can only add it using the exact VNet + Tag combination. Just
>> adding the VNet would not work.
> How is this different than just adding the VNet? Will this restrict the user
> from adding another vlan tag on the VM (when using vlanaware vnets)? Is this
> just to prevent the user from editing the VNet tag?

Yes it will restrict the user.
This is how I tested it (and what I envision the primary use case to
be) is this:
* You create a simple zone.
* In that zone, you create a VNet and make it vlanaware.
* You add this VNet to the pool by selecting the zone, the VNet, and
   setting a specific tag (e.g., 1).

The user then gets the following ACL path from the pool:
/sdn/zones/zone/vnet/1

If the user tries to add a network card to their VM using only the
zone and VNet without the VLAN tag, it will fail:
Permission check failed (/sdn/zones/zone/vnet, SDN.Use) (403)

Trying to assign a different VLAN tag (e.g., 2) will also fail:
Permission check failed (/sdn/zones/zone/vnet/2, SDN.Use) (403)

Only using the zone, VNet, and tag 1 will work.

So it effectively allows an admin to share a single VLAN-aware VNet
across multiple pools, strictly isolating users to their assigned
VLANs.

>> Let me know if this makes sense.
>>
>> [snip]