From: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>
To: Fiona Ebner <f.ebner@proxmox.com>,
Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH storage] close #5492: api: content: allow listing volumes with Datastore.Audit privilege
Date: Wed, 30 Jul 2025 16:27:33 +0200 [thread overview]
Message-ID: <1753885617.knb4qo26fj.astroid@yuna.none> (raw)
In-Reply-To: <b7a87104-08a9-4e59-93bb-d1799a414dab@proxmox.com>
On July 30, 2025 4:20 pm, Fiona Ebner wrote:
> Am 30.07.25 um 3:11 PM schrieb Fabian Grünbichler:
>> On July 18, 2025 5:03 pm, Fiona Ebner wrote:
>>> The check_volume_access() method is for checking read access to a
>>> volume. Users should be able to list the images, e.g. to check backup
>>> health via monitoring like reported in #5492 comment 3, with just an
>>> audit privilege.
>>>
>>> Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
>>> ---
>>> src/PVE/API2/Storage/Content.pm | 6 ------
>>> 1 file changed, 6 deletions(-)
>>>
>>> diff --git a/src/PVE/API2/Storage/Content.pm b/src/PVE/API2/Storage/Content.pm
>>> index 1fe7303..c1f9a1f 100644
>>> --- a/src/PVE/API2/Storage/Content.pm
>>> +++ b/src/PVE/API2/Storage/Content.pm
>>> @@ -154,12 +154,6 @@ __PACKAGE__->register_method({
>>>
>>> my $res = [];
>>> foreach my $item (@$vollist) {
>>> - eval {
>>> - PVE::Storage::check_volume_access(
>>> - $rpcenv, $authuser, $cfg, undef, $item->{volid},
>>> - );
>>> - };
>>> - next if $@;
>>
>> the data here also contains things like the notes content for that
>> volume, which might be sensitive..
>>
>> should we maybe limit the returned information if there is no volume
>> access? e.g., just return volid, format, type, owner, and size
>> information?
>
> Good catch! But should information like 'verification', 'protected',
> 'encrypted' really be limited as well (maybe mapping a fingerprint to
> just 1 and updating the docs)? The feature request is precisely for
> backup monitoring, where those would be important. 'parent' and 'ctime'
> seem also useful for auditing a storage.
yes, probably we should take a look at all the returned members and make
a list of allowed-for-audit-purposes and drop the rest.
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
prev parent reply other threads:[~2025-07-30 14:26 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-18 15:03 Fiona Ebner
2025-07-30 13:11 ` Fabian Grünbichler
2025-07-30 14:20 ` Fiona Ebner
2025-07-30 14:27 ` Fabian Grünbichler [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1753885617.knb4qo26fj.astroid@yuna.none \
--to=f.gruenbichler@proxmox.com \
--cc=f.ebner@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.