On 07/09/2012 03:29 PM, Eric Blake wrote:
On 07/09/2012 02:00 PM, Anthony Liguori wrote:
with the fd:name approach, the sequence is:
libvirt calls getfd:name1 over normal monitor
qemu responds
libvirt calls getfd:name2 over normal monitor
qemu responds
libvirt calls transaction around blockdev
On 07/09/2012 02:00 PM, Anthony Liguori wrote:
>> with the fd:name approach, the sequence is:
>>
>> libvirt calls getfd:name1 over normal monitor
>> qemu responds
>> libvirt calls getfd:name2 over normal monitor
>> qemu responds
>> libvirt calls transaction around blockdev-snapshot-sync over norma
On 05/17/2012 09:14 AM, Eric Blake wrote:
On 05/17/2012 07:42 AM, Stefan Hajnoczi wrote:
The -open-hook-fd approach allows QEMU to support file descriptor passing
without changing -drive. It also supports snapshot_blkdev and other commands
By the way, How will it support them?
The problem
On Thu, May 17, 2012 at 08:14:15AM -0600, Eric Blake wrote:
> On 05/17/2012 07:42 AM, Stefan Hajnoczi wrote:
>
> >>>
> >>> The -open-hook-fd approach allows QEMU to support file descriptor passing
> >>> without changing -drive. It also supports snapshot_blkdev and other
> >>> commands
> >> By th
On 05/17/2012 07:42 AM, Stefan Hajnoczi wrote:
>>>
>>> The -open-hook-fd approach allows QEMU to support file descriptor passing
>>> without changing -drive. It also supports snapshot_blkdev and other
>>> commands
>> By the way, How will it support them?
>
> The problem with snapshot_blkdev is
On 05/01/2012 06:15 PM, Eric Blake wrote:
On 05/01/2012 03:53 PM, Anthony Liguori wrote:
I think (correct me if I'm wrong) libvirt should be aware of any file
that qemu
asks it to open. So from a security point of view, libvirt can prevent
opening a
file if it isn't affiliated with the guest.
On 05/02/2012 04:45 AM, Kevin Wolf wrote:
Am 02.05.2012 10:53, schrieb Daniel P. Berrange:
I would much prefer to see us be able to pass FDs in directly alongside
the disk config as we do for netdev TAP/etc, and for QEMU / kernel to be
fixed so that you do not need to re-open FDs on the fly.
I
On Wed, May 02, 2012 at 11:45:26AM +0200, Kevin Wolf wrote:
> Am 02.05.2012 10:53, schrieb Daniel P. Berrange:
> > On Wed, May 02, 2012 at 10:20:17AM +0200, Kevin Wolf wrote:
> >> Am 01.05.2012 22:25, schrieb Anthony Liguori:
> >>> Thanks for sending this out Stefan.
> >>>
> >>> On 05/01/2012 10:31
Am 02.05.2012 10:53, schrieb Daniel P. Berrange:
> On Wed, May 02, 2012 at 10:20:17AM +0200, Kevin Wolf wrote:
>> Am 01.05.2012 22:25, schrieb Anthony Liguori:
>>> Thanks for sending this out Stefan.
>>>
>>> On 05/01/2012 10:31 AM, Stefan Hajnoczi wrote:
Libvirt can take advantage of SELinux t
Am 02.05.2012 10:27, schrieb Stefan Hajnoczi:
> On Wed, May 2, 2012 at 9:20 AM, Kevin Wolf wrote:
>> Am 01.05.2012 22:25, schrieb Anthony Liguori:
>>> Thanks for sending this out Stefan.
>>>
>>> On 05/01/2012 10:31 AM, Stefan Hajnoczi wrote:
Libvirt can take advantage of SELinux to restrict t
On Wed, May 02, 2012 at 10:20:17AM +0200, Kevin Wolf wrote:
> Am 01.05.2012 22:25, schrieb Anthony Liguori:
> > Thanks for sending this out Stefan.
> >
> > On 05/01/2012 10:31 AM, Stefan Hajnoczi wrote:
> >> Libvirt can take advantage of SELinux to restrict the QEMU process and
> >> prevent
> >>
On Wed, May 2, 2012 at 9:20 AM, Kevin Wolf wrote:
> Am 01.05.2012 22:25, schrieb Anthony Liguori:
>> Thanks for sending this out Stefan.
>>
>> On 05/01/2012 10:31 AM, Stefan Hajnoczi wrote:
>>> Libvirt can take advantage of SELinux to restrict the QEMU process and
>>> prevent
>>> it from opening
Am 01.05.2012 22:25, schrieb Anthony Liguori:
> Thanks for sending this out Stefan.
>
> On 05/01/2012 10:31 AM, Stefan Hajnoczi wrote:
>> Libvirt can take advantage of SELinux to restrict the QEMU process and
>> prevent
>> it from opening files that it should not have access to. This improves
>>
On 05/01/2012 05:15 PM, Eric Blake wrote:
On 05/01/2012 03:53 PM, Anthony Liguori wrote:
I think (correct me if I'm wrong) libvirt should be aware of any file
that qemu
asks it to open. So from a security point of view, libvirt can prevent
opening a
file if it isn't affiliated with the guest.
On 05/01/2012 03:53 PM, Anthony Liguori wrote:
>> I think (correct me if I'm wrong) libvirt should be aware of any file
>> that qemu
>> asks it to open. So from a security point of view, libvirt can prevent
>> opening a
>> file if it isn't affiliated with the guest.
>
> Right, libvirt can maintai
On 05/01/2012 04:45 PM, Corey Bryant wrote:
On 05/01/2012 04:25 PM, Anthony Liguori wrote:
Thanks for sending this out Stefan.
On 05/01/2012 10:31 AM, Stefan Hajnoczi wrote:
Libvirt can take advantage of SELinux to restrict the QEMU process and
prevent
it from opening files that it should no
On 05/01/2012 03:56 PM, Eric Blake wrote:
On 05/01/2012 02:25 PM, Anthony Liguori wrote:
Thanks for sending this out Stefan.
Indeed.
This series adds the -open-hook-fd command-line option. Whenever QEMU
needs to
open an image file it sends a request over the given UNIX domain
socket. The
On 05/01/2012 04:25 PM, Anthony Liguori wrote:
Thanks for sending this out Stefan.
On 05/01/2012 10:31 AM, Stefan Hajnoczi wrote:
Libvirt can take advantage of SELinux to restrict the QEMU process and
prevent
it from opening files that it should not have access to. This improves
security beca
18 matches
Mail list logo
