[pve-devel] [RFC v10 qemu-server 6/7] api: support VM disk import
Fabian Grünbichler
f.gruenbichler at proxmox.com
Tue Feb 22 16:33:14 CET 2022
On February 22, 2022 1:11 pm, Fabian Ebner wrote:
> Am 13.01.22 um 11:08 schrieb Fabian Ebner:
>> @@ -89,6 +90,10 @@ my $check_storage_access = sub {
>> } else {
>> PVE::Storage::check_volume_access($rpcenv, $authuser, $storecfg, $vmid, $volid);
>> }
>> +
>> + if (my $source_image = $drive->{'import-from'}) {
>> + PVE::Storage::check_volume_access($rpcenv, $authuser, $storecfg, $vmid, $source_image);
>> + }
>> });
>>
>
> AFAICT, if $vmid doesn't match the one from the volume, the check
> requires Datastore.Allocate privileges on the storage, which might be a
> bit much for many scenarios. Should the check rather be something like
>
> if ($ownerid) {
> # check VM.Clone for owner VM
> # Note that v11 will use clone_disk() for such disks
sounds sensible to me - if it's possible to copy the volume (and other
stuff) already with that privilege, then re-using that check for the
similar functionality here is fine.
check_volume_access is like that because it assumes that the caller
already checked that changes/access to the guest itself is okay - so if
a 'foreign' volume is queried, it requires more permissions since it
assumes that assumption doesn't hold.
since most queries here will be for 'foreign' volumes, checking that
cloning from that owner is okay and then passing in that vmid instead of
the target one would probably be best (as that still handles the
question of whether accessing the source storage is okay in general),
and of course we'd need that fallback anyway in case there is no
owner/we don't have clone permissions?
> } else {
> # PVE::Storage::check_volume_access
> }
>
> ?
>
More information about the pve-devel
mailing list