Bug 1390345

Summary: libvirt cannot start machine w/ backing file & SELinux enabled
Product: [Community] Virtualization Tools Reporter: Nelson Araujo <nelson>
Component: libvirtAssignee: Libvirt Maintainers <libvirt-maint>
Status: CLOSED DEFERRED QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: berrange, libvirt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2024-12-17 12:12:09 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 Nelson Araujo 2016-10-31 18:34:19 UTC
Description of problem:

With SELinux in Enforcing mode


Version-Release number of selected component (if applicable):

libvirt-1.3.3.2-1.fc24.x86_64
kernel-4.7.9-200.fc24.x86_64
selinux-policy-targeted-3.13.1-191.19.fc24.noarch


How reproducible:
100%


Steps to Reproduce:
1. Create a .qcow2 image with a backing file
2. Set SELinux to Enforcing mode
3. Start the VM: "virsh start mymachine"

Actual results:

Access denied while accessing the template file.


Expected results:

VM to start


Additional info:

When libvirt attempts to start the VM, it sets a label with a ":s0:cXXX.cYYY" to the machine image. Although the template is "r--r--r--" and it is ":s0", and qemu user can access the machine it gets access denied.

type=AVC msg=audit(1477934362.744:2180): avc:  denied  { read } for  pid=19743 comm="qemu-system-x86" name="vm" dev="dm-2" ino=499679 scontext=system_u:system_r:svirt_t:s0:c284,c779 tcontext=system_u:object_r:default_t:s0 tclass=lnk_file permissive=0

By creating an image without the backing file (and no other changes) the VM starts successfully.

Comment 1 Daniel Berrangé 2024-12-17 12:12:09 UTC
Thank you for reporting this issue to the libvirt project. Unfortunately we have been unable to resolve this issue due to insufficient maintainer capacity and it will now be closed. This is not a reflection on the possible validity of the issue, merely the lack of resources to investigate and address it, for which we apologise. If you none the less feel the issue is still important, you may choose to report it again at the new project issue tracker https://gitlab.com/libvirt/libvirt/-/issues The project also welcomes contribution from anyone who believes they can provide a solution.