[jira] [Comment Edited] (VFS-630) Sftp code assumes that exec channels are available and *nix server

["Gary D. Gregory (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/VFS-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17085928#comment-17085928 ] 

Gary D. Gregory edited comment on VFS-630 at 4/17/20, 4:47 PM:
---------------------------------------------------------------

Definitively do not "rip it out", you'll want to add a toggle, see {{org.apache.commons.vfs2.provider.sftp.SftpFileSystemConfigBuilder}} and the {{DISABLE_DETECT_EXEC_CHANNEL}} option.

The preferred format is a PR on GitHub at [https://github.com/apache/commons-vfs |https://github.com/apache/commons-vfs]on top of git master. 


was (Author: garydgregory):
Definitively do not "rip it out", you'll want to add a toggle, see 

The preferred format is a PR on GitHub at [https://github.com/apache/commons-vfs |https://github.com/apache/commons-vfs]on top of git master. see {{org.apache.commons.vfs2.provider.sftp.SftpFileSystemConfigBuilder}} and the {{DISABLE_DETECT_EXEC_CHANNEL}} option.

> Sftp code assumes that exec channels are available and *nix server
> ------------------------------------------------------------------
>
>                 Key: VFS-630
>                 URL: https://issues.apache.org/jira/browse/VFS-630
>             Project: Commons VFS
>          Issue Type: Bug
>    Affects Versions: 2.1
>         Environment: Any client running VFS 2.1/JSch 1.51 and later using remote sftp server that's locked down or not *nix based.
>            Reporter: Will Wood
>            Priority: Minor
>
> In working with VFS using SFTP there's an assumption in the code that creates a problem if the remote server is locked down or it's not *nix based.  I hit this when working with a server that had exec commands disabled and attempting to do a moveTo command on a remote file object renaming it to the same server as a remote file object.  At one point the VFS code attempts to execute an "id -G" command on a JSch "exec" channel. Since the remote server disallows the exec command the subsequent read from the input stream blocks until the O/S default socket timeout occurs, it basically hangs.
> I tested this same scenario against a Linux server, it worked fine.  I also tested a Windows server which doesn't have an id command, it failed.
> Since JSch deals with this natively, I would recommend getting rid of the exec commands altogether and letting the client deal with those issues outside of the framework, i.e., moveTo in this case doesn't need to worry about permissions but rather throws the underlying exceptions from JSch.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)