[ https://issues.apache.org/jira/browse/SSHD-787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16302684#comment-16302684 ]
Goldstein Lyor commented on SSHD-787: ------------------------------------- {quote} as I stated, there are three more checks in the . I would advise t remove them, or to replace them as default implementations in SCP helper. {quote} Please indicate exact line(s) > 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)