qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Corey Bryant <coreyb@linux.vnet.ibm.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	bryntcor@us.ibm.com, libvir-list@redhat.com, mprivozn@redhat.com,
	qemu-devel <qemu-devel@nongnu.org>,
	eblake@redhat.com, gcwilson@us.ibm.com,
	Marcelo Cerri <mhcerri@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [libvirt] [PATCH v4 0/5] Per-guest configurable user/group for QEMU processes
Date: Fri, 14 Sep 2012 09:40:51 +0100	[thread overview]
Message-ID: <20120914084051.GA7208@redhat.com> (raw)
In-Reply-To: <504F7F52.2010809@linux.vnet.ibm.com>

On Tue, Sep 11, 2012 at 02:13:38PM -0400, Corey Bryant wrote:
> Are there any other requirements that need to be taken care of to
> enable execution of QEMU guests under separate unprivileged user IDs
> (ie. DAC isolation)?
> 
> At this point, this patch series (Per-guest configurable user/group
> for QEMU processes) is upstream, allowing libvirt to execute guests
> under separate unprivileged user IDs.  Additionally, the QEMU bridge
> helper series is upstream, allowing QEMU to allocate a tap device
> and attach it to a bridge when run under an unprivileged user ID (http://www.redhat.com/archives/libvir-list/2012-August/msg00277.html).
> 
> Is there any other feature in QEMU that requires QEMU to be run as root?

Well those features you mention are for two separate issues. When
running libvirt privileged (qemu:///system), QEMU was already run
as non-root (qemu:qemu). The per-guest user/group was just making
sure that QEMU VMs were  isolated from each other using user IDs.
Since libvirtd is running privileged, it can either set permissions
or open things on QEMU's behalf. All this side of things really
works already.

The TAP device bridge helper is something that's needed when running
libvirtd itself unprivileged (eg the per user qemu:///session libvirtd).
In this case libvirtd can't access privileged resources at all, hence
the setuid TAP helper was required.

So I guess this is a roundabout way of saying that I'm not really
clear what you're asking about ? If you're using qemu:///system
there has never been any problem with running QEMU unprivileged.
When using qemu:///session you're obviously limited to whatever
resources the user is allowed to access.

Regards,
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 :|

  parent reply	other threads:[~2012-09-14  8:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1345068639-19528-1-git-send-email-mhcerri@linux.vnet.ibm.com>
2012-09-11 18:13 ` [Qemu-devel] [libvirt] [PATCH v4 0/5] Per-guest configurable user/group for QEMU processes Corey Bryant
2012-09-13 20:36   ` Marcelo Cerri
2012-09-14  8:40   ` Daniel P. Berrange [this message]
2012-09-14 13:31     ` Corey Bryant
2012-09-14 13:51       ` Daniel P. Berrange
2012-09-14 14:44         ` Corey Bryant

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=20120914084051.GA7208@redhat.com \
    --to=berrange@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=bryntcor@us.ibm.com \
    --cc=coreyb@linux.vnet.ibm.com \
    --cc=eblake@redhat.com \
    --cc=gcwilson@us.ibm.com \
    --cc=libvir-list@redhat.com \
    --cc=mhcerri@linux.vnet.ibm.com \
    --cc=mprivozn@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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).