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

Fabian Grünbichler f.gruenbichler at proxmox.com
Thu Sep 5 14:42:17 CEST 2024


> 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..




More information about the pbs-devel mailing list