[
https://issues.apache.org/jira/browse/SSHD-787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16296815#comment-16296815
]
jiri vanek commented on SSHD-787:
---------------------------------
I cant reopen the issue, but loks like at elast one more mtehod (taking place
instead of if (shouldBeDir) {} statement,) is needed.
> Secure trasnfer file's directoy existence is alway checked (on real FS) no
> metter of any other settings
> -------------------------------------------------------------------------------------------------------
>
> Key: SSHD-787
> URL: https://issues.apache.org/jira/browse/SSHD-787
> Project: MINA SSHD
> Issue Type: New Feature
> Reporter: jiri vanek
> Assignee: Goldstein Lyor
> Priority: Minor
> Fix For: 1.7.0
>
>
> Hello!
> mina-sshd iss awesomely configurable tool. It is so powerful, that it
> allows programmer to provide VirtualFileSystem or even more, ScpFileOpener
> for custom stream.
> However, before any of above comes to play, the target path is checked by
> simple nio.File.exists, which successfully kills any afterwards customisations
> This is caused by following chain:
> receiveFile is called first, and alwys calls LocalFileScpTargetStreamResolver
> https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/common/scp/ScpHelper.java#L334
> This is imo the core of bug - the StreamResolver should be replaceable. Or at
> least it should take in consideration VirtualFileSystem and/or ScpFileOpener,
> ending like
> https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/common/scp/helpers/LocalFileScpTargetStreamResolver.java#L91
> or any of many checks *before* there is actual call to custom
> StreamOpener. Those checks consist from simple path,parene, path.isDirecotry
> path.isWriteable and simialr. IMho nothing of this should happen when
> custom ScpFileOpener is in play. But more likely I'm underestimating some
> security check.
> I will be happy to implement those fix if we agree on approach.
> Currnetly I have in mind possiblity of custom ScpTargetStreamResolver set in
> simialr way as StramOpener is, or fixing LocalFileScpTargetStreamResolver so
> it do nto check if custom StramOpener is in play.
> Background
> I'm usign mina as moreover simple scp-l;ike upload. Now the system where it
> runs changed dramatically, so - based on the target path - I need to store
> the file on completely different place ("backward comaptible upload:) ) or -
> in addition - to send it over network .
> Due to changes of destinations, I was unsuccessful to use VirtualFileSystem
> and in case of network forwarding I think I'm domed to StreamOpener anyway.
> Best regards
> j.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
