[pbs-devel] [PATCH v2 proxmox-backup 13/31] api types: define remote permissions and roles for push sync

[Fabian Grünbichler]

On September 5, 2024 1:17 pm, Christian Ebner wrote:
> On 8/7/24 13:21, Fabian Grünbichler wrote:
>> after thinking about this some more - this is missing some more bits I think.
>> 
>> for a pull based sync, we have two users:
>> - local owner/user
>> - remote user via remote.cfg
>> 
>> we only ever query/read from the remote side, so having two privs is fine:
>> - one to see the remote in the first place
>> - one to read backups that the configured remote user sees
>> 
>> for the local side, we have the full set of privs/operations:
>> - create/delete namespaces (DATASTORE_MODIFY)
>> - delete snapshots or groups (DATASTORE_MODIFY or DATASTORE_PRUNE+owner)
>> - create snapshots or groups (DATASTORE_BACKUP+owner)
>> 
>> but for push based backups, we basically need to map the "local" privs from a
>> pull to the remote privs, since we possibly need to do the same set of
>> operations (while in the case of push, we only query/read the local side, so
>> the priv matrix there is simpler).

you didn't reply to this part - would you agree with the above approach?

>> the owner semantics for push based backups are also rather weird/confusing:
>> 
>> - if owner has PRIV_DATASTORE_READ on the source, all groups will be synced
>> - if owner only has PRIV_DATASTORE_BACKUP only owned groups will be synced
>> - the backups on the target will always be owned by the remote.cfg user(!)
> 
> Yes, I agree that this might be confusing. I think however that the main 
> confusion stems from the fact, that the local user is currently referred 
> to as `owner`, while as a matter of fact this is the `source reader`? I 
> do think it makes sense that only backups which that user can see are 
> synced, after all that is the reason to even create a user with that 
> permission set?

exactly, owner is very much a misnomer for push based syncing, since
it's not possible at all to set the owner (since even if the remote.cfg
user/token is highly privileged enough to change the ownership after
creating the group, the next sync would then fail again cause of owner
mismatch).

> The owner will be the user as which the backup is written onto the 
> target (which is given by the remote). This cannot currently be 
> configured as for the pull job.

yes.

>> syncing back is thus only possible if the (source) owner and the remote.cfg
>> user are identical?
> 
> When syncing back by a pull, the owner can be set by the sync job again, 
> so that should be possible. Although, the initial ownership might get 
> lost. But that is already the case with the pull sync job? Or do you 
> mean syncing back by pushing the snapshots over from the remote again?

I guess such back and forth syncing always requires either high
privileges (to allow overriding the owner) or carefully synced owners on
both ends..

>> should we rename that parameter? owner makes sense for pulling (it is the user
>> that owns the synced groups after the sync), but not so much for pushing, where
>> something like "Local User" might be less misleading?
> 
> Yes, agreed.

ack. we also need similar priv checks for setting a different "local
user" than the current authid, like for the owner parameter for pull
based syncing..