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 BB6D5932D2 for ; Fri, 16 Sep 2022 09:51:04 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id A813B210C8 for ; Fri, 16 Sep 2022 09:50:34 +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:50:33 +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 A10104446B; Fri, 16 Sep 2022 09:50:33 +0200 (CEST) Message-ID: Date: Fri, 16 Sep 2022 09:50:32 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:105.0) Gecko/20100101 Thunderbird/105.0 To: Thomas Lamprecht , Proxmox VE development discussion References: <20220621092012.1776825-1-d.csapak@proxmox.com> <075c15f6-15e2-caf1-8605-a9bf53f0ad05@proxmox.com> Content-Language: en-US From: Dominik Csapak In-Reply-To: <075c15f6-15e2-caf1-8605-a9bf53f0ad05@proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.838 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:51:04 -0000 On 9/16/22 09:19, Thomas Lamprecht wrote: > 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. thats true of course, the current tags require 'VM.Config.Options' privileges, so anybody who has some edit access to vms can add tags there > > 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 looks nice, the default would have to be usable=free for it to be not a breaking change though (or is it?), could be changed ofc with the next major release > > 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). we could also add a list of predefined admin tags here too (either as seperate option, or as second list in the property string), that would only be settable by users with 'Sys.Modify' on / that is what i suggested to Aarons review regarding admin confusion would that make more sense than using some prefix maybe? > > 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. yes, a 'datacenter-info' (or similar, it was the first thing that popped into my mind) would be nicer