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
