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

[Luiz Capitulino <lcapitulino@redhat.com>]

On Mon, 09 Jul 2012 13:40:34 -0500
Anthony Liguori <aliguori@us.ibm.com> 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.

> 
> Perhaps we should reconsider using an RPC for QEMU to request an fd as this 
> solves all the cited problems in a much simpler fashion.
> 
> Regards,
> 
> Anthony Liguori
>