mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "jiri vanek (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SSHD-787) Secure trasnfer file's directoy existence is alway checked (on real FS) no metter of any other settings
Date Fri, 22 Dec 2017 12:41:00 GMT

    [ https://issues.apache.org/jira/browse/SSHD-787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16301326#comment-16301326
] 

jiri vanek commented on SSHD-787:
---------------------------------

Sure I have ScpFileOpener! That would be sad without him!  And yes, I have all the methods
implemented, but of course they can be implemented wrongly.
I agree, that recursive download for completely non fs streams is tricky. As yuo told, maybe
not accommodatable. 

Still the point is same - ScpFileOpener is generally returning streams. That means it is most
ultimate  weapon of all. As I stated, it can be even network stream, or some ram stream or
whatever. So *any* check anywhere in ScpHelper will  fail, if ScpFileOpener is supposed to
return not non FS stream. 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.

However, directory transfer is much more tricky.  The only way I see s that ScpFileOpener
will have some listing listDirectory  method, and thus, last obstacle to do any manual checks
in ScpHelper will fade away.

Current behaviour (with three  "unknown file type" in ScpHelper) is possible to walk around
by always creating te file the ScpHelper is checking, and then deleting it once it is missuesd.
You must agree that it is not nice.

Again thank you for your work on this feature up to now (not mentioning all the work on sshd-mina
at all)!

> 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)

Mime
View raw message