You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "jiri vanek (JIRA)" <ji...@apache.org> on 2017/12/18 16:17:00 UTC
[jira] [Comment Edited] (SSHD-787) Secure trasnfer file's directoy
existence is alway checked (on real FS) no metter of any other settings
[ https://issues.apache.org/jira/browse/SSHD-787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16295190#comment-16295190 ]
jiri vanek edited comment on SSHD-787 at 12/18/17 4:16 PM:
-----------------------------------------------------------
Hello!
I have built and tried your impl. It is doing what Is necessary to walk around hardcoded path checks.
From code scope itself, it have one disadvantage - now you have two stream openers. (two methods which opens stream for you)
Although you can say that both are making the plug on different place, they dont, You can achive all with new ScpStreamResolverFactory what is possible with old StreamOpener, but not vice versa.
Maybe time to deprecate stream opener?-)
Or to use stream opener with default method checking the path as it is, but allow to overwrite it?
Or to put streamopener to ScpStreamResolver?
If you think that the stream opener's place on world was not affected, then we are done.
Because resolve stream returns stream, I think we weills see code like
public OutputStream resolveTargetStream(Session sn, String string, long l, Set<PosixFilePermission> set, OpenOption... oos) throws IOException { return sf.getScpFileOpener().openWrite(sn, path, oos); }
prety often....
Maybe resolveTargetStream can just return tru/fasle?
Jsut thougts...
TYVM for your help on this issue!
was (Author: judovana):
Hello!
I have built and tried your impl. It is doing what Is necessary to walk around hardcoded path checks.
From code scope itself, it have one disadvantage - now you have two stream openers. (two methods which opens stream for you)
Although you can say that both are making the plug on different place, they dont, You can achive all with new ScpStreamResolverFactory what is possible with old StreamOpener, but not vice versa.
Maybe time to deprecate stream opener?-)
Or to use stream opener with default method checking the path as it is, but allow to overwrite it?
Or to put streamopener to ScpStreamResolver?
If you think that the stream opener's place on world was not affected, then we are done.
Because resolve stream returns stream, I think we weills ee code like
public OutputStream resolveTargetStream(Session sn, String string, long l, Set<PosixFilePermission> set, OpenOption... oos) throws IOException { return sf.getScpFileOpener().openWrite(sn, path, oos); }
prety often....
Maybe resolveTargetStream can just return tru/fasle?
Jsut thougts...
TYVM for your help on this issue!
> 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
>
> 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)