When a /dev/tun special file is closed, it loses its assigned IP address. Looks like it happens near line 467 of if_tun.c (the close routine), but I am not sure exactly where. How-To-Repeat: [root@fb91 ~]# ifconfig tun0 up 10.0.0.103 10.0.0.104 [root@fb91 ~]# ifconfig tun0 tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500 options=80000<LINKSTATE> inet6 fe80::7254:d2ff:fe45:e0a0%tun0 prefixlen 64 scopeid 0x5 inet 10.0.0.103 --> 10.0.0.104 netmask 0xff000000 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> [root@fb91 ~]# cat /dev/tun0 ^C [root@fb91 ~]# ifconfig tun0 tun0: flags=8010<POINTOPOINT,MULTICAST> metric 0 mtu 1500 options=80000<LINKSTATE> nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
Perhaps I should describe my application. I wish to configure a tun device at boot with an IP address and chown the corresponding /dev/tun file to the userID that will use it running Hercules. The other end of the tunnel is an IBM System/360 channel-to-channel adapter. I would like to be able to restart Hercules without having to issue commands (or ioctl()s) that require root privileges. Hercules ships a setuid program, hercifc, to set interface parameters by ioctl(). I am required to be rid of this trojan horse. Thanks, j.
The error was introduced by http://www.freebsd.org/cgi/query-pr.cgi?pr=100080
Responsible Changed From-To: freebsd-bugs->freebsd-net Over to maintainer(s).
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped
Created attachment 198393 [details] Proposed patch I took a stab at patching tun to bring it into parity with tap. In line with tap behavior, it will check for the IFF_LINK0 flag on the interface. If present, it will persist the IPs and routes even when the device node is closed. In addition to the use case listed in earlier comments, this makes IP-aliased jail interaction with tun nicer in that processes within the jail (e.g. OpenVPN) can be bounced without having to restart the jail or externally reconfigure IPs/routes on the tun.
Thank you. The current behaviour actually has a security issue as a non-privileged user can cause reconfiguration, i.e., remove the ip address from the interface. E.g., (from a linux system where this bug arrived some five years ago): openvpn --mktun --dev tun4 --user john --group john ifconfig tun4 up 10.0.0.32/30 pointopoint 10.0.0.33 User john now has escalated privileges with respect to the configuration of tun4, insofar as he can clear the IP address assigned simply by opening and closing the device.