Snapshot ownership and API tokens

[tuxis]

If I create an API token and try to use that token to make a new backup, I get the error:

ERROR: VM 785017 qmp command 'backup' failed - backup connect failed: command error: backup owner check failed ($USER@pbs!CD != $USER@pbs)

I would expect an API instance of a user to be the same 'owner' as the original user. Is my expectation incorrect? If so, is there an efficient way to change ownership of all snapshots in one go?

 

[joke]

I face this same problem. I want to prune some backup differently from default datastore prune config. So I create API token and run curl from cron. The prune API requires Datastore.Prune privilege which included in DatastoreSuperuser role. However, if I use this role, it will error:

backup owner check failed (root@pam!prune != root@pam)

If I use DatastoreAdmin role, it can run the job successfully.

 

[t.lamprecht]

Currently, the token is seen as a sub set of a user that is not equal to the user. So the real user is owing all backups made with API tokens derived from that user, but such API-tokens are not the real owner of backups made by the user or other tokens.

This comes from the fact that tokens should not be as powerful as the user, as they are intended for automated/headless access, so if one is leaked or compromised in any other way, the harm it can do should be restricted. Adding new backups is certainly most often seen as less harm than being able to delete existing ones, but remember that an advisory could permanently loop and create small bogus backups, thus 1. potentially breaking an actual backup of another machine owned by another token (as the same time gets used eventually), or 2. it shifts out the existing backups so that they will all be pruned eventually and one is left with only the bogus "bad actor" backups. So deletion and creation privilege have both their implications.

I get the basic issue though, and we may look into finding a sane way to make some tokens be owner of different tokens, as opt-in ACL or option or the like - needs a bit of good though to make this fit in the rest of the PBS stack without confusing anyone too much.