[
https://issues.apache.org/jira/browse/SSHD-787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16300311#comment-16300311
]
Goldstein Lyor commented on SSHD-787:
-------------------------------------
{quote} Recursive requests still calls not-overwritable methods{quote}
I don't see how this can happen - *everything* goes through the opener - please
provide an exact example of the flow, how it behaves and how you think it
should behave (no promises that we can accommodate it...). Furthermore, are you
sure you are using the latest https://github.com/apache/mina-sshd/ clone
version ?
> 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)
