Re: [Qemu-devel] [PATCH] net: Allow specifying ifname for qemu-bridge-helper

[Michael Tokarev <mjt@tls.msk.ru>]

Somehow I missed this email initially.. replying now.

On 12.10.2012 22:04, Mike Lovell wrote:
> On 10/12/2012 02:32 AM, Michael Tokarev wrote:
>> On 12.10.2012 10:49, Mike Lovell wrote:
>>>       /* request a tap device, disable PI, and add vnet header support if
>>> -     * requested and it's available. */
>>> -    prep_ifreq(&ifr, "tap%d");
>>> +     * requested and it's available. use ifname if provided for tap name. */
>>> +    prep_ifreq(&ifr, ifname != NULL ? ifname : "tap%d");
>> Should we check for special symbols here? prep_ifreq() does this:
>>
>>      snprintf(ifr->ifr_name, IFNAMSIZ, "%s", ifname);
>>
>> so at least it ensures we have length constraint.
> 
> I tried the code as is with specifying ifnames with various random combinations of special characters. Some of them we just allowed through, some caused an error when initializing the tap device, and some cause problems in the shell invoking qemu. I think the linux kernel does the necessary checking during the TUNSETIFF ioctl and the qemu-bridge-helper exits with an error if there was a problem.
> 
>> Actually I'm not so sure anymore this is a good idea.
>> For example, system may have firewall (iptables) rules
>> in place for, say, future ppp interfaces for ppp clients,
>> and this way we may request the interface to be named
>> pppX and be allowed to send packets where we don't usually
>> have access to.
> 
> While I admit this does have that possibility, I'm not sure its a qemu problem. I don't know what the original motivation for the request was but I could see this being the reason for the request. Some administrator sets up firewall rules for a variety of guests ahead of actually running them and needs to specify the interface at runtime. Also, without using the helper programs, the qemu already allows specifying arbitrary names such as ppp0.

qemu allows arbitrary names, yes, but it does not have extra
permissions to create them, -- only ones of the current user.
The helper, on the other hand, does have extra privileges which
a regular user does not.  That's exactly what I was talking
about.

Maybe _always_ having a common prefix is a good idea after all,
with --name=FOO appended to it, like qvifFOO.  Or use --ifnumber=NNN
instead of --name (which I dislike).

>> Maybe - at least - require some common prefix for the
>> interfaces created this way, so we'll live in our own,
>> easily distinguishable namespace -- like, qvif* (from
>> Qemu Virtual InterFace)?
> 
> I do like the idea of using a common prefix for the default name of tap devices. Something like "qvif%d" instead of "tap%d" in tap initialization code. But something tells me this could break compatibility with external management software where something might be expecting the interface name to start with tap.

Does any management interface use this bridge-helper functionality?
If it were me, I'd always created the tap fd in the management
layer and passed the tap fd# (or at least ifname= of an existing
iface) to qemu.  Bridge helper is useful for users calling qemu
directly, not for management software.  Sure, such users are also
important - including compatibility.  But I don't think current
unpredictable tapNN names was a good idea to start with, and that
it's good idea to rely on this prefix in firewall rules or whatnot.

Thanks,

/mjt