On Wed, Nov 04, 2009 at 01:48:01PM -0600, Anthony Liguori wrote: > Michael S. Tsirkin wrote: >> On Tue, Nov 03, 2009 at 06:28:01PM -0600, Anthony Liguori wrote: >> >>> This series solves a problem that I've been struggling with for a few years >>> now. >>> One of the best things about qemu is that it's possible to run guests as an >>> unprivileged user to improve security. However, if you want to have your >>> guests >>> communicate with the outside world, you're pretty much forced to run qemu as >>> root. >>> >>> At least with KVM support, this is probably the most common use case which >>> means >>> that most of our users are running qemu as root. That's terrible. >>> >>> We address this problem by introducing a new network backend: -net bridge. >>> This >>> backend is less flexible than -net tap because it relies on a helper with >>> elevated privileges to do the heavy lifting of allocating and attaching a >>> tap >>> device to a bridge. We use a special purpose helper because we don't want >>> to elevate the privileges of more generic tools like brctl. >>> >>> >From a user perspective, to use bridged networking with a guest, you >>> >simply use: >>> >>> qemu -hda linux.img -net bridge -net nic >>> >>> And assuming a bridge is defined named qemubr0 and the administrator has >>> setup >>> permissions accordingly, it will Just Work. My hope is that distributions >>> will >>> do this work as part of the qemu packaging process such that for most users, >>> the out-of-the-box experience will also Just Work. >>> >>> More details are included in individual patches. I broke up the helper into >>> a series of patches to improve reviewabilty. >>> >> >> Would raw backend attached to a bridge mostly do the same? >> > > Well it doesn't really help with the issue of privileges which is what > this series is really about. > > Regards, > > Anthony Liguori
I note that by default you grant all users all access. If you do that, just give them net cap admin already? -- MST
