Add support for working directory in Server #528
Conversation
This commit switches to our fork of `pkg/sftp` which includes a Server option for changing the current working directory. Attempt to upstream: pkg/sftp#528 Supercedes and closes #4420 Fixes #3620
This commit switches to our fork of `pkg/sftp` which includes a Server option for changing the current working directory. Attempt to upstream: pkg/sftp#528 Supercedes and closes #4420 Fixes #3620
mafredri
force-pushed
the
mafredri/add-workdir-to-server
branch
from
da6a69d
to
68783f7
Compare
This commit allows the working directory for the (old) Server implementation to be changed without doing a `os.Chdir` first. The feature can be enabled with `sftp.WithServerWorkingDirectory(dir)` passed as an option to `sftp.NewServer`. It is useful when the `sftp` is used as part of a larger service that does more than just serve `sftp` and using `os.Chdir` is not an option. The fallback behavior (when the option is not specified) is that the path remains unmodified (as before).
mafredri
force-pushed
the
mafredri/add-workdir-to-server
branch
from
68783f7
to
6a7168c
Compare
|
Hi, thanks for your PR. At first glance it looks ok, but I have never user the server implementation myself. If no other contributors have time to review this PR you will have to wait a while for a proper review. Thanks for your patience. Please note that no larger refactor is planned for the request server, we just don't provide a sample implementation that uses the local filesystem but you can easily write your own implementation and it is much more customizable than the old server implementation. I'm not sure we'll continue to maintain the old server implementation in the future, maybe we'll rewrite it using the request server interfaces (and probably outside the root package) |
There was a problem hiding this comment.
As drakkan says, you should be able to just implement a raw OS RequestServer and I just don’t see the value in adding features to a deprecated implementation.
There are a large number of caveats in path handling, and making sure they’re all correct, compatible, and won’t break others is way harder than one might think.
|
Did I misinterpret what was being discussed in #407? To me it sounds like a refactor/rework of the API, and I think it sounds wonderful TBH. But it's also a reason why I wasn't looking to work with the The fact that
I appreciate the review, but I'm left wondering if I should clean up this PR or discard it? It sounds like you're not interested in merging it but I could be wrong. I tried to make sure that no code paths are altered unless this new feature is enabled so that it'd be easier to merge in, but I can understand if you don't want it at all. Edit: Made some updates anyway, happy to work on this further to get it merged, so let me know what you think/want. |
|
😐 It seems like github had been spamming out all of my draft responses. Learn from me, don’t do code review responses after a long hard day of toiling in the salt mines of legacy code… |
server.go
Outdated
| @@ -256,13 +267,14 @@ func handlePacket(s *Server, p orderedRequest) error { | |||
| rpkt = statusFromError(p.ID, err) | |||
| } | |||
| case *sshFxpOpendirPacket: | |||
| p.Path = toLocalPath(p.Path) | |||
| lp := toLocalPath(s.workDir, p.Path) | |||
There was a problem hiding this comment.
There’s another p.Path that wasn’t replaced by lp in the &sshFxpOpenPacket packet. I’d probably recommend backing out the s/lp/p.Path/ change instead.
Less change, less chance of new bug.
There was a problem hiding this comment.
I'm not sure I follow. The only other assignment to p.Path that I can find is in (*sshFxpSetstatPacket).respond.
This change was to prevent the following scenario: toLocalPath(s.workDir, toLocalPath(s.workDir, p.Path)) which happens in (*sshFxpOpenPacket).respond because of this assignment to p.Path. This becomes a problem when workDir is being used and we're not checking filepath.IsAbs, resulting in double workDir prefix on Windows and Plan 9.
There was a problem hiding this comment.
Ach so! You’re absolutely right. The toLocalPath really should be deferred in that case until the .respond happens. Nice bug catch!
|
@puellanivis thanks for the thorough PR review! I've amended most of the feedback now. The only thing I have yet to revert is #528 (comment) because doing so may introduce a bug when used with a I went ahead with refactoring |
* fix: Start SFTP sessions in user home (working directory) This commit switches to our fork of `pkg/sftp` which includes a Server option for changing the current working directory. Attempt to upstream: pkg/sftp#528 Supercedes and closes #4420 Fixes #3620 * Update fork
|
Cheers guys, It's being awesome for me to come just a week after this feature has been landed. I was seeking for it, it's not in release yet, and found this. Many thanks. |
This commit allows the working directory for the (old) Server
implementation to be changed without doing a
os.Chdirfirst.The feature can be enabled with
sftp.WithServerWorkingDirectory(dir)passed as an option to
sftp.NewServer.It is useful when the
sftpis used as part of a larger service thatdoes more than just serve
sftpand usingos.Chdiris not an option.The fallback behavior (when the option is not specified) is that the
path remains unmodified (as before).
Motivation: I know the new
sftp.RequestServeralready supports this, however, since it currently only has an in-memory filesystem and is potentially going to see a larger refactor in the future, I think it's a good idea to include it for this older implementation as well.