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

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. Kevin