openssh server and tun devices

[Alex Bligh]

Ralf,

(Hi - long time no speak)

--On 21 September 2009 23:18:30 +0100 Ralf Hack <ralf.hack at gmail.com> wrote:

>   So the tunnel device should be available in ifr.ifr_name ( i.e. tun0,
> tun0, etc. ) in sys_tun_open(). At this point the struct is put on the
> stack and destroyed of course when leaving sys_tun_open() but not before
> it is printed for debugging purposes. The server does not appear to make
> use of this information any further than that and relies on
> open(/dev/net/tun) to be race condition free and to create a unique fd
> handle. Have you any reason to believe that this is not the case ?

That, in the end, was my conclusion too. Combined with the assumption
that there could be only one tun/tap tunnel per child, I think this
is race free (see my patch).

>   As to the latter question - for the above reason the tunnel device is
> probably not available anywhere to query. Would be nice though to see it
> in when probing the server with "~#".

I think the client also uses tun_open etc., in which case my patch could
easily be adapted so that '~#' listed the /client/ tunnel name. It
would simply need to call tun_getname(). Bringing the server tunnel
name back to the client would be harder (I'm not sure how ~# etc work).

-- 
Alex Bligh