From: Eric Blake <eblake@redhat.com>
To: Jes Sorensen <Jes.Sorensen@redhat.com>
Cc: Stefan Hajnoczi <stefanha@gmail.com>,
QEMU Developers <qemu-devel@nongnu.org>,
Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] live snapshot wiki updated
Date: Tue, 19 Jul 2011 07:58:08 -0600 [thread overview]
Message-ID: <4E258D70.6000205@redhat.com> (raw)
In-Reply-To: <4E258635.2040108@redhat.com>
On 07/19/2011 07:27 AM, Jes Sorensen wrote:
> On 07/19/11 15:23, Stefan Hajnoczi wrote:
>> On Tue, Jul 19, 2011 at 8:24 AM, Jes Sorensen<Jes.Sorensen@redhat.com> wrote:
>>> On 07/18/11 16:08, Stefan Hajnoczi wrote:
>>>> On Fri, Jul 15, 2011 at 3:58 PM, Jes Sorensen<Jes.Sorensen@redhat.com> wrote:
>>>>> I have been updating the live snapshot wiki for qemu to try and cover
>>>>> the commands we will want for async snapshot handling too.
>>>>>
>>>>> http://wiki.qemu.org/Features/Snapshots
>>>>
>>>> Regarding fd passing, do we even support SELinux today with backing files?
>>>
>>> Not sure I understand what you mean. The current code should be happy to
>>> take an existing file or a raw device for the snapshot.
>>
>> Sorry, I was off on a tangent.
>>
>> I think today QEMU does not support opening image files with a backing
>> file purely using file descriptors. We currently require the ability
>> to open files.
>
> I see what you mean - I don't actually know how that would work, since
> the backing file specified in the front image will be a file name.
>
> Eric, what happens if libvirt in an selinux environment tells QEMU to
> launch using an image file that is backed by backing file(s)?
Before starting qemu, libvirt first parses all the image files, to see
if any of them have backing images. For every qcow2 or qed image with a
backing file, libvirt sets the SELinux context of both the qcow2 image
and its backing file so that qemu will be able to successfully open()
them. But if any of those files reside on NFS, then it is not possible
to label individual files, so it requires setting the SELinux bool
virt_use_nfs, which thus gives qemu the power to open() arbitrary files
on NFS, and you've lost security.
It would be nice if libvirt had a way to pass fds for every disk and
backing file up front; then, SELinux can work around the lack of NFS
per-file labelling by blocking open() in qemu. In fact, this has
already been proposed:
http://lists.gnu.org/archive/html/qemu-devel/2011-06/msg02072.html
http://lists.gnu.org/archive/html/qemu-devel/2011-06/msg01992.html
That thread mentioned both a command-line syntax for passing in fds for
backing files, as well as an extension to the getfd monitor command to
allow association of a runtime fd with a filename.
--
Eric Blake eblake@redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
next prev parent reply other threads:[~2011-07-19 14:13 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-15 14:58 [Qemu-devel] live snapshot wiki updated Jes Sorensen
2011-07-18 14:08 ` Stefan Hajnoczi
2011-07-19 7:24 ` Jes Sorensen
2011-07-19 13:23 ` Stefan Hajnoczi
2011-07-19 13:27 ` Jes Sorensen
2011-07-19 13:58 ` Eric Blake [this message]
2011-07-19 14:09 ` Jes Sorensen
2011-07-19 14:24 ` Eric Blake
2011-07-19 14:30 ` Jes Sorensen
2011-07-19 15:14 ` Stefan Hajnoczi
2011-07-19 16:46 ` Daniel P. Berrange
2011-07-20 7:30 ` Markus Armbruster
2011-07-20 8:23 ` Jes Sorensen
2011-07-20 9:36 ` Daniel P. Berrange
2011-07-20 10:15 ` [Qemu-devel] [libvirt] " Nicolas Sebrecht
2011-07-20 10:28 ` Daniel P. Berrange
2011-07-20 11:40 ` [Qemu-devel] [libvirt] " Stefan Hajnoczi
[not found] ` <4E27E610.7090502@redhat.com>
[not found] ` <4E282DE6.1020603@redhat.com>
[not found] ` <4E283554.4080903@redhat.com>
2011-07-21 14:51 ` Eric Blake
[not found] ` <4E27E5A2.2030208@redhat.com>
[not found] ` <4E28317D.9020502@redhat.com>
2011-07-21 15:01 ` [Qemu-devel] " Stefan Hajnoczi
2011-07-21 19:42 ` Blue Swirl
2011-07-22 5:06 ` Stefan Hajnoczi
2011-07-22 15:49 ` Blue Swirl
2011-07-22 7:22 ` Kevin Wolf
2011-07-22 9:11 ` Stefan Hajnoczi
2011-07-22 16:05 ` Blue Swirl
2011-07-20 9:50 ` Kevin Wolf
2011-07-20 10:18 ` Daniel P. Berrange
2011-07-19 16:14 ` Anthony Liguori
2011-07-20 8:25 ` Jes Sorensen
2011-07-20 10:01 ` Kevin Wolf
2011-07-20 13:25 ` Jes Sorensen
2011-07-20 13:46 ` Eric Blake
2011-07-20 17:27 ` Blue Swirl
2011-07-20 17:47 ` Eric Blake
2011-07-20 19:51 ` Blue Swirl
[not found] ` <4E27DE5D.5050502@redhat.com>
2011-07-21 19:34 ` Blue Swirl
2011-07-20 13:51 ` Kevin Wolf
2011-07-20 17:20 ` Blue Swirl
2011-07-20 17:41 ` Eric Blake
2011-07-20 18:00 ` Blue Swirl
2011-07-20 18:17 ` Eric Blake
2011-07-20 20:01 ` Blue Swirl
2011-07-20 20:10 ` Eric Blake
[not found] ` <4E27E280.2060306@redhat.com>
2011-07-21 19:01 ` Blue Swirl
2011-07-22 7:36 ` Avi Kivity
2011-07-22 8:11 ` Kevin Wolf
2011-07-22 16:09 ` Blue Swirl
2011-07-20 13:50 ` Cleber Rosa
2011-07-20 14:34 ` Anthony Liguori
2011-07-20 18:34 ` Cleber Rosa
2011-07-19 16:47 ` Daniel P. Berrange
2011-07-20 8:26 ` Jes Sorensen
2011-07-20 9:38 ` Daniel P. Berrange
2011-07-20 14:35 ` Anthony Liguori
2011-07-21 18:56 ` Michael Roth
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=4E258D70.6000205@redhat.com \
--to=eblake@redhat.com \
--cc=Jes.Sorensen@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--cc=stefanha@linux.vnet.ibm.com \
/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).