On 10/31/2012 05:10 AM, Ishimoto, Ryu wrote: It's not just that. It's also problematic that we are passing control over to some random external script about which we know nothing. This not only has security implications, but also supportability implications. That's why we set the "tainted" flag in the domain's status whenever there is an external script. As I recall, the "lowered host security level" is at least some extra cgroups acls (cgroup_device_acl, set in /etc/libvirt/qemu.conf) due to the fact that the tap device *name* is sent to qemu rather than libvirt opening the device and sending the open fd. Yes, that's exactly the kind of situation the generic ethernet device exists for. So the difference from standard type='network' or type='bridge' is that it expects the device to be already created, but not yet opened? And will it also already be attached to its bridge (or whatever device)? (One thing to point out is that the existing type='bridge' and type='network' interfaces already allow for the tap device to be already-created - if the interface definition has a <target> element with a "dev" attribute that doesn't start with "vnet", then libvirt doesn't try to auto-generate a name, instead using the name provided. Because ioctl(TUNSETIFF) (which libvirt uses to create/open the tap device) properly handles the case where the tap device already exists, in this case the existing tap device will be used.) Both of these are what the generic ethernet type is intended for, and as a matter of fact before explicit support was added for Open vSwitch, that's how people connected their tap devices to an Open vSwitch bridge. 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,...". 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. 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). 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)

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(a)laine.org&gt; wrote: 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. 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. 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. 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