[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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





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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]