Re: [libvirt] [PATCH v4 0/7] file descriptor passing using pass-fd

On Mon, 09 Jul 2012 13:40:34 -0500 Anthony Liguori <aliguori(a)us.ibm.com&gt; wrote: > On 06/26/2012 04:10 AM, Daniel P. Berrange wrote: > > On Fri, Jun 22, 2012 at 02:36:07PM -0400, Corey Bryant wrote: > >> 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 stored on the same NFS > >> mount. > >> > >> This patch series adds the pass-fd QMP monitor command, which allows > >> an fd to be passed via SCM_RIGHTS, and returns the received file > >> descriptor. Support is also added to the block layer to allow QEMU > >> to dup the fd when the filename is of the /dev/fd/X format. This > >> is useful if MAC policy prevents QEMU from opening specific types > >> of files. > > > > I was thinking about some of the sources complexity when using > > FD passing from libvirt and wanted to raise one idea for discussion > > before we continue. > > > > With this proposed series, we have usage akin to: > > > > 1. pass_fd FDSET={M} -> returns a string "/dev/fd/N" showing QEMU's > > view of the FD > > 2. drive_add file=/dev/fd/N > > 3. if failure: > > close_fd "/dev/fd/N" > > > > My problem is that none of this FD passing is "transactional". > > My original patch series did not suffer from this problem. > > QEMU owned the file descriptor once it received it from libvirt. > > I don't think the cited problem (QEMU failing an operation if libvirt was down) > is really an actual problem since it would be libvirt that would be issuing the > command in the first place (so the command would just fail which libvirt would > have to assume anyway if it crashed). > > I really dislike where this thread has headed with /dev/fdset. This has become > extremely complex and cumbersome. I agree, maybe it's time to start over and discuss the original problem again.