[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qemu
Date: Thu, 05 Nov 2009 18:15:38 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Thunderbird/3.0b4

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]