On Mon, May 23, 2011 at 2:21 PM, Anthony Liguori <aligu...@us.ibm.com> wrote:
> On 05/23/2011 08:09 AM, Stefan Hajnoczi wrote:
>>
>> On Mon, May 23, 2011 at 1:50 PM, Anthony Liguori<aligu...@us.ibm.com>
>> wrote:
>>>
>>> On 05/23/2011 04:45 AM, Daniel P. Berrange wrote:
>>>>
>>>> On Fri, May 20, 2011 at 02:48:23PM -0400, Corey Bryant wrote:
>>>>>
>>>>> sVirt provides SELinux MAC isolation for Qemu guest processes and their
>>>>> corresponding resources (image files). sVirt provides this support
>>>>> by labeling guests and resources with security labels that are stored
>>>>> in file system extended attributes. Some file systems, such as NFS, do
>>>>> not support the extended attribute security namespace, which is needed
>>>>> for image file isolation when using the sVirt SELinux security driver
>>>>> in libvirt.
>>>>>
>>>>> The proposed solution entails a combination of Qemu, libvirt, and
>>>>> SELinux patches that work together to isolate multiple guests' images
>>>>> when they're stored in the same NFS mount. This results in an
>>>>> environment where sVirt isolation and NFS image file isolation can both
>>>>> be provided.
>>>>>
>>>>> Currently, Qemu opens an image file in addition to performing the
>>>>> necessary read and write operations. The proposed solution will move
>>>>> the open out of Qemu and into libvirt. Once libvirt opens an image
>>>>> file for the guest, it will pass the file descriptor to Qemu via a
>>>>> new fd: protocol.
>>>>>
>>>>> If the image file resides in an NFS mount, the following SELinux policy
>>>>> changes will provide image isolation:
>>>>>
>>>>> - A new SELinux boolean is created (e.g. virt_read_write_nfs) to
>>>>> allow Qemu (svirt_t) to only have SELinux read and write
>>>>> permissions on nfs_t files
>>>>>
>>>>> - Qemu (svirt_t) also gets SELinux use permissions on libvirt
>>>>> (virtd_t) file descriptors
>>>>>
>>>>> Following is a sample invocation of Qemu using the fd: protocol:
>>>>>
>>>>> qemu -drive file=fd:4,format=qcow2
>>>>>
>>>>> This patch contains the Qemu code to support this solution. I would
>>>>> like to solicit input from the libvirt community prior to starting
>>>>> the libvirt patch.
>>>>>
>>>>> This patch was tested with the following formats: raw, cow, qcow,
>>>>> qcow2, vmdk, using the fd: protocol as well as existing file name
>>>>> support. Non-valid file descriptors were also tested.
>>>>
>>>> How can backing files work ? The '-drive' syntax doesn't provide
>>>> any way to set properties against the backing files (which may be
>>>> nested to arbitrary depth).
>>>
>>> This is orthogonal to having an fd: protocol.
>>>
>>>> Also, there are a few places in QEMU, where it re-opens the existing
>>>> block driver on the fly. What is the plan for supporting this, without
>>>> having QEMU block on waiting for libvirt to pass it a new FD ?
>>>
>>> That's only host CDROM AFAICT.
>>
>> The host page cache on|off option also uses it because fcntl(2) cannot
>> change O_DIRECT. Actually for Linux it may be doable with
>> open('/proc/fd/<old>', flags ^ O_DIRECT) and on other hosts SELinux
>> does not exist.
>
> QEMU doesn't actually know which caching mode the fd is in if it's being
> passed to it so this command doesn't make much sense.
>
fcntl(2) will report the flags.
Also, we need to make sure that the O_SYNC flag and write caching are
in agreement, although I guess it is libvirt's responsibility to set
that up correctly.
Stefan
