From: Fiona Ebner <f.ebner@proxmox.com>
To: Daniel Kral <d.kral@proxmox.com>,
Thomas Ellmenreich <t.ellmenreich@proxmox.com>,
pve-devel@lists.proxmox.com
Subject: Re: [PATCH qemu-server v2 1/2] refactor checks for absolute path as drive
Date: Wed, 22 Jul 2026 16:01:50 +0200 [thread overview]
Message-ID: <0b4272e1-3634-4fdd-b79f-6b077dd387d5@proxmox.com> (raw)
In-Reply-To: <DK53YSH7NPZ2.1SP4SG7GC2J11@proxmox.com>
Am 22.07.26 um 2:45 PM schrieb Daniel Kral:
> On Wed Jul 22, 2026 at 11:52 AM CEST, Thomas Ellmenreich wrote:
>> Previously there were a bunch of separate checks for whether a drive was
>> an absolute path. These have been refactored to use two checks in
>> QemuServer::Drive and QemuServer::Helpers.
While these helpers are fine at a glance, a classify_drive_volid()
similar to LXC/Config.pm's classify_mountpoint() might be a bit nicer in
the long run. It could return 'absolute', 'none', 'cdrom' and 'volume'.
>> @@ -913,7 +914,7 @@ PVE::JSONSchema::register_format(
>> sub verify_volume_id_or_absolute_path {
>> my ($volid, $noerr) = @_;
>>
>> - return $volid if $volid =~ m|^/|;
>> + return $volid if PVE::QemuServer::Helpers::is_absolute_path($volid);
>>
>> $volid = eval { PVE::JSONSchema::check_format('pve-volume-id', $volid, '') };
>> if ($@) {
>> @@ -1555,7 +1556,7 @@ sub print_vga_device {
>> sub vm_is_volid_owner {
>> my ($storecfg, $vmid, $volid) = @_;
>>
>> - if ($volid !~ m|^/|) {
>> + if (!PVE::QemuServer::Helpers::is_absolute_path($volid)) {
>> my ($path, $owner);
>> eval { ($path, $owner) = PVE::Storage::path($storecfg, $volid); };
>> log_warn("ownership of volume '$volid' could not be determined: $@") if $@;
>> @@ -1841,11 +1842,9 @@ sub destroy_vm {
>> { include_unused => 1 },
>> sub {
>> my ($ds, $drive) = @_;
>> - return if drive_is_cdrom($drive);
>> + return if drive_is_cdrom($drive) || drive_is_absolute_path($drive);
>>
>> my $volid = $drive->{file};
>> - return if !$volid || $volid =~ m|^/|;
>
> Hm, the !$volid check should be included in the check above as well as
> drive_is_absolute_path() doesn't check this and shouldn't need to.
>
> Though if there's good reason that !$volid will never be true here, this
> can be removed in a previous commit with a clear reasoning why.
We should be protected. We don't allow empty values as part of a
property string and even if, the schema validation against
'pve-volume-id-or-qm-path' would fail. The implementation in
foreach_volume_full() in pve-guest-common won't call the closure if
parsing fails. So I think dropping the check is fine. If it really
triggers, it will just result in a warning pointing to a programming
error somewhere else, which we should fix then.
next prev parent reply other threads:[~2026-07-22 14:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-22 9:52 [PATCH qemu-server v2 0/2] fix #7828: avoid parsing absolute paths as volume ids Thomas Ellmenreich
2026-07-22 9:52 ` [PATCH qemu-server v2 1/2] refactor checks for absolute path as drive Thomas Ellmenreich
2026-07-22 12:45 ` Daniel Kral
2026-07-22 13:40 ` Thomas Ellmenreich
2026-07-22 14:01 ` Fiona Ebner [this message]
2026-07-22 9:52 ` [PATCH qemu-server v2 2/2] fix #7828: avoid parsing absolute paths as volume ids Thomas Ellmenreich
2026-07-22 13:01 ` Fiona Ebner
2026-07-22 13:11 ` Thomas Ellmenreich
2026-07-22 14:10 ` Elias Huhsovitz
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=0b4272e1-3634-4fdd-b79f-6b077dd387d5@proxmox.com \
--to=f.ebner@proxmox.com \
--cc=d.kral@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
--cc=t.ellmenreich@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