[
https://issues.apache.org/jira/browse/SSHD-787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16302815#comment-16302815
]
Goldstein Lyor commented on SSHD-787:
-------------------------------------
{quote}
It is getting complex
{quote}
Not really (IMO)
{quote}
And various usages of Path are still there.
{quote}
That's the whole idea - _Path_ is the standard interface used by the SSHD code
to access files (SCP, SFTP) and it will remain so in the near future - we have
no plans to provide a special wrapper (like it was in v1.0). Since as you say
{quote}
you may end in wrapping every call to Files inisde ScpFile opener
{quote}
and we don't want that.
{quote}
I'm afraid, how those changes affects security in Virtual FSs already provided
by Mina.
{quote}
It shouldn't affect VFS - although I believe I have reached the limit of can be
done as an _evolution_ rather than a _revolution_ of the {{SCPHelper}} code. If
that is not enough for your needs - then I'm afraid the only avenue left for
you is to implement your own {{FileSystem, FileSystemProvider, Path}} - a
complex task, though not insurmountable (see the {{SshFileSystemProvider}}).
> 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)
