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

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