[Top][All Lists]

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

Re: [Qemu-discuss] Tap Devices

From: Jakob Bohm
Subject: Re: [Qemu-discuss] Tap Devices
Date: Fri, 30 Nov 2012 11:25:44 +0100
User-agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0

On 11/30/2012 7:02 AM, Mike Lovell wrote:
On 11/29/2012 01:59 PM, Frans de Boer wrote:
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.

having ifconfig, tunctl, and ovs-vsctl all suid is probably a really bad idea. that would allow anyone, or anything, on the system to reconfigure the networking on the host without security checking and possibly without the ability to know who made the changes.

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.

do you use ifconfig, tunctl, or ovs-vsctl for operations other than bring the tap interface up, creating a tap interface, and adding the tap to the openvswitch bridge?

if that is all you are using them for then it is possible to use qemu-bridge-helper. without access to those utilities, it can create a tap device, bring the interface up, and connect it to a bridge. the potentially hard part is that the operation to connect the tap to the bridge is through the standard bridge interface and so it wouldn't be able to directly manipulate openvswitch. it is possible to do this when also using the openvswitch brcompat module and daemon. these make it so the standard bridge interfaces will manipulate openvswitch bridges. see INSTALL.bridge in the openvswitch source for setting it up.

i set up openvswitch on a box i had laying around and got the brcompat support working. after doing that, i was able to use openvswitch with the qemu-bridge-helper. 'qemu-system-x86_64 -net nic -net bridge,helper=/usr/lib/qemu-bridge-helper,br=br0' was able to start a vm and checking 'ovs-vsctl list-ports br0' showed a new tap device connected to the openvswitch bridge.

if the scripts you are using do more than just creating the tap interface, connecting it to the bridge, and bringing up the interface then the qemu-bridge-helper probably wouldn't work as is. if that is case, i would recommend writing some set of scripts that include sudo and adding the sudo commands to sudoers. something like this might work

sudo ifconfig $1 up
sudo ovs-vsctl add-port $BRIDGE $1

sudo ifconfig $1 down
sudo ovs-vsctl del-port $BRIDGE $1

sTAPID=`sudo tunctl -b -u $USER`
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=sudo-ovs-ifup,downscript=sudo-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

then add something like "%qemu ALL= NOPASSWD: /sbin/ifconfig,/usr/bin/ovs-vsctl,/usr/sbin/tunctl " in sudoers. i just typed this in the email and not tested so typos or slight errors might exist but the general idea should work.

There is also the "super" program which is more tailored to this kind of situation.

"super" is a suid binary which consults a global "super.tab" file listing virtual commands such as "qemu-ifup", specifies what real users can call it and what real command to execute as which user and in which environment. Unlike sudo, there is no "type your password again" prompting, security is assured by more strictly limiting who can do what and not having a general shell as a default option. If you symlink /usr/local/bin/qemu-ifdown to /usr/bin/super, when non-root runs "qemu-ifdown", this gets mapped to the "qemu-ifdown" entry in super.tab, which then determines the rules and script to run.



Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

reply via email to

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