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 65A6EA028 for ; Wed, 27 Apr 2022 14:45:57 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 52A1526741 for ; Wed, 27 Apr 2022 14:45:27 +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) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 51E8A26738 for ; Wed, 27 Apr 2022 14:45:26 +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 DB5BA42E06; Wed, 27 Apr 2022 14:45:25 +0200 (CEST) Date: Wed, 27 Apr 2022 14:45:15 +0200 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= To: "DERUMIER, Alexandre" , "pve-devel@lists.proxmox.com" References: <20220427113600.166803-1-f.gruenbichler@proxmox.com> <27858f5825dd14d370504c67bf877dc6d53a4bfc.camel@groupe-cyllene.com> In-Reply-To: <27858f5825dd14d370504c67bf877dc6d53a4bfc.camel@groupe-cyllene.com> MIME-Version: 1.0 User-Agent: astroid/0.15.0 (https://github.com/astroidmail/astroid) Message-Id: <1651063060.qfgje4ssa0.astroid@nora.none> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL 0.020 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment POISEN_SPAM_PILL 0.1 Meta: its spam POISEN_SPAM_PILL_1 0.1 random spam to be learned in bayes POISEN_SPAM_PILL_3 0.1 random spam to be learned in bayes SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [PATCH manager] api2: network: anybridge: re-add regular bridges 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: Wed, 27 Apr 2022 12:45:57 -0000 On April 27, 2022 2:32 pm, DERUMIER, Alexandre wrote: > Hi Fabian > Le mercredi 27 avril 2022 =C3=A0 13:36 +0200, Fabian Gr=C3=BCnbichler a = =C3=A9crit=C2=A0: >> commit 052fbb2a4d1bdeb490b2e3b67cd7555e460ebe93 introduced permission >> > checks here that caused all regular bridges to be removed from the >> > returned list as soon as the SDN package is installed, unless the >> > user >> > is root@pam or there exists a VNET with the same ID. >> >=20 > mmm, this is unexpected. > with my original patch : >=20 > if user don't have any permissions on vnets: > - all vmbrX bridges are displayed > - no vnets is displayed >=20 > if user have a permission on at least 1vnet: > - vmbrX bridge are no more displayed (untie you add a specific > permissions with /sdn/vnets/vmbrX) > - only vnet with permissions are displayed >=20 >=20 > I didn' see, but Thomas have reworked it: > https://git.proxmox.com/?p=3Dpve-manager.git;a=3Dcommit;h=3D640c0b26891c4= 08d0456c355b3724c1be18cc75f >=20 > and the behaviour seem to be different: >=20 > if user don't have any permissions on vnets: > - no vmbrX displayed ----> different behaviour > - no vnets is displayed >=20 > if user have a permission on at least 1vnet: > - vmbrX bridge are no more displayed (untile you add a specific > permissions with /sdn/vnets/vmbrX) > - only vnet with permissions are displayed >=20 >=20 > with your patch, it seem to be different too: >=20 > if user don't have any permissions on vnets: > - vmbrX displayed =20 > - no vnets is displayed >=20 > if user have a permission on at least 1vnet: > - vmbrX brige are still displayed ----> different behaviour > - only vnet with permissions are displayed yeah that's true. I missed which commit was the culprit (relying on the=20 commit messages) given that - we can't require some new ACL path/priv for regular bridges until the=20 next major release (as that would be quite the breaking change ;)) - removing access to the last VNET would suddenly make all regular=20 bridges available (again) with your original patch, which is strange=20 behaviour for an ACL (removing a positive ACL shouldn't give me more=20 access ;)) - with the original patch it's impossible to say "user FOO can play=20 around with SDN but also use regular bridges" without 'faking' ACLs=20 for vnets that aren't actually vnets, but regular bridges I think the current variant is what we can have for the time being - and=20 then with 8.0 either say - 'regular bridges also require FOO on /sdn/vnets/vmbrX' (identical to=20 vnets, but a bit ugly as the ACL path is technically 'wrong') - 'regular bridges require FOO on /network/bridge/vmbrX' (like vnets,=20 but different ACL path/namespace, probably with some helper that 'does=20 the right thing' in places where we don't care what kind it is) and then filter here and in other places accordingly?