| Summary: | QEMU DAC security driver should not chown of iso images (on NFS shares) | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Daniel Riek <riek> |
| Component: | libvirt | Assignee: | Laine Stump <laine> |
| Status: | CLOSED DUPLICATE | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.1 | CC: | agraham, berrange, bjohnson, bsarathy, clalance, cra, crobinso, dallan, daniel.riek, dswegen, dyuan, frankly3d, gren, gscarborough, gsun, itamar, jflorian, jlaska, kraxel, me, mmilgram, petersen, rjones, rwu, tichikawa, twaugh, veillard, virt-maint, walkerrichardj, whuang, yaneti, yury |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 517304 | Environment: | |
| Last Closed: | 2011-09-28 06:26:23 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Daniel Riek
2011-06-09 17:08:18 UTC
One addition: if I understand NFS4 right, this bug means that the user QEMU has to actually exist on the storage server or at least be visible to idmap in the server - so in addition to having to allow qemu to chown files, you have to create users that should not have to exist. Build: RHEL6.2-20110623.n.0 Packages: # rpm -q libvirt virt-manager kernel libvirt-0.9.3-2.el6.x86_64 virt-manager-0.8.6-4.el6.noarch kernel-2.6.32-166.el6.x86_64 The nfs server is with (rw,no_root_squash) Steps: 1. #setsebool virt_use_nfs on This allows all virtual machine to read/write nfs share that do not specify a mount context. 2. mount the share # mount -o context="system_u:object_r:virt_content_t:s0" 10.66.6.148:/var/lib/libvirt/images/ /mnt 3. check the label and chown # ll -Z /mnt/ -rw-r--r--. qemu qemu system_u:object_r:nfs_t:s0 RHEL6.0-20100922.1-Server-x86_64-DVD1.iso The chown is qemu:qemu, and label is not as set. # mount |grep virt 10.66.90.121:/vol/S3/libvirtauto on /media type nfs (rw,addr=10.66.90.121) 10.66.6.148:/var/lib/libvirt/images/ on /mnt type nfs (rw,context="system_u:object_r:virt_content_t:s0",vers=4,addr=10.66.6.148,clientaddr=10.66.7.191) but the label shows by mount is as set 4. In virt-manager choose install media from local iso, use /mnt/RHEL6.0-20100922.1-Server-x86_64-DVD1.iso The installation success There is no error of permission denied this way. Without set virt_use_nfs on in last comment. the installation will fail at step 4, and permission denied error msg appear. So, maybe this bug is related to: Bug 589922 - permission denied error for NFS image, should libvirt error message mention virt_use_nfs? https://bugzilla.redhat.com/show_bug.cgi?id=589922 The problem is not SELinux-related. It's that libvirt takes *ownership* of the file, fails if it can't. - All of which creates multiple problems and is completely unnecessary. Hi! I am also annoyed by the fact that libvirt changes the ownership and SELinux security type of the ISO files. It doesn't matter whether it happens on the NFS shares or not, but on the NFS shares it's particularly harmful, because it causes a failure as stated by the reporter. To my mind, there is no reason why libvirt would need to be able to write to the *read-only* ISO images as long as it does have read access to them, and also, potentially, this might lead to privilege escalation issues. FYI, I have found a patch to work around this issue: https://launchpadlibrarian.net/61177315/debdiff This is already included in latest Ubuntu, however, I feel that it might be incomplete, because it doesn't seem to check whether there are read flags on; but whatever, let the competent people to find out the correct solution to this problem. Thanks, Z. If you look at the function virSecurityDACSetOwnership() (which is what is doing the chowning), you will see that it does the following if the chown fails: 1) it will check the current owner/group of the file, and if it matches the qemu user/group, it will return success 2) it will check if the errno of the failed chown is EOPNOTSUPP or EINVAL, and if so will log an INFO message saying that the file system doesn't support chowning the file, but still return success. Item (2) is explained more fully in Bug 702044 (reported against RHEL6.1, fixed in libvirt-0.9.2-1), which is *very* similar to this bug. Just to verify that this is a non-issue, I ran the following test: 1) mount an NFS share containing ISO images with both r/o and root_squash turned on. 2) Attempt installing a guest using one of those ISO images which was owned by qemu:qemu - SUCCESS. 3) Attempt mounting a different ISO image owned by root:root (permissions 0644) on an existing guest - SUCCESS. As far as I can see, this bug is reporting the same issue as Bug 702044, and was fixed as of libvirt-0.9.2-1. *** This bug has been marked as a duplicate of bug 702044 *** |