On Tue, Nov 6, 2012 at 3:30 AM, Laine Stump <laine@xxxxxxxxx> wrote:
I've only used type='ethernet' to verify that it worked, so don't have a
very good database of potential usage scenarios and whether or not what
I suggest below would work for all of them, so my advice here is suspect
:-) However, this is what I notice:
On the qemu commandline, both type='bridge' (I'll leave out
type='network' from now on, as it's essentially identical to bridge for
this discussion) and type='ethernet' add a "tap" argument to the qemu
command line, but in one case we create/open a tap device and sent the
fd to qemu with
-netdev tap,fd=nn,...
and in the other, we just blindly send the name of the tap device, as
well as script parameter (if requested) and allow qemu to open it:
-netdev tap,ifname=/dev/mytapX,script=/etc/libvirt/myscript,...
It *looks* like (from the "qemu-kvm -help" output) we could just as
easily open that tap device in libvirt, and send "-netdev
tap,fd=nn,script=/etc/libvirt/myscript,..." to qemu (or, when no script
is specified, just "-netdev tap,fd=nn,...".
After briefly looking at the qemu code, it looks like qemu does not like it when you send both fd and script. It requires that you send the device name if script is specified. But this isn't a problem as libvirt would have no problem figuring out whether it should send fd or device name.
If this is true (any qemu people who can tell me for sure?), simply
changing the code for type='ethernet' in this manner would solve your
problem - you would make sure that:
1) your <interface> is "type='ethernet'"
2) your tap device has a name ("<target dev='xxx'/>") that doesn't start
with "vnet", *and*
3) that device is created and attached to the proper place beforehand
libvirt would then open the provided tap device and pass it to qemu,
with no other action performed. Because it would be passing an open fd
to qemu (instead of a tap device name) and because there would be no
script involved, no decreased security level would be required for qemu.
This is precisely the solution that I was looking for :-) With this solution, if the device name is specified(that does not start with 'vnet'), libvirt will try to open the device with this name, and if the device does not exist, it would create a new one, and if it already exists, it would attach to it. Either way, libvirt has access to its fd which would be passed over to qemu, allowing it to run without fiddling around with its privilege level.
As far as running a user-specified script, currently we leave it up to
qemu to do this; perhaps we should have an attribute for type='ethernet'
that indicates libvirt should execute the script instead? (maybe the
choice of sending tap device name vs fd to qemu should be controlled by
the same attribute that controls whether libvirt or qemu executes the up
script.
(and btw, there's an open request to support the "down script" that qemu
supports).
One possible implementation could be that we introduce a 'secure' attribute for generic ethernet where if set to true, libvirt runs the script instead of qemu.
Would what I outlined above work? (modify type='ethernet' to open the
given tap device and send its fd rather than name + optionally executing
the script in libvirt rather than passing it to qemu)
Yes, your solution does work for me. Thanks for your helpful comments. As a first step, I think libvirt should implement the logic in which it opens an existing device and pass its fd to qemu if script is not specified(instead of always passing the device name). This should eliminate the security concerns for cases in which no script needs to run. And the second step is to handle the script execution logic where libvirt could optionally handle the execution of the script. Does that sound reasonable?
Ryu
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list