Re: [Qemu-devel] [RFC PATCH 0/4] block: file descriptor passing using -filefd and getfd_file

[Corey Bryant <coreyb@linux.vnet.ibm.com>]

On 05/22/2012 11:39 AM, Kevin Wolf wrote:
> Am 22.05.2012 17:29, schrieb Corey Bryant:
>>
>>
>> On 05/22/2012 10:45 AM, Kevin Wolf wrote:
>>> Am 22.05.2012 16:30, schrieb Corey Bryant:
>>>>
>>>>
>>>> On 05/22/2012 04:18 AM, Kevin Wolf wrote:
>>>>> Am 21.05.2012 22:19, schrieb Corey Bryant:
>>>>>> libvirt's sVirt security driver provides SELinux MAC isolation for
>>>>>> Qemu guest processes and their corresponding image files.  In other
>>>>>> words, sVirt uses SELinux to prevent a QEMU process from opening
>>>>>> files that do not belong to it.
>>>>>>
>>>>>> 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, and therefore cannot support sVirt
>>>>>> isolation.
>>>>>>
>>>>>> A solution to this problem is to provide fd passing support, where
>>>>>> libvirt opens files and passes file descriptors to QEMU.  This,
>>>>>> along with SELinux policy to prevent QEMU from opening files, can
>>>>>> provide image file isolation for NFS files.
>>>>>>
>>>>>> This patch series adds the -filefd command-line option and the
>>>>>> getfd_file monitor command.  This will enable libvirt to open a
>>>>>> file and push the corresponding filename and file descriptor to
>>>>>> QEMU.  When QEMU needs to "open" a file, it will first check if the
>>>>>> file descriptor was passed by either of these methods before
>>>>>> attempting to actually open the file.
>>>>>
>>>>> I thought we decided to avoid making some file names magic, and instead
>>>>> go for the obvious /dev/fd/42?
>>>>
>>>> I understand that open("/dev/fd/42") would be the same as dup(42), but
>>>> I'm not sure that I'm entirely clear on how this would work.  Could you
>>>> give an example?
>>>
>>> With your approach you open the file outside qemu, pass the fd to qemu
>>> along with a file name that it's supposed to replace and then you use
>>> that fake file name:
>>>
>>> (qemu) getfd_file abc
>>> (qemu) drive_add 0 file=abc,...
>>>
>>> Instead you could use the existing getfd command and avoid the translation:
>>>
>>> (qemu) getfd
>>> 42
>>> (qemu) drive_add 0 file=/dev/fd/42,...
>>>
>>> Er, well. Just that getfd doesn't return the assigned fd today, so the
>>> management tool doesn't know it. We would have to add that.
>>
>> Thanks for the explanation.  This would mean the management app that
>> performs the open(/path/to/my.img) would have to keep a mapping of
>> filenames (/path/to/my.img) to corresponding /dev/fd/X paths, or perhaps
>> just keeping track of the filename and fd is enough.  It sounds like
>> this would simplify things in QEMU and get rid of any need for
>> canonicalization of filenames in QEMU.
>
> I don't know the implementation details of libvirt, but I would assume
> that they don't have to keep a name/fd map and deal with strings, but
> could just add the fd to some internal object representing a block
> device of a running domain. I would be surprised if this didn't exist.
>

Ok, that's probably the case.

>> I'm not sure why getfd would have to return the fd though.  I'm assuming
>> this would be the fd returned from open("dev/fd/42").
>
> It would be the 42. When you pass a file descriptor via getfd, you don't
> know yet which number it gets assigned in qemu.
>
> Kevin
>

Sorry, I must be missing something. Isn't 42 the fd that libvirt got 
from the open() call?  I assume you are talking about returning the fd 
that QEMU created as a dup.  I'm still not seeing the point in returning 
an fd to libvirt.  It seems like QEMU should just be able to dup the fd 
that it was passed, and close/re-dup it as needed.

-- 
Regards,
Corey