>>@Alexandre: please set the permissions to root@pam only for this new API >>path.
yes, sure. >>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. Ok, I'll look at this. ----- Mail original ----- De: "Fabian Grünbichler" <[email protected]> À: "pve-devel" <[email protected]> Cc: "aderumier" <[email protected]> Envoyé: Mercredi 14 Novembre 2018 11:37:16 Objet: Re: [pve-devel] [PATCH qemu-server 1/7] api2 : migrate_vm : add migration_type "external" 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
