qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: kwolf@redhat.com, libvir-list@redhat.com, aliguori@us.ibm.com,
	Corey Bryant <coreyb@linux.vnet.ibm.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [libvirt] [PATCH v4] Add support for fd: protocol
Date: Mon, 22 Aug 2011 17:24:44 +0100	[thread overview]
Message-ID: <20110822162444.GI9456@redhat.com> (raw)
In-Reply-To: <20110822153820.GA4774@lst.de>

On Mon, Aug 22, 2011 at 05:38:20PM +0200, Christoph Hellwig wrote:
> I'm still totally against this.  FD passing is a nice feature for sandboxing,
> but the passing should be between closely cooperating programs.  We'll
> need a tool shipped from the qemu source tree to open and set up the
> FDs, and not someone external.  With that setup in place we can use
> a protocol similar to the various OpenBSD privilegue separated deaemons
> to also allow reopening / snapshots / etc.
> 
> Opening fds in libvirt and passing them into qemu is exactly the wrong way,
> and just cements the current horrors where libvirt duplicates parsing
> of image format headers.

The primary goal of this work is to allow QEMU to use a file, without
giving it permission to open the file. This lets us cope with the current
limitations of NFS wrt SELinux labelling. Where ordinarily we'd relabel
the disk file to allow QEMU to open them, on NFS we can't do that. So we
setup a SELinux policy that allows QEMU to read any NFS files that it is
passed, but not actually open them. This allows secure use of QEMU with
NFS, without having to solve the NFS + SELinux labelling problems, which
is still a long term ongoing effort by NFS vendors.

Whether or not libvirt parses image format headers, is a completely
unrelated. Consider if libvirt did not parse image formats and instead
required the mgmt app to pass in details of all backing files. We still
have the problem of how to securely grant just one QEMU instance access
to the files. This still needs the FD passing support being proposed
here to cope with NFS.

So the question of whether or not libvirt should be parsing image format
headers is completely irrelevant to acceptability of this FD passing
support.

Regards,
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 :|

  parent reply	other threads:[~2011-08-22 16:24 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-22 14:50 [Qemu-devel] [PATCH v4] Add support for fd: protocol Corey Bryant
2011-08-22 15:38 ` Christoph Hellwig
2011-08-22 16:06   ` Corey Bryant
2011-08-22 16:24   ` Daniel P. Berrange [this message]
2011-08-22 16:29     ` [Qemu-devel] [libvirt] " Anthony Liguori
2011-08-22 16:50       ` Daniel P. Berrange
2011-08-22 17:25         ` Anthony Liguori
2011-08-22 17:42           ` Corey Bryant
2011-08-22 18:39             ` Blue Swirl
2011-08-23 15:13               ` Corey Bryant
2011-08-23 15:26                 ` Daniel P. Berrange
2011-08-23 15:50                   ` Kevin Wolf
2011-08-23 15:51                     ` Daniel P. Berrange
2011-08-23 16:04                       ` Daniel P. Berrange
2011-08-23 16:14                     ` Corey Bryant
2011-08-22 18:22           ` Daniel P. Berrange
2011-08-22 18:54             ` Blue Swirl
2011-08-22 19:25             ` Anthony Liguori
2011-08-23 14:26               ` Corey Bryant
2011-08-23 14:33                 ` Anthony Liguori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110822162444.GI9456@redhat.com \
    --to=berrange@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=coreyb@linux.vnet.ibm.com \
    --cc=hch@lst.de \
    --cc=kwolf@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).