Bug 491906
| Summary: | virt is fubar | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Bill Nottingham <notting> |
| Component: | libvirt | Assignee: | Daniel Veillard <veillard> |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | rawhide | CC: | berrange, clalance, crobinso, dwalsh, itamar, jkubin, markmc, mgrepl, rvokal, veillard, virt-maint |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-05-04 15:40:31 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
If you change the svirt image to svirt_image_t it should work. Did you change the context of this image or did you copy it to a particular directory? I just set a patch to virt-manager to label images automatically in the users home and /tmp directory. Just downloaded the boot.iso directly (from a root shell) to /var/lib/libvirt/images. WHat do you think about downloading to this directory instead? /var/lib/libvirt/boot Not that it would work now, but I do not want to allow svirt to rad all images in /var/lib/libvirt/images, which is currently labeled virt_image_t. libvirt changes the context to svirt_image_t:MCS when the image is running and back to virt_image_t when it completes. This prevents a running image from reading a non running image. Shared storage and read only shared storage has to be labeled something that svirt can read. Currently I am leaning toward virt_content_t. Which I could label /var/lib/libvirt/boot and all svirt images could read. The only reason I downloaded to /var/lib/libvirt/images is because that's where it needed to be for the proper context to be applied before sVirt came into play. Do we have a flag day scenario here, where before sVirt you need to do X, but after you need to do Y? Well I guess so. With svirt we are trying to prevent one image from stealing information from another, which is why we are chaning the image labels. libvirt is doing a lot of relabeling now but not on readonly content. So we need to label readonly content something different then a read/write image file and a read/write image file has to be labeled different then a read/write running image file. So my current thinking is we label images files that are not running qemu_image_t:s0, images that are running svirt_image_t:MCS, shared and read/only content as virt_content_t:s0. All users have to do is copy or install readonly content in a separate directory then the images directory to get labelling correct. Currently default labeling for /var/lib/libvirt/isos is virt_content_t that way, but this directory does not exist If we have a 'svirt_content_t' then we could also consider having libvirt automatically label read-only files with this context, so anyone already using ISOs in /var/lib/libvirt/images would not get broken. Yes we can do that but we don't want to do this for devices. /dev/cdrom for example, since we could remove rights to other non svirt processes that want to use the file/device. This looks like a dup of bug #493692, which has a patch *** This bug has been marked as a duplicate of bug 493692 *** |
Description of problem: type=AVC msg=audit(1237910177.043:171): avc: denied { read } for pid=4783 comm="qemu-system-x86" name="boot.iso" dev=sda2 ino=5551920 scontext=system_u:system_r:svirt_t:s0:c753,c788 tcontext=system_u:object_r:virt_image_t:s0 tclass=file Interestingly enough, the root fs for the image (not boot.iso) is *als* system_u:object_r:virt_image_t: ... and it's read fine. Version-Release number of selected component (if applicable): selinux-policy-targeted-3.6.8-3.fc11.noarch qemu-system-x86-0.10-0.9.kvm20090310git.fc11.x86_64 How reproducible: 100% Steps to Reproduce: 1. Attach a CDROM image to a F9 guest 2. Attempt to boot