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 6CA34887F for ; Wed, 16 Nov 2022 10:40:34 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 505071D01D for ; Wed, 16 Nov 2022 10:40:34 +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:40:33 +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 09BF544B5D for ; Wed, 16 Nov 2022 10:40:33 +0100 (CET) Message-ID: Date: Wed, 16 Nov 2022 10:40:32 +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: =?UTF-8?Q?Fabian_Gr=C3=BCnbichler?= , Dominik Csapak , Proxmox VE development discussion 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: Thomas Lamprecht In-Reply-To: <1668590513.dxe50wm4po.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 09:40:34 -0000 Am 16/11/2022 um 10:31 schrieb Fabian Gr=C3=BCnbichler: >>> ok, then i have to change the permission checking code (currently i f= orbid >>> 'normal' users the tag if it was in the 'privileged-tags' section, re= gardless >>> =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 s= trongly >> but can imagine that it might be sensible and useful, and hard to chan= ge later. > If we say vzdump should only use privileged tags for backup inclusion l= ogic (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 pl= ace? 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 > that sounds like a complicated way (with lots of side-effects, because it's very simple? > 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 ther= e should > simply be a list of "vzdump tags" in addition to the privileged ones? t= hose > would then be unprivileged, but the scope of "these allow vzdump job in= clusion" > 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 =F0=9F= =98=89 not sure where you get complicated? - You have a list of tags that are useable for backup source - You have a mode where you can say that a list of tags that "normal VM a= dmins" 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 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