Bug 2318 - ControlPath name collisions when using shared locations like /tmp for the sockets.
Summary: ControlPath name collisions when using shared locations like /tmp for the soc...
Status: CLOSED WONTFIX
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: ssh (show other bugs)
Version: 6.7p1
Hardware: All All
: P5 enhancement
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-15 13:39 AEDT by Christoph Anton Mitterer
Modified: 2016-08-02 10:42 AEST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christoph Anton Mitterer 2014-11-15 13:39:14 AEDT

    
Comment 1 Christoph Anton Mitterer 2014-11-15 13:44:35 AEDT
(Sorry, hit enter too fast)


This issue is from [0], see also bug #2311.


If a shared location like /tmp would be used for the ControlPath setting of ssh, the following issues may arise:

1) %C (the hash hover local host, remote user, hostname, port) alone, may lead to collisions, since local host, remote user, hostname, port are not alone to generate unique names.
The local user name should be added to %C.

2) The manpage section which tells people which data they should use at least to prevent collisions should be adapted as well, to also include %u (i.e. the local user name).


Cheers,
Chris.

[0] https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-November/033140.html
Comment 2 Damien Miller 2014-12-11 15:12:58 AEDT
Like the manual now recommends, don't use shared directories for mux sockets.

If you do use shared directories and are happy to accept that particular risk, then it is up to you to make the path unique. You can add %u to the path explicitly very easily.

I don't see a compelling reason to change this.
Comment 3 Christoph Anton Mitterer 2014-12-12 13:28:56 AEDT
(In reply to Damien Miller from comment #2)
> I don't see a compelling reason to change this.
Becuase it's a better an cleaner way of handling it, for those people who do want to use shared locations, and likely is trivial or doesn't require much work?

Apart from that,... same argumentation with the bug #2311 - since closing that one is a mistake, closing this one is either.
Comment 4 Damien Miller 2016-08-02 10:42:46 AEST
Close all resolved bugs after 7.3p1 release