http://25thandclement.com/~william/openssh-4.3p2-streamlocal-20060421.patch The above URL is a complete patch to OpenSSH 4.3p2 to implement unix domain socket forwarding (this supercedes a canceled message I sent last night w/ an inline attachment). Basically, for forward and reverse forwardings anywhere you previously put a port number you can now put a path. The socket path should go between braces (`[' and `]'), and backslash escaping is honored within. Basically, any "port" which uses an escaping mechanism is considered a path instead. That way you can have socket paths like 1234 w/o ambiguity. -L[</path/to/socket>]:<host>:<port> -L<port>:[</path/to/socket>] -L[</path/to/socket>]:[</path/to/another_socket>] -R[</path/to/socket>]:<host>:<port> -R<port>:[</path/to/socket>] -R[</path/to/socket>]:[</path/to/another_socket>] I've added several new SSH messages: streamlocal-forward at openssh.com forarded-streamlocal at openssh.com cancel-streamlocal-forward at openssh.com direct-streamlocal at openssh.com streamlocal from "AF_LOCAL" and "SOCK_STREAM". Seemed to logically follow from the tcpip messages. Um, included in this patch, for now, is my previous patch which added options to specify a mask and access control lists for control sockets. I'll seperate them out when I port this over to the main OpenSSH source in OpenBSD. So, the following options are honored with this patch: Client: -> old stuff <- ControlBindMask Mask to use when binding a control socket ControlAllowUsers List of users and uids allowed to connect ControlAllowGroups List of groups and gids allows to connect ControlDenyUsers List of users and uids disallowed ControlDenyGroups List of groups and gids disallowed -> new stuff <- StreamLocalBindMask Mask to use when binding a forward socket StreamLocalBindUnlink Attempt an unlink before binding FakeStreamLocalForwards Fake a connection originating from a socket as tcpip. This isn't currently honored, but is the default and only behavior. See channel_post_port_listener(). Server: StreamLocalBindMask See above. StreamLocalBindUnlink See above. All regression tests pass, though I haven't yet added any for the new functionality. Please send suggestions and comments. It would be nice if this were included, or at least had the prospect of inclusion in the future. - Bill
On Sat, Apr 22, 2006 at 11:07:57PM +0200, Joachim Schipper wrote:> I don't want to be disrespectful or anything - this is a honest > question. But: what's the point? Why would one want to forward UNIX > domain sockets?Fair enough ;) That's the first question I'd ask, too, considering how large the patch is. So, I'll reply to the list as well.> I can see it being useful in some theoretic cases, but almost all > programs can either use internet sockets too (X), or netcat will do just > fine.In some circumstances binding to internet sockets can become unwieldly. If you map a single service to a single port, it's easy. But try mapping a single service from multiple remote machines to multiple ports. How do you choose which ports to use, especially if the remote machines are dynamic? (Don't forget you might have t deal w/ conflicts.) How you do you relay that information to the clients so they know which dynamic port to use to reach particular remote services? Using the filesystem namespace is _much_ cleaner because, well, it's a more powerful _namespace_. TUN doesn't always solve this problem as well as domain sockets. Dare I say it's a less desirable solution altogether when anything less than full network visibility is required. Domain sockets fill the gap between internet addressing and filesystem naming. netcat just doesn't work; it only allows you to open one connection at a time, assuming you're tunneling through a channel. Using it to link a port to a socket doesn't solve the naming issues at all. Originally I wrote this for my job. We have at least two different widely disparate uses for it. But, I intend to use it outside of work for several other things as well (which is why I'll make the effort to suit this patch to everybody's needs, if it indeed might be accepted). Just keep in mind that being able to use the filesystem namespace can make some tasks much, much simpler. Plus, it just makes sense, IMHO. Also, on some platforms (like Linux and maybe all of SysV-land) which obey socket file permissions it gives you free access control (for better or worse; I don't necessarily agree or disagree that socket file permissions should be obeyed). - Bill