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 3EB058911 for ; Wed, 16 Nov 2022 10:51:25 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 280C51D367 for ; Wed, 16 Nov 2022 10:51:25 +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:51:24 +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 3D9FD44B71 for ; Wed, 16 Nov 2022 10:51:24 +0100 (CET) Date: Wed, 16 Nov 2022 10:51:17 +0100 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= To: Dominik Csapak , 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> In-Reply-To: MIME-Version: 1.0 User-Agent: astroid/0.16.0 (https://github.com/astroidmail/astroid) Message-Id: <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.139 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?=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:51:25 -0000 On November 16, 2022 10:40 am, Thomas Lamprecht wrote: > Am 16/11/2022 um 10:31 schrieb Fabian Gr=C3=BCnbichler: >>>> ok, then i have to change the permission checking code (currently i fo= rbid >>>> 'normal' users the tag if it was in the 'privileged-tags' section, reg= ardless >>>> =C2=A0if 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 st= rongly >>> but can imagine that it might be sensible and useful, and hard to chang= e later. >> If we say vzdump should only use privileged tags for backup inclusion lo= gic (to >> avoid unprivileged users adding that tag to their VM and causing it to b= e 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 pla= ce? >=20 > maybe re-read my scenario, feels like you're missing a bit here, maybe na= me it > "registered-tags" as suggested to make the confusion go away. >=20 >>=20 >> that sounds like a complicated way (with lots of side-effects, because >=20 > it's very simple? >=20 >> 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? th= ose >> would then be unprivileged, but the scope of "these allow vzdump job inc= lusion" >> is clear and limited. or we just keep "vzdump only looks at privileged t= ags" 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 =F0=9F= =98=89 >=20 > not sure where you get complicated? >=20 > - 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 things t= han backup source (either by PVE, or by custom tooling) where the difference be= tween (who can set a) "regular tag" and (a) "privileged/registered/.. tag" matter= s. > - You have a mode where you can say that a list of tags that "normal VM a= dmins" can use >=20 > - If they intersect then a "normal VM admin" can use it too >=20 > If you want to give a user control of what a (admin controlled!) job incl= udes in > terms of guests then you can do so easily by also allowing the registered= tag, if > not then don't? Note that not all setups host externally mostly untrusted= guests/ > users, the bigger market for us is those where a admin has a trust basis = and also > no problem in giving control I understand the issue/scenario, but I think the missing scope restricts us= down the line when we want to start using the difference between "registered" (restricted?) tags and normal ones for other things besides vzdump - becaus= e the admin when lifting the restriction might not be aware of the implication th= at this doesn't just affect vzdump jobs (for example, because the other featur= e 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 lists a= nd allow tags being in both, but it should come with a warning about the implications ;)