Re: [pve-devel] [PATCH cluster v10 4/5] datacenter.cfg: add tag rights control to the datacenter config

[Thomas Lamprecht <t.lamprecht@proxmox.com>]

Am 16/11/2022 um 10:51 schrieb Fabian Grünbichler:
>> - 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 than
> backup source (either by PVE, or by custom tooling) where the difference between
> (who can set a) "regular tag" and (a) "privileged/registered/.. tag" matters.
> 
>> - You have a mode where you can say that a list of tags that "normal VM admins" 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 includes 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 - because the
> admin when lifting the restriction might not be aware of the implication that
> this doesn't just affect vzdump jobs (for example, because the other feature
> 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 and
> allow tags being in both, but it should come with a warning about the
> implications 😉

meh, that is somewhat true for a lot of feature expansions, but yes, we don't have
any such feature (as we need tags to work first -> chicken/egg), and deciding that
stuff now for the future is probably always missing some things; so I recommended
Dominik off-list to go for the "require / Sys.Modify" approach for now and ideally
add a frontend warning/hint if there are shared ones between the registered/privileged
and user allow-list. We can then expand on this when actually implementing features
and getting user feedback, that is def. safer for now.