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

[Daniel P. Berrange]

On Mon, Jul 09, 2012 at 04:00:37PM -0300, Luiz Capitulino wrote:
> On Mon, 09 Jul 2012 13:40:34 -0500
> Anthony Liguori <address@hidden> 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.

I must say, I'm not entirely sure of all the problems we're trying to
solve anymore. I don't think we've ever clearly stated in this thread
what all the requirements/problems are, so I'm finding it hard to see
what the optimal solution is.


Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|