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 36FBE1FF14C for ; Fri, 12 Jun 2026 15:47:07 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 6F38914E10; Fri, 12 Jun 2026 15:47:04 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH pve-network 5/9] fix #7294: sdn: register api formats for zones and vnets From: Gabriel Goller To: David Riley In-Reply-To: <920d1522-9a76-4ba7-90a6-f7fa5ffecc73@proxmox.com> 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> Date: Fri, 12 Jun 2026 15:46:55 +0200 Message-Id: <178127201519.718919.5198816838031871654.b4-reply@b4> X-Mailer: b4 0.16-dev X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1781271970201 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.028 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: J24TIULSNZ2FKTC25ENNQ6BXTSQE2AL4 X-Message-ID-Hash: J24TIULSNZ2FKTC25ENNQ6BXTSQE2AL4 X-MailFrom: g.goller@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 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? > 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? > Let me know if this makes sense. > > [snip]