From: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH qemu-server 1/1] api2: add check_bridge_access for create/update vm
Date: Mon, 05 Jun 2023 09:24:27 +0200 [thread overview]
Message-ID: <1685949820.13thlnnkk8.astroid@yuna.none> (raw)
In-Reply-To: <2ded7b16a00bb521fe45c166e668e2eb26f074f2.camel@groupe-cyllene.com>
On June 2, 2023 2:12 pm, DERUMIER, Alexandre wrote:
> Le vendredi 02 juin 2023 à 13:43 +0200, Fabian Grünbichler a écrit :
>> a few more places that come to my mind that might warrant further
>> thinking or discussion:
>> - restoring a backup
> doesn't it also use create_vm ?
yes, but the potentially problematic parameters are coming from the
backup in that case, not $param :) we do check the storage permissions
at least, if we view nics on bridges/vnet as being the same kind of
entity as volumes on storages than it would make sense to also check
vnet permissions there (PVE::QemuServer -> $parse_backup_hints , but
probably that is not the best place for network related checks ;))
> __PACKAGE__->register_method({
> name => 'create_vm',
> path => '',
> method => 'POST',
> description => "Create or restore a virtual machine.",
>
>
>> - cloning a VM
>
> for cloning, we can't change the target bridge, so if user have access
> to the clone, isn't it enough ?
same as above - if we treat "volume on storage" and "nic in vnet" as
being equivalent, then cloning would also need to check whether I am
allowed to add new nics to a vnet via cloning (like we do for volumes,
even without a storage override set!). $check_storage_access_clone is
the current helper, a similar one could be added for nics.
note: we'd also need a similar patch for pve-container ;) but if you
want, I can handle that one once this series is done or almost done, the
current approach is guest-agnostic anyway so I don't expect any changes
required for container support.
next prev parent reply other threads:[~2023-06-05 7:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-26 7:33 [pve-devel] [PATCH qemu-server 0/1] api2: add check_bridge_access Alexandre Derumier
2023-05-26 7:33 ` [pve-devel] [PATCH qemu-server 1/1] api2: add check_bridge_access for create/update vm Alexandre Derumier
2023-06-02 11:43 ` Fabian Grünbichler
2023-06-02 12:12 ` DERUMIER, Alexandre
2023-06-05 7:24 ` Fabian Grünbichler [this message]
2023-06-06 4:38 ` DERUMIER, Alexandre
2023-06-02 11:43 ` [pve-devel] [PATCH qemu-server 0/1] api2: add check_bridge_access Fabian Grünbichler
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=1685949820.13thlnnkk8.astroid@yuna.none \
--to=f.gruenbichler@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.