On Fri, Jul 22, 2011 at 11:11 AM, Kevin Wolf 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 aroun
On Fri, Jul 22, 2011 at 12:11 PM, Stefan Hajnoczi wrote:
> On Fri, Jul 22, 2011 at 8:22 AM, Kevin Wolf wrote:
>> Am 21.07.2011 17:01, schrieb Stefan Hajnoczi:
>>> On Thu, Jul 21, 2011 at 3:02 PM, Eric Blake wrote:
Thank you for persisting - you've found another hole that needs to be
pl
On Fri, Jul 22, 2011 at 8:06 AM, Stefan Hajnoczi wrote:
> On Thu, Jul 21, 2011 at 8:42 PM, Blue Swirl wrote:
>> On Thu, Jul 21, 2011 at 6:01 PM, Stefan Hajnoczi wrote:
>>> On Thu, Jul 21, 2011 at 3:02 PM, Eric Blake wrote:
Thank you for persisting - you've found another hole that needs to
On Fri, Jul 22, 2011 at 8:22 AM, Kevin Wolf wrote:
> Am 21.07.2011 17:01, schrieb Stefan Hajnoczi:
>> On Thu, Jul 21, 2011 at 3:02 PM, Eric Blake 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 proce
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 t
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 so
Am 21.07.2011 17:01, schrieb Stefan Hajnoczi:
> On Thu, Jul 21, 2011 at 3:02 PM, Eric Blake 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 head
On Thu, Jul 21, 2011 at 8:42 PM, Blue Swirl wrote:
> On Thu, Jul 21, 2011 at 6:01 PM, Stefan Hajnoczi wrote:
>> On Thu, Jul 21, 2011 at 3:02 PM, Eric Blake wrote:
>>> Thank you for persisting - you've found another hole that needs to be
>>> plugged. It sounds like you are proposing that after a
On Thu, Jul 21, 2011 at 6:01 PM, Stefan Hajnoczi wrote:
> On Thu, Jul 21, 2011 at 3:02 PM, Eric Blake 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 me
On Thu, Jul 21, 2011 at 11:07 AM, Jes Sorensen 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 you put in t
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 g
On Thu, Jul 21, 2011 at 11:25 AM, Kevin Wolf wrote:
> Am 20.07.2011 19:20, schrieb Blue Swirl:
>> On Wed, Jul 20, 2011 at 4:51 PM, Kevin Wolf 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 s
On Thu, Jul 21, 2011 at 3:02 PM, Eric Blake 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 file informat
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 u
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, li
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 i
On 07/21/11 15:07, Markus Armbruster wrote:
> Jes Sorensen 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 happen.
>>
>> My sugges
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 i
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: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 with
Jes Sorensen 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 partial
>>
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
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
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 oth
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
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 shou
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 fil
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 f
Am 20.07.2011 19:20, schrieb Blue Swirl:
> On Wed, Jul 20, 2011 at 4:51 PM, Kevin Wolf 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 pr
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 t
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
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
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
>>
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 (patche
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
On Wed, Jul 20, 2011 at 9:17 PM, Eric Blake 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 tricke
On Wed, Jul 20, 2011 at 8:47 PM, Eric Blake 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 fd/name
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 al
On Wed, Jul 20, 2011 at 8:41 PM, Eric Blake 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 needed to a
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 s
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 stora
On Wed, Jul 20, 2011 at 4:46 PM, 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 f
On Wed, Jul 20, 2011 at 4:51 PM, Kevin Wolf 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
> sa
On 07/19/2011 11:47 AM, Daniel P. Berrange wrote:
This would be possible if QEMU to provide a libblockformat.so library
which allowed apps to extract metadata from file formats using a stable
API.
I'm in 100% agreement that we need to provide the equivalent of a
libblockformat.so down the road
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 libvir
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 hap
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 m
On Wed, Jul 20, 2011 at 11:28 AM, Daniel P. Berrange
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 data to see
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 data to see if the filename actually
> > matches the backing file required by
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
> >> wrote:
> >>> On 07/19/11 16:24, Eric Blake wrote:
> [add
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
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
>> wrote:
>>> On 07/19/11 16:24, Eric Blake wrote:
[adding the libvir-list]
On 07/19/2011 08:09 AM, Jes Sorensen 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 well-documented file format, so that
> >>> ind
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 re
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
>>> sem
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. Beside
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 r
"Daniel P. Berrange" 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
>> 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, libv
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 :( libvi
On Tue, Jul 19, 2011 at 04:14:27PM +0100, Stefan Hajnoczi wrote:
> On Tue, Jul 19, 2011 at 3:30 PM, 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 unfortun
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 in
On Tue, Jul 19, 2011 at 3:30 PM, 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 sh
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
[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 sta
64 matches
Mail list logo
