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

[Michael Tokarev]

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