From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id 634D81FF0AB for ; Wed, 09 Sep 2026 14:24:45 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id BE22D2159E; Wed, 09 Sep 2026 14:24:44 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH proxmox 02/28] pbs-api-types: add remote datastore append privs and role From: Robert Obkircher To: Christian Ebner In-Reply-To: <20260813171002.809441-3-c.ebner@proxmox.com> References: <20260813171002.809441-1-c.ebner@proxmox.com> <20260813171002.809441-3-c.ebner@proxmox.com> Date: Wed, 09 Sep 2026 14:24:31 +0200 Message-Id: <178895667178.166380.3556210384656557808.b4-review@b4> X-Mailer: b4 0.16-dev X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1788956672158 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.583 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: X7MKYQPVGGB2ABBVLH4YMDY7WTPQKMHP X-Message-ID-Hash: X7MKYQPVGGB2ABBVLH4YMDY7WTPQKMHP X-MailFrom: r.obkircher@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: pbs-devel@lists.proxmox.com X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox Backup Server development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: > 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 > > 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. -- Robert Obkircher