Bug 491906

Summary: virt is fubar
Product: [Fedora] Fedora Reporter: Bill Nottingham <notting>
Component: libvirtAssignee: Daniel Veillard <veillard>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: berrange, clalance, crobinso, dwalsh, itamar, jkubin, markmc, mgrepl, rvokal, veillard, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-05-04 11:40:31 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Bill Nottingham 2009-03-24 11:59:39 EDT
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):


How reproducible:


Steps to Reproduce:
1. Attach a CDROM image to a F9 guest 
2. Attempt to boot
Comment 1 Daniel Walsh 2009-03-26 20:29:35 EDT
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.
Comment 2 Bill Nottingham 2009-03-27 10:51:49 EDT
Just downloaded the boot.iso directly (from a root shell) to /var/lib/libvirt/images.
Comment 3 Daniel Walsh 2009-03-27 15:20:16 EDT
WHat do you think about downloading to this directory instead?


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.
Comment 4 Bill Nottingham 2009-03-27 15:22:57 EDT
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?
Comment 5 Daniel Walsh 2009-03-27 15:31:07 EDT
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
Comment 6 Daniel Berrange 2009-03-27 15:58:58 EDT
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.
Comment 7 Daniel Walsh 2009-03-27 16:53:26 EDT
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.
Comment 8 Mark McLoughlin 2009-05-04 11:40:31 EDT
This looks like a dup of bug #493692, which has a patch

*** This bug has been marked as a duplicate of bug 493692 ***