Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mandatory workDir even for absolute paths #549

Open
mpkondrashin opened this issue May 12, 2023 · 1 comment
Open

mandatory workDir even for absolute paths #549

mpkondrashin opened this issue May 12, 2023 · 1 comment

Comments

@mpkondrashin
Copy link

mpkondrashin commented May 12, 2023

I have faced the product (it acts as sFTP client) that accepts only absolute paths in sFTP server configuration (/file.zip and not file.zip). Issue is that even if I provide correct wordDir (by using sftp.WithServerWorkingDirectory(...)), sftp Server writes files to the root of my filesystem (C:\file.zip). There is not chance for me to change the product I am using sftp with, so question is, does it make sense to have mandatory workDir that will be added to any path, provided in put command?

I see two possible solutions:

  1. One more field ("root") should be added the the Server struct along with setting it function WithServerRootDirectory(root string)... So when addressing local files, Server will join root and path it path is absolute and root workDir and path if path is relative. This will be not breaking existing code.
  2. Change behavior of workDir and join it with provided path despite it being relative or absolute.
@puellanivis
Copy link
Collaborator

I do not see any sftp.WithServerWorkingDirectory(…) option in master, or in a PR.

The Server struct is known to be of a limited use, since it works only with the raw filesystem and has no ability to add a subdirectory option. The core problem relevant here is that getting a proper chroot to work is an infamously Difficult Problem™, and so we have actively avoided attempting to bodge this functionality into the Server implementation. If the Server does not suit ones needs, then we strongly recommend that one should move on to the RequestServer implementation, which allows for significantly more control (and more well behaved control) over how file requests are handled.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants