Commit Graph

155 Commits

Author SHA1 Message Date
David Woodhouse
ca6bb5d7ab [NET]: Require CAP_NET_ADMIN to create tuntap devices.
The tuntap driver allows an admin to create persistent devices and
assign ownership of them to individual users. Unfortunately, relaxing
the permissions on the /dev/net/tun device node so that they can
actually use those devices will _also_ allow those users to create
arbitrary new devices of their own. This patch corrects that, and
adjusts the recommended permissions for the device node accordingly.

Signed-off-By: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-06-23 02:07:44 -07:00
Dave Jones
8f22757ee8 [TUN]: Fix leak in tun_get_user()
We're leaking an skb in a failure path in this function.

Coverity #632
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-03-11 18:49:13 -08:00
Mike Kershaw
ff4cc3ac93 [TUNTAP]: Allow setting the linktype of the tap device from userspace
Currently tun/tap only supports the EN10MB ARP type.  For use with
wireless and other networking types it should be possible to set the
ARP type via an ioctl.

Patch v2: Included check that the tap interface is down before changing the
link type out from underneath it

Signed-off-by: Mike Kershaw <dragorn@kismetwireless.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-09-01 17:40:05 -07:00
David S. Miller
b03efcfb21 [NET]: Transform skb_queue_len() binary tests into skb_queue_empty()
This is part of the grand scheme to eliminate the qlen
member of skb_queue_head, and subsequently remove the
'list' member of sk_buff.

Most users of skb_queue_len() want to know if the queue is
empty or not, and that's trivially done with skb_queue_empty()
which doesn't use the skb_queue_head->qlen member and instead
uses the queue list emptyness as the test.

Signed-off-by: David S. Miller <davem@davemloft.net>
2005-07-08 14:57:23 -07:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00