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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
