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

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

[肖 宇良]

Hello,
I would like to clarify the intended permission semantics of the prunebackups dry-run API.
Tested environment:

  *
Proxmox VE 9.2.21
  *
Proxmox Backup Server storage 4.2.8-1
  *
User B with PVEVMUser on its own pool and PVEDatastoreUser on the storage; no permission on VM 124, which belongs to another pool

Observed behavior:

  1.
As B, GET /nodes/<node>/storage/<storage>/prunebackups?prune-backups=keep-last%3D1 returns backups of all five guests on the storage, including VM 124, with volid, vmid, ctime and the keep/remove mark.
  2.
Adding &type=qemu&vmid=124 also returns both backups of VM 124.
  3.
GET /nodes/<node>/storage/<storage>/content?content=backup&vmid=124 returns no entries for the same user. The same content request without vmid also returns no entries.
  4.
GET /nodes/<node>/storage/<storage>/content/<volid> returns:
     *
Permission check failed (/vms/124, VM.Backup)
  5.
As the owner of VM 124, the content listing returns both backups.

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?

This is a permission-model and API-consistency question. The behavior was observed only with disposable users and backups in a private lab.
Regards,
Yuliang Xiao

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

[Fiona Ebner]

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