Re: [PATCH proxmox 02/28] pbs-api-types: add remote datastore append privs and role

[Christian Ebner <c.ebner@proxmox.com>]

On 9/9/26 2:24 PM, Robert Obkircher wrote:
>> While allowing to push/backup to remotes like Remote.DatastoreBackup,
>> Remote.DatastoreAppend also allows creation of namespaces, but never
>> deletion/modification as Remote.DatastoreModify would imply, not even
>> for owned contents.
>>
>> The role is intended to allow local (source) user configuration for
>> immutable push sync jobs and is to be set on the user/token on the
>> remote's datastore ACL path.
>>
>> This is intended to be used with a remote user on the push target
>> having Datastore.Audit and Datastore.Append on the target datastore
>> or sub-namespace.
>>
>> Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
>>
>> diff --git a/pbs-api-types/src/acl.rs b/pbs-api-types/src/acl.rs
>> index 9055dfab..f467db8d 100644
>> --- a/pbs-api-types/src/acl.rs
>> +++ b/pbs-api-types/src/acl.rs
>> @@ -61,6 +61,8 @@ constnamedbitmap! {
>>           PRIV_REMOTE_MODIFY("Remote.Modify");
>>           /// Remote.Read allows reading data from a configured `Remote`
>>           PRIV_REMOTE_READ("Remote.Read");
>> +        /// Remote.DatastoreAppend allows creating new snapshots and namespaces on remote datastores
>> +        PRIV_REMOTE_DATASTORE_APPEND("Remote.DatastoreAppend");
>>           /// Remote.DatastoreBackup allows creating new snapshots on remote datastores
>>           PRIV_REMOTE_DATASTORE_BACKUP("Remote.DatastoreBackup");
> 
> I would have expected privileges to be more atomic. i.e. wouldn't it
> make more sense to have one privilege for creating namespaces, one for
> creating snapshots, and separate ones for modifications or deletions?
> That could eliminate some of the branching logic around permission
> checks.
> 
> Same question for the previous patch, but this is mostly just me being
> a bit confused about where we should draw the line.

This would however escalate rather quickly, therefore we generally tend 
to keep the number of privs and roles limited. But I agree that here it 
might make sense to re-consider splitting up `Datastore.Modify` into 
more fine grained sets and update rules and documentation accordingly.

Will see if this can be done in a backwards compatible manner.