Date: Fri, 09 Mar 2007 12:30:48 +0000 From: "Bruce M. Simpson" <bms@FreeBSD.org> To: Frank Behrens <frank@pinky.sax.de> Cc: freebsd-net@freebsd.org Subject: Re: tap(4) should go UP if opened Message-ID: <45F15378.3020207@FreeBSD.org> In-Reply-To: <200703091036.l29AawwJ005466@pinky.frank-behrens.de> References: <200703091036.l29AawwJ005466@pinky.frank-behrens.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Frank Behrens wrote: > How does tun(4) handle this? tun(4) is also set to down, when closed. It is not set to up, when > ist is opened, but when an address is assigned by the user process. This is fine, because it > needs always an ip address. tap(4) as layer 2 tunnel device does not need an ip address, so > setting it up on open is IMHO the best solution. > > This isn't consistent with the other software cloneable interfaces which emulate certain layer 2 semantics, e.g. bridge, trunk, vlan; see below. > Sound this reasonable or how should I handle the tap(4) open by an user process, when this > process does not run as root? > I recently committed Landon Fuller's code which makes tap and tun cloneable interfaces which may then be created via 'ifconfig tap0 create'. Automatically setting the interface to IFF_UP is not consistent with the semantics for other network interfaces; it requires specific privileges (usually super-user or PRIV_NET_SETIFFLAGS in -CURRENT) to do. However, we also support the creation of tap/tun instances by non-super-users, so there is motivation for the change. Configuring a tap interface to up by a non-superuser should only be permitted if the interface itself was created by a non-superuser, and if net.link.tap.user_open is set to 1. A more involved patch is needed to do this right for all cases -- we should not do this by default. Regards, BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45F15378.3020207>