MacOS; Unix sockets & man (Re: Call for testing: OpenSSH 6.7)

[Phil Pennock]

On 2014-09-11 at 06:31 +0000, Phil Pennock wrote:
> Downloaded openssh-SNAP-20140911.tar.gz onto MacOS 10.8.5, using Clang
> (Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)).

> The Unix port forwarding appears to be undocumented.  From reading the
> code, presence of a '/' anywhere in the PORT field causes
> parse_fwd_field() to mark the item as a path.  When I supply an absolute
> path, this works and works great!  :)  If I supply a relative path, then
> it's passed to the server as a path but fails, triggering a warning
> message:

In addition, `-o StreamLocalBindUnlink=yes` is ineffective when used
with -R:

  ssh -R /tmp/f1:www.spodhuis.org:80 \
    -o ExitOnForwardFailure=yes \
    -o StreamLocalBindUnlink=yes \
    -p 27 localhost

The server logs:
----------------------------8< cut here >8------------------------------
debug1: server_init_dispatch_20
debug1: server_input_global_request: rtype streamlocal-forward at openssh.com want_reply 1
debug1: server_input_global_request: streamlocal-forward listen path /tmp/f1
debug3: channel_setup_fwd_listener_streamlocal: type 19 path /tmp/f1
bind: Address already in use
unix_listener: cannot bind to path: /tmp/f1
----------------------------8< cut here >8------------------------------

For `StreamLocalBindUnlink` the man-page text "This option is only used
for port forwarding to a Unix-domain socket file." is also a little
strange.  It might be a failure of my imagination, but it seems that
port-forwarding destinations which are also accept-only are really
bi-directional and so with "interesting" security implications.

It seems more likely that the "forwarded to" location is always going to
be a connect() to an existing socket, which it makes no sense to unlink
first, so the `StreamLocalBindUnlink` bind+unlink semantics mean this
should be "for port forwarding from a Unix-domain socket file." --
"from", not "to".

Regards,
-Phil