Bug 2066773

This is another side effect of https://bugzilla.redhat.com/show_bug.cgi?id=1045069
When virt-v2v runs as root, libvirt runs qemu as a non-root user (eg. qemu:qemu).
This means that qemu cannot open /tmp/v2v.<RAND>/in0, with this error:

  [   1.0] Opening the source
  virt-v2v: error: libguestfs error: could not create appliance through 
  libvirt.

  Try running qemu directly without libvirt using this environment variable:
  export LIBGUESTFS_BACKEND=direct

  Original error from libvirt: internal error: process exited while 
  connecting to monitor: 2022-03-22T13:19:56.454788Z qemu-kvm: -blockdev 
  {"driver":"nbd","server":{"type":"unix","path":"/tmp/v2v.AuSBWm/in0"},"node-name":"libvirt-2-storage","cache":{"direct":false,"no-flush":true},"auto-read-only":true,"discard":"unmap"}: 
  Failed to connect to '/tmp/v2v.AuSBWm/in0': Permission denied [code=1 
  int1=-1]

(With LIBGUESTFS_BACKEND=direct it does work because we don't use libvirt).

To avoid this we have to set the directory with that socket to 0711:

https://github.com/libguestfs/virt-v2v/blob/b365a87b99a7630afc974667dbe23135e35ba4d0/v2v/v2v.ml#L48

This avoids the above error, but introduces the current one instead.

Patch posted:
https://listman.redhat.com/archives/libguestfs/2022-March/028449.html

Additional cleanup after Rich's v3:

[v2v PATCH] nbdkit, qemuNBD: run_unix: formally require externally provided socket
Message-Id: <20220323104330.9667-1-lersek>
https://listman.redhat.com/archives/libguestfs/2022-March/028464.html

Upstream commits:

     1  4e7f20684373 lib: Improve security of in/out sockets when running virt-v2v as root
     2  9788b06765af nbdkit, qemuNBD: run_unix: formally require externally provided socket

Verified with virt-v2v-2.0.1-1.el9.x86_64.

1. Run v2v by root and check the permission of the /tmp/v2v.xxx directory.
# ll /tmp/v2v.LSsUhy
total 12
-rw-r--r--. 1 root root   0 Mar 24 06:37 copy
srwx------. 1 qemu root   0 Mar 24 06:35 in0
srwx------. 1 qemu root   0 Mar 24 06:37 out0
-rw-r--r--. 1 root root 471 Mar 24 06:37 out.params0.json
-rw-------. 1 root root 168 Mar 24 06:37 v2vprecheck.json
-rw-------. 1 root root 173 Mar 24 06:37 v2vtransfer.json

2. Access the file in that directory by non-root user.
$ ll -d /tmp/v2v.LSsUhy
drwx------. 2 qemu root 113 Mar 24 06:37 /tmp/v2v.LSsUhy
$ ll /tmp/v2v.LSsUhy/in0
ls: cannot access '/tmp/v2v.LSsUhy/in0': Permission denied

3. Run automation scripts to verify the basic function and make sure no regression. 

# avocado run --vt-type v2v convert_vm_to_ovirt.esx.vm.7_0.linux.latest8.arch_x86_64.raw_f.NFS.rhv_upload.rhv_direct.rhv_noverifypeer.preallocated.it_vddk convert_vm_to_ovirt.esx.vm.6_5.linux.latest8.arch_x86_64.raw_f.NFS.rhv_upload.rhv_direct.rhv_noverifypeer.preallocated.it_vddk
JOB ID     : af2d095bd50ec34f53b79fae4d08c2c4faa75bbf
JOB LOG    : /root/avocado/job-results/job-2022-03-24T06.35-af2d095/job.log
 (1/2) type_specific.io-github-autotest-libvirt.convert_vm_to_ovirt.esx.vm.7_0.linux.latest8.arch_x86_64.raw_f.NFS.rhv_upload.rhv_direct.rhv_noverifypeer.preallocated.it_vddk: STARTED
█ 100% [****************************************]
 (1/2) type_specific.io-github-autotest-libvirt.convert_vm_to_ovirt.esx.vm.7_0.linux.latest8.arch_x86_64.raw_f.NFS.rhv_upload.rhv_direct.rhv_noverifypeer.preallocated.it_vddk: PASS (306.28 s)
 (2/2) type_specific.io-github-autotest-libvirt.convert_vm_to_ovirt.esx.vm.6_5.linux.latest8.arch_x86_64.raw_f.NFS.rhv_upload.rhv_direct.rhv_noverifypeer.preallocated.it_vddk: STARTED
█ 100% [****************************************]
 (2/2) type_specific.io-github-autotest-libvirt.convert_vm_to_ovirt.esx.vm.6_5.linux.latest8.arch_x86_64.raw_f.NFS.rhv_upload.rhv_direct.rhv_noverifypeer.preallocated.it_vddk: PASS (2075.30 s)
RESULTS    : PASS 2 | ERROR 0 | FAIL 0 | SKIP 0 | WARN 0 | INTERRUPT 0 | CANCEL 0
JOB TIME   : 2382.91 s

# avocado run --vt-type v2v convert_from_file.positive_test.linux.input_mode.ova.parse.SHA1_SHA256.output_mode.rhev.rhv_upload
JOB ID     : 082a05a6a536dbf4ab60ad5f1171dad2e6c82c9c
JOB LOG    : /root/avocado/job-results/job-2022-03-24T06.22-082a05a/job.log
 (1/1) type_specific.io-github-autotest-libvirt.convert_from_file.positive_test.linux.input_mode.ova.parse.SHA1_SHA256.output_mode.rhev.rhv_upload: STARTED
█ 100% [****************************************]
 (1/1) type_specific.io-github-autotest-libvirt.convert_from_file.positive_test.linux.input_mode.ova.parse.SHA1_SHA256.output_mode.rhev.rhv_upload: PASS (120.45 s)
RESULTS    : PASS 1 | ERROR 0 | FAIL 0 | SKIP 0 | WARN 0 | INTERRUPT 0 | CANCEL 0
JOB TIME   : 122.41 s

*** Bug 2068136 has been marked as a duplicate of this bug. ***

The automation job were also triggered to make sure there is no regression issue.

https://libvirt-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/v2v/view/RHEL-9.1/job/v2v-RHEL-9.1-runtest-x86_64-function-function_test_esx-rhel/1/testReport/rhel/function_test_esx/
https://libvirt-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/v2v/view/RHEL-9.1/job/v2v-RHEL-9.1-runtest-x86_64-function-convert_from_file-rhel/1/testReport/rhel/convert_from_file/
https://libvirt-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/v2v/view/RHEL-9.1/job/v2v-RHEL-9.1-runtest-x86_64-function-function_test_xen-rhel/1/testReport/rhel/function_test_xen/

The failure script in the jobs were known issues and have nothing to do with this bug.

So I think this bug can be moved to VERIFIED.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Low: virt-v2v security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2022:7968