sVirt

[Gene Czarcinski]

On Sunday 05 July 2009 06:36:05 Daniel P. Berrange wrote:
> > 2. For files on read-only file systems, don't do anything ... they are
> > protected about as much as they can be.
>
> As has been mentioned in the bug you raised several days ago, this issue
> should already be addressed
>
>   https://bugzilla.redhat.com/show_bug.cgi?id=507555

I am still looking for the update libvirt to be post to updates-testing.

>
> > 4. For ISO files, maybe there should be a new/special file context which
> > allows sharing between processes ... it would be explicit but it would
> > allow sharing ... maybe something like "public_content_t".
>
> There is already a label for read only guest images
>
>   system_u:object_r:svirt_image_t:s0
>
> it shouldn't be much work for you to add a custom SELinux plugin that
> gives httpd_t access to content labelled svirt_image_t. Ask the
> fedora-selinux mailing list for assistance if needed

I believe this is backwards from the way things should work.  Please see my 
new bugzilla report:
https://bugzilla.redhat.com/show_bug.cgi?id=509834

sVirt is the new kid on the block and should work with others not the reverse.  
Why should I need to create an SELinux plugin so that stuff that did work still 
does work?

>
> > 5. Maybe implement a switch which disables SELinux enforcing (and does
> > not change the file context of ISO files) for Fedora-virtualization.
>
> Already present /etc/libvirt/qemu.conf , change  security_driver="none"

OK, I can certainly edit the config file myself (now that I am aware of it).  
However, shouldn't I be able to set this with either an SELinux boolean or via 
virt-manager's preferences?

BTW, there are currently a number of SELinux booleans for "virt" but I am not 
sure what each does/means.
>
> > 6.  Maybe the switch should be by guest.
>
> Easy enough to add - file a bug if you want this capability.

Yes, something like this is desirable (IMHO).  

However, what I really want is to be able to define and build a guest without 
screwing up "other" shared files and/or devices but then be able to lock that 
guest down once it is built.  The system settings for a guest in 
creation/build mode should not effect the settings of other guest virtuals 
already built 

This is analogous to development versus production environments. 

Gene