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 0AEE088DA for ; Wed, 16 Nov 2022 10:38:30 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id E7D8E1CF33 for ; Wed, 16 Nov 2022 10:38:29 +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 10:38:29 +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 F2F1D44B58; Wed, 16 Nov 2022 10:38:28 +0100 (CET) Message-ID: <394c7f15-1ee5-b4eb-7a85-611ced55623d@proxmox.com> Date: Wed, 16 Nov 2022 10:38:28 +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-US To: =?UTF-8?Q?Fabian_Gr=C3=BCnbichler?= , Proxmox VE development discussion , Thomas Lamprecht 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> From: Dominik Csapak In-Reply-To: <1668590513.dxe50wm4po.astroid@yuna.none> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: =?UTF-8?Q?0=0A=09?=AWL 0.065 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 09:38:30 -0000 On 11/16/22 10:31, Fabian Grünbichler wrote: > On November 16, 2022 10:10 am, Thomas Lamprecht wrote: >> Am 16/11/2022 um 10:04 schrieb Dominik Csapak: >>> On 11/16/22 09:54, Thomas Lamprecht wrote: >>>> Am 16/11/2022 um 09:47 schrieb Dominik Csapak: >>>>>> I am not sure the second sentence is necessary, or rather, wouldn't it be better >>>>>> to make the two lists mutually exclusive? e.g., by removing privileged tags from >>>>>> the other list? >>>>> >>>>> i don't really want to auto remove stuff from one option when set on another. >>>>> maybe it'd make more sense if we don't allow setting and admin tag when >>>>> it's already set in the 'user-allow-list' and vice versa? then >>>>> there cannot be a situation where a tag is in both lists at the same time? >>>>> >>>> >>>> >>>> Limits use cases, as we'll only ever allow priv'd tags to be used for things >>>> like backup job guest-source selection, and there may be scenarios where an >>>> admin wants to allow the user to set a specific privileged tags in the VMs >>>> they control. >>>> >>>> To make that work we'd: >>>> - explicitly allow such listed tags for "normal" VM users even if they're in the >>>>    privileged-tags (that's why I used the term "registered" in previous comments, >>>>    might be better suited if we deem that privileged is then confusing) >>>> >>>> - highlight the fact if a tag is in both >>>> >>> >>> ok, then i have to change the permission checking code (currently i forbid >>> 'normal' users the tag if it was in the 'privileged-tags' section, regardless >>>  if it was in the 'user-allow-list' or not) >> >> maybe wait on Fabian's opinion on that, I don't want to push this to strongly >> but can imagine that it might be sensible and useful, and hard to change later. > > If we say vzdump should only use privileged tags for backup inclusion logic (to > avoid unprivileged users adding that tag to their VM and causing it to be backed > up), but then make some of those tags effectively non-privileged (which allows > exactly that), why do we have the restriction in vzdump in the first place? > > that sounds like a complicated way (with lots of side-effects, because > privileged tags might be used in other places in the future as well) to make the > "vzdump should only use privileged tags" part configurable.. maybe there should > simply be a list of "vzdump tags" in addition to the privileged ones? those > would then be unprivileged, but the scope of "these allow vzdump job inclusion" > is clear and limited. or we just keep "vzdump only looks at privileged tags" for > now to keep it simple - extending that one way or another in the future is > always possible if it is restricted now, the other way is harder ;) i think the reasoning of thomas here is that when we allow setting it in both it's up to the admin how to interpret that for example: we have x places where we only use privileged tags (e.g vzdump, migration, ...) but now the admin wants to allow the other admins to add the tags necessary for migration, but not for the others then we'd have to add a seperate list for each occurance of privileged tags, or we do it like thomas described then the admin simply sets in the 'user-allow-list' too does that make sense?