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

[Mike Lovell]

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.

> 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.

mike