[pve-devel] [PATCH common/cluster/qemu/container/wt/manager v7] add tags to ui

[Dominik Csapak]

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/<vmid>)
> 
> * 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=<none|existing|free|list>[,list=<tag1;tag2;...>]
>    
>    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