Re: Specifying names for tap interfaces

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

On Mon, 18 Jun 2012 12:21:17 -0400
Thor Lancelot Simon <tls%panix.com@localhost> wrote:

> On Mon, Jun 18, 2012 at 11:54:43AM -0400, Greg Troxel wrote:
> > 
> > Thor Lancelot Simon <tls%panix.com@localhost> writes:
> > 
> > > On Mon, Jun 18, 2012 at 11:51:13AM -0400, Greg Troxel wrote:
> > >> 
> > >> It seems easy enough to add the ioctl and see if things blow up...
> > >
> > > You can be pretty sure ipf, pf, and npf will blow up.
> > 
> > Because they watch interface creation and keep matching state?  Or do
> > you just mean that rules written for tap3 will no longer match?
> 
> Rename the interface.  Now watch what happens when you try to load new
> rules.  Now tell ipfilter, for example, to "resynchronize the interface
> list" (ipf -y).  Imagine the fun possible if interfaces change names,
> old interfaces, with rules affixed, still exist but the names no longer
> match, etc...
> 
> I think a lot of fun is possible, and likely.

Firewall rules can use interface names rather than device IDs as they
can be loaded before interfaces get configured?

In the case of cloned pseudo-devices such as tap(4), new firewall rules
generally have to be dynamically added after the new interface name/id
is known however, similar to with routes.

If TAPSIFNAME was allowed, possibly that it should be restricted to
cloning pseudo-interfaces, and only allow to be used once per
instance.  I still see some possible race condition issue if another
subsystem monitors newly created interfaces; it's unlikely that they
expect a special message about an interface name change.

It would be nicer if it was possible to specify the name before the
interface was created, such that they atomically be created with the
target name, but I'm not sure how to provide this without breaking
backwards compatibility, as I think that cloning tap(4) devices are
implicitely created (before one has the opportunity to set its
name)...  Unless of course we had yet another tap(4) cloning device
node, behaving slightly differently.
-- 
Matt