My apologies for double posting... I just realized that my last post
was not in plain text. Re-sending it in case the formatting caused
annoyance.
On Tue, Nov 6, 2012 at 3:30 AM, Laine Stump <laine@xxxxxxxxx> wrote:
> 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