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

[Fabian Grünbichler]

> Christian Ebner <c.ebner at proxmox.com> hat am 05.09.2024 15:27 CEST geschrieben: 
> On 9/5/24 14:42, Fabian Grünbichler wrote:
> >> Christian Ebner <c.ebner at proxmox.com> hat am 05.09.2024 14:26 CEST geschrieben:
> >> On 9/5/24 14:12, Fabian Grünbichler wrote:
> >>> 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?
> >>
> >> Maybe I did not understand you correctly here: Is this not already
> >> inherently given by the user permission on the remote target for push
> >> operations? Or do you meant to explicitly implement these permissions
> >> and check for these on the source side before even attempting to perform
> >> a push operation? Is that even possible, as the authid for the remote is
> >> configured in the remote.cfg and not as user?
> > 
> > no, what I meant is that we basically need to extend the remote privs (on the source side) so that it is possible to say:
> > 
> > "local user X is allowed to create namespaces on remote A" (provided the remote user for remote A can do that, of course). basically we want a REMOTE_DATASTORE_MODIFY, and only do certain operations if the user doing the sync/pull has that. the same applies to DATASTORE_PRUNE (e.g., to use remove_vanished with pushing I need to have REMOTE_DATASTORE_PRUNE), else I can't give a user push rights to a remote where the remote user has DATASTORE_MODIFY on the other end, because I'd risk a sync deleting whole trees of backups..
> 
> Ah I see, yeah for the local user performing the sync job, not the one 
> configured as the remote user.
> In the end I will have 3 users at play here:
> 1. the remote user as configured in remote.cfg, handled by the remote admin
> 2. the local source reader user, configured in the push sync job which 
> has to have access to read the contents from the datastore/namespace
> 3. the user executing the sync job, which must have the REMOTE_* 
> capabilities in order for the sync job to be executed and limit the 
> possible operations to be performed by that user.
> 
> Sorry for my confusion here and thanks for clarification.

yes, and just like for pull (with owner and configuring user), in most cases the "local source reader user" and the "user configuring the sync job" will be one and the same, or the configuring user will be a very highly privileged user setting up sync jobs for someone else.