Re: [QUESTION] pve-storage: intended Datastore.Audit visibility of prunebackups metadata

[Fiona Ebner <f.ebner@proxmox.com>]

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