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. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
