From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 906491FF14C for ; Fri, 12 Jun 2026 16:17:08 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 1484715C6D; Fri, 12 Jun 2026 16:17:07 +0200 (CEST) Message-ID: Date: Fri, 12 Jun 2026 16:17:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH pve-network 5/9] fix #7294: sdn: register api formats for zones and vnets To: Gabriel Goller References: <20260611145935.147788-1-d.riley@proxmox.com> <20260611145935.147788-6-d.riley@proxmox.com> <178126670392.718919.12595073108998221237.b4-review@b4> <920d1522-9a76-4ba7-90a6-f7fa5ffecc73@proxmox.com> <178127201519.718919.5198816838031871654.b4-reply@b4> Content-Language: en-US From: David Riley In-Reply-To: <178127201519.718919.5198816838031871654.b4-reply@b4> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1781273774075 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.165 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: LJULLATKUZXP3DLO3FLUXITVFRVRWZ7G X-Message-ID-Hash: LJULLATKUZXP3DLO3FLUXITVFRVRWZ7G X-MailFrom: d.riley@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: pve-devel@lists.proxmox.com X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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]