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.iva...@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 _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel