Re: [Qemu-devel] [PATCH] Add support for fd: protocol

[Blue Swirl <blauwirbel@gmail.com>]

On Mon, May 23, 2011 at 6:56 PM, Kevin Wolf <kwolf@redhat.com> wrote:
> Am 23.05.2011 17:24, schrieb Markus Armbruster:
>> Kevin Wolf <kwolf@redhat.com> writes:
>>
>>> Am 20.05.2011 21:53, schrieb Blue Swirl:
>>>> On Fri, May 20, 2011 at 10:42 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
>>>>> On 05/20/2011 02:25 PM, Blue Swirl wrote:
>>>>>>
>>>>>> On Fri, May 20, 2011 at 9:48 PM, Corey Bryant<bryntcor@us.ibm.com>  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.
>>>>>>
>>>>>> Very nice. QEMU should use this to support privilege separation. We
>>>>>> already have chroot and runas switches, a new switch should convert
>>>>>> all file references to fd references internally for that process. If
>>>>>> this can be made transparent, this should even be the default way of
>>>>>> operation.
>>>>>
>>>>> You mean, QEMU starts up, opens all disk images, reinvokes itself in a
>>>>> confined context, and then passes fds to the child?
>>>>
>>>> And exit after that, or do the same without forking.
>>>>
>>>> This wouldn't work now for the native CDROM devices which need to
>>>> reopen the device. For that, an explicit reopen method could be added.
>>>> The method could even chat with the privileged process to get that to
>>>> do the reopening, but I'd leave that to libvirt and fail without it
>>>> for plain QEMU.
>>>
>>> There are more cases where we reopen the image file. One example is the
>>> 'commit' monitor command which temporarily reopens the backing file r/w.
>>> Or Christoph's patch that allows guests to toggle the write-cache
>>> enabled bit. Same for live snapshots. So we'll need a solution for them
>>> before doing anything like this.
>>>
>>> And breaking qemu without libvirt isn't really an option for me.
>>
>> Reopening files is evil.  Sometimes flaws in the system call API make it
>> the only option.  You can mitigate via /dev/fd/%d, but only on some
>> systems.  The less we reopen, the better.
>>
>> An fd: protocol can't easily support reopen.  So fail it.  This doesn't
>> break any existing usage.  It's just a restriction on the new protocol.
>> Restrictions can render the new protocol useless in practice, but we're
>> not "breaking qemu without libvirt" there.
>>
>> Perhaps we can make relax the restriction on some system by avoiding the
>> reopen in a system-dependent way.
>
> Right, you only get the regression once libvirt starts using it (or even
> worse, qemu itself, like Blue Swirl suggested). Doesn't make it much better.

One solution could be to add new commands which supply fresh fds while
performing the operation which needs reopening:
commit_fd ide0-hd0 #33
change ide1-cd0 fd:34
I don't remember the syntax for fd passing, so that part may be weird.