Bug 1700372

Summary:	Label correctly unique/temporary directories
Product:	Red Hat Enterprise Linux Advanced Virtualization	Reporter:	Jaroslav Suchanek <jsuchane>
Component:	libvirt	Assignee:	Martin Kletzander <mkletzan>
Status:	CLOSED ERRATA	QA Contact:	chhu
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	8.1	CC:	chhu, dyuan, fdeutsch, jdenemar, knoel, lhuang, lmen, mkletzan, vromanso, xuzhang, yafu, yalzhang
Target Milestone:	pre-dev-freeze
Target Release:	8.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	libvirt-5.3.0-1.el8	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-11-06 07:14:08 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jaroslav Suchanek 2019-04-16 12:03:39 UTC

Problem originally reported here:
https://github.com/kubevirt/kubevirt/pull/2181

Fixed by following commit:
commit 673f805d4df2484bc2a5cc637524e92c0cbc5584
Author:     Martin Kletzander <mkletzan>
AuthorDate: Fri Apr 12 15:22:48 2019 +0200
Commit:     Martin Kletzander <mkletzan>
CommitDate: Sat Apr 13 00:56:45 2019 +0200

    qemu: Label uniqDir when probing capabilities
    
    This does not cause a problem in usual scenarios thanks to us allowing
    CAP_DAC_OVERRIDE for the qemu process, however in some scenarios this might be
    an issue because the directory is created with mkdtemp(3) which explicitly
    creates that with 0700 permissions and qemu running as non-root cannot access
    that.
    
    The scenarios include:
     - Builds without CAPNG
     - Running libvirtd in certain container configurations [1]
     - and possibly others.
    
    [1] https://github.com/kubevirt/kubevirt/pull/2181#issuecomment-481840304
    
    Signed-off-by: Martin Kletzander <mkletzan>
    Reviewed-by: Daniel P. Berrangé <berrange>

v5.2.0-256-g673f805

Comment 5 chhu 2019-09-05 02:42:18 UTC

Reproduce this issue with libvirt build without CAPNG, please see more details as below:
1. Git upstream libvirt code, build libvirt without CAPNG:
libvirt-daemon-kvm-5.2.0-1.el8.x86_64.rpm
2. Install libvirt 5.2.0-1.el8.x86_64
# systemctl start libvirtd
3. Try to start VM
# virsh define r8-1.xml
error: Failed to define domain from r8-1.xml
error: invalid argument: could not find capabilities for arch=x86_64 domaintype=kvm

4. Check the /var/log/message, get error log:
-----------------------------------------------------------------------------------------------------
Sep 4 03:57:27 hp-*** journal[4581]: internal error: Failed to start QEMU binary /usr/libexec/qemu-kvm for probing: qemu-kvm: could not acquire pid file: Permission denie
......
Sep 4 03:58:18 hp-*** journal[4581]: Failed to probe capabilities for /usr/libexec/qemu-kvm: internal error: Failed to start QEMU binary /usr/libexec/qemu-kvm for probing: qemu-kvm: could not acquire pid file: Permission denied
Sep 4 03:58:18 hp-*** journal[4581]: invalid argument: could not find capabilities for arch=x86_64 domaintype=kvm
-------------------------------------------------------------------------------------------------

Test steps:
1. Get libvirt-5.6.0-1.module+el8.1.0+3890+4d3d259c.src.rpm,
build libvirt without CAPNG:
libvirt-daemon-kvm-5.6.0-1.el8.x86_64

2. Install libvirt 5.6.0-1.el8.x86_64
# systemctl start libvirtd
3. Start VM successfully. Login to VM, ifconfig,touch command work well
# virsh define r8-1.xml
Domain r8 defined from r8-1.xml
# virsh start r8
Domain r8 started

4. Check the log, no error like below:
"internal error: Failed to start QEMU binary /usr/libexec/qemu-kvm for probing: qemu-kvm: could not acquire pid file: Permission denie"
# cat /var/log/messages|grep qemu-kvm
# cat /var/log/messages|grep "Permission denied"

Comment 10 errata-xmlrpc 2019-11-06 07:14:08 UTC

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, 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/RHBA-2019:3723