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.
> 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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list