Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
Prepare a image with root user:
# ll /var/lib/libvirt/images/test.qcow2 -Z
-rw-rw-rw-. root root system_u:object_r:virt_image_t:s0 /var/lib/libvirt/images/test.qcow2
With non-root user, start a guest, and attach the disk to guest:
$ virsh start rhel7
Domain rhel7 started
$ virsh attach-disk rhel7 --source /var/lib/libvirt/images/test.qcow2 --target vdb --mode readonly
error: Failed to attach disk
error: internal error: unable to execute QEMU command '__com.redhat_drive_add': Device 'drive-virtio-disk1' could not be initialized
libvirt log
error : virSecuritySELinuxSetFileconHelper:920 : unable to set security context 'system_u:object_r:virt_content_t:s0' on '/var/lib/libvirt/images/test.qcow2': Operation not permitted
qemu log:
Could not open '/var/lib/libvirt/images/test.qcow2': Permission denied
Version-Release number of selected component:
libvirt-2.0.0-6.el7.x86_64
How reproducible:
100%
Steps to Reproduce:
As the description
Actual results:
Attach disk failed with unclear error
Expected results:
Attach disk failed and output error "Permission denied"
Hm, now that I'm checking the code, I'm not sure this is an error. I'd say this is expected behaviour. From src/security/security_selinux.c:
static int
virSecuritySELinuxSetFileconHelper(const char *path, char *tcon,
bool optional, bool privileged)
{
/* ... */
virReportSystemError(setfilecon_errno,
_("unable to set security context '%s' on '%s'"),
tcon, path);
/* However, don't claim error if SELinux is in Enforcing mode and
* we are running as unprivileged user and we really did see EPERM.
* Otherwise we want to return error if SELinux is Enforcing. */
if (security_getenforce() == 1 && (setfilecon_errno != EPERM || privileged))
return -1;
/* ... */
return 0;
}
http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/security/security_selinux.c;h=4be946d2e872657ce5a01be786f9236e393d1699;hb=HEAD#l883
IOW, when daemon is running unde non-privileged user, we just do our best and hope it works. We can't be sure that even if relabelling fails qemu is denied access. I mean, libvirt would need to parse selinux policies, all the linux users & groups, AppArmor rules, ACLs to be 100% sure whether qemu will or will not have the access (when relabelling fails). So we don't undertake all the burden and just let qemu find out itself.