From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (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 lists.proxmox.com (Postfix) with ESMTPS id 8C5399DB7C for ; Tue, 6 Jun 2023 09:44:03 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 50F2630E44 for ; Tue, 6 Jun 2023 09:43:33 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Tue, 6 Jun 2023 09:43:32 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 8BA5548BDF for ; Tue, 6 Jun 2023 09:43:32 +0200 (CEST) Date: Tue, 06 Jun 2023 09:43:25 +0200 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= To: Proxmox VE development discussion References: <20230604233709.1340089-1-aderumier@odiso.com> <1685958374.jxhx4d0md8.astroid@yuna.none> <45c767c555473f0969dd1036627c9f9b76d2c340.camel@groupe-cyllene.com> <48d2176fec4cb32dec1889cb2e6efeda1fec4c64.camel@groupe-cyllene.com> In-Reply-To: <48d2176fec4cb32dec1889cb2e6efeda1fec4c64.camel@groupe-cyllene.com> MIME-Version: 1.0 User-Agent: astroid/0.16.0 (https://github.com/astroidmail/astroid) Message-Id: <1686036509.uv78m51dug.astroid@yuna.none> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL 0.073 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 T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pve-devel] [PATCH-SERIE pve-access-control/pve-manager/qemu-server] check permissions on local bridge X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2023 07:44:03 -0000 On June 6, 2023 8:54 am, DERUMIER, Alexandre wrote: > Le mardi 06 juin 2023 =C3=A0 05:32 +0000, DERUMIER, Alexandre a =C3=A9cri= t=C2=A0: >> > to have at least the local bridge ACL path (for the zone, or for >> > the >> > zone and the bridges?) in the regular ACL selectors in 7.x as well, >> > if >> > we pull in something in pve-manager, than IMHO it should be that, >> > not >> > the full-flegded new panels. >> I'll look to rewrok the selector, vnets are not yet displayed. (only >> sdn zones, and localnetwork zone is also not displayed ) >=20 > Looking at that, > currently the pathselector is filled from cluster ressources. >=20 > I really don't known if we want to add all vnets to the cluster > ressources api. (as we don't really want to expose them in the tree > anyway, like a disk from a datastore is not exposed. User could have a > lot bridges, and the ressource json can be already big) >=20 > User could still add manually the bridge in the path if needed. >=20 > User could still use the new panel for easy add more granular > permissions on bridge/vlan. I think for PVE 7, we mainly want to provide an easy way to stay compatible to the old behaviour, that would basically mean: pveum acl modify /sdn/zones/localnetwork --groups XXX --users YYY --tokens = ZZZ --roles PVESDNUser rinse repeat for any SDN zones if you have any. for the GUI, the least invasive change would be to just add a hardcoded ACL selector entry for /sdn/zones/localnetwork (the rest can be done manually via the GUI or pveum). note that existing guests continue to work fine, it's just - creating new ones (from scratch, backup or via clone) - modifying any virtual nics on any guests that require the permissions. PVEAdmins and existing PVESDNAdmins would already have the required permissions anyway (Administrator as well). so this would mostly affect PVEVMAdmins and custom roles.