You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
consider renaming internal ssh.exe to prevent sshfs-win picking up system tool with the same name #39
A SiriKali user just reported sshfs-win picking ssh.exe executable installed on the system and not the private copy shipping with sshfs-win and this could cause hard to debug issues.
Sshfs-win.c is a simple wrapper that is used to support the Windows \\sshfs\... syntax. I think SiriKali can use sshfs.exe directly (so that it also has access to its various options), but with some care in setting up the PATH, etc.
Sshfs-win.c is a simple wrapper that is used to support the Windows \sshfs... syntax.
Sorry for an off-topic question, but I'm getting more and more curious about all these projects surrounding sshfs for windows. Where exactly is this magic responsible for \\sshfs syntax implemented? Here or somewhere in WinFSP or elsewhere?
There's another occurence of this problem, but it's now cygwin's fault instead. See: #37 (comment)
While renaming internal ssh.exe might solve the issue, I don't think it is a good idea. I think it's better to keep these executables as close to original as possible to avoid any confusion. Maybe move it to some isolated subdirectory instead?
It would also be nice to make a proper public CLI wrappers. For example: there could be a new sshfs.exe proxy whose only job would be to init the env and then redirect all command line args straight to the original sshfs.exe (which should be isolated and not in PATH so it can't be accidentally called). All WinFsp-related customizations and hardcoded options could be extracted from sshfs-win to sshfs-fsp / sshfs-winfsp and sshfs-win.exe itself should be removed. In my opinion it would provide the best user experience no matter if one prefers mounting drives directly via CLI or mapping them with Explorer. What do you think?
PS I'm volunteering to help and work on this of course
The primary purpose of sshfs-win.c is to facilitate running sshfs through the WinFsp Launcher. Not everything that it does applies to command-line usage.
The Launcher is a Windows service and it runs in the context of the SYSTEM account (by default). So when it launches sshfs-win it does so in the SYSTEM context. But running sshfs in the SYSTEM context without the proper options is not very useful, because it gives file access to the SYSTEM account, but not to the user account that started the file system.
So sshfs-win.c determines the user account that actually started the file system and runs sshfs with the appropriate uid, gid options.
Of course, sshfs-win.c does some other things as well, like setting up the environment and default command-line parameters. For example, sshfs-win.c passes the special option -opassword_stdout, which instructs sshfs to respond OK when authentication succeeds. This is to support password-based authentication via the Explorer, etc.
Having said that I can see the usefulness of an sshfs proxy that could be used both from the WinFsp Launcher and the command line. What would the command line interface for such a utility look like in your opinion?
When I find some spare time I will make a few experiments based on the ideas from my previous comments and the insights you have provided. If there's anything useful born in the process then I think it's gonna be the best if I come back with an initial PR and we'll continue from there :)
Activity
billziss-gh commentedon Jul 24, 2018
Interesting
Sshfs-win.csets the path to/bin, so I would not have expected any issues.I am not sure about this, but I believe that
sshfshardcodes thesshname, so it might not be possible to rename it (except perhaps with a patch).I think the correct solution is to find out why
sshfsmay pick up the wrongsshat times.billziss-gh commentedon Jul 24, 2018
https://github.com/billziss-gh/sshfs-win/blob/master/sshfs-win.c#L33
4O4 commentedon Jul 25, 2018
@mhogomchungu @billziss-gh SiriKali is using
sshfs.exedirectly and not through thesshfs-win.exeproxy which actually sets the envmhogomchungu commentedon Jul 25, 2018
Which one of the two is SiriKali supposed to be using?
billziss-gh commentedon Jul 25, 2018
Sshfs-win.cis a simple wrapper that is used to support the Windows\\sshfs\...syntax. I think SiriKali can usesshfs.exedirectly (so that it also has access to its various options), but with some care in setting up thePATH, etc.4O4 commentedon Jul 25, 2018
Sorry for an off-topic question, but I'm getting more and more curious about all these projects surrounding sshfs for windows. Where exactly is this magic responsible for
\\sshfssyntax implemented? Here or somewhere in WinFSP or elsewhere?billziss-gh commentedon Jul 25, 2018
The
\\sshfs("UNC syntax") support is provided by WinFsp.EDIT: If you want the full story read this: WinFsp Service Architecture
4O4 commentedon Jul 27, 2018
Thanks! I'm gonna dig into it. I really like your projects, amazing job on the detailed documentation 👍
billziss-gh commentedon Jul 27, 2018
Thanks :)
4O4 commentedon Jul 30, 2018
There's another occurence of this problem, but it's now cygwin's fault instead. See: #37 (comment)
While renaming internal ssh.exe might solve the issue, I don't think it is a good idea. I think it's better to keep these executables as close to original as possible to avoid any confusion. Maybe move it to some isolated subdirectory instead?
It would also be nice to make a proper public CLI wrappers. For example: there could be a new sshfs.exe proxy whose only job would be to init the env and then redirect all command line args straight to the original sshfs.exe (which should be isolated and not in PATH so it can't be accidentally called). All WinFsp-related customizations and hardcoded options could be extracted from sshfs-win to sshfs-fsp / sshfs-winfsp and sshfs-win.exe itself should be removed. In my opinion it would provide the best user experience no matter if one prefers mounting drives directly via CLI or mapping them with Explorer. What do you think?
PS I'm volunteering to help and work on this of course
billziss-gh commentedon Jul 31, 2018
The primary purpose of
sshfs-win.cis to facilitate runningsshfsthrough the WinFsp Launcher. Not everything that it does applies to command-line usage.The Launcher is a Windows service and it runs in the context of the SYSTEM account (by default). So when it launches
sshfs-winit does so in the SYSTEM context. But runningsshfsin the SYSTEM context without the proper options is not very useful, because it gives file access to the SYSTEM account, but not to the user account that started the file system.So
sshfs-win.cdetermines the user account that actually started the file system and runssshfswith the appropriateuid,gidoptions.Of course,
sshfs-win.cdoes some other things as well, like setting up the environment and default command-line parameters. For example,sshfs-win.cpasses the special option-opassword_stdout, which instructssshfsto respond OK when authentication succeeds. This is to support password-based authentication via the Explorer, etc.Having said that I can see the usefulness of an
sshfsproxy that could be used both from the WinFsp Launcher and the command line. What would the command line interface for such a utility look like in your opinion?4O4 commentedon Aug 2, 2018
When I find some spare time I will make a few experiments based on the ideas from my previous comments and the insights you have provided. If there's anything useful born in the process then I think it's gonna be the best if I come back with an initial PR and we'll continue from there :)