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 F41BC93274 for ; Fri, 16 Sep 2022 09:20:02 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id E4B7A20C42 for ; Fri, 16 Sep 2022 09:19:32 +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)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Fri, 16 Sep 2022 09:19:32 +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 193F3443EE for ; Fri, 16 Sep 2022 09:19:32 +0200 (CEST) Message-ID: <075c15f6-15e2-caf1-8605-a9bf53f0ad05@proxmox.com> Date: Fri, 16 Sep 2022 09:19:31 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:105.0) Gecko/20100101 Thunderbird/105.0 Content-Language: en-GB To: Proxmox VE development discussion , Dominik Csapak References: <20220621092012.1776825-1-d.csapak@proxmox.com> From: Thomas Lamprecht In-Reply-To: <20220621092012.1776825-1-d.csapak@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.743 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 NICE_REPLY_A -1.816 Looks like a legit reply (A) 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 common/cluster/qemu/container/wt/manager v7] add tags to ui 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: Fri, 16 Sep 2022 07:20:03 -0000 Am 21/06/2022 um 11:19 schrieb Dominik Csapak: > this series brings the already existing 'tags' for ct/vms to the gui: > * tags can be edited in the status toolbar of the guest > * existing tags will be shown in the tree/global search/resource grids > * when editing a tag, a list of existing tags will be shown > * by default, the color is (consistently) autogenerated based on the > text > * that color can be overriden in datacenter -> options (cluster wide) > (edit window for browser local storage is TBD) > * by default, the text color is either white or black, depending which > provides the greater contrast (according to SAPC) > * this text color can also be overridden > * there are multiple shapes available for the tree (see [0]) > * adds new 'admin' tags that need higher privliges, these can then be > used to enable features like 'inlude in backup by tag', etc. I didn't find the permission semantics for non-admin tags when skimming the series, but after thinking about it off an on again recently I figure that it could be seen as quite problematic in general to even assign existing tags, then visible in the resource view, if the user got only limited privileges to a VM; and that it could be quite problematic for such users to create new ones, allowing typo squatting, slurs, ...? to have ill effects to other users or admins of the same system/cluster. I mean to a certain degree this can be correlated to the permission semantics of the hostname, but still there's more of them and they're way flashier. One method could be (always talking about non-admin tags for now): * allow unrestricted usage of those for users with Sys.Modify on / + the rights on the object to modify (i.e., for guests that would be VM.Modify on /vms/) * for users without the powerful Sys.Modify on / we could give the admins the decision, for example through a datactenter.cfg property that could work like: user-tag-privs: useable=[,list=] Meaning: - useable=none -> only users with powerful Sys.Modify -> / can configure tags - useable=existing -> currently existing tags can be used, the list could be added as base-set (so that users that only got one VM can actually set some) - useable=free -> existing can be used freely and new ones can be added freely, the list would only act as base suggestion set. - useable=list -> well, the list reflects all allowed tags to use (independent if they exist for that users POV or don't). This would be still orthogonal to admin:tags (as their purpose is to avoid users adding a possible OK tag to a unwanted guest due to actions like backup using said tag). ps, semi-related. I'd like (as it not strictly insist on that, but I find it a bit too ugly to do) to not further extend the already misused /version call if possible. I just find it unidiomatic and adding a new one now with the current extra info would be possible, we then could remove that extra info from /version with the next major release.