openssh unix dev - Feb 2007 - tunneling support for PF_UNIX sockets

Hi,

I've been planning to develop a support for tunneling between
"local_tcp
=> server_AF_UNIX".

This way, every user of server machine, can have:
1. personal address space (if socket is located on personal directory).
Currently one must check assigned local port every time starting a
server (e.g. vncserver), and redirect a local port to "random" remote
port.
2. Added security. If server application in remote machine supports
AF_UNIX sockets, socket can be made accissible to the user only (by
locating it to 700 directory).

Questions:

3. Is there a way to achieve same goals with current ssh version?

4. Is there a reason not to do this?

5. Is there a already available naming convention to support different
address families?
Quick_n_dirty way would be prefixing host_address with some predefined
"illegal" character (e.g. '#'), to signal the AF_UNIX address.
But I see
that general, expandable naming convention would give more. One could
e.g. define an address space of "AF_EXEC", which would execute program
on remote host every time new tunnel is initiated.
I was thinking something like:
"AF_UNIX::/home/user/dir/sock_file" for UNIX sockets (ssh -newflag
8080:AF_UNIX::/home/user/dir/sock_file hostname.com)
"AF_INET::localhost:80" for tcp redirection, this should be default,
if
no AF_* is specified.
"AF_EXEC::/home/user/server_executable -p param" for executable
redirection.

6. Local port support for new address families can gain some new usage.
Any ideas for this?

Any further ideas ?

-- 
  Topi

On Mon, Feb 05, 2007 at 05:47:19PM +0200, Topi Rinkinen
wrote:
> Hi,
> 
> I've been planning to develop a support for tunneling between
"local_tcp
> => server_AF_UNIX".
http://www.25thandclement.com/~william/projects/streamlocal.html
> Questions:
> 
> 3. Is there a way to achieve same goals with current ssh version?
No. And extensive patching to OpenSSH is required for AF_UNIX because the
codebase assumes AF_INET or AF_INET6 at every single point, and it assumes
in such a way that precludes easy integration of AF_UNIX.
> 4. Is there a reason not to do this?
1) It took a ton of work.

2) So much work the OpenSSH folks haven't even cared to look into it my
patch, let alone hold out the chance for integration into the trunk.
> 5. Is there a already available naming convention to support different
> address families?
No. I used a square brace ('[') convention, and re-wrote the option
parser
for addresses.
> Quick_n_dirty way would be prefixing host_address with some predefined
Nope. The addresses are sent across the wire in a fixed format which
precludes use of the relatively free-form AF_UNIX paths.

- Bill