Hi, checking the Changelog for 2.6.18 (and diffing) one can see, that the CAP_NET_ADMIN requirement was added for the tun/tap inerface in tun.c. The question is, is it acceptable for a user to add a tun/tap interface in a running system. It was before 2.6.18. A different approach is, to grant the user or the process the CAP_NET_ADMIN capabillity. If the user of the system running qemu is in control of the system, he might start qemu as root. The tun/tap interface is created (due to root-rights), but i wouldn't like to see windows running in a root started qemu. Running qemu with kqemu, you need to be able to modprobe kqemu in a root context. If a user has the right to modprobe a module, he can do anything. What might be critical is that a user-context started app might create also a tun/tap interface (for evil reason) without the knowledge of the user. But than one has to ask, what kind of software is he running. But nevertheless, if you patch the kernel, you have to know what you do ...
The changelog: http://lwn.net/Articles/190305/ (search for tuntap) Chris ######################################## On Sun, 15 Oct 2006 15:31:11 +0800 Tace <[EMAIL PROTECTED]> wrote: > Hi, > That might be some security issues with removal of that capability > check. I think it is not a good idea to remove it. > > 2006/10/14, chris friedhoff <[EMAIL PROTECTED]>: > > Hello, > > > > bringing up the tun/tap interface depends now on the capability > > CAP_NET_ADMIN, which usually only root has. > > This patch just removes this dependency, so normal user rights suffices > > again to bring up the tun/tap interface. > > > > diff -ruN linux-2.6.18-orig/drivers/net/tun.c linux-2.6.18/drivers/net/tun.c > > --- linux-2.6.18-orig/drivers/net/tun.c 2006-09-20 05:42:06.000000000 +0200 > > +++ linux-2.6.18/drivers/net/tun.c 2006-10-02 09:21:52.000000000 +0200 > > @@ -489,9 +489,6 @@ > > > > err = -EINVAL; > > > > - if (!capable(CAP_NET_ADMIN)) > > - return -EPERM; > > - > > /* Set dev type */ > > if (ifr->ifr_flags & IFF_TUN) { > > /* TUN device */ > > -------------------- Chris Friedhoff [EMAIL PROTECTED] _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
