public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Dominik Csapak <d.csapak@proxmox.com>
To: "Proxmox VE development discussion" <pve-devel@lists.proxmox.com>,
	"Fiona Ebner" <f.ebner@proxmox.com>,
	"Fabian Grünbichler" <f.gruenbichler@proxmox.com>
Subject: Re: [pve-devel] [PATCH v2 qemu-server 1/1] disk import: add additional safeguards for imported image files
Date: Fri, 15 Nov 2024 10:55:05 +0100	[thread overview]
Message-ID: <787aaaa9-1f7a-49c8-925e-49308d24df0d@proxmox.com> (raw)
In-Reply-To: <5940b821-b931-4b4a-8262-05c12f7c7cdc@proxmox.com>

On 11/15/24 10:49, Fiona Ebner wrote:
> On 15.11.24 10:42 AM, Fiona Ebner wrote:
>> On 04.11.24 11:42 AM, Fabian Grünbichler wrote:
>>> creating non-raw disk images with arbitrary content is only possible with raw
>>> access to the storage, but checking for references to external files doesn't
>>> hurt.
>>>
>>> Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
>>> ---
>>>
>>> Notes:
>>>      requires pve-storage change to actually have an effect
>>>      
>>>      v2:
>>>      - re-order code to improve readability
>>>      - extract $path into variable to avoid scalar vs array context issue
>>>
>>>   PVE/API2/Qemu.pm | 18 +++++++++++++++---
>>>   1 file changed, 15 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
>>> index 848001b6..ae0c39bf 100644
>>> --- a/PVE/API2/Qemu.pm
>>> +++ b/PVE/API2/Qemu.pm
>>> @@ -412,18 +412,29 @@ my sub create_disks : prototype($$$$$$$$$$) {
>>>   
>>>   		$needs_creation = $live_import;
>>>   
>>> -		if (PVE::Storage::parse_volume_id($source, 1)) { # PVE-managed volume
>>> +		my ($source_storage, $source_volid) = PVE::Storage::parse_volume_id($source, 1);
>>> +
>>> +		if ($source_storage) { # PVE-managed volume
>>>   		    if ($live_import && $ds ne 'efidisk0') {
>>>   			my $path = PVE::Storage::path($storecfg, $source)
>>>   			    or die "failed to get a path for '$source'\n";
>>>   			$source = $path;
>>> -			($size, my $source_format) = PVE::Storage::file_size_info($source);
>>> +			# check potentially untrusted image file!
>>> +			($size, my $source_format) = PVE::Storage::file_size_info($source, undef, 1);
>>> +
>>>   			die "could not get file size of $source\n" if !$size;
>>>   			$live_import_mapping->{$ds} = {
>>>   			    path => $source,
>>>   			    format => $source_format,
>>>   			};
>>>   		    } else {
>>> +			# check potentially untrusted image file!
>>> +			my $scfg = PVE::Storage::storage_config($storecfg, $source_storage);
>>> +			if ($scfg->{path}) {
>>
>> Is there a special reason this is made conditional on the presence of
>> $scfg->{path}? Note that the above check for live import isn't.
>> Shouldn't matter much right now (except if there is a weird third-party
>> plugin that has qcow2 and doesn't use $scfg->{path}), but as long as we
>> get a result for PVE::Storage::path(), we should be able to call
>> file_size_info() too, right?
>>
> 
> Or maybe not, but then live-import should've used volume_size_info() too
> I guess? I think it would be good to add an 'untrusted' flag to
> volume_size_info() too and have the storage layer do the right thing,
> rather than manually checking $scfg->{path} here.
> 
> 
my 2 cents:

the checking of untrusted images is mainly helpful for file based volumes
(such as qcow2/vmdk/etc.) where we can detect backing images etc.

the check for 'path' is how we ususually determine if a storage is
file-based or not (would probably better to have that check
in storage and it should probably check for qcow2/vmdk/etc. support)

but we already use that check in some places


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

  reply	other threads:[~2024-11-15  9:55 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-04 10:42 [pve-devel] [PATCH v2 storage/guest-common/qemu-server 0/3] harden import of file-based volumes Fabian Grünbichler
2024-11-04 10:42 ` [pve-devel] [PATCH v2 guest-common 1/1] storage tunnel: check just-imported image files Fabian Grünbichler
2024-11-04 10:42 ` [pve-devel] [PATCH v2 storage 1/1] file_size_info: implement untrusted mode Fabian Grünbichler
2024-11-07 12:16   ` Fiona Ebner
2024-11-14  9:33   ` Dominik Csapak
2024-11-14 18:14   ` [pve-devel] applied: " Thomas Lamprecht
2024-11-04 10:42 ` [pve-devel] [PATCH v2 qemu-server 1/1] disk import: add additional safeguards for imported image files Fabian Grünbichler
2024-11-14  9:34   ` Dominik Csapak
2024-11-15  9:42   ` Fiona Ebner
2024-11-15  9:49     ` Fiona Ebner
2024-11-15  9:55       ` Dominik Csapak [this message]
2024-11-15 10:05         ` Fiona Ebner
2024-11-15 10:16           ` Dominik Csapak
2024-11-15 10:15   ` Fiona 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=787aaaa9-1f7a-49c8-925e-49308d24df0d@proxmox.com \
    --to=d.csapak@proxmox.com \
    --cc=f.ebner@proxmox.com \
    --cc=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 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