Skip to content

consider renaming internal ssh.exe to prevent sshfs-win picking up system tool with the same name #39

Open

Description

@mhogomchungu

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.

[1] mhogomchungu/sirikali#71

[2] mhogomchungu/sirikali#73

Activity

  1. billziss-gh commented on Jul 24, 2018

    @billziss-gh
    Collaborator

    Interesting Sshfs-win.c sets the path to /bin, so I would not have expected any issues.

    I am not sure about this, but I believe that sshfs hardcodes the ssh name, so it might not be possible to rename it (except perhaps with a patch).

    I think the correct solution is to find out why sshfs may pick up the wrong ssh at times.

  2. 4O4 commented on Jul 25, 2018

    @4O4
    Contributor

    @mhogomchungu @billziss-gh SiriKali is using sshfs.exe directly and not through the sshfs-win.exe proxy which actually sets the env

  3. mhogomchungu commented on Jul 25, 2018

    @mhogomchungu
    Author

    Which one of the two is SiriKali supposed to be using?

  4. billziss-gh commented on Jul 25, 2018

    @billziss-gh
    Collaborator

    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.

  5. 4O4 commented on Jul 25, 2018

    @4O4
    Contributor

    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?

  6. billziss-gh commented on Jul 25, 2018

    @billziss-gh
    Collaborator

    The \\sshfs ("UNC syntax") support is provided by WinFsp.

    EDIT: If you want the full story read this: WinFsp Service Architecture

  7. 4O4 commented on Jul 27, 2018

    @4O4
    Contributor

    Thanks! I'm gonna dig into it. I really like your projects, amazing job on the detailed documentation 👍

  8. billziss-gh commented on Jul 27, 2018

    @billziss-gh
    Collaborator

    Thanks :)

  9. 4O4 commented on Jul 30, 2018

    @4O4
    Contributor

    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

  10. billziss-gh commented on Jul 31, 2018

    @billziss-gh
    Collaborator

    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?

  11. 4O4 commented on Aug 2, 2018

    @4O4
    Contributor

    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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions