Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qemu

[Avi Kivity]

On 11/05/2009 06:06 PM, Anthony Liguori wrote:
> Avi Kivity wrote:
> > > If we make this easy for management software to do, they're more 
> > > likely to do the right thing.
> >
> > But we're forcing our style of security management on them.  How to 
> > store permissions is the management system's job (and for a clu^Houd, 
> > it will typically be stored in a central database, not be scattered 
> > around /etc).
> >
> > Again, IMO we should stick to making a guest work, and leave all the 
> > glue to management.
>
> That's short sighted.  If we just focus on "making a guest work" we'll 
> end up with crappy interfaces that cripple management tools. 

Only with management tools that cripple themselves.  It's pretty easy to 
get unprivileged bridging with -net tap; it's just that libvirt hadn't 
gotten around to it yet -- see Dan's comment.  Are you going to take on 
every libvirt deficiency and push it into qemu?

> If users are constantly struggling to do even the simplest things with 
> qemu, then it doesn't matter how well our "guest works".  No one will 
> use it.

That's not the case today, even with virt-manager.

> I think we absolutely have to think about the full stack and how all 
> the pieces interact.  There are definitely problems in the stack right 
> now.  Security is the one I'm trying to address in this series.  If 
> you cannot launch a reasonable configured qemu from the command line 
> as an unprivileged user, there's really no hope that we can expect a 
> management tool to do that.

I'm almost offended on Dan's behalf.

> Again, there are no shortage of existence proofs of this (beyond 
> libvirt).  I suspect there isn't a management tool out there that does 
> the right thing today.

RHEV-H launches guests as unprivileged users; the management daemon is 
also unprivileged.

--
error compiling committee.c: too many arguments to function