On Tue, Nov 13, 2018 at 11:22:23AM +0100, Dietmar Maurer wrote:
> I would like to move forward with that, but changing an existing API makes
> that difficult.
>
> I would suggest to add a second API entry point instead:
>
> __PACKAGE__->register_method({
> name => 'external_migrate_vm',
> path => '{vmid}/external_migrate',
> method => 'POST',
> ...
>
> Feel free to choose a better name ;-) We can the mark this API as
> unstable/experimental, and modify
> the parameters/types. IMHO most existing parameters does not really makes
> sense with external migration.
> I guess it is still possible to factor out most common code to avoid code
> duplication.
>
> What do you think?
@Alexandre: please set the permissions to root@pam only for this new API
path.
I see the following problematic aspects otherwise:
- potential back channel from a user/attacker-controlled target host to
the source node via bugs in Qemu (might not even require a bug?)
- enumeration of hosts that root@pam can automatically connect to
- intrusion into node/cluster that root@pam can automatically connect to
by live-migrating user/attacker-controlled VM there and trying to
escape VM (e.g., the bridge/network there might have totally different
assumptions about the trustworthiness of the attached guests, the
node/cluster might not have the same patch level, etc.pp.)
given the above, I am not sure whether a model with explicit public keys
to target mapping somewhere in /etc/pve/priv/ might not be preferable
even with a limitation to root@pam.
_______________________________________________
pve-devel mailing list
[email protected]
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
