Bug 1902

Summary: persistent mux master should chdir away from the current directory
Product: Portable OpenSSH Reporter: Bert Wesarg <Bert.Wesarg>
Component: sshAssignee: Assigned to nobody <unassigned-bugs>
Status: NEW ---    
Severity: normal CC: calestyo, chrysn, djm, simon
Priority: P2    
Version: 5.8p2   
Hardware: All   
OS: All   
Attachments:
Description Flags
/home/djm/bz1902.diff none

Description Bert Wesarg 2011-05-06 22:28:57 AEST 
The persistent mux master keeps the same pwd where the initial call to ssh/scp happen. This is bad because this may be a mountpoint from an USB stick or sshfs, which can't be unmounted since than.

There are three possible proposals where to change into:

* the directory where the mux socket is in
* the users home directory
* the directory where the UserKnownHostsFile file is in
Comment 1 Damien Miller 2011-05-20 12:25:29 AEST 
Created attachment 2049 [details]
/home/djm/bz1902.diff

chdir to dirname(ControlPath)
Comment 2 Damien Miller 2011-05-20 12:27:18 AEST 
Unfortunately, I just thought of an annoying wrinkle: this will break any relative paths to known hosts files. Perhaps these should be run through derelativise_path() first?
Comment 3 chrysn 2015-02-19 00:19:41 AEDT 
looking to report this myself, i first found bug #1988; the change that fixed that back then ("djm@cvs.openbsd.org 2013/07/25 00:29:10") introduced a daemon(nochdir=1) call.

using daemon(0, 1) instead of daemon(1, 1) at the end of control_persist_detach solves this bug for me. it is a little hard for me to test continuously, though -- the change works when i building from source, not when building the debian package, but those issues don't belong here.

for reference, my test setup is

$ killall ssh
$ mkdir a
# mount -ttmpfs tmp a
$ cd a
$ ssh -F /dev/null -oControlPersist=yes -oControlMaster=auto -oControlPath=/tmp/x.sock somehost
somehost$ exit
$ cd ..
# umount a

which works (ie. umount returns 0) iff i run the using_daemon(0,1) version.

i did no tests with respect to relative paths -- what would a setup look like where relative paths could fail?
Comment 4 Damien Miller 2019-07-19 15:31:05 AEST 
*** Bug 2679 has been marked as a duplicate of this bug. ***