Am 21.07.2011 17:01, schrieb Stefan Hajnoczi:
On Thu, Jul 21, 2011 at 3:02 PM, Eric Blake ebl...@redhat.com wrote:
Thank you for persisting - you've found another hole that needs to be
plugged. It sounds like you are proposing that after a qemu process dies,
that libvirt re-reads the qcow2
On 07/20/2011 04:51 PM, Kevin Wolf wrote:
The problem is that QEMU will find backing file file names inside the
images which it will be unable to open. How do you suggest we get around
that?
This is the part with allowing libvirt to override the backing file. Of
course, this is not
Am 22.07.2011 09:36, schrieb Avi Kivity:
On 07/20/2011 04:51 PM, Kevin Wolf wrote:
The problem is that QEMU will find backing file file names inside the
images which it will be unable to open. How do you suggest we get around
that?
This is the part with allowing libvirt to override the
On Fri, Jul 22, 2011 at 8:22 AM, Kevin Wolf kw...@redhat.com wrote:
Am 21.07.2011 17:01, schrieb Stefan Hajnoczi:
On Thu, Jul 21, 2011 at 3:02 PM, Eric Blake ebl...@redhat.com wrote:
Thank you for persisting - you've found another hole that needs to be
plugged. It sounds like you are
On Fri, Jul 22, 2011 at 8:06 AM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Thu, Jul 21, 2011 at 8:42 PM, Blue Swirl blauwir...@gmail.com wrote:
On Thu, Jul 21, 2011 at 6:01 PM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Thu, Jul 21, 2011 at 3:02 PM, Eric Blake ebl...@redhat.com wrote:
On Fri, Jul 22, 2011 at 12:11 PM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Fri, Jul 22, 2011 at 8:22 AM, Kevin Wolf kw...@redhat.com wrote:
Am 21.07.2011 17:01, schrieb Stefan Hajnoczi:
On Thu, Jul 21, 2011 at 3:02 PM, Eric Blake ebl...@redhat.com wrote:
Thank you for persisting - you've
On Fri, Jul 22, 2011 at 11:11 AM, Kevin Wolf kw...@redhat.com wrote:
Am 22.07.2011 09:36, schrieb Avi Kivity:
On 07/20/2011 04:51 PM, Kevin Wolf wrote:
The problem is that QEMU will find backing file file names inside the
images which it will be unable to open. How do you suggest we get
On 07/20/11 15:46, Eric Blake wrote:
On 07/20/2011 07:25 AM, Jes Sorensen wrote:
I think if libvirt wants qemu to use an fd instead of a file name, it
shouldn't pass a file name but an fd in the first place. Which means
that the two that we need are support for an fd: protocol (patches on
the
On 07/20/11 19:47, Eric Blake wrote:
On 07/20/2011 11:27 AM, Blue Swirl wrote:
I'd avoid any name based access in this case. If QEMU has write access
to main file, it could forge the backing file name in main file to
point to for example /etc/shadow and then request libvirt to perform
the
On 07/20/11 21:51, Blue Swirl wrote:
And the snapshot_blkdev monitor command is a case where qemu needs to create
a new qcow2 image on the fly, while referencing the name of an existing
file. What backing name do you put in the new qcow2 file unless you
already
have a name association
On 07/20/11 11:38, Daniel P. Berrange wrote:
On Wed, Jul 20, 2011 at 10:26:49AM +0200, Jes Sorensen wrote:
On 07/19/11 18:47, Daniel P. Berrange wrote:
On Tue, Jul 19, 2011 at 04:30:19PM +0200, Jes Sorensen wrote:
On 07/19/11 16:24, Eric Blake wrote:
Besides, I feel that having a
Am 20.07.2011 19:47, schrieb Eric Blake:
We really _do_ need a way to give qemu both an fd and the name of the
file that the fd is tied to. On Linux, qemu could use /proc/self/fd to
reconstruct the name from fd, but that's not portable to other OS.
Is there any reason for qemu to know the
Am 20.07.2011 19:20, schrieb Blue Swirl:
On Wed, Jul 20, 2011 at 4:51 PM, Kevin Wolf kw...@redhat.com wrote:
Am 20.07.2011 15:25, schrieb Jes Sorensen:
On 07/20/11 12:01, Kevin Wolf wrote:
Right, we're stuck with the two horros of NFS and selinux, so we need
something that gets around the
Am 21.07.2011 10:07, schrieb Jes Sorensen:
On 07/20/11 21:51, Blue Swirl wrote:
And the snapshot_blkdev monitor command is a case where qemu needs to create
a new qcow2 image on the fly, while referencing the name of an existing
file. What backing name do you put in the new qcow2 file unless
On 07/20/11 11:36, Daniel P. Berrange wrote:
On Wed, Jul 20, 2011 at 10:23:12AM +0200, Jes Sorensen wrote:
Pardon, but I fail to see the issue here. If QEMU passes a filename back
to libvirt, libvirt still gets to make the decision whether or not it is
legitimate for QEMU to get that file
On 07/20/11 12:28, Daniel P. Berrange wrote:
On Wed, Jul 20, 2011 at 12:15:02PM +0200, Nicolas Sebrecht wrote:
Actually, libvirt should not have to worry if the filename provided by
QEMU is valid. I think it should trust QEMU. If QEMU doesn't provide
information others can trust; it should be
On 07/21/11 10:36, Kevin Wolf wrote:
Am 21.07.2011 10:07, schrieb Jes Sorensen:
Rather than trying to do this by mangling files on the disk, I would
suggest we allow registering a call-back open function, which calls back
into libvirt and requests it to open a given file. It can then do all
On 07/21/11 10:18, Kevin Wolf wrote:
Am 20.07.2011 19:47, schrieb Eric Blake:
We really _do_ need a way to give qemu both an fd and the name of the
file that the fd is tied to. On Linux, qemu could use /proc/self/fd to
reconstruct the name from fd, but that's not portable to other OS.
On Thu, Jul 21, 2011 at 10:40:48AM +0200, Jes Sorensen wrote:
On 07/20/11 12:28, Daniel P. Berrange wrote:
On Wed, Jul 20, 2011 at 12:15:02PM +0200, Nicolas Sebrecht wrote:
Actually, libvirt should not have to worry if the filename provided by
QEMU is valid. I think it should trust QEMU. If
On 07/21/11 11:34, Daniel P. Berrange wrote:
QEMU is *not* yet running at the time libvirt reads the file metadata.
Of course it is: hotplug
In the case of hotplug, the hotplug monitor commands have not yet been
invoked when libvirt access the file metadata, or the drive has already
Jes Sorensen jes.soren...@redhat.com writes:
On 07/19/11 18:14, Anthony Liguori wrote:
As nice as that sentiment is, it will never fly, because it would be a
regression in current behavior. The whole reason that the virt_use_nfs
SELinux bool exists is that some people are willing to make the
On 07/21/2011 02:40 AM, Jes Sorensen wrote:
The security goal of libvirt is to protect the host from a compromised
QEMU, therefore QEMU is, by definition, untrusted.
Well that part goes both ways. By applying this model you are going to
make it a hard requirement for libvirt to be upgraded
On 07/21/2011 03:34 AM, Jes Sorensen wrote:
On 07/21/11 11:34, Daniel P. Berrange wrote:
QEMU is *not* yet running at the time libvirt reads the file metadata.
Of course it is: hotplug
In the case of hotplug, the hotplug monitor commands have not yet been
invoked when libvirt access the file
On 07/21/2011 02:38 AM, Jes Sorensen wrote:
On 07/20/11 11:36, Daniel P. Berrange wrote:
On Wed, Jul 20, 2011 at 10:23:12AM +0200, Jes Sorensen wrote:
Pardon, but I fail to see the issue here. If QEMU passes a filename back
to libvirt, libvirt still gets to make the decision whether or not it
On 07/21/11 15:07, Markus Armbruster wrote:
Jes Sorensen jes.soren...@redhat.com writes:
Right, we're stuck with the two horros of NFS and selinux, so we need
something that gets around the problem. In a sane world we would simply
say 'no NFS, no selinux', but as you say that will never
On 07/21/11 15:47, Eric Blake wrote:
On 07/21/2011 02:40 AM, Jes Sorensen wrote:
The security goal of libvirt is to protect the host from a compromised
QEMU, therefore QEMU is, by definition, untrusted.
Well that part goes both ways. By applying this model you are going to
make it a hard
On 07/21/11 16:02, Eric Blake wrote:
On 07/21/2011 02:38 AM, Jes Sorensen wrote:
On 07/20/11 11:36, Daniel P. Berrange wrote:
On Wed, Jul 20, 2011 at 10:23:12AM +0200, Jes Sorensen wrote:
Pardon, but I fail to see the issue here. If QEMU passes a filename
back
to libvirt, libvirt still gets
On 07/21/2011 08:19 AM, Jes Sorensen wrote:
There is a difference between upgrading to pick up additional features
and forced upgrade.
It is not just a question of libvirt possibly reviewing a file format,
it is also having two codebases that needs to be implemented and maintained.
Then give
On Thu, Jul 21, 2011 at 3:02 PM, Eric Blake ebl...@redhat.com wrote:
Thank you for persisting - you've found another hole that needs to be
plugged. It sounds like you are proposing that after a qemu process dies,
that libvirt re-reads the qcow2 metadata headers, and validates that the
backing
On Thu, Jul 21, 2011 at 11:25 AM, Kevin Wolf kw...@redhat.com wrote:
Am 20.07.2011 19:20, schrieb Blue Swirl:
On Wed, Jul 20, 2011 at 4:51 PM, Kevin Wolf kw...@redhat.com wrote:
Am 20.07.2011 15:25, schrieb Jes Sorensen:
On 07/20/11 12:01, Kevin Wolf wrote:
Right, we're stuck with the two
On 07/19/2011 11:47 AM, Daniel P. Berrange wrote:
On Tue, Jul 19, 2011 at 04:30:19PM +0200, Jes Sorensen wrote:
On 07/19/11 16:24, Eric Blake wrote:
[adding the libvir-list]
On 07/19/2011 08:09 AM, Jes Sorensen wrote:
Urgh, libvirt parsing image files is really unfortunate, it really
doesn't
On Thu, Jul 21, 2011 at 11:07 AM, Jes Sorensen jes.soren...@redhat.com wrote:
On 07/20/11 21:51, Blue Swirl wrote:
And the snapshot_blkdev monitor command is a case where qemu needs to create
a new qcow2 image on the fly, while referencing the name of an existing
file. What backing name do
On Thu, Jul 21, 2011 at 6:01 PM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Thu, Jul 21, 2011 at 3:02 PM, Eric Blake ebl...@redhat.com wrote:
Thank you for persisting - you've found another hole that needs to be
plugged. It sounds like you are proposing that after a qemu process dies,
that
On Thu, Jul 21, 2011 at 8:42 PM, Blue Swirl blauwir...@gmail.com wrote:
On Thu, Jul 21, 2011 at 6:01 PM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Thu, Jul 21, 2011 at 3:02 PM, Eric Blake ebl...@redhat.com wrote:
Thank you for persisting - you've found another hole that needs to be
plugged.
Daniel P. Berrange berra...@redhat.com writes:
On Tue, Jul 19, 2011 at 04:14:27PM +0100, Stefan Hajnoczi wrote:
On Tue, Jul 19, 2011 at 3:30 PM, Jes Sorensen jes.soren...@redhat.com
wrote:
On 07/19/11 16:24, Eric Blake wrote:
[adding the libvir-list]
On 07/19/2011 08:09 AM, Jes Sorensen
On 07/19/11 18:46, Daniel P. Berrange wrote:
On Tue, Jul 19, 2011 at 04:14:27PM +0100, Stefan Hajnoczi wrote:
For fd-passing perhaps we have an opportunity to use a callback
mechanism (QEMU request: filename - libvirt response: fd) and do all
the image format parsing in QEMU.
The reason why
On 07/19/11 18:14, Anthony Liguori wrote:
As nice as that sentiment is, it will never fly, because it would be a
regression in current behavior. The whole reason that the virt_use_nfs
SELinux bool exists is that some people are willing to make the partial
security tradeoff. Besides, the use
On 07/19/11 18:47, Daniel P. Berrange wrote:
On Tue, Jul 19, 2011 at 04:30:19PM +0200, Jes Sorensen wrote:
On 07/19/11 16:24, Eric Blake wrote:
Besides, I feel that having a well-documented file format, so that
independent applications can both parse the same file with the same
semantics by
On Wed, Jul 20, 2011 at 10:23:12AM +0200, Jes Sorensen wrote:
On 07/19/11 18:46, Daniel P. Berrange wrote:
On Tue, Jul 19, 2011 at 04:14:27PM +0100, Stefan Hajnoczi wrote:
For fd-passing perhaps we have an opportunity to use a callback
mechanism (QEMU request: filename - libvirt response:
On Wed, Jul 20, 2011 at 10:26:49AM +0200, Jes Sorensen wrote:
On 07/19/11 18:47, Daniel P. Berrange wrote:
On Tue, Jul 19, 2011 at 04:30:19PM +0200, Jes Sorensen wrote:
On 07/19/11 16:24, Eric Blake wrote:
Besides, I feel that having a well-documented file format, so that
independent
Am 19.07.2011 18:46, schrieb Daniel P. Berrange:
On Tue, Jul 19, 2011 at 04:14:27PM +0100, Stefan Hajnoczi wrote:
On Tue, Jul 19, 2011 at 3:30 PM, Jes Sorensen jes.soren...@redhat.com
wrote:
On 07/19/11 16:24, Eric Blake wrote:
[adding the libvir-list]
On 07/19/2011 08:09 AM, Jes Sorensen
Am 20.07.2011 10:25, schrieb Jes Sorensen:
On 07/19/11 18:14, Anthony Liguori wrote:
As nice as that sentiment is, it will never fly, because it would be a
regression in current behavior. The whole reason that the virt_use_nfs
SELinux bool exists is that some people are willing to make the
On Wed, Jul 20, 2011 at 11:50:53AM +0200, Kevin Wolf wrote:
Am 19.07.2011 18:46, schrieb Daniel P. Berrange:
On Tue, Jul 19, 2011 at 04:14:27PM +0100, Stefan Hajnoczi wrote:
On Tue, Jul 19, 2011 at 3:30 PM, Jes Sorensen jes.soren...@redhat.com
wrote:
On 07/19/11 16:24, Eric Blake wrote:
On Wed, Jul 20, 2011 at 11:28 AM, Daniel P. Berrange
berra...@redhat.com wrote:
On Wed, Jul 20, 2011 at 12:15:02PM +0200, Nicolas Sebrecht wrote:
The 20/07/11, Daniel P. Berrange wrote:
To make the decision whether the filename from QEMU is valid, we have
to parse the master image header
On 07/20/11 12:01, Kevin Wolf wrote:
Right, we're stuck with the two horros of NFS and selinux, so we need
something that gets around the problem. In a sane world we would simply
say 'no NFS, no selinux', but as you say that will never happen.
My suggestion of a callback mechanism where
Am 20.07.2011 15:25, schrieb Jes Sorensen:
On 07/20/11 12:01, Kevin Wolf wrote:
Right, we're stuck with the two horros of NFS and selinux, so we need
something that gets around the problem. In a sane world we would simply
say 'no NFS, no selinux', but as you say that will never happen.
My
On 07/20/2011 07:25 AM, Jes Sorensen wrote:
I think if libvirt wants qemu to use an fd instead of a file name, it
shouldn't pass a file name but an fd in the first place. Which means
that the two that we need are support for an fd: protocol (patches on
the list, need review), and a way for
On Wed, Jul 20, 2011 at 4:51 PM, Kevin Wolf kw...@redhat.com wrote:
Am 20.07.2011 15:25, schrieb Jes Sorensen:
On 07/20/11 12:01, Kevin Wolf wrote:
Right, we're stuck with the two horros of NFS and selinux, so we need
something that gets around the problem. In a sane world we would simply
say
On Wed, Jul 20, 2011 at 4:46 PM, Eric Blake ebl...@redhat.com wrote:
On 07/20/2011 07:25 AM, Jes Sorensen wrote:
I think if libvirt wants qemu to use an fd instead of a file name, it
shouldn't pass a file name but an fd in the first place. Which means
that the two that we need are support for
On 07/20/2011 11:20 AM, Blue Swirl wrote:
There could still be some issues:
Let's have files A, B, C etc. with backing files AA etc. How would
libvirt know that when QEMU wants to write to file CA, this is because
it's needed to access C, or is it just trickery by a devious guest to
corrupt
On 07/20/2011 11:27 AM, Blue Swirl wrote:
We've already told you - qemu must have a way to be passed fds which are
associated with names, and when a file refers to another backing file by
name, then qemu falls back on its fd/name mapping to use the already-passed
fd instead. Which implies that
On Wed, Jul 20, 2011 at 8:41 PM, Eric Blake ebl...@redhat.com wrote:
On 07/20/2011 11:20 AM, Blue Swirl wrote:
There could still be some issues:
Let's have files A, B, C etc. with backing files AA etc. How would
libvirt know that when QEMU wants to write to file CA, this is because
it's
On 07/20/2011 12:00 PM, Blue Swirl wrote:
Let's have files A, B, C etc. with backing files AA etc. How would
libvirt know that when QEMU wants to write to file CA, this is because
it's needed to access C, or is it just trickery by a devious guest to
corrupt storage?
The fix for CVE-2010-2238
On Wed, Jul 20, 2011 at 8:47 PM, Eric Blake ebl...@redhat.com wrote:
On 07/20/2011 11:27 AM, Blue Swirl wrote:
We've already told you - qemu must have a way to be passed fds which are
associated with names, and when a file refers to another backing file by
name, then qemu falls back on its
On Wed, Jul 20, 2011 at 9:17 PM, Eric Blake ebl...@redhat.com wrote:
On 07/20/2011 12:00 PM, Blue Swirl wrote:
Let's have files A, B, C etc. with backing files AA etc. How would
libvirt know that when QEMU wants to write to file CA, this is because
it's needed to access C, or is it just
On 07/20/2011 02:01 PM, Blue Swirl wrote:
Either because CA was mentioned as a backing file for C (in which case
libvirt already knows about it, because either libvirt handed C to qemu at
startup time after already parsing C's headers to learn that CA is a backing
file, or because libvirt called
[adding the libvir-list]
On 07/19/2011 08:09 AM, Jes Sorensen wrote:
On 07/19/11 15:58, Eric Blake wrote:
On 07/19/2011 07:27 AM, Jes Sorensen wrote:
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
On 07/19/11 16:24, Eric Blake wrote:
[adding the libvir-list]
On 07/19/2011 08:09 AM, Jes Sorensen wrote:
Urgh, libvirt parsing image files is really unfortunate, it really
doesn't give me warm fuzzy feelings :( libvirt really should not know
about internals of image formats.
But even if
On Tue, Jul 19, 2011 at 3:30 PM, Jes Sorensen jes.soren...@redhat.com wrote:
On 07/19/11 16:24, Eric Blake wrote:
[adding the libvir-list]
On 07/19/2011 08:09 AM, Jes Sorensen wrote:
Urgh, libvirt parsing image files is really unfortunate, it really
doesn't give me warm fuzzy feelings :(
On 07/19/2011 09:30 AM, Jes Sorensen wrote:
On 07/19/11 16:24, Eric Blake wrote:
[adding the libvir-list]
On 07/19/2011 08:09 AM, Jes Sorensen wrote:
Urgh, libvirt parsing image files is really unfortunate, it really
doesn't give me warm fuzzy feelings :( libvirt really should not know
about
On Tue, Jul 19, 2011 at 04:14:27PM +0100, Stefan Hajnoczi wrote:
On Tue, Jul 19, 2011 at 3:30 PM, Jes Sorensen jes.soren...@redhat.com wrote:
On 07/19/11 16:24, Eric Blake wrote:
[adding the libvir-list]
On 07/19/2011 08:09 AM, Jes Sorensen wrote:
Urgh, libvirt parsing image files is
On Tue, Jul 19, 2011 at 04:30:19PM +0200, Jes Sorensen wrote:
On 07/19/11 16:24, Eric Blake wrote:
[adding the libvir-list]
On 07/19/2011 08:09 AM, Jes Sorensen wrote:
Urgh, libvirt parsing image files is really unfortunate, it really
doesn't give me warm fuzzy feelings :( libvirt really
62 matches
Mail list logo
