[pve-devel] [PATCH storage] ZFSPlugin: untaint lun number

[Stoiko Ivanov]

ZFS over iSCSI fetches information about the disk-images via ssh, thus
the obtainted data is tainted (perlsec (1)).

Since pvedaemon runs with '-T' enabled trying to start a VM via GUI/API failed,
while it still worked via `qm` or `pvesh`.

The issue surfaced after commit cb9db10c1a9855cf40ff13e81f9dd97d6a9b2698 in
pve-common ('run_command: improve performance for logging and long lines'),
and results from concatenating the original (tainted) buffer to a variable,
instead of a captured subgroup.

Untainting the value in ZFSPlugin should not cause any regressiosn, since the
other 3 target providers already have a match on '\d+' for retrieving the
lun number.

reported via pve-user [0].

reproduced and tested by setting up a LIO-target (on top of a virtual PVE),
adding it as storage and trying to start a guest (with a disk on the
ZFS over iSCSI storage) with `perl -T /usr/sbin/qm start $vmid`

[0] https://lists.proxmox.com/pipermail/pve-user/2020-October/172055.html

Signed-off-by: Stoiko Ivanov <s.ivanov at proxmox.com>
---
 PVE/Storage/ZFSPlugin.pm | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/PVE/Storage/ZFSPlugin.pm b/PVE/Storage/ZFSPlugin.pm
index 383f0a0..63b9551 100644
--- a/PVE/Storage/ZFSPlugin.pm
+++ b/PVE/Storage/ZFSPlugin.pm
@@ -159,7 +159,11 @@ sub zfs_get_lun_number {
 
     die "could not find lun_number for guid $guid" if !$guid;
 
-    return $class->zfs_request($scfg, undef, 'list_view', $guid);
+    if ($class->zfs_request($scfg, undef, 'list_view', $guid) =~ /^(\d+)$/) {
+	return $1;
+    }
+
+    die "lun_number for guid $guid is not a number";
 }
 
 # Configuration
-- 
2.20.1