qemu-discuss
[Top][All Lists]
Advanced

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

Re: [Qemu-discuss] Tap Devices


From: Frans de Boer
Subject: Re: [Qemu-discuss] Tap Devices
Date: Thu, 29 Nov 2012 21:59:51 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0

On 11/29/2012 06:41 PM, Mike Lovell wrote:
On 11/28/2012 12:26 PM, Frans de Boer wrote:
Thanks, I did tried that before and setting the sguid bit did work
until the point that the device must be written in the /dev directory,
having made the /dev/net/tun node made world RW.
Another option is to create a new system group, and assign tunctl,
ifconfig and ovs-vsctl to that group. Assigning the new group to the
/dev directory does not seem to be a good (security) idea but might
solve the issue for now.

on my system, running ubuntu 12.04, /dev/net/tun by default had world RW
permissions. i checked the history of udev and its had 0666 as the
defaults for several years. i'm somewhat surprised that your system
doesn't have it that way. as i understand things, it doesn't hurt to
have it world RW since the tun module does permission checking on the
ioctl requests used to control it. i could be wrong on that one but
seeing that its been that way by default makes me think its not a problem.

the permissions shouldn't really matter though since all of the work to
create the tap device should be handled in the helper program. if the
helper is running as root, then it should be able to open /dev/net/tun
and issue requests to it properly. are you using sgid or suid on the
helper? i've never tried it sgid. what does ls -l on the helper look
like? it should have a s instead of x for the owner permission and it
needs to be owned by root. like

-rwsr-xr-x 1 root root 32282 Nov 29 10:29 qemu-bridge-helper

i just ran a vm using the qemu-bridge-helper as shown and running qemu
as my unprivileged user and without sudo. i even did a chmod 660
/dev/net/tun first and it still worked.

mike
I have made the solution. Remember that OpenvSwitch is part of the issue. The part initializing OpenvSwitch is not discussed here, but I needed to take the next steps:

Involved programs are: ifconfig, tunctl, ovs-vsctl.
These programs are set to system group 'qemu' (make it yourself)
The programs have the suid (sorry, not sgid!) bit set.
Also, /dev/net/tun has already the (default) 666 mode settings and there is no need to change the group from root to qemu.

Use the next example script nipped to create the tap device:

# Create the tap device with the proper group and user id's
sTAPID=$(/sbin/tunctl -b -g qemu -u `who -m|sed -r -e 's/[[:space:]]+.*$//'`)

qemu-system-x86_64 -machine type=pc,accel=kvm,kernel_irqchip=on --enable-kvm -cpu coreduo -smp 2 -vga std -soundhw ac97 -net tap,vlan=0,ifname=$sTAPID,script=/etc/openvswitch/ovs-ifup,downscript=/etc/openvswitch/ovs-ifdown -net nic,model=virtio,vlan=0,macaddr=52:54:00:00:FB:02 -m 2048 -localtime -name VWinXP-nl -boot c -monitor vc:1680x1050 -usb -usbdevice tablet -alt-grab -drive file=/media/raidarray/vms/vwinxpnl.raw,index=0,media=disk,if=virtio,cache=writeback -no-frame -cdrom /dev/null

The programs ifconfig and ovs-vsctl are used by the ovs-if[up|down] scripts when the tap device is initialized.

Note: the script as well as the disk image should have the same (qemu) group settings.


So, using OpenvSwitch has cost me much work - as opposed to using VDE who's documentation is far richer - but it pays off by a 20-30% faster net throughput.

That's all...pfffff.
Frans.



reply via email to

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