[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [libvirt] [RFC 0/5] block: File descriptor passing usin
From: |
Daniel P. Berrange |
Subject: |
Re: [Qemu-devel] [libvirt] [RFC 0/5] block: File descriptor passing using -open-hook-fd |
Date: |
Wed, 2 May 2012 10:56:21 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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, 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 because it prevents the attacker from escaping the QEMU process
> >>>> if
> >>>> they manage to gain control.
> >>>>
> >>>> NFS has been a pain point for SELinux because it does not support labels
> >>>> (which
> >>>> I believe are stored in extended attributes). In other words, it's not
> >>>> possible to use SELinux goodness on QEMU when image files are located on
> >>>> NFS.
> >>>> Today we have to allow QEMU access to any file on the NFS export rather
> >>>> than
> >>>> restricting specifically to the image files that the guest requires.
> >>>>
> >>>> File descriptor passing is a solution to this problem and might also
> >>>> come in
> >>>> handy elsewhere. Libvirt or another external process chooses files
> >>>> which QEMU
> >>>> is allowed to access and provides just those file descriptors - QEMU
> >>>> cannot
> >>>> open the files itself.
> >>>>
> >>>> 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
> >>>> response includes the file descriptor or an errno on failure. Please
> >>>> see the
> >>>> patches for details on the protocol.
> >>>>
> >>>> The -open-hook-fd approach allows QEMU to support file descriptor passing
> >>>> without changing -drive. It also supports snapshot_blkdev and other
> >>>> commands
> >>>> that re-open image files.
> >>>>
> >>>> Anthony Liguori<address@hidden> wrote most of these patches. I added a
> >>>> demo -open-hook-fd server and added some small fixes. Since Anthony is
> >>>> traveling right now I'm sending the RFC for discussion.
> >>>
> >>> What I like about this approach is that it's useful outside the block
> >>> layer and
> >>> is conceptionally simple from a QEMU PoV. We simply delegate open() to
> >>> libvirt
> >>> and let libvirt enforce whatever rules it wants.
> >>>
> >>> This is not meant to be an alternative to blockdev, but even with
> >>> blockdev, I
> >>> think we still want to use a mechanism like this even with blockdev.
> >>
> >> What does it provide on top?
> >>
> >> This doesn't look like something that I'd like a lot. qemu should be
> >> able to continue to run no matter what the management tool does, whether
> >> it responds to RPCs properly or whether it has crashed. You need a
> >> really good use case for the RPC that cannot be covered otherwise in
> >> order to justify this.
> >
> > Indeed, this solution breaks if you stop or restart libvirtd while
> > QEMU is running. Restarting libvirt while QEMU is running is something
> > we must support, since installing RPM updates will restart libvirtd
> > and we cannot let guests die in this case.
> >
> > 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 agree, and this is what -blockdev would give us.
>
> Part of why I don't like the RFC (apart from RPCing the management tool
> being just wrong) is that once again it's trying to take shortcuts and
> only provide a hack for the urgent need instead of doing it properly and
> implementing -blockdev. I suspect that if we take something half-baked
> like this, we will keep being unhappy with the situation in the block
> layer, but it won't hurt enough any more to actually spend effort on it,
> so that we'll go another five years with it.
I tend to agree - we have been talking about -blockdev for faar to long
without (AFAICT) making any real progress towards getting it done. I'd
love to see someone bite the bullet & have a go at implementing it
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 :|
- Re: [Qemu-devel] [RFC 0/5] block: File descriptor passing using -open-hook-fd, (continued)
Re: [Qemu-devel] [RFC 0/5] block: File descriptor passing using -open-hook-fd, Kevin Wolf, 2012/05/02
Re: [Qemu-devel] [libvirt] [RFC 0/5] block: File descriptor passing using -open-hook-fd, Daniel P. Berrange, 2012/05/02
Re: [Qemu-devel] [libvirt] [RFC 0/5] block: File descriptor passing using -open-hook-fd, Kevin Wolf, 2012/05/02
Re: [Qemu-devel] [libvirt] [RFC 0/5] block: File descriptor passing using -open-hook-fd,
Daniel P. Berrange <=
Re: [Qemu-devel] [libvirt] [RFC 0/5] block: File descriptor passing using -open-hook-fd, Paolo Bonzini, 2012/05/02
Re: [Qemu-devel] [libvirt] [RFC 0/5] block: File descriptor passing using -open-hook-fd, Anthony Liguori, 2012/05/03
Re: [Qemu-devel] [RFC 0/5] block: File descriptor passing using -open-hook-fd, Daniel P. Berrange, 2012/05/02
Re: [Qemu-devel] [libvirt] [RFC 0/5] block: File descriptor passing using -open-hook-fd, Zhi Yong Wu, 2012/05/03