Consider UUID syntax in qrexec policy

[marmarek]

One thing I really want is the ability to grant qrexec rights to a specific DispVM once (until it is shut down), and not have the possibility of those rights being assumed by a later different VM whose disp[0-9]{1,4} happens to collide. The best way to achieve this is not clear to me with the current architecture.

What do you think about adding another syntax for domain UUID? Those are hard enough to not conflict? Alternatively, there could be a mechanism that remove policy rules involving a VM name explicitly - when you remove that VM. That would be more fragile though.
On the other hand, there are similar issues not only about DispVM:

• policy after VM rename (clone & remove) - would be nice to have an option to adjust policy here (including target= arguments)
• unrelated re-creation of a VM with a name that got a special permission before - in most cases, should not inherit that permission; but probably not all the cases - for example restoring a VM from a backup probably should not invalidate policy (but this particular case could be solved by also included policy in the backup)

The second point would be solved by UUID. But not the first one - in the current design of rename operation you can't possibly preserve UUID, by the definition of the second "unique" there.

BTW it's already possible to have similar effect using the current syntax: add a tag uuid-.... and use that in the policy (@tag:uuid-...). It will even work for renames (tags are preserved). But tags will be also inherited during non-rename clone operation. Which may or may not be a good thing here. It will not solve target= and similar arguments.

Originally posted by @marmarek in #4370 (comment)

[andrewdavidwong]

• policy after VM rename (clone & remove) - would be nice to have an option to adjust policy here (including target= arguments)
• unrelated re-creation of a VM with a name that got a special permission before - in most cases, should not inherit that permission; but probably not all the cases - for example restoring a VM from a backup probably should not invalidate policy (but this particular case could be solved by also included policy in the backup)

FWIW, I do sometimes intentionally (re)create and (re)name my qubes in such a way that I assume my custom RPC policies with hardcoded names will match the eventual arrangement of qubes. (For example, I want to recreate qube abc, but I need to keep some files, so I create abc-1, transfer from abc to abc-1, delete abc, then rename abc-1 to abc.) If my custom RPC policies were changing out from under me as I tried to perform deletions and renames, I would be frustrated that I had to "fight against" the system to get it to do what I want. Just one data point from one user. :)

[DemiMarie]

This requires:

• Support UUIDs in the Admin API #8862