Bug 1717768 - blockcommit failed due to permission deny when selinux in Enforcing mode
Summary: blockcommit failed due to permission deny when selinux in Enforcing mode
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux Advanced Virtualization
Classification: Red Hat
Component: libvirt
Version: 8.1
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: 8.0
Assignee: Peter Krempa
QA Contact: yisun
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-06-06 07:27 UTC by yisun
Modified: 2020-11-14 08:37 UTC (History)
8 users (show)

Fixed In Version: libvirt-5.5.0-1.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-11-06 07:16:08 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
libvirtd debug log (3.05 MB, text/plain)
2019-06-06 07:27 UTC, yisun
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:3723 0 None None None 2019-11-06 07:17:06 UTC

Description yisun 2019-06-06 07:27:09 UTC
Created attachment 1577795 [details]
libvirtd debug log

Description of problem:
blockcommit failed due to permission deny when selinux in Enforcing mode

versions:
(.libvirt-ci-venv-ci-runtest-L7pPd9) [root@jslave-libvirt-rhel-8 images]# rpm -qa | egrep "libvirt-5|qemu-kvm-4|selinux|kernel-4"
selinux-policy-3.14.3-8.el8.noarch
libselinux-2.9-1.el8.x86_64
libselinux-utils-2.9-1.el8.x86_64
qemu-kvm-4.0.0-3.module+el8.1.0+3265+26c4ed71.x86_64
libvirt-5.4.0-1.module+el8.1.0+3304+7eb41d5f.x86_64
selinux-policy-targeted-3.14.3-8.el8.noarch
kernel-4.18.0-94.el8.x86_64


How reproducible:
100%


Steps to Reproduce:
1. have a running vm
(.libvirt-ci-venv-ci-runtest-L7pPd9) [root@jslave-libvirt-rhel-8 images]# virsh start vm1
Domain vm1 started

(.libvirt-ci-venv-ci-runtest-L7pPd9) [root@jslave-libvirt-rhel-8 images]# ll -Z
total 780224
-rw-r--r--. 1 qemu qemu system_u:object_r:svirt_image_t:s0:c438,c643 798949376 Jun  6 03:16 jeos-27-x86_64.qcow2

(.libvirt-ci-venv-ci-runtest-L7pPd9) [root@jslave-libvirt-rhel-8 images]# virsh domblklist vm1
 Target   Source
--------------------------------------------------------
 vda      /var/lib/libvirt/images/jeos-27-x86_64.qcow2

2. create a snapshot for its vda
(.libvirt-ci-venv-ci-runtest-L7pPd9) [root@jslave-libvirt-rhel-8 images]# virsh snapshot-create-as vm1 snap1 --disk-only  vda,snapshot=external,file=/var/lib/libvirt/images/vm1.snap1
Domain snapshot snap1 created

(.libvirt-ci-venv-ci-runtest-L7pPd9) [root@jslave-libvirt-rhel-8 images]# ll -Z
total 780420
-rw-r--r--. 1 qemu qemu system_u:object_r:svirt_image_t:s0:c438,c643 798949376 Jun  6 03:16 jeos-27-x86_64.qcow2
-rw-------. 1 qemu qemu system_u:object_r:svirt_image_t:s0:c438,c643    196768 Jun  6 03:16 jeos-27-x86_64.snap1

3. do the blockcommit to merge the snapshot, failed as follow:
(.libvirt-ci-venv-ci-runtest-L7pPd9) [root@jslave-libvirt-rhel-8 images]# virsh blockcommit vm1 vda --wait --verbose --active --pivot
error: internal error: unable to execute QEMU command 'block-commit': Could not reopen file: Permission denied

(.libvirt-ci-venv-ci-runtest-L7pPd9) [root@jslave-libvirt-rhel-8 images]# ll -Z
total 780420
-rw-r--r--. 1 qemu qemu system_u:object_r:virt_content_t:s0          798949376 Jun  6 03:16 jeos-27-x86_64.qcow2
-rw-------. 1 qemu qemu system_u:object_r:svirt_image_t:s0:c438,c643    196768 Jun  6 03:16 jeos-27-x86_64.snap1

4. if set selinux to Permissive mode, blockcommit could work:
(.libvirt-ci-venv-ci-runtest-L7pPd9) [root@jslave-libvirt-rhel-8 images]# setenforce 0

(.libvirt-ci-venv-ci-runtest-L7pPd9) [root@jslave-libvirt-rhel-8 images]# virsh blockcommit vm1 vda --wait --verbose --active --pivot
Block commit: [100 %]
Successfully pivoted

Actual results:
blockcommit failed due to permission denied if set selinux to Enforcing mode

Expected results:
blockcommit should work well

Additional info:
not reproduced in previous versions

Comment 2 Peter Krempa 2019-06-12 09:55:00 UTC
This was broken in v5.4.0 and will be fixed in v5.5.0

commit 4c4953fb37158025c8216e96a9e0cbd0b7e03e1e
Author: Peter Krempa <pkrempa>
Date:   Tue Jun 11 16:38:02 2019 +0200

    qemu: domain: Allow forcing images to read-write in qemuDomainStorageSourceAccessAllow
    
    In commit 76b9aba2ba6 I refactored how the function treats the readonly
    flag which introduced a bug when we'd not allow to force read-write
    state for an image.
    
    This created problems with blockjobs where we need to temporarily
    force images to have read-write permissions.
    
    Rename QEMU_DOMAIN_STORAGE_SOURCE_ACCESS_READ_ONLY to
    QEMU_DOMAIN_STORAGE_SOURCE_ACCESS_FORCE_READ_ONLY and also introduce
    a complement QEMU_DOMAIN_STORAGE_SOURCE_ACCESS_FORCE_READ_WRITE which
    will allow to force write access.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1717768
    
    Signed-off-by: Peter Krempa <pkrempa>
    Reviewed-by: Ján Tomko <jtomko>

commit 9961e7799a6943655e5a976e62e789deded576ef
Author: Peter Krempa <pkrempa>
Date:   Tue Jun 11 15:16:09 2019 +0200

    qemu: domain: Fix logic bug in qemuDomainStorageSourceAccessAllow
    
    In commit 76b9aba2ba6 I tried to refactor qemuDomainStorageSourceAccessAllow
    but used wrong operators for adding bitwise flags.
    
    This way the flags would result in 0 if any of them would be applied.
    
    Signed-off-by: Peter Krempa <pkrempa>
    Reviewed-by: Ján Tomko <jtomko>

Comment 4 yisun 2019-07-05 02:43:11 UTC
verified by the auto job with following pkgs:
libvirt-5.5.0-1.module+el8.1.0+3580+d7f6488d.x86_64
qemu-kvm-4.0.0-4.module+el8.1.0+3523+b348b848.x86_64
kernel-4.18.0-107.el8.x86_64
selinux-policy-3.14.3-9.el8.noarch
libcgroup-0.41-19.el8.x86_64
systemd-239-15.el8.x86_64
dnsmasq-2.79-4.el8.x86_64

Comment 7 errata-xmlrpc 2019-11-06 07:16: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


Note You need to log in before you can comment on or make changes to this bug.