From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id 684ED1FF0AA for ; Tue, 03 Nov 2026 16:18:09 +0100 (CET) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id D195821941; Tue, 03 Nov 2026 16:17:54 +0100 (CET) Message-ID: <27370b52-b557-47f4-a5a4-fe65ca26831e@proxmox.com> Date: Tue, 3 Nov 2026 16:17:35 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [QUESTION] pve-storage: intended Datastore.Audit visibility of prunebackups metadata To: =?UTF-8?B?6IKWIOWuh+iJrw==?= , "pve-devel@lists.proxmox.com" References: Content-Language: en-US From: Fiona Ebner In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1793719055583 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.300 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: 3QYF7MBP45X5LWF7QKAOSTCFO4B7AHCW X-Message-ID-Hash: 3QYF7MBP45X5LWF7QKAOSTCFO4B7AHCW X-MailFrom: f.ebner@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 X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Hello Yuliang Xiao, Am 03.11.26 um 1:28 PM schrieb 肖 宇良: > The prunebackups API explicitly permits Datastore.Audit or Datastore.AllocateSpace and does not apply check_volume_access() to its result. The content API currently does apply that per-volume check. > The original prunebackups API discussion introduced the Datastore.Audit/Datastore.AllocateSpace permission check together with the volid, ctime, mark and vmid response fields: > https://lore.proxmox.com/pve-devel/ae57fdf5-c43a-f828-0d47-8e7aceb5ea62@proxmox.com/T/ > In January 2023 it was explained that Datastore.Audit alone only permits knowing about the storage, and that listing backup archives additionally requires the per-volume check: Datastore.AllocateSpace on the storage plus VM.Backup on the owning guest: > https://lore.proxmox.com/pve-devel/1672907478.qzv3ze8grn.astroid@yuna.none/T/ > A July 2025 patch for bug #5492 proposed letting Datastore.Audit users list a restricted set of backup metadata for monitoring. The thread was still discussing which fields to retain, and the content API still applies check_volume_access() in Proxmox VE 9.2.21: > https://lore.proxmox.com/pve-devel/1753881023.tvgbrwck0i.astroid@yuna.none/T/ > Could you clarify whether the current prunebackups behavior is intentional? > > * > If yes, would it make sense to document that Datastore.Audit includes visibility of backup IDs and timestamps through the prune preview? > * > If not, should the dry-run result apply the same per-volume filtering as the content API? thank you for the question! Yes, applying the same filtering as the content endpoint is sensible. I sent a patch to do so: https://lore.proxmox.com/pve-devel/20261103151432.197799-1-f.ebner@proxmox.com/T/ Best Regards, Fiona