public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>
To: Fabian Ebner <f.ebner@proxmox.com>, pve-devel@lists.proxmox.com
Subject: Re: [pve-devel] [PATCH storage 1/4] check volume access: allow if user has VM.Config.Disk
Date: Thu, 24 Mar 2022 09:18:15 +0100	[thread overview]
Message-ID: <1648109081.y13k852cx6.astroid@nora.none> (raw)
In-Reply-To: <8f1859ba-c782-7dee-09e6-7fac1561ce74@proxmox.com>

On March 22, 2022 10:31 am, Fabian Ebner wrote:
> Am 22.03.22 um 09:31 schrieb Fabian Ebner:
>> Am 21.03.22 um 14:06 schrieb Fabian Ebner:
>>> Listing guest images should not require Datastore.Allocate in this
>>> case. In preparation for adding disk import to the GUI.
>>>
>>> Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
>>> ---
>>>  PVE/Storage.pm | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/PVE/Storage.pm b/PVE/Storage.pm
>>> index 6112991..efa304a 100755
>>> --- a/PVE/Storage.pm
>>> +++ b/PVE/Storage.pm
>>> @@ -486,6 +486,8 @@ sub check_volume_access {
>>>  	} elsif ($vtype eq 'backup' && $ownervm) {
>>>  	    $rpcenv->check($user, "/storage/$sid", ['Datastore.AllocateSpace']);
>>>  	    $rpcenv->check($user, "/vms/$ownervm", ['VM.Backup']);
> 
> @Fabian G. should access to backups also be allowed if the user /just/
> has Datastore.Allocate?
> 
> Otherwise, backups cannot be listed or removed (there is a separate
> check, but works similarly) and attributes cannot be changed by a
> supposedly high-privileged user.

yeah, I think Datastore.Allocate could be allowed here, it's documented 
as:

Datastore.Allocate: create/modify/remove a datastore and delete volumes

but in practice, any user that has Datastore.Allocate likely also has 
Datastore.AllocateSpace anyway which is probably why nobody complained 
yet ;)

> On the other hand, we also use this check for extractconfig, where it
> makes sense to be limited to users with VM.Backup, but could be changed
> at the call site of course.

IMHO same as above applies here, and I think the idea here was 'if you have 
VM.Backup and Datastore.AllocateSpace you are allowed to access "your 
own" backups, even if you can't access the whole range of files on the 
storage', the code was just not very thought through (and in practice, 
high-privileged users on storages are usually also high-privileged users 
on guests, so nobody noticed/cared).

I think adding an early return with the check from the else branch with 
$noerr set and replacing the else branch with a `die` would be fine (so 
Datastore admins are always allowed to access all volumes on their 
storages).

>>> +	} elsif (($vtype eq 'images' || $vtype eq 'rootdir') && $ownervm) {
>>> +	    $rpcenv->check($user, "/vms/$ownervm", ['VM.Config.Disk']);
>> 
>> Of course this needs to be or-ed with the Datastore.Allocate privilege.
>> Will fix it in v2.

and and-ed with Datastore.AllocateSpace?

>> 
>>>  	} else {
>>>  	    # allow if we are Datastore administrator
>>>  	    $rpcenv->check($user, "/storage/$sid", ['Datastore.Allocate']);
>> 
>> 
>> _______________________________________________
>> pve-devel mailing list
>> pve-devel@lists.proxmox.com
>> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>> 
>> 
> 




  reply	other threads:[~2022-03-24  8:18 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-21 13:06 [pve-devel] [PATCH-SERIES storage/manager/container/qemu-server] improve check_volume_access Fabian Ebner
2022-03-21 13:06 ` [pve-devel] [PATCH storage 1/4] check volume access: allow if user has VM.Config.Disk Fabian Ebner
2022-03-22  8:31   ` Fabian Ebner
2022-03-22  9:31     ` Fabian Ebner
2022-03-24  8:18       ` Fabian Grünbichler [this message]
2022-03-28  9:07         ` Fabian Ebner
2022-03-28 11:36           ` Fabian Grünbichler
2022-03-29  7:48             ` Fabian Ebner
2022-03-29 12:33               ` Fabian Grünbichler
2022-03-21 13:06 ` [pve-devel] [PATCH storage 2/4] check volume accesss: add content type parameter Fabian Ebner
2022-03-21 13:06 ` [pve-devel] [PATCH storage 3/4] pvesm: extract config: add content type check Fabian Ebner
2022-03-21 13:06 ` [pve-devel] [PATCH storage 4/4] api: file restore: use check_volume_access to restrict content type Fabian Ebner
2022-03-21 13:06 ` [pve-devel] [PATCH manager 1/2] pveam: remove: add content type check Fabian Ebner
2022-03-21 13:06 ` [pve-devel] [PATCH manager 2/2] api: vzdump: extract config: " Fabian Ebner
2022-03-21 13:06 ` [pve-devel] [PATCH container 1/1] api: create/modify: add content type checks Fabian Ebner
2022-03-21 13:06 ` [pve-devel] [PATCH qemu-server " Fabian Ebner

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=1648109081.y13k852cx6.astroid@nora.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal