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)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 17C628B9B for ; Wed, 16 Nov 2022 14:57:09 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id E4C5A1FF7E for ; Wed, 16 Nov 2022 14:56:38 +0100 (CET) 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 ; Wed, 16 Nov 2022 14:56:38 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 0A7A244B5D for ; Wed, 16 Nov 2022 14:56:38 +0100 (CET) Message-ID: <50ed1d5d-671f-5e0c-f0cf-87b8791d0d6a@proxmox.com> Date: Wed, 16 Nov 2022 14:56:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:107.0) Gecko/20100101 Thunderbird/107.0 Content-Language: en-GB To: Proxmox VE development discussion , =?UTF-8?Q?Fabian_Gr=C3=BCnbichler?= , Dominik Csapak References: <20221115130248.1007325-1-d.csapak@proxmox.com> <20221115130248.1007325-5-d.csapak@proxmox.com> <1668524410.yomu90q6hb.astroid@yuna.none> <895c5e1e-4de0-19fe-91a0-f604cc451be8@proxmox.com> <7cfca64a-2ab1-405a-fde1-1f4f14e043b8@proxmox.com> <1668590513.dxe50wm4po.astroid@yuna.none> <1668591829.ftuvm1lejc.astroid@yuna.none> From: Thomas Lamprecht In-Reply-To: <1668591829.ftuvm1lejc.astroid@yuna.none> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: =?UTF-8?Q?0=0A=09?=AWL -0.031 Adjusted score from AWL reputation of From: =?UTF-8?Q?address=0A=09?=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 =?UTF-8?Q?Alignment=0A=09?=NICE_REPLY_A -0.001 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF =?UTF-8?Q?Record=0A=09?=SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [PATCH cluster v10 4/5] datacenter.cfg: add tag rights control to the datacenter config 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, 16 Nov 2022 13:57:09 -0000 Am 16/11/2022 um 10:51 schrieb Fabian Gr=C3=BCnbichler: >> - You have a list of tags that are useable for backup source >> > the problem is that this list of tags might also be used for other thin= gs than > backup source (either by PVE, or by custom tooling) where the differenc= e between > (who can set a) "regular tag" and (a) "privileged/registered/.. tag" ma= tters. >=20 >> - You have a mode where you can say that a list of tags that "normal V= M admins" can use >> >> - If they intersect then a "normal VM admin" can use it too >> >> If you want to give a user control of what a (admin controlled!) job i= ncludes in >> terms of guests then you can do so easily by also allowing the registe= red tag, if >> not then don't? Note that not all setups host externally mostly untrus= ted guests/ >> users, the bigger market for us is those where a admin has a trust bas= is and also >> no problem in giving control > I understand the issue/scenario, but I think the missing scope restrict= s us down > the line when we want to start using the difference between "registered= " > (restricted?) tags and normal ones for other things besides vzdump - be= cause the > admin when lifting the restriction might not be aware of the implicatio= n that > this doesn't just affect vzdump jobs (for example, because the other fe= ature > that also uses the list of special tags is not even implemented yet at = that > point). if we don't care about that then sure, we can just have two lis= ts and > allow tags being in both, but it should come with a warning about the > implications =F0=9F=98=89 meh, that is somewhat true for a lot of feature expansions, but yes, we d= on't have any such feature (as we need tags to work first -> chicken/egg), and deci= ding that stuff now for the future is probably always missing some things; so I rec= ommended Dominik off-list to go for the "require / Sys.Modify" approach for now an= d ideally add a frontend warning/hint if there are shared ones between the register= ed/privileged and user allow-list. We can then expand on this when actually implementin= g features and getting user feedback, that is def. safer for now.