openssh bugs - Jul 2016 - [Bug 2601] New: StreamLocalBindUnlink not working

https://bugzilla.mindrot.org/show_bug.cgi?id=2601

            Bug ID: 2601
           Summary: StreamLocalBindUnlink not working
           Product: Portable OpenSSH
           Version: 7.2p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: harald at redhat.com

StreamLocalBindUnlink is advertised as an option for the client
program.
Following the codepath, it ends up as an option for the server program.

Server process receives in serverloop.c:1409
"streamlocal-forward at openssh.com"

receives fwd.listen_path

calls channel_setup_remote_fwd_listener(&fwd, NULL, &options.fwd_opts)

channels.c:
channel_setup_local_fwd_listener ->
channel_setup_fwd_listener_streamlocal

channel_setup_fwd_listener_streamlocal(int type, struct Forward *fwd,
    struct ForwardOptions *fwd_opts)

calls unix_listener(fwd->listen_path, SSH_LISTEN_BACKLOG,
        fwd_opts->streamlocal_bind_unlink)

fwd_opts->streamlocal_bind_unlink is set in servconf.c and thus a
server option.

To fix this, not only the fwd.listen_path would have to be transmitted,
but also the bind_unlink flag, which would probably need a new type of
message, like "streamlocal-forward-unbind at openssh.com"

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2601

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Todd.Miller at courtesan.com,
                   |                            |djm at mindrot.org

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
Could you take a look at this Todd?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2601

--- Comment #2 from Harald Hoyer <harald at redhat.com> ---
ping?

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2601

--- Comment #3 from Todd C. Miller <Todd.Miller at courtesan.com> ---
A Unix domain socket can be used on either the local or remote side. 
That is why the StreamLocalBindUnlink and StreamLocalBindMask settings
appear in both ssh_config and sshd_config.  I'm not sure that
overriding the values in sshd_config on the remote end with those from
the local ssh is a good idea.  Perhaps we need separate options to
specify the values to be sent to the remote end?

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2601

--- Comment #4 from Harald Hoyer <harald at redhat.com> ---
(In reply to Todd C. Miller from comment #3)
> A Unix domain socket can be used on either the local or remote side.
> That is why the StreamLocalBindUnlink and StreamLocalBindMask
> settings appear in both ssh_config and sshd_config.  I'm not sure
> that overriding the values in sshd_config on the remote end with
> those from the local ssh is a good idea.  Perhaps we need separate
> options to specify the values to be sent to the remote end?
why should it be globally restricted in sshd_config?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2601

nwf <OU4S0YPQ4GIF0BDMXA6HD90Q6ZVEL0 at cmx.ietfng.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |OU4S0YPQ4GIF0BDMXA6HD90Q6ZV
                   |                            |EL0 at cmx.ietfng.org

--- Comment #5 from nwf <OU4S0YPQ4GIF0BDMXA6HD90Q6ZVEL0 at cmx.ietfng.org>
---
This bug is remarkably irritating!  I use domain sockets forwarding to
bring my GPG agent with me as I ssh around the universe and roughly
100% of the time, I have to log in, rm the stale forwarding socket, log
out, and log back in.  "Warning: remote port forwarding failed for
listen path /users/nwf/.gnupg/S.gpg-agent" is particularly galling
because I have full permission to remove the offending file *and* I
have the StreamLocalBindUnlink directive asserted which is documented
to solve this problem!

There appears to be nothing that executes, server-side, under client
control prior to attempting UNIX domain socket bindings, so I can't
even hack around the bug with something like .ssh/rc containing a rm
call.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2601

Luca Capello <luca at pca.it> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |luca at pca.it

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2601

benlongo9807 at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |benlongo9807 at gmail.com

--- Comment #6 from benlongo9807 at gmail.com ---
Just ran into this - the documentation on the client makes it sound
like it will clean up the socket when remote forwarding is happening,
but the server must be configured to do this. Currently, there is no
way to properly do remote forwarding of unix sockets to a server more
than once as it will fail the second time.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.