Patchwork tun: add IFF_TUN_EXCL flag to avoid opening a persistent device.

login
register
mail settings
Submitter David Woodhouse
Date April 23, 2009, 5:04 p.m.
Message ID <1240506258.15245.11.camel@macbook.infradead.org>
Download mbox | patch
Permalink /patch/26375/
State Accepted
Delegated to: David Miller
Headers show

Comments

David Woodhouse - April 23, 2009, 5:04 p.m.
When creating a certain types of VPN, NetworkManager will first attempt
to find an available tun device by iterating through 'vpn%d' until it
finds one that isn't already busy. Then it'll set that to be persistent
and owned by the otherwise unprivileged user that the VPN dæmon itself
runs as.

There's a race condition here -- during the period where the vpn%d
device is created and we're waiting for the VPN dæmon to actually
connect and use it, if we try to create _another_ device we could end up
re-using the same one -- because trying to open it again doesn't get
-EBUSY as it would while it's _actually_ busy.

So solve this, we add an IFF_TUN_EXCL flag which causes tun_set_iff() to
fail if it would be opening an existing persistent tundevice -- so that
we can make sure we're getting an entirely _new_ device.

Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
David Miller - April 27, 2009, 10:24 a.m.
From: David Woodhouse <dwmw2@infradead.org>
Date: Thu, 23 Apr 2009 18:04:18 +0100

> When creating a certain types of VPN, NetworkManager will first attempt
> to find an available tun device by iterating through 'vpn%d' until it
> finds one that isn't already busy. Then it'll set that to be persistent
> and owned by the otherwise unprivileged user that the VPN dæmon itself
> runs as.
> 
> There's a race condition here -- during the period where the vpn%d
> device is created and we're waiting for the VPN dæmon to actually
> connect and use it, if we try to create _another_ device we could end up
> re-using the same one -- because trying to open it again doesn't get
> -EBUSY as it would while it's _actually_ busy.
> 
> So solve this, we add an IFF_TUN_EXCL flag which causes tun_set_iff() to
> fail if it would be opening an existing persistent tundevice -- so that
> we can make sure we're getting an entirely _new_ device.
> 
> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>

Applied to net-next-2.6, thanks David.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 16716ae..0488380 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -867,6 +867,8 @@  static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
 
 	dev = __dev_get_by_name(net, ifr->ifr_name);
 	if (dev) {
+		if (ifr->ifr_flags & IFF_TUN_EXCL)
+			return -EBUSY;
 		if ((ifr->ifr_flags & IFF_TUN) && dev->netdev_ops == &tun_netdev_ops)
 			tun = netdev_priv(dev);
 		else if ((ifr->ifr_flags & IFF_TAP) && dev->netdev_ops == &tap_netdev_ops)
diff --git a/include/linux/if_tun.h b/include/linux/if_tun.h
index 049d6c9..915ba57 100644
--- a/include/linux/if_tun.h
+++ b/include/linux/if_tun.h
@@ -55,6 +55,7 @@ 
 #define IFF_NO_PI	0x1000
 #define IFF_ONE_QUEUE	0x2000
 #define IFF_VNET_HDR	0x4000
+#define IFF_TUN_EXCL	0x8000
 
 /* Features for GSO (TUNSETOFFLOAD). */
 #define TUN_F_CSUM	0x01	/* You can hand me unchecksummed packets. */